NAT64 Tunnel ProtocolEllemosevænget 31Tranbjerg J.8310Denmarkkasperd@ntstm.30.mar.2019.kasperd.dk
This document describes a stateless NAT64 extension which
allows for creation of reliable tunnels between islands of
IPv6 deployment.
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 portFlow labelSource 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.