Re: [v6ops] draft-palet-v6ops-464xlat-opt-cdn-caches

[JORDI PALET MARTINEZ <[e-mail]>]

Hi Dusan,

 

Responding below in-line (removed 6man).

 

Regards,

Jordi

@jordipalet

 

 

 

El 10/7/19 16:59, "Mudric, Dusan (Dusan)" <[e-mail]> escribió:

 

Hi Jordi,

 

I changed the thread title since we are now discussing draft-palet-v6ops-464xlat-opt-cdn-caches solution.

 

When DNS64 translator in this figure https://en.wikipedia.org/wiki/IPv6_transition_mechanism#/media/File:NAT64.svg sends a packet to 192.0.2.1, the packet has the source IPv4 address of DNS64. How can DNS server be configured to return that address during h2.example.com resolution?

 

I guess you mean the NAT64, because the DNS64 is not the translator.

 

The query for h2.example.com will return 192.0.2.1. The DNS64 in turn will synthetize 64:ff9b::c000:200 and return that to the host that want to talk to 192.0.2.1, so when this communication flow actually starts, will use the NAT64 translator.

 

Please find more comments and questions inlined.

 

Thanks,

Dusan.

 

From: JORDI PALET MARTINEZ <[e-mail]> 
Sent: Tuesday, July 9, 2019 4:24 PM
To: Mudric, Dusan (Dusan) <[e-mail]>; IPv6 Operations <[e-mail]>
Cc: 6man <[e-mail]>
Subject: Re: [v6ops] NAT64 in RA, draft-ietf-6man-ra-pref64

 

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

[Dusan] This is a different solution that addresses a different use case: IPv4-only client accessing IPv6-only “remote server” in IPv6 only network. IPv6-only server does not need PLAT (btw, found a nice diagram that depicts CLAT-PLAT https://sites.google.com/site/tmoipv6/464xlat )

 

è   Yes, as explained already, 464XLAT was meant to allow IPv4-only devices to use NAT64 (the PLAT), by means of the CLAT daemon. The optimization is to avoid a double translation if the destination is already dual-stack.

 

 

In normal conditions, if the streaming service is really dual-stack 

[Dusan] Need to be more specific. Is the streaming “remote server” server supporting dual stack and is in a dual stack network? Is the access network IPv6-only?

 

è   Never mind, in our optimization, the streaming is dual-stack and attached with dual-stack. The idea is to avoid a dual-translation.

 

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

[Dusan] If the IPv4-ony client is streaming over IPv6-only network to a dual stack “remote server” in a dual stack network, 

 

è   Again. Yes, the optimization was originally designed to allow IPv4-only devices to avoid dual-translation if the destination service is already IPv6 enables. To work without the optimization needs to be dual-stack, just think in a CDN (they are today dual-stack, typically). But then we discovered that this will actually work as well even if the CDN is IPv6-only but has an A record (even if it is a fake one).

 

·         IPv6 from the CLAT to the NAT64

·         IPv4 from the NAT64 to the streaming service

is not needed. IPv6 access network can directly send IPv6 packets over dual stack network to the dual stack “remote server”.

 

è   NO. Without the optimization, the flow is forced to be as I’ve described, because the NAT64 prefix will force the path to the NAT64. Unless you go for approach 1 in the document but then this will only work if 1) the CDN interfaces have NAT64 WKP addresses (and that means they are “locally” connected, because it is non routable in Internet), or 2), an NSP prefix is used and the CDN is configured with them.

 

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

[Dusan] If the streaming service is IPv6 only, meaning the IPv6 only “remote server” is in IPv6-only network, after IPv4-to-IPv6 CLAT translation the packets from IPv4-only host will be able to reach the IPv6 only “remote server”.

 

è   No, read my previous explanation, because the NAT64 prefix disallows that.

 

You see the point?

[Dusan] Not yet. Please see the comments above.

 

è   I’ve the feeling that you still didn’t understand how NAT64 works. You need to understand that before getting here!

 

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.

[Dusan] Sorry, I am not able to get the main ideas from draft-palet-v6ops-464xlat-opt-cdn-caches. I expect if there are:

-          A diagram explaining the problem(s) with call flows, 

-          Depicted components and where they are (on which devices ), and

-          Glossary with definitions

it will be easier to grasp the ideas.

[Dusan] Section 4.2.2 is not clear. Why DNS proxy resolver needs to do additional AAAA query? Why is this DNS response needed by CLAT?

[Dusan] Section 4.2.3 goes into details and it is not clear which problem needs to be solved and what the solution is. I cannot follow these details because I don’t know what they are for.

[Dusan] Section 4.2.4: my understanding is that EMT table is in CPE router (should be described in the document where which components are and should be a glossary for acronyms, defining function blocks) . Probably A and AAAA resolutions are stored on the router and when IPv4 packet, destined to A-resolved IP, comes to CPE, destination IPv4 address will be mapped to IPv6 address from AAAA resolution. This should be explained and flow diagram provided.

 

Question: So far I can see how this will work if everything is statically configured. Based on Jen’s call flow:

 

è   Exactly, SIIT-DC means some static configuration at the server side for the EAMT entries for each host. And this forces the double translation and then a new translation at the SIIT-DC border relay. Our optimization avoids this multiple translation and create in the CE the EAMT entries automatically.

 

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

the IPv6-only “remote server” is configured to have 2001:db8:1::192.0.2.2 and IPv4 packets from IPv4-only client, destined to 192.0.2.2, will be routed to CPE translator (I guess because all devices behind the translator have to be in the same subnet). What if the IPv6-only hosts (or the remote server in this example) use SLAAC? How is this going to work?

 

 

è   You need to first understand very well NAT64, then 464XLAT, then you will catch it.

 

Regards,

Jordi

@jordipalet

 

 

 

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

 

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 <[e-mail]> On Behalf Of JORDI PALET MARTINEZ
Sent: Monday, July 8, 2019 5:40 PM
To: IPv6 Operations <[e-mail]>
Cc: 6man <[e-mail]>
Subject: Re: [v6ops] NAT64 in RA, draft-ietf-6man-ra-pref64

 

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" <[e-mail] en nombre de [e-mail]> escribió:

 

 

 

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

> -----Original Message-----
> From: Manfredi (US), Albert E <[e-mail]>
> 
> -----Original Message-----
> From: ipv6 <[e-mail]> 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, 
[Dusan] There is no solution for IPv4only client to reach IPv6only client? 

 

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. 

 

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

 

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?
> 
> 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..
[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.
[Dusan] Where and how is this configuration done?

> 
> Bert

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


 

-- 

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

_______________________________________________ v6ops mailing list [e-mail] 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.

_______________________________________________ v6ops mailing list [e-mail] 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.



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