idnits 2.17.1 draft-farinacci-lisp-simple-nat-04.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 : ---------------------------------------------------------------------------- == There are 1 instance of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 1, 2022) is 727 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-15) exists of draft-farinacci-lisp-name-encoding-14 == Outdated reference: A later version (-38) exists of draft-ietf-lisp-rfc6830bis-36 == Outdated reference: A later version (-31) exists of draft-ietf-lisp-rfc6833bis-30 ** Obsolete normative reference: RFC 1700 (Obsoleted by RFC 3232) Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Farinacci 3 Internet-Draft lispers.net 4 Intended status: Informational May 1, 2022 5 Expires: November 2, 2022 7 A Simple LISP NAT-Traversal Implementation 8 draft-farinacci-lisp-simple-nat-04 10 Abstract 12 This informational draft documents the lispers.net LISP NAT-Traversal 13 implementation. 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 November 2, 2022. 32 Copyright Notice 34 Copyright (c) 2022 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. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 4 51 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 6 52 4. Protocol Messages . . . . . . . . . . . . . . . . . . . . . . 7 53 5. xTR Map-Registering and Map-Server Proxy Map-Replying . . . . 10 54 6. Packet Flow from ITR-behind-NAT to RTR . . . . . . . . . . . 11 55 7. Packet Flow from Remote ITR to RTR . . . . . . . . . . . . . 11 56 8. Packet Flow from RTR to ETR-behind-NAT . . . . . . . . . . . 11 57 9. Design Observations . . . . . . . . . . . . . . . . . . . . . 13 58 10. Security Considerations . . . . . . . . . . . . . . . . . . . 14 59 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 60 12. Normative References . . . . . . . . . . . . . . . . . . . . 14 61 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 15 62 Appendix B. Document Change Log . . . . . . . . . . . . . . . . 15 63 B.1. Changes to draft-farinacci-lisp-simple-nat-04 . . . . . . 15 64 B.2. Changes to draft-farinacci-lisp-simple-nat-03 . . . . . . 15 65 B.3. Changes to draft-farinacci-lisp-simple-nat-02 . . . . . . 15 66 B.4. Changes to draft-farinacci-lisp-simple-nat-01 . . . . . . 16 67 B.5. Changes to draft-farinacci-lisp-simple-nat-00 . . . . . . 16 68 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16 70 1. Introduction 72 This draft documents the LISP messages and protocol procedures for a 73 simple mechanism for the NAT Traversal problem. A subset of message 74 definitions and protocol procedures are taken from 75 [I-D.ermagan-lisp-nat-traversal]. This design was first implemented 76 in the lispers.net LISP implementation dating back to January 2014. 78 The procedures described in this document are performed by LISP 79 compliant [I-D.ietf-lisp-rfc6830bis] [I-D.ietf-lisp-rfc6833bis] xTRs 80 that reside on the private side of one or more NAT devices that 81 connect them to the public side of the network. 83 The solution is applicable to the following xTR deployments: 85 o A physical ITR/ETR device that is directly connected or multiple 86 hops away from a NAT device. 88 o A LISP-MN acting as an ITR/ETR device on an cellular service where 89 a mobile provider is providing a NAT function. 91 o A logical ITR/ETR that resides in a VM that is behind a NAT device 92 managed by a hypervisor or cloud provider. 94 o A logical ITR/ETR that resides in a container where a NAT function 95 is provided by the container service. 97 o The above xTR deployments can operate through multiple levels of 98 NATs. 100 o The above deployments are also applicable to RTR and PxTR devices 101 that may reside behind NAT devices. 103 o The lispers.net lig [RFC6835] implementation uses the protocol 104 messaging defined in this draft so any system behind a NAT (either 105 running as a LISP xTR or not running LISP at all), can query the 106 mapping system to obtain mappings for network maintenance and 107 troubleshooting. 109 2. Definition of Terms 111 Routing Locator (RLOC): an RLOC address is a routable address on the 112 public Internet. It is used by LISP to locate where EIDs are 113 topologically located and appears in the outer header of LISP 114 encapsulated packets. With respect to this design, an RLOC can be 115 a private or public address. Private RLOCs can be registered to 116 the LISP mapping system so they can be used by other LISP xTRs 117 which reside in the same private network. Public RLOCs can be 118 registered to the LISP mapping system and are used by LISP xTRs 119 that are on the public side of the network. 121 Network Address Translator (NAT): is a router type device that 122 isolates a private network from a public network. The addresses 123 used on the private side of a network are known as private 124 addresses and are not routable on the public side of the network. 125 Therefore, a NAT device must translate private addresses to public 126 addresses. In this document, xTRs that reside on the private side 127 of the network use private RLOCs. These RLOCs must be translated 128 to public addresses so they can be registered in the LISP mapping 129 system. 131 Private RLOC: is the IP address of the interface of an xTR that 132 faces outbound towards a NAT device. This address is typically 133 translated to a public RLOC address before the packet appears on 134 the public side of the network. 136 Ephemeral Port: is the UDP source port in a LISP data-plane or 137 control-plane message. This address is typically translated by a 138 NAT device when the packet goes from the private side of the NAT 139 device to the public side of the network. 141 Global RLOC: is an address that has been translated by a NAT device. 142 The Private RLOC is translated to a Global RLOC and is registered 143 to the mapping system. This RLOC will be the source address in 144 LISP encapsulated packets on the public side of the network. 146 Translated Port: is the Ephemeral Port that is translated by a NAT 147 device. For an xTR outgoing packet, the source Ephemeral Port is 148 translated to a source Translated Port seen by the public side of 149 the network. For an incoming packet, the NAT device translates 150 the destination Translated Port to the destination Ephemeral Port. 152 Re-encapsulating Tunnel Router (RTR): is a LISP network element that 153 receives a LISP encapsulated packet, strips the outer header and 154 prepends a new outer header. With respect to this NAT-Traversal 155 design, an ITR (either behind a NAT device or on the public 156 network) encapsulates a packet to the RTR's RLOC address. The RTR 157 strips this ITR prepended header and then prepends a its own new 158 outer header and sends packet to the RLOC address of an ETR that 159 registered the EID that appears as the destination address from 160 the inner header. 162 NAT Info Cache: is a data structure managed by an RTR to track xTR 163 hostname, Global RLOC and Translated Port information. The RTR 164 uses this table so it knows what is the destination port to be 165 used for LISP encapsulated packets that much travel through a NAT 166 device. 168 Address Family Identifier (AFI): a term used to describe an address 169 encoding in a packet [AFI] and [RFC1700]. All LISP control 170 messages use AFI encoded addresses. The AFI value is 16-bits in 171 length and precedes all LISP encoded addresses. In this document, 172 the design calls for AFI encodings for IPv4 and IPv6 addresses as 173 well as Distinguished-Name [I-D.farinacci-lisp-name-encoding] and 174 LCAF [RFC8060] address formats. 176 3. Overview 178 The following sequence of actions describes at a high-level how the 179 lispers.net implementation performs NAT-Traversal and is the basis 180 for a simplified NAT-Traversal protocol design. 182 1. An xTR sends a Info-Request message to port 4342 to its 183 configured Map-Servers so it can get a list of RTRs to be used 184 for NAT-Traversal. 186 2. The Map-Servers return an Info-Reply message with the list of 187 RTRs. 189 3. The xTR then sends an Info-Request message to port 4341 to each 190 RTR. 192 4. Each RTR caches the translated RLOC address and port in a NAT 193 Info Cache. At this point, the NAT device has created state to 194 allow the RTR to send encapsulated packets from port 4341 to the 195 translated port. 197 5. The RTR returns an Info-Reply message so the xTR can learn its 198 translated Global RLOC address and Translated Port. 200 6. The xTR registers its EID-prefixes with an RLOC-set that 201 contains all its global RLOCs as well as the list of RTRs it has 202 learned from Info-Reply messages. 204 7. The Map-Servers are configured to proxy Map-Reply for these 205 registered EID-prefixes. 207 8. When a remote ITR sends a Map-Request for an EID that matches 208 one of these EID-prefixes, the Map-Server returns a partial 209 RLOC-set which contain only the list of RTRs. The remote ITR 210 encapsulates packets to the RTRs. 212 9. When one of the RTRs send a Map-Request for an EID that matches 213 one of these EID-prefixes, the Map-Server returns a partial 214 RLOC-set which contain only the global RLOCs so the RTR can 215 encapsulate packets that will make it through the NAT device to 216 the xTR. 218 10. The xTR behind a NAT device only stores default map-cache 219 entries with an RLOC-set that contain the list of RTRs the Map- 220 Server supplied it with. The xTR load-splits traffic across the 221 RTRs based on the 5-tuple hash algorithm detailed in 222 [I-D.ietf-lisp-rfc6830bis]. 224 4. Protocol Messages 226 The lispers.net implementation uses the Info-Request and Info-Reply 227 messages from [I-D.ermagan-lisp-nat-traversal] as well as the NAT- 228 Traversal LISP Canonical Address Format (LCAF) from [RFC8060]. 230 0 1 2 3 231 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 |Type=7 |0| Reserved | 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 | Nonce . . . | 236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 237 | . . . Nonce | 238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 239 | Key ID | Authentication Data Length | 240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 241 ~ Authentication Data ~ 242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 243 | TTL | 244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 | Reserved | EID mask-len | EID-prefix-AFI | 246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 247 | EID-prefix | 248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 249 | AFI = 0 | | 250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 LISP Info-Request Message Format 254 The lispers.net implementation will send an Info-Request message to 255 each configured Map-Server. The message is sent to UDP destination 256 port 4342 which is the control-plane port for LISP 257 [I-D.ietf-lisp-rfc6833bis] from a UDP ephemeral source port. The 258 source address is its Private RLOC. When the xTR is multi-homed to 259 more than one NAT device, it sends the Info-Request on all interfaces 260 facing NAT devices. 262 A randomized 64-bit nonce is selected for the message and no 263 authentication is used. The EID-prefix AFI is 17 according to the 264 encoding format in [I-D.farinacci-lisp-name-encoding] and the EID- 265 prefix is the hostname of the xTR encoded as a string null 266 terminated. 268 An Info-Request is sent out each outgoing interface, with the address 269 of that interface as the Private RLOC, leading to a NAT device. The 270 port pair in the UDP message is the same for each outgoing interface. 272 When the xTR receives an Info-Reply message from the Map-Server in 273 response to this control-plane Info-Request, it caches a list of RTRs 274 from the Info-Reply. If the list of RTRs are different from each 275 Map-Server, the lists are merged. The xTR stores the merged list as 276 the RLOC-set for 4 default map-cache entries. The map-cache entries 277 have the following EID-prefixes: 279 IPv4 unicast: 0.0.0.0/0 280 IPv4 multicast: (0.0.0.0/0, 224.0.0.0/4) 281 IPv6 unicast: 0::/0 282 IPv6 multicast: (0::/0, ff00::/8) 284 Now that the xTR has a list of RTRs, it sends a data-plane Info- 285 Request to each RTR to UDP destination port 4341 from a UDP ephemeral 286 source port. The data-plane Info-Request is sent out each interface 287 just like the control-plane Info-Request was sent for the multi-homed 288 NAT device case. 290 When Map-Servers and RTRs return an Info-Reply message to xTRs behind 291 NAT devices, the format of the Info-Reply message is the following: 293 0 1 2 3 294 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 296 |Type=7 |1| Reserved | 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 | Nonce . . . | 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 | . . . Nonce | 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 | Key ID | Authentication Data Length | 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 304 ~ Authentication Data ~ 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 | TTL | 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 308 | Reserved | EID mask-len | EID-prefix-AFI | 309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 310 | EID-prefix | 311 +->+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 312 | | AFI = 16387 | Rsvd1 | Flags | 313 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 314 | | Type = 7 | Rsvd2 | 4 + n | 315 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 316 N | MS UDP Port Number | ETR UDP Port Number | 317 A +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 318 T | AFI = x | Global ETR RLOC Address ... | 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 L | AFI = x | MS RLOC Address ... | 321 C +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 322 A | AFI = x | Private ETR RLOC Address ... | 323 F +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 324 | | AFI = x | RTR RLOC Address 1 ... | 325 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 326 | | AFI = x | RTR RLOC Address n ... | 327 +->+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 329 LISP Info-Reply Message Format 331 The information returned is the same information that was sent in the 332 Info-Request message except the Info-Reply bit is set (the bit next 333 to Type=7) and the NAT Traversal LCAF encoding is appended. 335 When a Map-Server returns the Info-Reply, the MS UDP Port Number and 336 ETR UDP Port Number is set to 0. All Address fields are empty by 337 using AFI equal to 0. Except for the RTR RLOC address fields which 338 the Map-Server is configured to return to xTRs behind NAT devices. 340 When an RTR returns the Info-Reply, the MS UDP Port Number is set to 341 0 and the ETR UDP Port Number is set to the UDP source port the RTR 342 received from the Info-Request message. The Global ETR RLOC Address 343 is set to the source address received by the RTR in the Info-Request 344 message. All other address fields are empty by using AFI equal to 0. 346 5. xTR Map-Registering and Map-Server Proxy Map-Replying 348 EID-prefixes registered by an xTR behind a NAT include all the global 349 RLOCs and RTR RLOCs it learns. The xTR can use the unicast priority 350 to control ingress packet flow as described in 351 [I-D.ietf-lisp-rfc6833bis]. The RTR RLOCs must be registered with a 352 unicast priority of 254 so the Map-Server can identify xTR global 353 RLOCs from RTR RLOCs when proxy Map-Replying. 355 The Global RLOCs are encoded in a RLOC-record using the AFI-List LCAF 356 encoding [RFC8060]. There are two AFI encoded addresses in the list, 357 one being AFI=1 which encodes the IPv4 translated NAT address and 358 other being the Distinguished-Name AFI=17 359 [I-D.farinacci-lisp-name-encoding] which encodes the hostname of the 360 xTR. When the xTR is multi-homed, the hostname is appended by a 361 unique interface name. For example, for an xTR behind a NAT that has 362 two interfaces facing the same or two different NAT devices, the 363 Distinguished-Name for each RLOC-record could be "dino-xtr-eth0" and 364 "dino-xtr-eth1" for an xTR configured to be named "dino-xtr". 366 Encoding a Distinguished-Name in an RLOC-record is important so an 367 RTR can use the Global RLOC registered to the mapping system with the 368 translated port stored in its NAT Info Cache. See Section 8 for more 369 details. 371 When a remote ITR sends a Map-Request for a unicast or multicast EID 372 registered by a xTR behind a NAT, the Map-Server returns a partial 373 RLOC-set that contains all the RTRs (RLOC-records with unicast 374 priority 254) in the proxied Map-Reply message. 376 When a RTR sends a Map-Request for a unicast or multicast EID 377 registered by a xTR behind a NAT, the Map-Server returns a partial 378 RLOC-set that contains all the Global RLOCs of the xTR behind the NAT 379 in the proxied Map-Reply message. 381 6. Packet Flow from ITR-behind-NAT to RTR 383 All packets received by the ITR from the private side of the NAT will 384 use one of the 4 default map-cache entries. There is a unicast and 385 multicast IPv4 default EID-prefix and a unicast and multicast IPv6 386 default EID-prefix. The RLOC-set is the same for all 4 entries. The 387 RLOC-set contains the globally reachable RLOCs of the RTRs. 5-tuple 388 hashing is used to load-split traffic across the RTRs. RLOC-Probing 389 is used to avoid encapsulating to unreachable RTRs. 391 7. Packet Flow from Remote ITR to RTR 393 A remote ITR will get a list of RTRs from the mapping system in a 394 proxy Map-Reply when it sends a Map-Request for a unicast or 395 multicast EID that is registered by an xTR behind a NAT device. The 396 remote ITR will load split traffic across the RTRs from the RLOC-set. 397 Those RTRs can get packets through the NAT devices destined for the 398 xTR behind the NAT since an Info-Request/Info-Reply exchange had 399 already happened between the xTR behind the NAT and the list of RTRs. 401 There can be a reachability situation where an RTR cannot reach the 402 xTR behind a NAT but a remote ITR may 5-tuple hash to this RTR. 403 Which means packets can travel from the remote ITR to the RTR but 404 then get dropped on the path from the RTR to the xTR behind the NAT. 405 To avoid this situation, the xTR behind the NAT RLOC-probes RTRs and 406 when they become unreachable, they are not included in the xTR 407 registrations. 409 8. Packet Flow from RTR to ETR-behind-NAT 411 The RTR will receive a list of Global RLOCs in a proxy Map-Reply from 412 the mapping system for the xTR behind the NAT. The RTR 5-tuple load- 413 splits packets across the RLOC-set of Global RLOCs that can travel 414 through one or more NAT devices along the path to the ETR behind the 415 NAT device. 417 When the RTR selects a Global RLOC to encapsulate to it must select 418 the correct Translated Port for the UDP destination port in the 419 encapsulation header. The RTR needs to use the same Translated 420 Address and Translated Port pair a NAT device used to translate the 421 Info-Request message otherwise the encapsulated packet will be 422 dropped. The NAT Info Cache contains an entry for every hostname 423 (and optionally appended interface name), translated address and port 424 cached when processing Info-Request messages. The RTR obtains the 425 correct Translated Port from the NAT Info Cache by using the Global 426 RLOC and RLOC-record hostname from the registered RLOC-set. 428 The RTR can test reachability for xTRs behind NATs by encapsulating 429 RLOC-Probe requests in data packets where the UDP source port is set 430 to 4341 and the UDP destination port is set to the Translated Port. 431 The outer header destination address is the Global RLOC for the xTR. 433 9. Design Observations 435 The following benefits and observations can be attributed to this 436 design: 438 o An ITR behind a NAT virtually runs no control-plane and a very 439 simple data-plane. All it does is RLOC-probe the RTRs in the 440 common RLOC-set for each default map-cache entry. And maintains a 441 very small map-cache of 4 entries per instance-ID it supports. 443 o An xTR behind a NAT can tell if another xTR is behind the same set 444 of NAT devices and use Private RLOCs to reach each other on a 445 short-cut path. It does this by comparing the Global RLOC 446 returned from RTRs in Info-Reply messages. 448 o An xTR behind a NAT is free to send a Map-Request to the mapping 449 system for any EID to test to see if there is a direct path to the 450 LISP site versus potentially using a sub-optimal path through an 451 RTR. This happens when xTRs exist that are not behind NAT devices 452 where their RLOCs are global RLOCs. 454 o By sending Info-Requests to Map-Servers, an xTR behind a NAT can 455 tell if they are reachable and if those Map-Servers also act as 456 Map-Resolvers, the xTR behind the NAT can avoid sending Map- 457 Requests to unreachable Map-Resolvers. 459 o Enhanced data-plane security can be used via LISP-Crypto 460 mechanisms detailed in [RFC8061] using this NAT-Traversal design 461 so both unicast and multicast traffic are encrypted. 463 o This design allows for the minimum amount of NAT device state 464 since only RTRs are encapsulating to ETRs behind NAT devices. 465 Therefore, the number of ITRs sending packets to EIDs behind NAT 466 devices is aggregated out for scale. Scale is also achieved when 467 xTRs behind NATs roam and RLOC-set changes need to update only RTR 468 map-caches. 470 o The protocol procedures in this document can be used when a LISP 471 site has multiple xTRs each connected via separate NAT devices to 472 the public network. Each xTR registers their Global RLOCs and 473 RTRs with merge semantics to the mapping system so remote ITRs can 474 load-split traffic across a merged RTR set as well as RTRs across 475 each xTR behind different NAT devices. 477 10. Security Considerations 479 There are no security considerations at this time. 481 However, the lispers.net implementation can be enhanced easily to 482 allow the same authentication xTRs use with Map-Register messages for 483 Info-Request messages when they send to Map-Servers. 485 For authentication of Info-Requests to RTRs, more work is required to 486 maintain key management associations between xTR behind NATs and 487 RTRs. It is not trivial to make this happen with a dynamic list of 488 RTRs that can change as the xTR behind a NAT roams to other parts of 489 the network and desire shorter paths to RTRs. 491 11. IANA Considerations 493 The code-point values in this specification are already allocated in 494 [AFI] or [RFC8060]. 496 12. Normative References 498 [AFI] "Address Family Identifier (AFIs)", ADDRESS FAMILY 499 NUMBERS http://www.iana.org/numbers.html, Febuary 2007. 501 [I-D.ermagan-lisp-nat-traversal] 502 Ermagan, V., Farinacci, D., Lewis, D., Maino, F., Comeras, 503 M. P., Skriver, J., White, C., Lopez, A., and A. Cabellos, 504 "NAT traversal for LISP", draft-ermagan-lisp-nat- 505 traversal-19 (work in progress), May 2021. 507 [I-D.farinacci-lisp-name-encoding] 508 Farinacci, D., "LISP Distinguished Name Encoding", draft- 509 farinacci-lisp-name-encoding-14 (work in progress), May 510 2022. 512 [I-D.ietf-lisp-rfc6830bis] 513 Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A. 514 Cabellos, "The Locator/ID Separation Protocol (LISP)", 515 draft-ietf-lisp-rfc6830bis-36 (work in progress), November 516 2020. 518 [I-D.ietf-lisp-rfc6833bis] 519 Farinacci, D., Maino, F., Fuller, V., and A. Cabellos, 520 "Locator/ID Separation Protocol (LISP) Control-Plane", 521 draft-ietf-lisp-rfc6833bis-30 (work in progress), November 522 2020. 524 [RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1700, 525 DOI 10.17487/RFC1700, October 1994, 526 . 528 [RFC6835] Farinacci, D. and D. Meyer, "The Locator/ID Separation 529 Protocol Internet Groper (LIG)", RFC 6835, 530 DOI 10.17487/RFC6835, January 2013, 531 . 533 [RFC8060] Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical 534 Address Format (LCAF)", RFC 8060, DOI 10.17487/RFC8060, 535 February 2017, . 537 [RFC8061] Farinacci, D. and B. Weis, "Locator/ID Separation Protocol 538 (LISP) Data-Plane Confidentiality", RFC 8061, 539 DOI 10.17487/RFC8061, February 2017, 540 . 542 Appendix A. Acknowledgments 544 The author would like to thank the authors of the LISP NAT-Traversal 545 specification [I-D.ermagan-lisp-nat-traversal] for their initial 546 ideas and prototyping to allow a simpler form of NAT-Traversal to be 547 designed. 549 Appendix B. Document Change Log 551 B.1. Changes to draft-farinacci-lisp-simple-nat-04 553 o Posted May 2022. 555 o Update document timer. 557 B.2. Changes to draft-farinacci-lisp-simple-nat-03 559 o Posted November 2021. 561 o Update document timer. 563 B.3. Changes to draft-farinacci-lisp-simple-nat-02 565 o Posted May 2021. 567 o Update document timer. 569 B.4. Changes to draft-farinacci-lisp-simple-nat-01 571 o Posted November 2020. 573 o Update document timer. 575 B.5. Changes to draft-farinacci-lisp-simple-nat-00 577 o Posted May 2020. 579 o Initial posting. 581 Author's Address 583 Dino Farinacci 584 lispers.net 585 San Jose, CA 586 USA 588 Email: farinacci@gmail.com