NAT64 Tunnel Protocol

Prior protocols for connecting islands of IPv6 through tunnels over IPv4 exist including . However since the introduction of those protocols NAT has gained widespread use and a majority of ISPs still have not started deploying IPv6. For those reasons there is a need for a new way of connecting islands of IPv6. NAT64 as defined in is a method for translating between IPv6 and IPv4. This is intended to allow IPv6-only clients to reach IPv4-only services. NAT64 also happens to be very useful for connecting islands of IPv6 to an IPv4-only ISP. Moreover high availability can easily be achieved by connecting an island of IPv6 through redundant NAT64 gateways to multiple ISPs. Many prior tunnel protocols fail to work reliably when one endpoint of the tunnel is behind NAT. And none of them work reliably when both endpoints are behind NAT64. specifies support for use of UDP, TCP, and ICMP. Of those only UDP is suitable for building a tunnel protocol. But when both endpoints are connecting through NAT the use of hole punching will be necessary. And in many NAT setups, especially those using multiple layers of NAT, the use of hole punching is unreliable. Even when these work they rely on state in each NAT device in order to maintain a connection. This document defines NAT64TP (the NAT64 Tunnel Protocol). NAT64TP is a simple stateless NAT64 extension which allows tunnel protocols to reliably establish connections between islands of IPv6. NAT64TP achieves this by using UDP packets in which each packet carries enough information in their UDP payload to route them to their destination with no state being maintained. NAT64TP only differs from in very minor ways to allow it to easily be added to existing NAT64 implementations. This also allows NAT64TP to achieve reliability when only a subset of the involved NAT64 gateways implement NAT64TP.

NAT64: A dual-stack node translating TCP and UDP according to and optionally implementing the NAT64TP protocol as specified in this document. NAT64TP: The NAT64 Tunnel Protocol is the extension for NAT64 defined in this document. Endpoint: An IPv6-only or dual-stack node which implements a higher level protocol on top of the NAT64TP protocol as specified in this document. Outer IP header: The IP header in front of the UDP header which gets translated from IPv6 to IPv4 and back during transmission. Inner IPv6 header: The IP header at the start of the UDP payload. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in when, and only when, they appear in all capitals, as shown here.

NAT64TP packets are IPv6 packets encapsulated in UDP. The UDP packets are translated by NAT64 gateways according to slightly different rules than .

Each endpoint has access to one or more NAT64 gateways which allow for communication through the IPv4 backbone. For redundancy the NAT64 gateways can connect to different IPv4 providers. At least one of the NAT64 gateways SHOULD support the NAT64TP protocol as specified in this document.

Upon receiving an UDPv6 packet with source port TBD the NAT64 MUST validate that the packet is a valid NAT64TP packet. The UDP payload length MUST be at least 40 octets. The inner IP version field MUST contain the value 6. The inner source IP MUST be identical to the outer source IP. The NAT64 MAY additionally validate the following fields. The UDP payload length MUST be exactly 40 octets plus the payload length specified in the inner IPv6 header. The inner hop limit must be in the range 43 to 255. A UDPv6 packet with source port TBD which fails any of the validations performed MUST be either dropped or translated as regular stateful NAT64. If the packet is dropped the NAT64 may generate an ICMPv6 error message. A packet which matches all of the validations performed MUST be translated statelessly. The outer source IP and destionation IP are translated as in . The UDP source and destination port MUST remain unchanged after translation. If the inner hop limit was validated it SHOULD be reduced to 42. If the UDP header has a checksum it must be adjusted to reflect all of the changes made to the packet.

Upon receiving an UDPv4 packet with destination port TBD the NAT64 MUST validate that the packet is a valid NAT64TP packet. The UDP payload length MUST be at least 40 octets. The inner IP version field MUST contain the value 6. The inner hop limit MUST be in the range 22 to 255. The NAT64 MAY additionally validate the following field. The UDP payload length MUST be exactly 40 octets plus the payload length specified in the inner IPv6 header. A UDPv4 packet with destination port TBD which fails any of the validations performed MUST be dropped. The NAT64 MAY generate an ICMP error message. A packet which matches all of the validations performed MUST be translated statelessly. The outer source IP is translated as in . The inner destination IP is copied to the outer destination IP. The UDP source and destination port MUST remain unchanged after translation. The inner hop limit MUST be reduced to 21. If the UDP header has a checksum it must be adjusted to reflect all of the changes made to the packet. If the UDP packet has no checksum a checksum must be computed over the resulting packet.

