Internet-Draft NAT June 2024
Farinacci Expires 19 December 2024 [Page]
Network Working Group
Intended Status:
D. Farinacci LISP NAT-Traversal Implementation Report


This memo documents the implementation of LISP NAT traversal functionality. The document describes message formats and protocol semantics necessary to interoperate with the implementation. This memo is not a standard and does not reflect IETF consensus.

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

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 19 December 2024.

Table of Contents

1. Introduction

This document is an implementation report of a simple mechanism for LISP NAT-Traversal functionality developed by Many ideas in the implementation are taken from [I-D.ermagan-lisp-nat-traversal]. This design was first implemented in the LISP implementation dating back to January 2014.

This implementation of NAT-traversal is not intended to interoperate with [I-D.ermagan-lisp-nat-traversal]. Parts of the implementation may interoperate with ITRs but likely to not interoperate with ETRs. See details about this later in the document.

The implementation takes an approach to use an RLOC-name set to "" in RLOC records to identify RLOC addresses of RTRs by Map-Registering xTRs and Map-Replying Map-Servers. In releases prior to January 2024, a shortcut approach, not specified in [RFC9300] and [RFC9301], is used for identifying RTR RLOCs with a unicast priority of 254 and RLOC-name of "RTR". This works among consenting implementations when no one else is using priority 254 in any other way, and therefore do not recommend it for arbitrary deployments. This approach is in the process of being deprecated.

The procedures described in this document are performed by LISP compliant [RFC9300] [RFC9301] xTRs that reside on the private side of one or more NAT devices that connect them to the public side of the network.

The solution is applicable to the following xTR deployments:

2. Definition of Terms

This document uses terms defined in [RFC9300] and [RFC9301]. The definitions are extended in this section to provide context and details for NAT-Traversal uses.

Routing Locator (RLOC):
an RLOC address is a routable address on the public Internet. It is used by LISP to locate where EIDs are topologically located and appears in the outer header of LISP encapsulated packets. With respect to this design, an RLOC can be a private or public address. Private RLOCs can be registered to the LISP mapping system so they can be used by other LISP xTRs which reside in the same private network. Public RLOCs can be registered to the LISP mapping system and are used by LISP xTRs that are on the public side of the network.
Network Address Translator (NAT):
is a router type device that isolates a private network from a public network. The addresses used on the private side of a network are known as private addresses and are not routable on the public side of the network. Therefore, a NAT device must translate private addresses to public addresses. In this document, xTRs that reside on the private side of the network use private RLOCs. These RLOCs must be translated to public addresses so they can be registered in the LISP mapping system. Details on NAT operation can be found in [RFC3022].
Private RLOC:
is the IP address of the interface of an xTR that faces outbound towards a NAT device. This address is typically translated to a public RLOC address before the packet appears on the public side of the network.
Ephemeral Port:
is the UDP source port in a LISP data-plane or control-plane message. This port number is typically translated by a NAT device when the packet goes from the private side of the NAT device to the public side of the network.
Global RLOC:
is an address that has been translated by a NAT device. The Private RLOC is translated to a Global RLOC and is registered to the mapping system. This RLOC will be the source address in LISP encapsulated packets on the public side of the network.
Translated Port:
is the Ephemeral Port that is translated by a NAT device. For an xTR outgoing packet, the source Ephemeral Port is translated to a source Translated Port seen by the public side of the network. For an incoming packet, the NAT device translates the destination Translated Port to the destination Ephemeral Port.
Re-encapsulating Tunnel Router (RTR):
is a LISP network element that receives a LISP encapsulated packet, strips the outer header and prepends a new outer header. With respect to this NAT-Traversal design, an ITR (either behind a NAT device or on the public network) encapsulates a packet to the RTR's RLOC address. The RTR strips this ITR prepended header and then prepends a its own new outer header and sends packet to the RLOC address of an ETR that registered the EID that appears as the destination address from the inner header.
NAT Info Cache:
is a data structure managed by an RTR to track xTR hostname, Global RLOC and Translated Port information. The RTR uses this table so it knows what is the destination port to be used for LISP encapsulated packets that go through a NAT device.
Address Family Identifier (AFI):
a term used to describe an address encoding in a packet [AFI] and [RFC1700]. All LISP control messages use AFI encoded addresses. The AFI value is 16-bits in length and precedes all LISP encoded addresses. In this document, the design calls for AFI encodings for IPv4 and IPv6 addresses as well as Distinguished-Name [I-D.ietf-lisp-name-encoding] and LCAF [RFC8060] address formats.

