Complications of NAT64

[juhoostman]

Are you aware of any problems with NAT64 that are not present with NAT44? If NAT64 is combined with a solution like tnat64 or Nat64d even IPv4 literal addresses work. It seems to me that only problems would be related to conversion between IPv4 and IPv6 packets. As far as I know, NAT64 operates exactly like a tunnel between the client and IPv4 network, just that the IPv4 header is compressed away when the packet is being transmitted on the IPv6 network, as all its information is contained in the IPv6 header and the state of the NAT64 gateway. I think that the vast majority of IPv4 packets don't employ any options or other fancy features that would be difficult to translate. Translation affects the PMTU, but IPv4 has much smaller required MTU than IPv6. Do you have any other ideas about this?

[maestroevolution]

Respectfully (and I do mean this to be 100% constructive), I believe there are some gaps in your understanding of NAT64.

NAT64 does not operate "like a tunnel between the client and the IPv4 network."  It operates like a NAT.  The IPv6 header is removed and the IPv4 header is added, while the payload is (ideally/usually) unchanged.  NAT operate at a layer 3 (IP level), and frequently at layer 4 (TCP/UDP port overload)

The IPv4 header is not compressed away on the IPv6 network; it's gone (again, it's a NAT).

Your statement on path MTU for IPv6 and IPv4 is reversed;  as IPv6 has a larger header, it has more overhead, so if the minimum MTU along the path is 1500 bytes, the payload size (tcp segment, UDP payload, etc) has less available.

I would generally agree with your first statement, though.  NAT64 is a NAT, and all the problems you have with NAT44, you're going continue to have with NAT64.  NAT64 does have a few additional challenges, though, such as 1) some  ICMP messages don't translate, 2) some fields don't translate (such as the flow label, but no one's using that anyway), and 3) the existing problem some protocols that don't like NAT is amplified.  FTP is the usual example for IPv4, and this problem is exacerbated in NAT64 because not only is the address type changing, ftp over v6 uses a completely different command structure (I don't know who thought that up), so your NAT64 gateway needs to do deeper inspection and protocol translation.

In my personal experience, the problem with NAT-PT and NAT64 isn't actually NATPT and NAT64: it's the DNS aspect of it.

[disneycheng]

As I know NAT64 gonna work with DNS64.

Otherwise that is useless.

That major address the transition of IPv6 and let pure IPv6 device access pure IPv4 resources. Most likely Web I guess.

NAT64 did not work if you use IP address, for example, you go to ping a IPv4 IP address on a IPv6 only host.

The magic of NAT64 is DNS64. It resolve A record as a AAAA synthesis address, so NAT64 device knows where to go.

I have test HTTP, HTTPS and ssh work fine. I didn't test FTP yet, but i guess just like traditional FTP, it will generate some headache issue.

[maestroevolution]

Re: "NAT64 did not work if you use IP address, for example, you go to ping a IPv4 IP address on a IPv6 only host."

Technically, you could ping the IPv4 host if you know the mapped IPv6 address, but as that's locally significant between your host and your NAT64 gateway (and configured on your DNS64 gateway), and you'd need to do the math yourself, which makes it impractical.  Reaching network elements by IP address was difficult enough with just IPv4... IPv6 is ludicrous.  It's also why (as you said), DNS64 is the magic pixie dust that glues everything together.

Taking the public DNS server 4.2.2.2, and knowing my NAT64 gateway used a prefix of 2001:470:1f11:10dd:4444::/96, I can successfully ping (and do digs against) it.

4.2.2.2 is mapped to 2001:470:1f11:10dd:4444:0:0402:0202



joel@maestro:~$ ping6 2001:470:1f11:10dd:4444:0:0402:0202
PING 2001:470:1f11:10dd:4444:0:0402:0202(2001:470:1f11:10dd:4444:0:402:202) 56 data bytes
64 bytes from 2001:470:1f11:10dd:4444:0:402:202: icmp_seq=1 ttl=55 time=11.1 ms
64 bytes from 2001:470:1f11:10dd:4444:0:402:202: icmp_seq=2 ttl=55 time=10.4 ms
^C
--- 2001:470:1f11:10dd:4444:0:0402:0202 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 10.422/10.770/11.119/0.363 ms

joel@maestro:~$ dig aaaa @2001:470:1f11:10dd:4444:0:0402:0202 www.google.com

