idnits 2.17.1 draft-dupont-6man-nat64tp-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 29, 2020) is 1236 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group K. Dupont 3 Internet-Draft November 29, 2020 4 Intended status: Standards Track 5 Expires: June 2, 2021 7 NAT64 Tunnel Protocol 8 draft-dupont-6man-nat64tp-02 10 Abstract 12 This document describes a stateless NAT64 extension which allows for 13 creation of reliable tunnels between islands of IPv6 deployment. 15 Status of This Memo 17 This Internet-Draft is submitted in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF). Note that other groups may also distribute 22 working documents as Internet-Drafts. The list of current Internet- 23 Drafts is at https://datatracker.ietf.org/drafts/current/. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 This Internet-Draft will expire on June 2, 2021. 32 Copyright Notice 34 Copyright (c) 2020 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents 39 (https://trustee.ietf.org/license-info) in effect on the date of 40 publication of this document. Please review these documents 41 carefully, as they describe your rights and restrictions with respect 42 to this document. Code Components extracted from this document must 43 include Simplified BSD License text as described in Section 4.e of 44 the Trust Legal Provisions and are provided without warranty as 45 described in the Simplified BSD License. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 50 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 3. Communication model . . . . . . . . . . . . . . . . . . . . . 3 52 4. Protocol operation . . . . . . . . . . . . . . . . . . . . . 4 53 4.1. NAT64 outgoing operation . . . . . . . . . . . . . . . . 4 54 4.2. NAT64 incoming operation . . . . . . . . . . . . . . . . 5 55 4.3. NAT64TP endpoint operation . . . . . . . . . . . . . . . 5 56 4.4. Intermediate network node operation . . . . . . . . . . . 7 57 5. Deployability . . . . . . . . . . . . . . . . . . . . . . . . 8 58 5.1. Sunsetting IPv4 . . . . . . . . . . . . . . . . . . . . . 8 59 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 60 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 61 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 62 8.1. Normative References . . . . . . . . . . . . . . . . . . 9 63 8.2. Informative References . . . . . . . . . . . . . . . . . 9 64 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 66 1. Introduction 68 Prior protocols for connecting islands of IPv6 through tunnels over 69 IPv4 exist including [RFC3056]. However since the introduction of 70 those protocols NAT has gained widespread use and a majority of ISPs 71 still have not started deploying IPv6. For those reasons there is a 72 need for a new way of connecting islands of IPv6. 74 NAT64 as defined in [RFC6146] is a method for translating between 75 IPv6 and IPv4. This is intended to allow IPv6-only clients to reach 76 IPv4-only services. NAT64 also happens to be very useful for 77 connecting islands of IPv6 to an IPv4-only ISP. Moreover high 78 availability can easily be achieved by connecting an island of IPv6 79 through redundant NAT64 gateways to multiple ISPs. 81 Many prior tunnel protocols fail to work reliably when one endpoint 82 of the tunnel is behind NAT. And none of them work reliably when 83 both endpoints are behind NAT64. 85 [RFC6146] specifies support for use of UDP, TCP, and ICMP. Of those 86 only UDP is suitable for building a tunnel protocol. But when both 87 endpoints are connecting through NAT the use of hole punching will be 88 necessary. And in many NAT setups, especially those using multiple 89 layers of NAT, the use of hole punching is unreliable. Even when 90 these work they rely on state in each NAT device in order to maintain 91 a connection. 93 This document defines NAT64TP (the NAT64 Tunnel Protocol). NAT64TP 94 is a simple stateless NAT64 extension which allows tunnel protocols 95 to reliably establish connections between islands of IPv6. NAT64TP 96 achieves this by using UDP packets in which each packet carries 97 enough information in their UDP payload to route them to their 98 destination with no state being maintained. 100 NAT64TP only differs from [RFC6146] in very minor ways such that it 101 can easily be added to existing NAT64 implementations. This also 102 allows NAT64TP to achieve reliability when only a subset of the 103 involved NAT64 gateways implement NAT64TP. 105 2. Terminology 107 NAT64: A dual-stack node translating TCP and UDP according to 108 [RFC6146] and optionally implementing the NAT64TP protocol as 109 specified in this document. 111 NAT64TP: The NAT64 Tunnel Protocol is the extension for NAT64 defined 112 in this document. 114 Endpoint: An IPv6-only or dual-stack node which implements a higher 115 level protocol on top of the NAT64TP protocol as specified in this 116 document. 118 Outer IP header: The IP header in front of the UDP header which gets 119 translated from IPv6 to IPv4 and back during transmission. 121 Inner IPv6 header: The IP header at the start of the UDP payload. 123 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 124 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 125 "OPTIONAL" in this document are to be interpreted as described in 126 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, 127 as shown here. 129 3. Communication model 131 NAT64TP packets are IPv6 packets encapsulated in UDP. The UDP 132 packets are translated by NAT64 gateways according to slightly 133 different rules than [RFC6146]. 135 +---------------------------------------------------+ 136 | IPv4 backbone | 137 +---------------------------------------------------+ 138 | | | | 139 | | | | 140 +---------+ +---------+ +---------+ +---------+ 141 | NAT64 | | NAT64 | | NAT64 | | NAT64 | 142 +---------+ +---------+ +---------+ +---------+ 143 | | | | 144 | | | | 145 +----------------------+ +----------------------+ 146 | Endpoint | | Endpoint | 147 +----------------------+ +----------------------+ 148 Figure 1: The communication model 150 Each endpoint has access to one or more NAT64 gateways which allow 151 for communication through the IPv4 backbone. For redundancy the 152 NAT64 gateways can connect to different IPv4 providers. At least one 153 of the NAT64 gateways SHOULD support the NAT64TP protocol as 154 specified in this document. 156 4. Protocol operation 158 4.1. NAT64 outgoing operation 160 Upon receiving an UDPv6 packet with source port TBD the NAT64 MUST 161 validate that the packet is a valid NAT64TP packet. 163 The UDP payload length MUST be at least 40 octets. 165 The inner IP version field MUST contain the value 6. 167 The inner source IP MUST be identical to the outer source IP. 169 The NAT64 MAY additionally validate the following fields. 171 The UDP length field MUST have the same value as the payload 172 length field in the outer IPv6 header. 174 The UDP length field MUST be exactly 48 octets plus the payload 175 length specified in the inner IPv6 header. 177 The inner hop limit MUST be in the range 43 to 255. 179 A UDPv6 packet with source port TBD which fails any of the 180 validations performed MUST be either dropped or translated as regular 181 stateful NAT64. If the packet is dropped the NAT64 MAY generate an 182 ICMPv6 error message. 184 A packet which matches all of the validations performed MUST be 185 translated statelessly. The outer source IP and destionation IP are 186 translated as in [RFC6146]. The UDP source and destination port MUST 187 remain unchanged after translation. If the inner hop limit was 188 validated it SHOULD be reduced to 42. 190 If the UDP header has a checksum it MUST be adjusted to reflect all 191 of the changes made to the packet. 193 4.2. NAT64 incoming operation 195 Upon receiving an UDPv4 packet with destination port TBD the NAT64 196 MUST validate that the packet is a valid NAT64TP packet. 198 The UDP payload length MUST be at least 40 octets. 200 The inner IP version field MUST contain the value 6. 202 The inner hop limit MUST be in the range 22 to 255. 204 The NAT64 MAY additionally validate the following field. 206 The IPv4 total length field MUST be equal to the sum of the IPv4 207 header length and the UDP length. 209 The UDP length field MUST be exactly 48 octets plus the payload 210 length specified in the inner IPv6 header. 212 A UDPv4 packet with destination port TBD which fails any of the 213 validations performed MUST be dropped. The NAT64 MAY generate an 214 ICMP error message. 216 A packet which matches all of the validations performed MUST be 217 translated statelessly. The outer source IP is translated as in 218 [RFC6146]. The inner destination IP is copied to the outer 219 destination IP. The UDP source and destination port MUST remain 220 unchanged after translation. The inner hop limit MUST be reduced to 221 21. 223 If the UDP header has a checksum it must be adjusted to reflect all 224 of the changes made to the packet. If the UDP packet has no checksum 225 a checksum must be computed over the resulting packet. 227 4.3. NAT64TP endpoint operation 229 NAT64TP is a layer of the networking stack. Like IP and UDP this 230 layer is intended as basis on which to build higher layer protocols. 231 The higher layer protocols to be used over NAT64TP are generally 232 expected to be a VPN or something resembling it. The full 233 specification of the higher layer protocol is outside the scope of 234 this document. 236 The intermediate NAT64 gateways only need to implement the NAT64TP 237 layer as specified in this document and need no knowledge of the 238 higher layer. Inspection of the higher layer protocols won't even be 239 possible for the NAT64 gateways due to the encryption used by the VPN 240 layer. 242 NAT64TP endpoints MUST comply with both the sepcification in this 243 document and the specification of the higher layer protocol which 244 they implement. 246 When originating a NAT64TP packet the endpoint MUST construct a 247 header chain consisting of at least three headers: Outer IPv6 header, 248 UDP header, and inner IPv6 header. The headers MUST satisfy the 249 following requirements: 251 All three headers MUST have consistent length information which 252 agrees on which octet is the last of the packet. 254 Inner and outer IPv6 headers MUST have identical source address. 256 Outer IPv6 header MUST have next header 17 (UDP). 258 The UDP header MUST have source port TBD. 260 The UDP header MUST have a valid checksum. 262 Inner IPv6 header MUST have a hop limit in the range 63 to 255. 264 Packets originated from a NAT64TP endpoint SHOULD be at most 1280 265 octets including the outer IPv6 header. When larger payloads are 266 needed the NAT64TP endpoint SHOULD either use a fragment header 267 following the inner IPv6 header or implement fragmentation at a 268 higher protocol layer. 270 When receiving a NAT64TP paket the endpoint MUST accept packets with 271 any outer source IP and any UDP source port. The higher layer 272 protocol MUST validate the authenticity and integrity of the packet 273 based on the payload of the inner IPv6 packet. 275 When receiving a valid NAT64TP packet from an unknown outer source IP 276 and UDP source port combination the endpoint SHOULD learn this source 277 address as a possible network path for return traffic. If the outer 278 source IP is within a known NAT64 prefix, the endpoint SHOULD attempt 279 recombining the embedded IPv4 address with other known NAT64 prefixes 280 to learn alternative network paths. 282 When sending packets over a learned network path the higher layer 283 protocol MUST take steps to guard against hijacking of traffic. 284 These steps MAY include: preference for paths with lowest latency and 285 encryption and digital signatures applied to payload data. 287 When choosing between possible network paths for sending a packet an 288 endpoint SHOULD include the inner destination IP and port TBD as one 289 of the possible options for filling in outer destination IP and 290 destination UDP port. 292 The configuration of an endpoint SHOULD allow for at least the 293 following two ways of configuring available network paths to a peer: 295 A list of NAT64 prefixes available to the local endpoint and a 296 list of IPv4 addresses of NAT64TP gateways available to the remote 297 endpoint. All combinations of these combined with destination 298 port TBD should be considered possible network paths. 300 A list of full IPv6 address and port number combinations for 301 network paths which doesn't follow the above scheme or where the 302 length of the NAT64 prefix being used isn't known. 304 An endpoint implementation SHOULD have the ability to send periodic 305 probe packets across its prefered network paths. If probe packets 306 are lost the endpoint SHOULD try alternative paths known to the same 307 destination. These probes additionally serve the purpose of keeping 308 alive state in case either NAT64 is stateful and doesn't implement 309 NAT64TP. 311 4.4. Intermediate network node operation 313 Routers on the network path between the endpoints only need to 314 consider the outer IP header in their routing decisions. Routers MAY 315 include the following fields from the UDP header and inner IPv6 316 header in ECMP hashes: 318 Source and destination port 320 Flow label 322 Source and destination IP 324 Routers MUST NOT modify the UDP header or payload in transit. 326 NAT64 gateways MUST update inner hop limit as well as UDP Port 327 numbers and checksum as specified in this document. Other than that 328 no part of the UDP header or payload may be modified in transit. 330 The minimum hop limit of originated packets was chosen as 63 to allow 331 the default value of most currently deployed implementations to work 332 without changes. The values in the range 1 to 63 has been split 333 evenly between the three legs of communication separated by the NAT64 334 gateways. This is done to ensure that packets reach their 335 destination even if a small number of intermediate network nodes 336 erroneously decrement the inner hop limit when they shouldn't. 338 5. Deployability 340 NAT64TP endpoints will in some cases work even if neither NAT64 341 gateway supports NAT64TP. If and endpoint combines NAT64TP with 342 traditional hole punching techniques it can achieve similar 343 reliability even if none of the NAT64 gateways support NAT64TP. 344 Those properties make it worthwhile for endpoints to support NAT64TP 345 even when only a minority of NAT64 gateways support NAT64TP. 347 Due to the similarity between NAT64TP and [RFC6146] it only takes 348 minimal effort to extend existing NAT64 implementations to support 349 NAT64TP. Because NAT64TP needs no state there is an incentive to 350 deploy it in order to save on state tracking. NAT64TP needs just a 351 single port which cannot be used for stateful connections. Thus it 352 only takes two NAT64TP users before NAT64TP support uses fewer ports 353 than stateful NAT64. And since NAT64TP can achieve reliability when 354 supported by just one side of the communication, there is an 355 incentive to deploy it even if other NAT64 gateways haven't deployed 356 it yet. 358 5.1. Sunsetting IPv4 360 If a reliable native IPv6 path exists between a pair of endpoints the 361 traffic between those endpoints SHOULD prefer that network path over 362 those network paths involving NAT64 gateways translating the outer 363 header from IPv6 to IPv4 and back. 365 This allows for NAT64 gateways to be turned down when they are no 366 longer needed for reaching IPv4-only networks/services. 368 6. Security Considerations 370 This document specifies the NAT64TP layer. Endpoints MUST implement 371 a higher layer on top of NAT64TP. Any protocol which can run on IPv6 372 could be used but for security it MUST be one which takes proper 373 steps to protect confidentiality and integrity. 375 To protect against DoS attacks by looping packets through a pair of 376 NAT64 gateways it is important for gateways implementing NAT64TP to 377 handle hop limit on the incoming path exactly as defined in this 378 document. 380 This protocol is not intending to hide the origin of packets. The 381 source IP which a packet had before translation can always be deduced 382 by the contents of the packet after translation. 384 7. IANA Considerations 386 One UDP port number for the NAT64TP protocol needs to be allocated by 387 IANA. 389 Service Name: NAT64TP 390 Transport Protocol(s): UDP 391 Description: NAT64 Tunnel Protocol 392 Reference: This document. 393 Port Number: TBD -- To be assigned by IANA. 395 8. References 397 8.1. Normative References 399 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 400 Requirement Levels", BCP 14, RFC 2119, 401 DOI 10.17487/RFC2119, March 1997, 402 . 404 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 405 NAT64: Network Address and Protocol Translation from IPv6 406 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, 407 April 2011, . 409 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 410 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 411 May 2017, . 413 8.2. Informative References 415 [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains 416 via IPv4 Clouds", RFC 3056, DOI 10.17487/RFC3056, February 417 2001, . 419 Author's Address 421 Kasper Dupont 422 Ellemosevaenget 31 423 Tranbjerg J. 8310 424 Denmark 426 Email: kasperd@ntstm.30.mar.2019.kasperd.dk