Subject: Re: [v6ops] NAT64 in RA, draft-ietf-6man-ra-pref64

From: "Mudric, Dusan (Dusan)" <[email-masked]>
Date: Wed, 3 Jul 2019 19:01:51 +0000

> 
> On Tue, Jul 2, 2019 at 9:49 AM Jen Linkova <[email-masked]> wrote:
> 
> > I've been told that an IPv6-only
> > host might want to exclude some addresses from synthesis and use IPv4
> > to reach them, so I'm trying to understand how *an IPv6-only* host
> > (which, IMHO, can only use IPv6) reach anything using IPv4.
> >
> 
> Right. That was the gist of my earlier comment. I believe we all agree that
> in the most common deployment scenario (i.e., an IPv6-only host with no
> IPv4), an exclusion list is not useful, because the host really can't reach
> anything that's not reachable via IPv6.
> 

> From: v6ops <[email-masked]> On Behalf Of JORDI PALET
> MARTINEZ
>     And, oh yes, someone using IPv4 (or X.25, or SNA) could go through a
> translator and communicate with an IPv6-only host in such a domain. It's
> IPv6-only up to that translator.

[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?

---

From: Fred Baker <[email-masked]>
Date: Wed, 3 Jul 2019 12:32:14 -0700

> On Jul 3, 2019, at 12:01 PM, Mudric, Dusan (Dusan) <[email-masked]> wrote:
> 

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...

---

From: "Mudric, Dusan (Dusan)" <[email-masked]>
Date: Thu, 4 Jul 2019 20:19:07 +0000

What is the best reference document for a Translator that facilitates:

- IPv4only - to - IPv6only, and
- IPv6only - to - IPv4Only 
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?

Thanks,
Dusan.

> -----Original Message-----
> From: Fred Baker <[email-masked]>
> Sent: Wednesday, July 3, 2019 3:32 PM
> To: Mudric, Dusan (Dusan) <[email-masked]>
> Cc: 6man <[email-masked]>; IPv6 Operations <[email-masked]>
> Subject: Re: NAT64 in RA, draft-ietf-6man-ra-pref64
> 
> 
> 
> > [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?
> 
> The fact that there is a highway to hell and a stairway to heaven is an
> interesting comment on projected traffic volume...

---

From: Jen Linkova <[email-masked]>
Date: Fri, 5 Jul 2019 12:21:25 +1000

Hi Dusan,

> - IPv4only - to - IPv6only, and

https://tools.ietf.org/html/rfc7755

> - IPv6only - to - IPv4Only

https://tools.ietf.org/html/rfc6146

> 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://tools.ietf.org/html/rfc6052.

> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

-- 
SY, Jen Linkova aka Furry

---

From: "Mudric, Dusan (Dusan)" <[email-masked]>
Date: Fri, 5 Jul 2019 19:16:06 +0000

Hi Jen,

If IPv4only - to - IPv6only client initiated communication needs SIIT-DC (rfc7755), and IPv6only - to - IPv4Only client initiated communication needs Stateful NAT64 (rfc6146), can the two protocols be combined in two device (DNS and  translator) and used at the same time for bidirectional communication? Is it called NAT64-NAT46 or something similar?

- How can DNS64 tell IPv6 only client the IP of IPv4 only client, and vice versa? Is DNS64 server returning IPv4ony client address to IPv6only client, using the A RR? 
- How can IPv4only client get the address of IPv6only client (or, it is impossible for IPv4only client to get IPv6 address of IPv6only client)? 
- Do these IPv4 and IPv6 client addresses need to be pre-configured on the translator and/or DNS64?

Thanks,
Dusan.

> From: Jen Linkova <[email-masked]>
> Sent: Thursday, July 4, 2019 10:21 PM
> Cc: Fred Baker <[email-masked]>; IPv6 Operations
> <[email-masked]>; 6man <[email-masked]>
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__tools.ietf.org_html_rfc7755&d=DwIBaQ&c=BFpWQw8bsuKpl1SgiZH64Q
> &r=UT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=rXn-
> qcfSIhjB1FVZq9fT0HWKIE4FsVW55Pw4ufcd4Qc&s=6jgy81ePeiWaBFML3XwP
> C3wDxGkyDrvzWG0Jg9Oog_w&e=
> 
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__tools.ietf.org_html_rfc6146&d=DwIBaQ&c=BFpWQw8bsuKpl1SgiZH64Q
> &r=UT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=rXn-
> qcfSIhjB1FVZq9fT0HWKIE4FsVW55Pw4ufcd4Qc&s=SobSFuvzPm9XQ3bWhSEL
> bnhk4KtAaYJ7yB5QWf70A6A&e=
> 
> > Is this communication bidirectional or works only from IPv6only-to-IPv4only
> client (meaning IPv6only client has to initiate the communication)?
> >
> 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.
> 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_I
> Ora8JAiRD_Uayt1SwrJnWv8&e=.
> 
> 
> > > > On Jul 3, 2019, at 12:01 PM, Mudric, Dusan (Dusan)
> > > > <[email-masked]>
> > > wrote:
> > > >
> > > versa. Also, how IPv6 only host can know IPv4 address of IPv4 only
> > > host, assuming IPv4 only host is in a public domain?
> > >
> > > ------------ The fact that there is a highway to hell and a stairway
> > > to heaven is an interesting comment on projected traffic volume...
> >
> > Administrative Requests:
> > https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_mail
> >
> man_listinfo_ipv6&d=DwIBaQ&c=BFpWQw8bsuKpl1SgiZH64Q&r=UT3Bk9cbL
> eaJxhf3
> > iCrhIoUWB8YLZU23029sMQGQ2kY&m=rXn-
> qcfSIhjB1FVZq9fT0HWKIE4FsVW55Pw4ufcd
> > 4Qc&s=GHcNdEhtOVJ_cLvOIIb6oNNDJIgpb8m_oqHiePqYicg&e=

---

From: "Manfredi (US), Albert E" <[email-masked]>
Date: Fri, 5 Jul 2019 20:11:11 +0000

-----Original Message-----
From: ipv6 <[email-masked]> On Behalf Of Mudric, Dusan (Dusan)

> - How can DNS64 tell IPv6 only client the IP of IPv4 only client, and vice versa?

IPv6 to IPv4 should be straightforward, because it's a one-to-one relationship. The other way around would normally not work, but everyone has been accustomed to that with IPv4 NAPT already. The client behind the NAPT initiates.

> Is DNS64 server returning IPv4ony client address to IPv6only client, using the A RR?

The DNS synthesizes the IPv6 address, which has the IPv4 address embedded in it.

> - How can IPv4only client get the address of IPv6only client (or, it is impossible for IPv4only client to get IPv6 address of IPv6only client)?

That's clearly more difficult, which is why the normal course of action is for the IPv6 client to initiate the session.

> - Do these IPv4 and IPv6 client addresses need to be pre-configured on the translator and/or DNS64?

For IPv4 to IPv6, if you must allow the IPv4 client to initiate the session, you'd have to have preconfigure something.

Bert

---

From: "Mudric, Dusan (Dusan)" <[email-masked]>
Date: Mon, 8 Jul 2019 15:49:21 +0000

> From: Manfredi (US), Albert E <[email-masked]>
> 
> IPv6 to IPv4 should be straightforward, because it's a one-to-one
> relationship. The other way around would normally not work, 
[Dusan] There is no solution for IPv4only client to reach IPv6only client? 

> but everyone
> has been accustomed to that with IPv4 NAPT already. 
[Dusan] How IPv4 only users (e.g. Avaya IPv4 only phones) can be accustomed not to be able to call IPv6only users (like Apple IPv6 only phones)?

>The client behind the
> NAPT initiates.
> > - How can IPv4only client get the address of IPv6only client (or, it is
> impossible for IPv4only client to get IPv6 address of IPv6only client)?
> 
[Dusan] What if IPv4only client needs to initiate the session to IPv6only client? What is the solution for that use case?

> have to have preconfigure something.
[Dusan] Where and how is this configuration done?

---

From: Gert Doering <[email-masked]>
Date: Mon, 8 Jul 2019 18:07:29 +0200

Hi,

> [Dusan] There is no solution for IPv4only client to reach IPv6only client? 

Of course there is - upgrade the IPv4-only client to do IPv6, and
get rid of all the translator stuff.

> [Dusan] How IPv4 only users (e.g. Avaya IPv4 only phones) can be accustomed not to be able to call IPv6only users (like Apple IPv6 only phones)?

SIP stuff usually goes via a media gateway / session border controller
anyway.  That gateway would be dual-stacked then.

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                      Vorstand: Sebastian v. Bomhard, Michael Emmer
Joseph-Dollinger-Bogen 14        Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                 HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444         USt-IdNr.: DE813185279

---

From: "Mudric, Dusan (Dusan)" <[email-masked]>
Date: Mon, 8 Jul 2019 16:21:30 +0000

> From: Gert Doering <[email-masked]>
> Sent: Monday, July 8, 2019 12:07 PM
> Cc: Manfredi (US), Albert E <[email-masked]>; IPv6
> Operations <[email-masked]>; 6man <[email-masked]>
> Subject: Re: [v6ops] NAT64 in RA, draft-ietf-6man-ra-pref64
> 
> Hi,
> 
> Of course there is - upgrade the IPv4-only client to do IPv6, and get rid of all
> the translator stuff.
[Dusan] The question was not about IPv6only client reaching IPv6only client. The question was about IPv4only client in IPv4only network reaching IPv6only client in IPv6only network. Which translation technology provides a solution for that?

> > [Dusan] How IPv4 only users (e.g. Avaya IPv4 only phones) can be
> accustomed not to be able to call IPv6only users (like Apple IPv6 only
> phones)?
> 
[Dusan] Imposing all enterprises to immediately upgrade to dual networks, to be able to talk to IPV6only devices, is not a realist request. The question is what is the translation technology that makes IPv4only client and gateway in IPv4only network, interwork with IPv6only client in IPv6only network?

---

From: David Farmer <[email-masked]>
Date: Mon, 8 Jul 2019 11:57:01 -0500

On Mon, Jul 8, 2019 at 10:49 AM Mudric, Dusan (Dusan) <[email-masked]>
wrote:

> > > - How can DNS64 tell IPv6 only client the IP of IPv4 only client, and
> vice
> > versa?
> >

I mostly say, so what! It is an unfortunate reality of today's Internet,
because of NAT44 and/or stateful firewall default deny inbound policy, many
times clients can't speak to other clients, be they IPv4 only, IPv6 only,
or even dual stack. Sometimes firewall traversal technologies can work
around this, also depending on the firewall traversal solution used
sometimes IPv4 only and IPv6 only clients will be able to talk to each
other.  My guess is that IPv4 only to IPv6 only firewall traversal would be
less effective than NAT44 client to NAT44 client firewall traversal, but it
is should still be possible in some cases.

> accustomed not to be able to call IPv6only users (like Apple IPv6 only

They may not be able to talk peer to peer. However, through a dual-stack
SIP or other proxies/session border controller, they could probably
complete a call.

> >The client behind the
> > NAPT initiates.
> >
> > > Is DNS64 server returning IPv4ony client address to IPv6only client,
> using
> > the A RR?
> >
> > That's clearly more difficult, which is why the normal course of action
> is for
> > the IPv6 client to initiate the session.
> [Dusan] What if IPv4only client needs to initiate the session to IPv6only
> client? What is the solution for that use case?
>

Many firewall traversal solutions should work in this case, but IPv4 only
client to client isn't guaranteed to work in all cases either.

> >
> > > - Do these IPv4 and IPv6 client addresses need to be pre-configured on
> the
> > translator and/or DNS64?
> >
> > For IPv4 to IPv6, if you must allow the IPv4 client to initiate the
> session, you'd
> > have to have preconfigure something.

-- 
===============================================
David Farmer               Email:[email-masked]
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE        Phone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Mon, 08 Jul 2019 23:39:58 +0200

I think there are several possible solutions, but the simpler one seems to be the dual-stack SIP proxies. Another one is draft-ietf-tram-turnbis, which I didn’t knew, until today, is already in the IESG for approval this Thrusday.

Also it can be done with EAM and also as I mention in a previous email via the optimization for 464XLAT. Just uploaded the new version:

https://datatracker.ietf.org/doc/draft-palet-v6ops-464xlat-opt-cdn-caches/?include_text=1

 

El 8/7/19 19:01, "v6ops en nombre de David Farmer" <[email-masked] en nombre de [email-masked]> escribió:

I mostly say, so what! It is an unfortunate reality of today's Internet, because of NAT44 and/or stateful firewall default deny inbound policy, many times clients can't speak to other clients, be they IPv4 only, IPv6 only, or even dual stack. Sometimes firewall traversal technologies can work around this, also depending on the firewall traversal solution used sometimes IPv4 only and IPv6 only clients will be able to talk to each other.  My guess is that IPv4 only to IPv6 only firewall traversal would be less effective than NAT44 client to NAT44 client firewall traversal, but it is should still be possible in some cases. 

They may not be able to talk peer to peer. However, through a dual-stack SIP or other proxies/session border controller, they could probably complete a call. 

Many firewall traversal solutions should work in this case, but IPv4 only client to client isn't guaranteed to work in all cases either. 

 

-- 

_______________________________________________ v6ops mailing list [email-masked] https://www.ietf.org/mailman/listinfo/v6ops 

**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.

---

From: Jen Linkova <[email-masked]>
Date: Tue, 9 Jul 2019 11:33:55 +1000

> [Dusan] What if IPv4only client needs to initiate the session to IPv6only client? What is the solution for that use case?

https://tools.ietf.org/html/rfc7755 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://ripe64.ripe.net/presentations/67-20120417-RIPE64-The_Case_for_IPv6_Only_Data_Centres.pdf

> [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 ;)

---

From: "Mudric, Dusan (Dusan)" <[email-masked]>
Date: Tue, 9 Jul 2019 20:03:26 +0000

Hi Jordi,

Are you saying your draft  “464XLAT Optimization” will provide IPv4only app to IPv6only app communication like this?

                  +-------+     .-----.
                  | IPv6  |    /       \
      .-----.     |  CE   |   /  IPv6-  \     .-----.
     / IPv4- \    |  or   +--(   only    )---( NAT64 )
    /  only   \   |  UE   |   \  Access /\    `-----'
   (  SmartTV  )--+       |    \       /  \
    \   STB   /   | with  |     `--+--'    \   .-----.
     \ VoIP  /    | NAT46 |        |        \ /       \
      `-----'     | CLAT  |    +---+----+    /  IPv6   \      .--+--.
                  |       |    |  DNS/  |   (  Internet )IPv6/ IPv6- \
                  +-------+    |  DNS64 |    \         /----/  only   \
                               +--------+     \       /    (           )
                                               `-----'      \  APP    /
                                                             \       /
                                                              `-----'
   <------------------------ IPv4 to IPv6 flow ------------------------>

What did not work so far and what had to be added in your draft to make this flow work?

How can IPv6-only APP get the IPV4 public address, used by NAT_translator, when sending a packet from IPv6-ony APP to IPv4-only APP? This IPv4 address is the same destination IPv4 address to which IPv4-only APP sends a packet towards IPv6-only APP ( 192.0.2.2. address in Jen’s example).

Thanks,
Dusan.

From: v6ops <[email-masked]> On Behalf Of JORDI PALET MARTINEZ
Sent: Monday, July 8, 2019 5:40 PM
To: IPv6 Operations <[email-masked]>
Cc: 6man <[email-masked]>
Subject: Re: [v6ops] NAT64 in RA, draft-ietf-6man-ra-pref64

https://datatracker.ietf.org/doc/draft-palet-v6ops-464xlat-opt-cdn-caches/?include_text=1<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dpalet-2Dv6ops-2D464xlat-2Dopt-2Dcdn-2Dcaches_-3Finclude-5Ftext-3D1&d=DwMFaQ&c=BFpWQw8bsuKpl1SgiZH64Q&r=UT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=WPk7nl7onGDFCBidWTXjZiU7tuZQ2SvySyapgepjfPs&s=m5bfbvspFsjn6u0cU9elUD6-0nKO9zuQE2xMCjjKvyw&e=>

El 8/7/19 19:01, "v6ops en nombre de David Farmer" <[email-masked]<mailto:[email-masked]> en nombre de [email-masked]<mailto:[email-masked]>> escribió:

On Mon, Jul 8, 2019 at 10:49 AM Mudric, Dusan (Dusan) <[email-masked]<mailto:[email-masked]>> wrote:
> From: Manfredi (US), Albert E <[email-masked]<mailto:[email-masked]>>
>
> From: ipv6 <[email-masked]<mailto:[email-masked]>> On Behalf Of Mudric, Dusan (Dusan)
>

> That's clearly more difficult, which is why the normal course of action is for
> the IPv6 client to initiate the session..

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]<mailto:[email-masked]>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_ipv6&d=DwMFaQ&c=BFpWQw8bsuKpl1SgiZH64Q&r=UT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=WPk7nl7onGDFCBidWTXjZiU7tuZQ2SvySyapgepjfPs&s=K766f4w5EmjOZi0vrE34mPRBOindlHcg9zmnYB-xfts&e=>
--------------------------------------------------------------------

--
===============================================
David Farmer               Email:[email-masked]<mailto:[email-masked]>
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE        Phone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================
_______________________________________________ v6ops mailing list [email-masked]<mailto:[email-masked]> https://www.ietf.org/mailman/listinfo/v6ops<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_v6ops&d=DwQFaQ&c=BFpWQw8bsuKpl1SgiZH64Q&r=UT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=WPk7nl7onGDFCBidWTXjZiU7tuZQ2SvySyapgepjfPs&s=OxfqvzylmIQ0IGckBWfgq4z0JsrPDyXBQ34WoQLmVaE&e=>

**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.theipv6company.com&d=DwQFaQ&c=BFpWQw8bsuKpl1SgiZH64Q&r=UT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=WPk7nl7onGDFCBidWTXjZiU7tuZQ2SvySyapgepjfPs&s=DlXaFAS9D4iXwAC_L9cjr3_1jVGVXs_25rn66Tvj7r8&e=>
The IPv6 Company

Subject: Re: NAT64 in RA, draft-ietf-6man-ra-pref64
From: Jen Linkova <[email-masked]>
To: "Mudric, Dusan (Dusan)" <[email-masked]>
Cc: "Manfredi (US), Albert E" <[email-masked]>, IPv6 Operations <[email-masked]>, 6man <[email-masked]>
Date: Tue, 9 Jul 2019 01:33:55 +0000

> [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=_cWRsdzof5dXI9yTQH51H_KHtcSRcMAtARArKVcdnWM&s=wDxWEwS-e-N-I0oAfcdi-5GucNiCQpR32t9Rw4RZyn0&e= mentioned before.

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=UT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=_cWRsdzof5dXI9yTQH51H_KHtcSRcMAtARArKVcdnWM&s=GsPTdPr_ZwWYK13LIrhTv9rYM6dYJfgbT8HtLwVRkZo&e=

---

From: "Mudric, Dusan (Dusan)" <[email-masked]>
Date: Tue, 9 Jul 2019 20:11:47 +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

> Sent: Monday, July 8, 2019 9:34 PM
> &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).
> 
> 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=
> 
> 
> 
> > > session, you'd have to have preconfigure something.
> 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 ;)
> 
> --

Subject: Re: NAT64 in RA, draft-ietf-6man-ra-pref64
From: Jen Linkova <[email-masked]>
To: "Mudric, Dusan (Dusan)" <[email-masked]>
Cc: Fred Baker <[email-masked]>, IPv6 Operations <[email-masked]>, 6man <[email-masked]>
Date: Fri, 5 Jul 2019 02:21:25 +0000

Hi Dusan,

> - 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=

In a nutshell:

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=.

> 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=

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Tue, 09 Jul 2019 22:24:01 +0200

Hi Dusan,

The problem is that the IPv6-only “remote server” don’t have IPv4 connectivity. Also, it doesn’t have an IPv4 address. Let’s suppose this is a streaming server.

The “local” IPv4-only host (let’s suppose is an IPv4-only SmartTV), is connected to a CLAT (this is in the CPE, and the CPE is connected via IPv6-only) to the service provider.

The optimization that we are suggesting is using EAM (explicit mapping) to avoid the IPv4 flow from the smartTV to be converted back to IPv4, because the CLAT already converted it to IPv6.

If we create a “fake” A record in the streaming server, the CLAT will create an EAMT, so because it believes the streaming service is reachable with IPv4 (which is not), but the “optimized CLAT” will then use the AAAA.

So, the flow is:

IPv4 from the smartTV to the CLAT

IPv6 from the CLAT to the streaming service

In normal conditions, if the streaming service is really dual-stack and we don’t have optimization (the “actual” 464XLAT protocol), it will be:

IPv4 from the smartTV to the CLAT

IPv6 from the CLAT to the NAT64

IPv4 from the NAT64 to the streaming service

If the streaming service is IPv6 only, with the actual 464XLAT protocol, this connectivity is not possible.

You see the point?

Please take a look at the document, I think is well described, otherwise provide suggestions about what you believe is not clear enough and we will make sure to improve the text and drawings!

By the way, I’m talking here about “approach 2”, which I think is the best solution.

Regards,

Jordi

@jordipalet

El 9/7/19 22:05, "v6ops en nombre de Mudric, Dusan (Dusan)" <[email-masked] en nombre de [email-masked]> escribió:

Hi Jordi,

 

                  +-------+     .-----.                   

                  | IPv6  |    /       \                

   (  SmartTV  )--+       |    \       /  \             

                               +--------+     \       /    (           )

                                               `-----'      \  APP    /

                                                             \       /

                                                              `-----'

Thanks,

Dusan.

 

 

 

--

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Tue, 09 Jul 2019 22:27:47 +0200

If you do "manual" EAM configurations at each side, it is fully solved, but is this useful in a generic case.

So what I'm trying to do with the optimization is that the EAM creation is "automated".

Regards,
Jordi
@jordipalet

El 9/7/19 22:13, "ipv6 en nombre de Mudric, Dusan (Dusan)" <[email-masked] en nombre de [email-masked]> escribió:

    Thanks Jen. 

    
    Dusan

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Tue, 09 Jul 2019 22:54:38 +0200

By the way, the difference between this and using SIIT-DC, is that in SIIT-DC the flow will be:

IPv4 from the NAT64 to the SIIT-DC BR

IPv6 from the SIIT-DC BR to the streaming service

Note that our main goal with this work, was not to make “a new SIIT-DC”, but to make sure that IPv4-only devices behind a CLAT don’t need to use the NAT64 if the services (such as CDNs, caches, etc.) are already IPv6-enabled.

Regards,

Jordi

@jordipalet

El 9/7/19 22:25, "ipv6 en nombre de JORDI PALET MARTINEZ" <[email-masked] en nombre de jordi.palet=[email-masked]> escribió:

Hi Dusan,

So, the flow is:

You see the point?

Regards,

Jordi

@jordipalet

Hi Jordi,

 

                  +-------+     .-----.                   

                  | IPv6  |    /       \                

   (  SmartTV  )--+       |    \       /  \             

                               +--------+     \       /    (           )

                                               `-----'      \  APP    /

                                                             \       /

                                                              `-----'

Thanks,

Dusan.

 

 

 

-- 

-------------------------------------------------------------------- IETF IPv6 working group mailing list [email-masked] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------

---

From: Mark Andrews <[email-masked]>
Date: Wed, 10 Jul 2019 09:27:35 +1000

And the answer to this “problem” is stop buying IPv4-only garbage and deploy IPv6.

Go talk to your legislators about banning the sale of IPv4-only equipment.  This is where this should be addressed.  Not in the IETF.  IPv6 aware products don’t cost more to produce.

Having lived through a metrification process, banning the sale of imperial only equipment really helped.  It was illegal to sell new cars without kph on the speedometer.  It was illegal to sell new rulers and tape measures which where imperial only.  It was illegal to sell new scales that where imperial only.  All packaging had to be labeled in metric units.  Sometimes governments need to step in and ban products for the greater good.

> On 10 Jul 2019, at 6:24 am, JORDI PALET MARTINEZ <jordi.palet=[email-masked]> wrote:
> 
> Hi Dusan,
>  
> _______________________________________________ v6ops mailing list [email-masked]://www.ietf.org/mailman/listinfo/v6ops
> 
> _______________________________________________ v6ops mailing list [email-masked]://www.ietf.org/mailman/listinfo/v6ops
> 
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: [email-masked]

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Wed, 10 Jul 2019 02:28:42 +0200

HI Mark,

I will agree with that, and I've actually recommended it to several governments: "ban imports and manufacturing of non-IPv6-ready devices in 12 months, ban sales of older stocks 6 months after that". Same we have done with DTV, for example. It is a basic consumer protection measure.

However, nobody is going to pay for replacement of existing IPv4-only equipment and apps in homes and enterprises, so we still need to provide solutions for those.

Regards,
Jordi
@jordipalet

El 10/7/19 1:27, "Mark Andrews" <[email-masked]> escribió:

---

From: Mark Andrews <[email-masked]>
Date: Wed, 10 Jul 2019 11:52:54 +1000

Do we really need to provide a solution?  The manufactures of the devices can update their firmware.  What internet connected device in the house isn’t upgradable?  All the games consoles are.  Printers are.  TV’s are.  Fridges are.  The list goes on.

Again this is where governments can force manufactures to do the right thing by their existing customers.

Mark

> On 10 Jul 2019, at 10:28 am, JORDI PALET MARTINEZ <jordi.palet=[email-masked]> wrote:
> 
> HI Mark,
>

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Wed, 10 Jul 2019 08:43:41 +0200

We could also suggest governments to apply that law: "your 10 years old device must be updated or you will get a fine". Do you think that's realistic? How the Spanish government apply a fine to a Chinese company? How about devices that were NOT designed to have any kind of firmware update?

May vendors or app developers doesn't exist. How you resolve the problem for those? Or governments should pay the renewal of all those devices and apps?

Really, I don't think is that easy/feasible!

Regards,
Jordi
@jordipalet

El 10/7/19 3:54, "v6ops en nombre de Mark Andrews" <[email-masked] en nombre de [email-masked]> escribió:

    
    Mark

---

From: Mark Andrews <[email-masked]>
Date: Wed, 10 Jul 2019 17:11:40 +1000

> On 10 Jul 2019, at 4:43 pm, JORDI PALET MARTINEZ <jordi.palet=[email-masked]> wrote:
> 
> We could also suggest governments to apply that law: "your 10 years old device must be updated or you will get a fine". Do you think that's realistic?

Actually yes.  It was clear 10 years ago that IPv4 was dead and IPv6 was the replacement.  The manufacture gambled and lost.

Think about the recent GPS epoch.  Vendors put out updates for otherwise eol’d products to avoid fines for
shipping non fit for purpose equipment.  They all knew or should have known that a GPS epoch would happen in
the life of the product.

The same applies to shipping IPv4 only equipment.

> How the Spanish government apply a fine to a Chinese company? How about devices that were NOT designed to have any kind of firmware update?

I you are in Australia the seller is the one that is primarily responsible.  How they deal with their supply chain is up to them. 

Devices that where not designed to have a firmware update you throw in the bin.  That said, for most of them, the machines they want to contact have IPv4 addresses.

> May vendors or app developers doesn't exist. How you resolve the problem for those? Or governments should pay the renewal of all those devices and apps?

You throw those in the bin as well.