; <<>> DiG 9.7.3 <<>> aaaa @2001:470:1f11:10dd:4444:0:0402:0202 www.google.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33215
;; flags: qr rd ra; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;www.google.com.         IN   AAAA

;; ANSWER SECTION:
www.google.com.      1774   IN   CNAME   www.l.google.com.
www.l.google.com.   274   IN   AAAA   2001:470:1f11:10dd:4444:0:4a7d:e111
www.l.google.com.   274   IN   AAAA   2001:470:1f11:10dd:4444:0:4a7d:e112
www.l.google.com.   274   IN   AAAA   2001:470:1f11:10dd:4444:0:4a7d:e113
www.l.google.com.   274   IN   AAAA   2001:470:1f11:10dd:4444:0:4a7d:e114
www.l.google.com.   274   IN   AAAA   2001:470:1f11:10dd:4444:0:4a7d:e110

;; Query time: 27 msec
;; SERVER: 2001:470:1f11:10dd:4444:0:402:202#53(2001:470:1f11:10dd:4444:0:402:202)
;; WHEN: Mon Jul 25 11:45:15 2011
;; MSG SIZE  rcvd: 192

[juhoostman]

NAT64 does not operate "like a tunnel between the client and the IPv4 network."  It operates like a NAT.  The IPv6 header is removed and the IPv4 header is added, while the payload is (ideally/usually) unchanged.  NAT operate at a layer 3 (IP level), and frequently at layer 4 (TCP/UDP port overload)
The IPv4 header is not compressed away on the IPv6 network; it's gone (again, it's a NAT).

I did not mean compression so that NAT64 is actually implemented that way, but analytically. Let's suppose there is dual-stacked host A with IPv6 connectivity to NAT64 gateway N and IPv4 host B. We could enable A to communicate with B by tunneling IPv4 traffic over IPv6 between A and N, then N does a NAT and forwards packets to B. Here A may use some private IPv4 address, which is immaterial since the traffic is NATted. In this tunneling scenario, which is something like DS-lite, we have to transmit both IPv4 and IPv6, which is unnecessary, if there is going to be a NAT anyway. NAT64 omits the IPv4 header on the IPv6 side, there is only an IPv6 header on the IPv6 side and an IPv4 header on the IPv4 side. N can use its state to determine which IPv6 and IPv4 addresses and ports correspond to each other and reconstruct headers as needed.

Your statement on path MTU for IPv6 and IPv4 is reversed;  as IPv6 has a larger header, it has more overhead, so if the minimum MTU along the path is 1500 bytes, the payload size (tcp segment, UDP payload, etc) has less available.

IPv6 has minimum allowed MTU 1280, IPv4 guarantees only 68. If IPv4 hosts transmit packets larger than that they have to be prepared for fragmentation. IPv4 hosts cannot expect MTU 1500.

I would generally agree with your first statement, though.  NAT64 is a NAT, and all the problems you have with NAT44, you're going continue to have with NAT64.  NAT64 does have a few additional challenges, though, such as 1) some  ICMP messages don't translate,

Do you have a reference for that? An IETF memo, an RFC or so on.

[maestroevolution]

Re: NAT64 and DSLite:  

I'm afraid I don't understand the point you're trying to make.  Your scenario with IPv6 host A, gateway N, and IPv4 Host B is a very good description of DSlite, which is not NAT64.  I believe Dslite gives the gateway N the option of NATting the IPv4 addresses, but this is essentially a regular IPv4 NAT where one interface is an IPv6 tunnel.

Re: MTU:

The MTU along a given path is generally limited by layer-2 encapsulation and/or the physical media, not the layer-3 protocol family used on top of it.  If a standard path from user A to server Z has an IP MTU of 1500, this gives the application (TCP MSS) 1460 bytes to play with).  A dual stacked application that does not know or care with that layer3 protocol is will have less payload per packet due to larger overhead of IPv6 header.  However, the dual-stacked application will again not know or care, as segmenting is usually again done by the OS.

Yes, MTU is sometimes less than 1500 due to tunneling techniques (IP-in-IP for Mobile IP, IPSEC VPNs, etc), but for a dual stacked provider, the MTU will be a limitation of the physical or layer-2 encapsulation, not the layer-3 payload on top of it.

(And, IMPO, a good service provider ensures its uses have end-to-end 1500 byte MTU connectivity at a minimum, because anything less causes fragmentation, and will eventually cause a problem).

Re: references/nat:

