Network Working Group K. Dupont Internet-Draft November 29, 2020 Intended status: Standards Track Expires: June 2, 2021 NAT64 Tunnel Protocol draft-dupont-6man-nat64tp-01 Abstract This document describes a stateless NAT64 extension which allows for creation of reliable tunnels between islands of IPv6 deployment. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on June 2, 2021. Copyright Notice Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Dupont Expires June 2, 2021 [Page 1] Internet-Draft NAT64TP November 2020 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Communication model . . . . . . . . . . . . . . . . . . . . . 3 4. Protocol operation . . . . . . . . . . . . . . . . . . . . . 4 4.1. NAT64 outgoing operation . . . . . . . . . . . . . . . . 4 4.2. NAT64 incoming operation . . . . . . . . . . . . . . . . 5 4.3. NAT64TP endpoint operation . . . . . . . . . . . . . . . 5 4.4. Intermediate network node operation . . . . . . . . . . . 7 5. Deployability . . . . . . . . . . . . . . . . . . . . . . . . 8 5.1. Sunsetting IPv4 . . . . . . . . . . . . . . . . . . . . . 8 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 8.1. Normative References . . . . . . . . . . . . . . . . . . 9 8.2. Informative References . . . . . . . . . . . . . . . . . 9 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 1. Introduction Prior protocols for connecting islands of IPv6 through tunnels over IPv4 exist including [RFC3056]. 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 [RFC6146] 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. [RFC6146] 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 Dupont Expires June 2, 2021 [Page 2] Internet-Draft NAT64TP November 2020 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 [RFC6146] in very minor ways such that it can 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. 2. Terminology NAT64: A dual-stack node translating TCP and UDP according to [RFC6146] 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 3. Communication model NAT64TP packets are IPv6 packets encapsulated in UDP. The UDP packets are translated by NAT64 gateways according to slightly different rules than [RFC6146]. Dupont Expires June 2, 2021 [Page 3] Internet-Draft NAT64TP November 2020 +---------------------------------------------------+ | IPv4 backbone | +---------------------------------------------------+ | | | | | | | | +---------+ +---------+ +---------+ +---------+ | NAT64 | | NAT64 | | NAT64 | | NAT64 | +---------+ +---------+ +---------+ +---------+ | | | | | | | | +----------------------+ +----------------------+ | Endpoint | | Endpoint | +----------------------+ +----------------------+ Figure 1: The communication model 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. 4. Protocol operation 4.1. NAT64 outgoing operation 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 length field MUST have the same value as the payload length field in the outer IPv6 header. The UDP length field MUST be exactly 48 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. Dupont Expires June 2, 2021 [Page 4] Internet-Draft NAT64TP November 2020 A packet which matches all of the validations performed MUST be translated statelessly. The outer source IP and destionation IP are translated as in [RFC6146]. 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. 4.2. NAT64 incoming operation 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 IPv4 total length field MUST be equal to the sum of the IPv4 header length and the UDP length. The UDP length field MUST be exactly 48 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 [RFC6146]. 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. 4.3. NAT64TP endpoint operation 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 Dupont Expires June 2, 2021 [Page 5] Internet-Draft NAT64TP November 2020 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. The UDP header MUST have a valid checksum. 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. Dupont Expires June 2, 2021 [Page 6] Internet-Draft NAT64TP November 2020 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. 4.4. Intermediate network node operation 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 Dupont Expires June 2, 2021 [Page 7] Internet-Draft NAT64TP November 2020 destination even if a small number of intermediate network nodes erroneously decrement the inner hop limit when they shouldn't. 5. Deployability NAT64TP endpoints will in some cases work even if neither NAT64 gateway supports NAT64TP. 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 [RFC6146] 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. 5.1. Sunsetting IPv4 If a reliable native IPv6 path exists 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. 6. Security Considerations 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. Dupont Expires June 2, 2021 [Page 8] Internet-Draft NAT64TP November 2020 7. IANA Considerations One UDP port number for the NAT64TP protocol needs to be allocated by IANA. Service Name: NAT64TP Transport Protocol(s): UDP Description: NAT64 Tunnel Protocol Reference: This document. Port Number: TBD -- To be assigned by IANA. 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, April 2011, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 8.2. Informative References [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, DOI 10.17487/RFC3056, February 2001, . Author's Address Kasper Dupont Ellemosevaenget 31 Tranbjerg J. 8310 Denmark Email: kasperd@ntstm.30.mar.2019.kasperd.dk Dupont Expires June 2, 2021 [Page 9]