RE: NAT64 in RA, draft-ietf-6man-ra-pref64

"Mudric, Dusan (Dusan)" <dmudric@avaya.com> Tue, 09 July 2019 20:12 UTC

Return-Path: <dmudric@avaya.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DBF712006D; Tue, 9 Jul 2019 13:12:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.699
X-Spam-Level:
X-Spam-Status: No, score=-6.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=avaya365.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WJw9O_V0LRhY; Tue, 9 Jul 2019 13:12:17 -0700 (PDT)
Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CEBEB12001B; Tue, 9 Jul 2019 13:12:16 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A2FHAAC29CRd/yYyC4dmHAEBAQQBAQcEAQGBVQUBAQsBgUNQbXUEMwqEEoNHA4UxiRqCW4UpNYNuAY8nFIEQAxgXJQkBAQENASAJBAIBAQKEPgIXglA2Bw4BAwEBAQQBAQEBBAECAmmFPAyCeE0vCgIvAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQUCDQIpHgEBGAEBAQECARIRHQEBLAsBBAcEAgEIDgMEAQEBKgICAh8RHQgCBA4FCAYNB4MBgWoDDg8BAgIKoToCgQgwiF8BAXCBMhqCNSoBAQV1hAsNC4ILBwkJAYEqAYhBgzSBQT6BEUaCTD6CGkcEGIELJhg8gkwygiaMHoJShH2BCpRyLUAJAoIXgyuDK4k8hA6CLG2GNIN5A4o3lHGBc44KAgICAgQFAg4BAQWBVgEygVhwFTuCbAmCOAwXg06EWYV6cgEBE4EUjQ4BgSABAQ
X-IPAS-Result: A2FHAAC29CRd/yYyC4dmHAEBAQQBAQcEAQGBVQUBAQsBgUNQbXUEMwqEEoNHA4UxiRqCW4UpNYNuAY8nFIEQAxgXJQkBAQENASAJBAIBAQKEPgIXglA2Bw4BAwEBAQQBAQEBBAECAmmFPAyCeE0vCgIvAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQUCDQIpHgEBGAEBAQECARIRHQEBLAsBBAcEAgEIDgMEAQEBKgICAh8RHQgCBA4FCAYNB4MBgWoDDg8BAgIKoToCgQgwiF8BAXCBMhqCNSoBAQV1hAsNC4ILBwkJAYEqAYhBgzSBQT6BEUaCTD6CGkcEGIELJhg8gkwygiaMHoJShH2BCpRyLUAJAoIXgyuDK4k8hA6CLG2GNIN5A4o3lHGBc44KAgICAgQFAg4BAQWBVgEygVhwFTuCbAmCOAwXg06EWYV6cgEBE4EUjQ4BgSABAQ
X-IronPort-AV: E=Sophos;i="5.63,471,1557201600"; d="scan'208";a="355778853"
Received: from mailauth.avaya.com (HELO p-us1-erheast-smtpauth.us1.avaya.com) ([135.11.50.38]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 09 Jul 2019 16:11:49 -0400
X-OutboundMail_SMTP: 1
Received: from unknown (HELO AZ-US1EXHC01.global.avaya.com) ([135.11.85.12]) by p-us1-erheast-out.us1.avaya.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 09 Jul 2019 16:11:48 -0400
Received: from PW365VMAP01.avaya.com (135.11.29.21) by az-us1exhc01.global.avaya.com (135.11.85.12) with Microsoft SMTP Server (TLS) id 14.3.408.0; Tue, 9 Jul 2019 16:11:48 -0400
Received: from NAM03-BY2-obe.outbound.protection.outlook.com (104.47.42.50) by PW365VMAP01.avaya.com (135.11.29.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1531.3; Tue, 9 Jul 2019 15:11:48 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=bhE1zx3zBE3cfIXVighFEH3dr5Edd3XQncyJr8nzhz9TPgYDneAJwKa5DRLvImiYw718qxe09C5mRbxFiYdJsND8R8JyFHq1xkIzlslnXJ6geWq1UsBaRA+DE5Al4ic9r7nArGz2YiVtlez0PgHcD7/6lqi6g8rEn6CHp+PfruDfo7BfOYst6/KgU6h6nMZn6UGocvlawFIggotr6zvz89j+E4te8BsJu1tw6OMAsT1igLTR+DErEzG83PHfjMi7H0TZe1XfTxB2VijojLkONb9pCopo1sYiS7Vg04/FUQ1ktdwDomUQudpTqYc3PGMyROMzihgkM08cFgsDBPPSbA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=NH2eQorqJcq5RCTK9gQyUwNXsQvOkju6yy+yvLjSbAo=; b=c4g8EsXy99D9TBhDVlvN3gf/9ZO72WkdGagGyL3vXMsVlQIQfShmue8Dr+KwWwgKlvS55DbKkXYrNqUIjLCdf+nVbpp92h7vsW1ugSJU70lnGWpXUGqxyoOoTaRfWCSAeWNrpXyPtvot2wacvv3IZTaaPNXYEx31zF1nj0B9hCQmJdC5KdtZohqb05LZRawBpu2xB84XUnNTbs1+o3oH3gvrrF7xBKs96ZJLs/3P8Sp8tLyRXSDA9tPc3kEsvrtiS+wezyHJE2FAoo+WSw2x4Lz0TM0kLhDzgmBYKLNO25lDceto3PSimigNNTEx7GNl7VU38wAtcmqZ8RTRuuM8/g==
ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=avaya.com;dmarc=pass action=none header.from=avaya.com;dkim=pass header.d=avaya.com;arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Avaya365.onmicrosoft.com; s=selector1-Avaya365-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=NH2eQorqJcq5RCTK9gQyUwNXsQvOkju6yy+yvLjSbAo=; b=nc7GoQKoWpwI97tQ+F/dV7bRAfkDBpjA+uBSX4S03GG/kprjO5UW78I5JnxAaP0jKeuwRsmGCwV2b2dJrqFjKVDCfcwUA+Zbldbq/b6F0uQP0BQsysmYCErhMmVL9CCPXupEYKTgLLQeNebdSvKSuwqKP3mhBNON2PnYhZcH6/k=
Received: from DM6PR15MB2506.namprd15.prod.outlook.com (20.176.71.32) by DM6PR15MB2473.namprd15.prod.outlook.com (20.176.71.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2073.10; Tue, 9 Jul 2019 20:11:47 +0000
Received: from DM6PR15MB2506.namprd15.prod.outlook.com ([fe80::e0dd:fb47:323c:d5ac]) by DM6PR15MB2506.namprd15.prod.outlook.com ([fe80::e0dd:fb47:323c:d5ac%7]) with mapi id 15.20.2052.020; Tue, 9 Jul 2019 20:11:47 +0000
From: "Mudric, Dusan (Dusan)" <dmudric@avaya.com>
To: Jen Linkova <furry13@gmail.com>
CC: "Manfredi (US), Albert E" <albert.e.manfredi@boeing.com>, IPv6 Operations <v6ops@ietf.org>, 6man <6man@ietf.org>
Subject: RE: NAT64 in RA, draft-ietf-6man-ra-pref64
Thread-Topic: NAT64 in RA, draft-ietf-6man-ra-pref64
Thread-Index: AQHVNfZfQTP2spnzX0G8BrvKPAtN5qbCtR3w
Date: Tue, 09 Jul 2019 20:11:47 +0000
Message-ID: <DM6PR15MB2506825AA181439E4151DD74BBF10@DM6PR15MB2506.namprd15.prod.outlook.com>
References: <DM6PR15MB2506C03D1D88F2785B5016C1BBFB0@DM6PR15MB2506.namprd15.prod.outlook.com> <675D1F10-02FF-4AB4-88E3-5A0D95A34ABF@gmail.com> <DM6PR15MB250640D3141DCB2C64789B95BBFA0@DM6PR15MB2506.namprd15.prod.outlook.com> <CAFU7BAROif-44uFy1+oiutsQLiFOa09jM1Ve_8qaqpr1TPLGyQ@mail.gmail.com> <DM6PR15MB2506ABCBD8457003114E60EBBBF50@DM6PR15MB2506.namprd15.prod.outlook.com> <d4d2f637b80544708def95dd77af4d81@boeing.com> <DM6PR15MB2506F92308CA8DA8921BA0A5BBF60@DM6PR15MB2506.namprd15.prod.outlook.com> <CAFU7BAQSUsDWFu6QGP4K4g+XAQAO5G23F+Z7jC5f=wu-Cvj=Vw@mail.gmail.com>
In-Reply-To: <CAFU7BAQSUsDWFu6QGP4K4g+XAQAO5G23F+Z7jC5f=wu-Cvj=Vw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=dmudric@avaya.com;
x-originating-ip: [104.129.196.166]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 6d6d82ac-be4e-4edb-3c13-08d704a9abd5
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(7168020)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(49563074)(7193020); SRVR:DM6PR15MB2473;
x-ms-traffictypediagnostic: DM6PR15MB2473:
x-ms-exchange-purlcount: 1
x-microsoft-antispam-prvs: <DM6PR15MB2473D6051F06C7AB2431F793BBF10@DM6PR15MB2473.namprd15.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:260;
x-forefront-prvs: 0093C80C01
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(136003)(396003)(346002)(376002)(366004)(39860400002)(13464003)(199004)(189003)(25786009)(81156014)(1411001)(81166006)(9686003)(99936001)(6306002)(66616009)(66476007)(66556008)(8676002)(68736007)(4326008)(66446008)(64756008)(55016002)(76116006)(476003)(6916009)(486006)(66946007)(316002)(54906003)(5660300002)(14444005)(3846002)(478600001)(6116002)(5024004)(52536014)(256004)(8936002)(966005)(66066001)(19627235002)(6436002)(71190400001)(76176011)(229853002)(7736002)(71200400001)(55236004)(53546011)(99286004)(33656002)(7696005)(86362001)(6506007)(14454004)(102836004)(305945005)(446003)(26005)(11346002)(186003)(2906002)(74316002)(53936002)(6246003); DIR:OUT; SFP:1101; SCL:1; SRVR:DM6PR15MB2473; H:DM6PR15MB2506.namprd15.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: avaya.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: z+k0J/Zrpojl8C4LLHwfj8mjMDIpOhgm6TqehQO6WBR+702gyn0o1wl3ZRzROTE5d6OMRXu+7kH5IvijIsPoZoGXBqfT6ctqndJgHNtpkEoMeTaSvXUvDCpoMnVDoIRj+Y3an1JJZFSmFkSlcRtrkv4CAkuo7CMUSSkw+5Cj3Y8m22ncjl0tl0me1pbc1c7w+EgLEfFsc3OGDf7ukxuxDxQxOq8vhPWcB/m/S7OM2UNtPAtKGbA2XAqkZI1TwxUer7bRFmZqmlwab7Fqmcm/1WvrvV2TWbbPAFv2cPUs8k21lYWMT6gKiAW20sIyIqM7+alXpfT1VgfaHXi0G2oMjt+b3DMDhM1Ev5BYwy9nvKhNH7mEQ9983cSi7KunPfE9E0ws4wjNizP66fqGSJwFhk84sBTUJgf3lqw04hMX7hU=
Content-Type: multipart/mixed; boundary="_002_DM6PR15MB2506825AA181439E4151DD74BBF10DM6PR15MB2506namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 6d6d82ac-be4e-4edb-3c13-08d704a9abd5
X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Jul 2019 20:11:47.2148 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 04a2636c-326d-48ff-93f8-709875bd3aa9
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: dmudric@avaya.com
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR15MB2473
X-OriginatorOrg: avaya.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/Jmxa-Itqnr2dvJRuhoCYE6iqzXs>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 09 Jul 2019 20:12:20 -0000

Thanks Jen. 

In your example " IPv4-only client needs to talk to the Ipv6-only server". If IPv4-only client needs to talk to the Ipv6-only client, the call flow will be the same? In the other direction, IPv6-only client calling IPv4-only client needs to use DNS64/NAT64, as in your previous example (attached). This means, for bi-directional communication NAT46/DNS46 and NAT64/DNS64 need to be used (may be my terminology is not quite correct). 

However, Jordi said that the problem is not fully solved yet ("the *actual* implementation of 464XLAT/NAT64 doesn't allow IPv4-only hosts to connect to IPv6-only hosts.") and he is writing draft-palet-v6ops-464xlat-opt-cdn-caches. What is in the current technology that prevents bi-directional call flow between IPv4-ony and IPv6-only hosts?

Dusan

> -----Original Message-----
> From: Jen Linkova <furry13@gmail.com>
> Sent: Monday, July 8, 2019 9:34 PM
> To: Mudric, Dusan (Dusan) <dmudric@avaya.com>
> Cc: Manfredi (US), Albert E <albert.e.manfredi@boeing.com>; IPv6
> Operations <v6ops@ietf.org>; 6man <6man@ietf.org>
> Subject: Re: NAT64 in RA, draft-ietf-6man-ra-pref64
> 
> On Tue, Jul 9, 2019 at 1:50 AM Mudric, Dusan (Dusan) <dmudric@avaya.com>
> wrote:
> > [Dusan] What if IPv4only client needs to initiate the session to IPv6only
> client? What is the solution for that use case?
> 
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__tools.ietf.org_html_rfc7755&d=DwIBaQ&c=BFpWQw8bsuKpl1SgiZH64Q
> &r=UT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=_cWRsdzof5dXI
> 9yTQH51H_KHtcSRcMAtARArKVcdnWM&s=wDxWEwS-e-N-I0oAfcdi-
> 5GucNiCQpR32t9Rw4RZyn0&e= mentioned before.
> 
> IPv4-only client -- IPv4-enabled network--- SIIT translator ---- IPv6-only LAN -
> -- IPv6-only server.
> 
> Let's say  your IPv4-only client needs to talk to the Ipv6-only server, ipv6-
> only.example.net.
> For this to happen the owner of the Ipv6-only server needs to configure the
> translator (SIIT box in the diagram above).
> The owner would create a DNS A RR for  ipv6-only.example.net. - let's say,
> 192.0.2.2 Ipv6-only server would have an IPv6 address which has that IPv4
> address encoded - for example, 2001:db8:1::192.0.2.2 That IPv4 address (or
> the prefix most likely) will be routed to the translator.
> 
> So your Ipv4-only client sends a DNS request to resolve ipv6-
> only.example.net, gets 192.0.2.2 back, sends a packet to 192.0.2.2.
> The packet reaches the translator. The translator translates IPv4 packet to
> IPv6 packet and sends it to the server (note that the destination IPv6 address
> can be easily constructed as the translator knows the prefix and just adds the
> IPv4 address - 192.0.2.2 - to that prefix to get the destination IPv6 address.
> IPv6 source address is synthesised in the same way from the client IPv4
> address).
> 
> Here is a nice talk Tore Anderson gave at RIPE 7 years ago:
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__ripe64.ripe.net_presentations_67-2D20120417-2DRIPE64-2DThe-
> 5FCase-5Ffor-5FIPv6-5FOnly-5FData-
> 5FCentres.pdf&d=DwIBaQ&c=BFpWQw8bsuKpl1SgiZH64Q&r=UT3Bk9cbLeaJ
> xhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=_cWRsdzof5dXI9yTQH51H_KHtcS
> RcMAtARArKVcdnWM&s=GsPTdPr_ZwWYK13LIrhTv9rYM6dYJfgbT8HtLwVRk
> Zo&e=
> 
> 
> 
> > > For IPv4 to IPv6, if you must allow the IPv4 client to initiate the
> > > session, you'd have to have preconfigure something.
> > [Dusan] Where and how is this configuration done?
> 
> On the translator which connects IPv6-only network to dual-stack/IPv4-only
> one.
> In general, when you need to let one protocol talk to another, you'd have a
> point (or the edge) where those two networks meet each other.
> Usually you'd have a box (or boxes) interconnecting them - quite often it's
> exactly the box you'd need to configure ;)
> 
> --
> SY, Jen Linkova aka Furry
--- Begin Message ---
Hi Dusan,

On Fri, Jul 5, 2019 at 6:19 AM Mudric, Dusan (Dusan) <dmudric@avaya.com> wrote:
> What is the best reference document for a Translator that facilitates:
>
> - IPv4only - to - IPv6only, and

https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc7755&d=DwIBaQ&c=BFpWQw8bsuKpl1SgiZH64Q&r=UT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=rXn-qcfSIhjB1FVZq9fT0HWKIE4FsVW55Pw4ufcd4Qc&s=6jgy81ePeiWaBFML3XwPC3wDxGkyDrvzWG0Jg9Oog_w&e=

> - IPv6only - to - IPv4Only

https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc6146&d=DwIBaQ&c=BFpWQw8bsuKpl1SgiZH64Q&r=UT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=rXn-qcfSIhjB1FVZq9fT0HWKIE4FsVW55Pw4ufcd4Qc&s=SobSFuvzPm9XQ3bWhSELbnhk4KtAaYJ7yB5QWf70A6A&e=

> clients message exchanges?
>
> Is this communication bidirectional or works only from IPv6only-to-IPv4only client (meaning IPv6only client has to initiate the communication)?
>
> How can Translator or DNS64 tell IPv6 only client the IP of IPv4 only client, and vice versa?

In a nutshell:

IPv6-only client asks DNS64 server for AAAA for, let's say, ipv4only.example.net
As that server is IPv4-onl, does not have AAAA RR, the DNS64 server
synthesise a new AAAA using an IPv6 prefix (usually /96 - the
Well-Known Prefix is 64:ff9b::/96) and IPv4 address from the A
RR. The algorithm described in rfc6147

So if ipv4only.example.net has an IPv4 address 192.0.2.2, then DNS64
will return 64:ff9b::192.0.2.2 as AAAA RR.
The ipv6-only client would initiate a connection to that address . As
NAT64 prefix is supposed to be routed to the NAT64 device, that device
would translate IPv6 packet to IPv4 packet using the algorithm
described in https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc6052&d=DwIBaQ&c=BFpWQw8bsuKpl1SgiZH64Q&r=UT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=rXn-qcfSIhjB1FVZq9fT0HWKIE4FsVW55Pw4ufcd4Qc&s=XTCYMjY3HOKEx535PU_IOra8JAiRD_Uayt1SwrJnWv8&e=.


> > -----Original Message-----
> > From: Fred Baker <fredbaker.ietf@gmail.com>
> > Sent: Wednesday, July 3, 2019 3:32 PM
> > To: Mudric, Dusan (Dusan) <dmudric@avaya.com>
> > Cc: 6man <6man@ietf.org>; IPv6 Operations <v6ops@ietf.org>
> > Subject: Re: NAT64 in RA, draft-ietf-6man-ra-pref64
> >
> >
> >
> > > On Jul 3, 2019, at 12:01 PM, Mudric, Dusan (Dusan) <dmudric@avaya.com>
> > wrote:
> > >
> > > [Dusan] Please clarify how IPv4-only host can reach IPv6 only host, and vice
> > versa. Also, how IPv6 only host can know IPv4 address of IPv4 only host,
> > assuming IPv4 only host is in a public domain?
> >
> > Simple. Using a Translator, either at layer 3 or above it. Any other way
> > doesn't work.
> > --------------------------------------------------------------------------------
> > The fact that there is a highway to hell and a stairway to heaven is an
> > interesting comment on projected traffic volume...
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_ipv6&d=DwIBaQ&c=BFpWQw8bsuKpl1SgiZH64Q&r=UT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=rXn-qcfSIhjB1FVZq9fT0HWKIE4FsVW55Pw4ufcd4Qc&s=GHcNdEhtOVJ_cLvOIIb6oNNDJIgpb8m_oqHiePqYicg&e=
> --------------------------------------------------------------------



--
SY, Jen Linkova aka Furry
--- End Message ---