3. Overview

The following sequence of actions describes at a high-level how the implementation performs NAT-Traversal and is the basis for a simplified NAT-Traversal protocol design.

  1. An xTR sends a Info-Request message to port 4342 to its configured Map-Servers so it can get a list of RTRs to be used for NAT-Traversal.

  2. The Map-Servers return an Info-Reply message with the list of RTRs.

  3. The xTR then sends an Info-Request message to port 4341 to each RTR.

  4. Each RTR caches the translated RLOC address and port in a NAT Info Cache. At this point, the NAT device has created state to allow the RTR to send encapsulated packets from port 4341 to the translated port.

  5. The RTR returns an Info-Reply message so the xTR can learn its translated Global RLOC address and Translated Port.

  6. The xTR registers its EID-prefixes with an RLOC-set that contains all its global RLOCs as well as the list of RTRs it has learned from Info-Reply messages.

  7. The Map-Servers are configured to proxy Map-Reply for these registered EID-prefixes.

  8. When a remote ITR sends a Map-Request for an EID that matches one of these EID-prefixes, the Map-Server returns a partial RLOC-set which contain only the list of RTRs. The remote ITR encapsulates packets to the RTRs.

  9. When one of the RTRs send a Map-Request for an EID that matches one of these EID-prefixes, the Map-Server returns a partial RLOC-set which contain only the global RLOCs so the RTR can encapsulate packets that will make it through the NAT device to the xTR.

  10. The xTR behind a NAT device only stores default map-cache entries with an RLOC-set that contain the list of RTRs the Map-Server supplied it with. The xTR load-splits traffic across the RTRs based on the 5-tuple hash algorithm detailed in [RFC9300].

4. Protocol Messages

The implementation uses the Info-Request and Info-Reply messages from [I-D.ermagan-lisp-nat-traversal] as well as the NAT-Traversal LISP Canonical Address Format (LCAF) from [RFC8060]. This section indicates how these messages are used by the implementation.

    0                   1                   2                     3
    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
   |Type=7 |0|            Reserved                                 |
   |                         Nonce . . .                           |
   |                      . . . Nonce                              |
   |              Key ID           |  Authentication Data Length   |
   ~                     Authentication Data                       ~
   |                              TTL                              |
   |   Reserved    | EID mask-len  |        EID-prefix-AFI         |
   |                          EID-prefix                           |
   |             AFI = 0           |   <Nothing Follows AFI=0>     |

           Figure 1 - LISP Info-Request Message Format

The implementation will send an Info-Request message to each configured Map-Server. The message is sent to UDP destination port 4342 which is the control-plane port for LISP [RFC9301] from a UDP ephemeral source port. The source address is its Private RLOC. When the xTR is multi-homed to more than one NAT device, it sends the Info-Request on all interfaces facing NAT devices.

A randomized 64-bit nonce is selected for the message and no authentication is used. The EID-prefix AFI is 17 according to the encoding format in [I-D.ietf-lisp-name-encoding] and the EID-prefix is the hostname of the xTR encoded as a string null terminated. Name collisions are dealt with according to procedures in [I-D.ietf-lisp-name-encoding].

An Info-Request is sent out each outgoing interface, with the address of that interface as the Private RLOC, leading to a NAT device. The port pair in the UDP message is the same for each outgoing interface.