Reference #1)  Me.  (My experience, my research, and my testing) NAT64 is still a NAT, and any problems you've had with with NAT44 you're going to have with NAT64/NATPT.  Especially problematic are those applications/protocols that embed IPv4 or IPv6 addresses in the payloads, and expect a gateway to translate those without use of NAT traversal techniques.

Reference #2)  Stateless IP/ICMP translation (SIIT)  RFC 2765, now RFC6145.  ICMP (my example) are sections 4.2, 4.3, 5.2, and 5.3.  

Reference #3) Re: FTP  RFC959 is the current spec, RFC2428 adds support for IPV6, and the new commands EPRT and EPSV.  If a NAT64 gateway is servicing an IPv6 client to an IPv4 server, it needs to 1) translate the IP addresses, as it always does for IPv4 NAT case, as well as 2) intercept and translate the commands being used: PORT to EPRT, PASV to EPSV.

Reference #3a) Combining #3 with experience... Any application that embeds IP addresses in payloads is going to be increasingly problematic with IPv6.  FTP just made it worse with the command change.  SIP will also be a challenge.

Reference #4)  Google is failing me at the moment, but there a good nanog presentation that essentially described NATPT = NAT64 + DNS64 +NAT46.  I thought its description of NATPT's failure was a bit harsh, but that one line covers 95% of it.

[edit] Reference #5)  RFC4966: Reasons to deprecate NATPT:  has good coverage of NATPT challenges, and does a good job of distinguishing those that are NAT in general vs IPv6 NAT specific vs DNS ALG.  It's a good read.

Thanks,

Joel

[maestroevolution]

I think this is what I remembered with the last reference:

http://www.slideshare.net/IOSHints/nat64-and-dns64-in-30-minutes

I disagree with some points, such as:

page 8:  "NAT with ALG is really bad (Scrap NAT-PT, see RFC4966)":  ALGs (Application Layer Gateways) are still needed for some protocols, such as FTP, TFTP, SIP, and anything with embedded IP addresses.  They are needed in NAT44 cases, still needed in NAT64 cases.  The author may be referring to the DNS ALG specifically, though (a la DNS64), which NATPT stated/implied? was tied to the forwarding plane: if that's his intent, I... well, I don't disagree.  The gear I'm using actually supports DNS ALG on the box, although it doesn't try to do the IPv6 to IPv4 PTR mapping and translation.

page 9: "DS-Lite"  I prefer NAT64 over DS-Lite, and see DS-lites use case in a different scenario: that of a consumer ISP (such as Time Warner, Comcast, or pick your provider) who needs to address hundreds of thousands / millions of unique devices (cable modems, setttop boxes, dslams, etc), plus all their vendor gear, plus their internal networks, while still providing IPv4 services to their customers.  The main use case I see for DSlite is letting the provider migrate their internal network to IPv6 while still providing IPv4 services to their users.  Also, DS-lite includes the overhead of the tunnel, decreasing the effective MTU still further.  For enterprise/ SP networks, I would use native or dual-stack IPv6 everywhere and NAT64 at the edges where necessary (a necessary evil).

Page15: "NAT64:  IPv6-only hosts, and NAT64 largely unknown".  NAT64 can still support dual-stack hosts, say for a migration, where servers are IPv6 enabled, but some legacy tools are still IPv4, or has some application on the box that is IPv4 only.  I'm not sure I agree with the 'largely unknown' part either, as NATPT (6-4 NAT perspective) has been around a lot longer than DS-Lite, and most of the challenges with NAT64 are 1) It's still a NAT, but we've dealt with that for 15+ years, 2) the FTP example, and 3) syncing up with DNS64.  The boxes I'm using support DNS64 on the box as NAT64 if you want (a la NATPT), and BIND now supports this natively anyway, making the need for DNS64 onboard moot.  I have not tried the new BIND version, but previously I used a utility called totd (trick-or-treat daemon) to do the DNS64 AAAA synthesis.  Again, I see DSlite as a carrier deployment, not small/medium/large enterprise, nor for carriers except for connecting to consumer edge.

Page17:  Bind supports the DNSALG function now (again, I haven't tried it yet).  Juniper has supported NATPT for years on ScreenOS, and now on the SRX as well.  I think/assume Cisco supports a NAT64 implementation other than CGv6 (CarrierGradev6, I think) as well.

Page 18:  I agree.  See, I can agree with something :)

Joel