NAT64TP is a layer of the networking stack. Like IP and UDP this layer is intended as basis on which to build higher layer protocols. The higher layer protocols to be used over NAT64TP are generally expected to be a VPN or something resembling it. The full specification of the higher layer protocol is outside the scope of this document. The intermediate NAT64 gateways only need to implement the NAT64TP layer as specified in this document and need no knowledge of the higher layer. Inspection of the higher layer protocols won't even be possible for the NAT64 gateways due to the encryption used by the VPN layer. NAT64TP endpoints MUST comply with both the sepcification in this document and the specification of the higher layer protocol which they implement. When originating a NAT64TP packet the endpoint MUST construct a header chain consisting of at least three headers: Outer IPv6 header, UDP header, and inner IPv6 header. The headers MUST satisfy the following requirements: All three headers MUST have consistent length information which agrees on which octet is the last of the packet. Inner and outer IPv6 headers MUST have identical source address. Outer IPv6 header MUST have next header 17 (UDP). The UDP header MUST have source port TBD. Inner IPv6 header MUST have a hop limit in the range 63 to 255. When receiving a NAT64TP paket the endpoint MUST accept packets with any outer source IP and any UDP source port. The higher layer protocol MUST validate the authenticity and integrity of the packet based on the payload of the inner IPv6 packet. When receiving a valid NAT64TP packet from an unknown outer source IP and UDP source port combination the endpoint SHOULD learn this source address as a possible network path for return traffic. If the outer source IP is within a known NAT64 prefix, the endpoint SHOULD attempt recombining the embedded IPv4 address with other known NAT64 prefixes to learn alternative network paths. When sending packets over a learned network path the higher layer protocol MUST take steps to guard against hijacking of traffic. These steps MAY include: preference for paths with lowest latency and encryption and digital signatures applied to payload data. When choosing between possible network paths for sending a packet an endpoint SHOULD include the inner destination IP and port TBD as one of the possible options for filling in outer destination IP and destination UDP port. The configuration of an endpoint SHOULD allow for at least the following two ways of configuring available network paths to a peer: A list of NAT64 prefixes available to the local endpoint and a list of IPv4 addresses of NAT64TP gateways available to the remote endpoint. All combinations of these combined with destination port TBD should be considered possible network paths. A list of full IPv6 address and port number combinations for network paths which doesn't follow the above scheme or where the length of the NAT64 prefix being used isn't known. An endpoint implementation SHOULD have the ability to send periodic probe packets across its prefered network paths. If probe packets are lost the endpoint SHOULD try alternative paths known to the same destination. These probes additionally serve the purpose of keeping alive state in case either NAT64 is stateful and doesn't implement NAT64TP.

Routers on the network path between the endpoints only need to consider the outer IP header in their routing decisions. Routers MAY include the following fields from the UDP header and inner IPv6 header in ECMP hashes: Source and destination port Flow label Source and destination IP Routers MUST NOT modify the UDP header or payload in transit. NAT64 gateways MUST update inner hop limit as well as UDP Port numbers and checksum as specified in this document. Other than that no part of the UDP header or payload may be modified in transit. The minimum hop limit of originated packets was chosen as 63 to allow the default value of most currently deployed implementations to work without changes. The values in the range 1 to 63 has been split evenly between the three legs of communication separated by the NAT64 gateways. This is done to ensure that packets reach their destination even if a small number of intermediate network nodes erroneously decrement the inner hop limit when they shouldn't.

NAT64TP endpoints will in some cases work even if neither NAT64 gateway supports NAT64TP. And if and endpoint combines NAT64TP with traditional hole punching techniques it can achieve similar reliability even if none of the NAT64 gateways support NAT64TP. Those properties make it worthwhile for endpoints to support NAT64TP even when only a minority of NAT64 gateways support NAT64TP. Due to the similarity between NAT64TP and it only takes minimal effort to extend existing NAT64 implementations to support NAT64TP. Because NAT64TP needs no state there is an incentive to deploy it in order to save on state tracking. NAT64TP needs just a single port which cannot be used for stateful connections. Thus it only takes two NAT64TP users before NAT64TP support uses fewer ports than stateful NAT64. And since NAT64TP can achieve reliability when supported by just one side of the communication, there is an incentive to deploy it even if other NAT64 gateways haven't deployed it yet.

If a reliable native IPv6 path exist between a pair of endpoints the traffic between those endpoints SHOULD prefer that network path over those network paths involving NAT64 gateways translating the outer header from IPv6 to IPv4 and back. This allows for NAT64 gateways to be turned down when they are no longer needed for reaching IPv4-only networks/services.

This document specifies the NAT64TP layer. Endpoints MUST implement a higher layer on top of NAT64TP. Any protocol which can run on IPv6 could be used but for security it MUST be one which takes proper steps to protect confidentiality and integrity. To protect against DoS attacks by looping packets through a pair of NAT64 gateways it is important for gateways implementing NAT64TP to handle hop limit on the incoming path exactly as defined in this document. This protocol is not intending to hide the origin of packets. The source IP which a packet had before translation can always be deduced by the contents of the packet after translation.

One UDP port number for the NAT64TP protocol needs to be allocated by IANA.