When the xTR receives an Info-Reply message from the Map-Server in response to this control-plane Info-Request, it caches a list of RTRs from the Info-Reply. If the list of RTRs are different from each Map-Server, the lists are merged. The xTR stores the merged list as the RLOC-set for 4 default map-cache entries. The map-cache entries have the following EID-prefixes:

        IPv4 unicast:
        IPv4 multicast:    (,
        IPv6 unicast:       0::/0
        IPv6 multicast:    (0::/0, ff00::/8)

Now that the xTR has a list of RTRs, it sends a data-plane Info-Request to each RTR to UDP destination port 4341 from a UDP ephemeral source port. The data-plane Info-Request is sent out each interface just like the control-plane Info-Request was sent for the multi-homed NAT device case.

When Map-Servers and RTRs return an Info-Reply message to xTRs behind NAT devices, the format of the Info-Reply message is the following.

Info-Request messages are sent periodically every 15 seconds to both the configured set of Map-Servers and the discovered set of RTRs to keep state alive in NAT devices.

    0                   1                   2                   3
    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
   |Type=7 |1|               Reserved                              |
   |                         Nonce . . .                           |
   |                      . . . Nonce                              |
   |            Key ID             |  Authentication Data Length   |
   ~                     Authentication Data                       ~
   |                              TTL                              |
   |   Reserved    | EID mask-len  |        EID-prefix-AFI         |
   |                          EID-prefix                           |
|  |           AFI = 16387         |    Rsvd1      |     Flags     |
|  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  |    Type = 7     |     Rsvd2   |             4 + n             |
|  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
N  |        MS UDP Port Number     |      ETR UDP Port Number      |
A  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
T  |              AFI = x          | Global ETR RLOC Address  ...  |
L  |              AFI = x          |       MS RLOC Address  ...    |
C  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A  |              AFI = x          | Private ETR RLOC Address ...  |
F  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  |              AFI = x          |      RTR RLOC Address 1 ...   |
|  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  |              AFI = x          |       RTR RLOC Address n ...  |

              Figure 2 - LISP Info-Reply Message Format

The information returned is the same information that was sent in the Info-Request message except the Info-Reply bit is set (the bit next to Type=7) and the NAT Traversal LCAF encoding is appended.

When a Map-Server returns the Info-Reply, the MS UDP Port Number and ETR UDP Port Number is set to 0. All Address fields are empty by using AFI equal to 0. Except for the RTR RLOC address fields which the Map-Server is configured to return to xTRs behind NAT devices.

When an RTR returns the Info-Reply, the MS UDP Port Number is set to 0 and the ETR UDP Port Number is set to the UDP source port the RTR received from the Info-Request message. The Global ETR RLOC Address is set to the source address received by the RTR in the Info-Request message. All other address fields are empty by using AFI equal to 0.

5. xTR Map-Registering and Map-Server Proxy Map-Replying

EID-prefixes registered by an xTR behind a NAT include all the global RLOCs and reachable RTR RLOCs it learns. The xTR can use the unicast priority to control ingress packet flow as described in [RFC9301]. The RTR RLOCs must be registered with with an RLOC name of "" so the Map-Server can identify xTR global RLOCs from RTR RLOCs when proxy Map-Replying. Each RTR RLOC weight is set to 1 so ITRs can load-split traffic across them.

The Global RLOCs are encoded in a RLOC-record using the AFI-List LCAF encoding [RFC8060]. There are two AFI encoded addresses in the list, one being AFI=1 which encodes the IPv4 translated NAT address and other being the Distinguished-Name AFI=17 [I-D.ietf-lisp-name-encoding] which encodes the hostname of the xTR. When the xTR is multi-homed, the hostname is appended by a unique interface name. For example, for an xTR behind a NAT that has two interfaces facing the same or two different NAT devices, the Distinguished-Name for each RLOC-record could be "dino-xtr-eth0" and "dino-xtr-eth1" for an xTR configured to be named "dino-xtr".

Encoding a Distinguished-Name in an RLOC-record is important so an RTR can use the Global RLOC registered to the mapping system with the translated port stored in its NAT Info Cache. See Section 8 for more details.

When a remote ITR sends a Map-Request for a unicast or multicast EID registered by a xTR behind a NAT, the Map-Server returns a partial RLOC-set that contains all the RTRs (RLOC-records with RLOC-name "") in the proxied Map-Reply message.

When a RTR sends a Map-Request for a unicast or multicast EID registered by a xTR behind a NAT, the Map-Server returns a partial RLOC-set that contains all the Global RLOCs of the xTR behind the NAT in the proxied Map-Reply message.

6. Packet Flow from ITR-behind-NAT to RTR

All packets received by the ITR from the private side of the NAT will use one of the 4 default map-cache entries. There is a unicast and multicast IPv4 default EID-prefix and a unicast and multicast IPv6 default EID-prefix. The RLOC-set is the same for all 4 entries. The RLOC-set contains the globally reachable RLOCs of the RTRs. 5-tuple hashing is used to load-split traffic across the RTRs. RLOC-Probing is used to avoid encapsulating to unreachable RTRs.

7. Packet Flow from Remote ITR to RTR

A remote ITR will get a list of RTRs from the mapping system in a proxy Map-Reply when it sends a Map-Request for a unicast or multicast EID that is registered by an xTR behind a NAT device. The remote ITR will load split traffic across the RTRs from the RLOC-set. Those RTRs can get packets through the NAT devices destined for the xTR behind the NAT since an Info-Request/Info-Reply exchange had already happened between the xTR behind the NAT and the list of RTRs.

There can be a reachability situation where an RTR cannot reach the xTR behind a NAT but a remote ITR may 5-tuple hash to this RTR. Which means packets can travel from the remote ITR to the RTR but then get dropped on the path from the RTR to the xTR behind the NAT. To avoid this situation, the xTR behind the NAT RLOC-probes RTRs and when they become unreachable, they are not included in the xTR registrations.

8. Packet Flow from RTR to ETR-behind-NAT

The RTR will receive a list of Global RLOCs in a proxy Map-Reply from the mapping system for the xTR behind the NAT. The RTR 5-tuple load-splits packets across the RLOC-set of Global RLOCs that can travel through one or more NAT devices along the path to the ETR behind the NAT device.

When the RTR selects a Global RLOC to encapsulate to it must select the correct Translated Port for the UDP destination port in the encapsulation header. The RTR needs to use the same Translated Address and Translated Port pair a NAT device used to translate the Info-Request message otherwise the encapsulated packet will be dropped. The NAT Info Cache contains an entry for every hostname (and optionally appended interface name), translated address and port cached when processing Info-Request messages. The RTR obtains the correct Translated Port from the NAT Info Cache by using the Global RLOC and RLOC-record hostname from the registered RLOC-set.

The RTR can test reachability for xTRs behind NATs by encapsulating RLOC-Probe requests in data packets where the UDP source port is set to 4341 and the UDP destination port is set to the Translated Port. The outer header destination address is the Global RLOC for the xTR.

9. Decentralized NAT

A decentralized version of this design is also supported in the implementation. See [DECENT-NAT] for an overview. The design allows direct encapsulation from an ITR to an ETR when they both reside behind NAT devices. Packets do not have to take a sub-optimal path through the RTR. The RTR does play a role in informing the ETRs about their translated address and port number just as it does for the centralized version. Here are some details of the design:

Your feature mileage may vary depending on the type of NAT or firewall deployed. There is an assumption that the translated port for an xTR that sends to the RTR is the same translated port used for other destinations.

10. Design Observations

The following benefits and observations can be attributed to this design:

11. Security Considerations

There are no additional security considerations the implementation provides for NAT-Traversal. However, the general implementation does adhere to the recommendations from [RFC9300] and [RFC9301].

This implementation does not support [RFC9303] at the current time. It can be implemented as requirements change.

The implementation is exposed to several threats described in [RFC7835]. An attacker may spoof Info-Request messages. This implementation does not mitigate that attack, but it could be done in future work by authenticating xTRs like the way key management is used for Map-Register messages according to [RFC9301].

The implementation does not set or use the authentication data fields in the Info-Request and Info-Reply messages. However, this will become future work.

12. IANA Considerations

This implementation makes a single request for IANA.

The N-bit in the Map-Request header specified in this document has been used in this implementation. This document requests assignment for this N-bit at the bit position in the Map-Request header indicated below.

Registry: Locator/ID Separation Protocol (LISP) Parameters, Sub-Registry: Map-Request Header Bits:

   0                   1                   2                   3
   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
  |Type=1 |A|M|P|S|p|s|R|R|  Rsvd |N|L|D|   IRC   | Record Count  |
Table 1: LISP Map-Request Header Bits
Spec Name IANA Name Bit Position Description
N map-request-N 16 NAT-Traversal Bit

13. Code-Point Considerations

The code-point values in this specification are already allocated in [AFI] or [RFC8060].

An RLOC name set to "", encoded in Distinguished-Name AFI format [I-D.ietf-lisp-name-encoding], is used in the implementation to identify an RTR RLOC-record. This is not an IANA registry code-point value and is not being requested to be reserved.

14. References

14.1. Normative References

"Address Family Identifier (AFIs)", ADDRESS FAMILY NUMBERS, .
Farinacci, D., "LISP Distinguished Name Encoding", Work in Progress, Internet-Draft, draft-ietf-lisp-name-encoding-07, , <>.
Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1700, DOI 10.17487/RFC1700, , <>.
Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, DOI 10.17487/RFC3022, , <>.
Farinacci, D. and D. Meyer, "The Locator/ID Separation Protocol Internet Groper (LIG)", RFC 6835, DOI 10.17487/RFC6835, , <>.
Saucez, D., Iannone, L., and O. Bonaventure, "Locator/ID Separation Protocol (LISP) Threat Analysis", RFC 7835, DOI 10.17487/RFC7835, , <>.
Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical Address Format (LCAF)", RFC 8060, DOI 10.17487/RFC8060, , <>.
Farinacci, D. and B. Weis, "Locator/ID Separation Protocol (LISP) Data-Plane Confidentiality", RFC 8061, DOI 10.17487/RFC8061, , <>.
Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A. Cabellos, Ed., "The Locator/ID Separation Protocol (LISP)", RFC 9300, DOI 10.17487/RFC9300, , <>.
Farinacci, D., Maino, F., Fuller, V., and A. Cabellos, Ed., "Locator/ID Separation Protocol (LISP) Control Plane", RFC 9301, DOI 10.17487/RFC9301, , <>.
Maino, F., Ermagan, V., Cabellos, A., and D. Saucez, "Locator/ID Separation Protocol Security (LISP-SEC)", RFC 9303, DOI 10.17487/RFC9303, , <>.

14.2. Informative References

"Decentralized-NAT", Decentralized-NAT Slide:, .
Ermagan, V., Farinacci, D., Lewis, D., Maino, F., Portoles-Comeras, M., Skriver, J., White, C., Brescó, A. L., and A. Cabellos-Aparicio, "NAT traversal for LISP", Work in Progress, Internet-Draft, draft-ermagan-lisp-nat-traversal-19, , <>.

Appendix A. Acknowledgments

The author would like to thank the authors of the LISP NAT-Traversal specification [I-D.ermagan-lisp-nat-traversal] for their initial ideas and prototyping to allow a simpler form of NAT-Traversal to be designed. A special grateful thank you to the members of who have been involved in testing the implementation.

Appendix B. Document Change Log

B.1. Changes to draft-farinacci-lisp-lispers-net-nat-08

B.2. Changes to draft-farinacci-lisp-lispers-net-nat-07

B.3. Changes to draft-farinacci-lisp-lispers-net-nat-06

B.4. Changes to draft-farinacci-lisp-lispers-net-nat-05

B.5. Changes to draft-farinacci-lisp-lispers-net-nat-04

B.6. Changes to draft-farinacci-lisp-lispers-net-nat-03

B.7. Changes to draft-farinacci-lisp-lispers-net-nat-02

B.8. Changes to draft-farinacci-lisp-lispers-net-nat-01

B.9. Changes to draft-farinacci-lisp-lispers-net-nat-00

B.10. Changes to draft-farinacci-lisp-simple-nat-06

B.11. Changes to draft-farinacci-lisp-simple-nat-05

B.12. Changes to draft-farinacci-lisp-simple-nat-04

B.13. Changes to draft-farinacci-lisp-simple-nat-03

B.14. Changes to draft-farinacci-lisp-simple-nat-02

B.15. Changes to draft-farinacci-lisp-simple-nat-01

B.16. Changes to draft-farinacci-lisp-simple-nat-00

Author's Address

Dino Farinacci
San Jose, CA
United States of America