Address Family Identifier (AFI):

"AFI" is a term used to describe an address encoding in a packet. An address family is an address format found in data plane packet headers, for example, an IPv4 address or an IPv6 address. See [AFN], [RFC 2453], [RFC 2677], and [RFC 4760] for details. An AFI value of 0 used in this specification indicates an unspecified encoded address where the length of the address is 0 octets following the 16-bit AFI value of 0.

Anycast Address:

"Anycast address" refers to the same IPv4 or IPv6 address configured and used on multiple systems at the same time. An EID or RLOC can be an anycast address in each of their own address spaces.

Client-side:

"Client-side" is a term used in this document to indicate a connection initiation attempt by an end-system represented by an EID.

Egress Tunnel Router (ETR):

An ETR is a router that accepts an IP packet where the destination address in the "outer" IP header is one of its own RLOCs. The router strips the "outer" header and forwards the packet based on the next IP header found. In general, an ETR receives LISP-encapsulated IP packets from the Internet on one side and sends decapsulated IP packets to site end-systems on the other side. ETR functionality does not have to be limited to a router device. A server host can be the endpoint of a LISP tunnel as well.

EID-to-RLOC Database:

The EID-to-RLOC Database is a distributed database that contains all known EID-Prefix-to-RLOC mappings. Each potential ETR typically contains a small piece of the database: the EID-to-RLOC mappings for the EID-Prefixes "behind" the router. These map to one of the router's own IP addresses that are routable on the underlay. Note that there MAY be transient conditions when the EID-Prefix for the LISP site and Locator-Set for each EID-Prefix may not be the same on all ETRs. This has no negative implications, since a partial set of Locators can be used.

EID-to-RLOC Map-Cache:

The EID-to-RLOC Map-Cache is a generally short-lived, on-demand table in an Ingress Tunnel Router (ITR) that stores, tracks, and is responsible for timing out and otherwise validating EID-to-RLOC mappings. This cache is distinct from the full "database" of EID-to-RLOC mappings; it is dynamic, local to the ITR(s), and relatively small, while the database is distributed, relatively static, and much more widely scoped to LISP nodes.

EID-Prefix:

An EID-Prefix is a power-of-two block of EIDs that are allocated to a site by an address allocation authority. EID-Prefixes are associated with a set of RLOC addresses. EID-Prefix allocations can be broken up into smaller blocks when an RLOC-Set is to be associated with the larger EID-Prefix block.

End-System:

An end-system is an IPv4 or IPv6 device that originates packets with a single IPv4 or IPv6 header. The end-system supplies an EID value for the destination address field of the IP header when communicating outside of its routing domain. An end-system can be a host computer, a switch or router device, or any network appliance.

Endpoint ID (EID):

An EID is a 32-bit (for IPv4) or 128-bit (for IPv6) value that identifies a host. EIDs are generally only found in the source and destination address fields of the first (innermost) LISP header of a packet. The host obtains a destination EID through a Domain Name System (DNS) [RFC 1034] lookup or Session Initiation Protocol (SIP) [RFC 3261] exchange. This behavior does not change when LISP is in use. The source EID is obtained via existing mechanisms used to set a host's "local" IP address. An EID used on the public Internet MUST have the same properties as any other IP address used in that manner; this means, among other things, that it MUST be unique. An EID is allocated to a host from an EID-Prefix block associated with the site where the host is located. An EID can be used by a host to refer to other hosts. Note that EID blocks MAY be assigned in a hierarchical manner, independent of the network topology, to facilitate scaling of the mapping database. In addition, an EID block assigned to a site MAY have site-local structure (subnetting) for routing within the site; this structure is not visible to the underlay routing system. In theory, the bit string that represents an EID for one device can represent an RLOC for a different device. When discussing other Locator/ID separation proposals, any references to an EID in this document will refer to a LISP EID.

Ingress Tunnel Router (ITR):

An ITR is a router that resides in a LISP site. Packets sent by sources inside of the LISP site to destinations outside of the site are candidates for encapsulation by the ITR. The ITR treats the IP destination address as an EID and performs an EID-to-RLOC mapping lookup. The router then prepends an "outer" IP header with one of its routable RLOCs (in the RLOC space) in the source address field and the result of the mapping lookup in the destination address field. Note that this destination RLOC may be an intermediate, proxy device that has better knowledge of the EID-to-RLOC mapping closer to the destination EID. In general, an ITR receives IP packets from site end-systems on one side and sends LISP-encapsulated IP packets toward the Internet on the other side.

LISP Header:

"LISP header" is a term used in this document to refer to the outer IPv4 or IPv6 header, a UDP header, and a LISP- specific 8-octet header, all of which follow the UDP header. An ITR prepends LISP headers on packets, and an ETR strips them.

LISP Router:

A LISP router is a router that performs the functions of any or all of the following: ITRs, ETRs, Re-encapsulating Tunneling Routers (RTRs), Proxy-ITRs (PITRs), or Proxy-ETRs (PETRs).

LISP Site:

A LISP site is a set of routers in an edge network that are under a single technical administration. LISP routers that reside in the edge network are the demarcation points to separate the edge network from the core network.

Locator-Status-Bits (LSBs):

Locator-Status-Bits are present in the LISP header. They are used by ITRs to inform ETRs about the up/down status of all ETRs at the local site. These bits are used as a hint to convey up/down router status and not path reachability status. The LSBs can be verified by use of one of the Locator reachability algorithms described in Section 10. An ETR MUST rate limit the action it takes when it detects changes in the Locator-Status-Bits.

Proxy-ETR (PETR):

A PETR is defined and described in [RFC 6832]. A PETR acts like an ETR but does so on behalf of LISP sites that send packets to destinations at non-LISP sites.

Proxy-ITR (PITR):

A PITR is defined and described in [RFC 6832]. A PITR acts like an ITR but does so on behalf of non-LISP sites that send packets to destinations at LISP sites.

Recursive Tunneling:

Recursive Tunneling occurs when a packet has more than one LISP IP header. Additional layers of tunneling MAY be employed to implement Traffic Engineering or other rerouting as needed. When this is done, an additional "outer" LISP header is added, and the original RLOCs are preserved in the "inner" header.

Re-encapsulating Tunneling Router (RTR):

An RTR acts like an ETR to remove a LISP header, then acts as an ITR to prepend a new LISP header. This is known as Re-encapsulating Tunneling. Doing this allows a packet to be rerouted by the RTR without adding the overhead of additional tunnel headers. When using multiple mapping database systems, care must be taken to not create re-encapsulation loops through misconfiguration.

Route-Returnability:

Route-returnability is an assumption that the underlying routing system will deliver packets to the destination. When combined with a nonce that is provided by a sender and returned by a receiver, this limits off-path data insertion. A route-returnability check is verified when a message is sent with a nonce, another message is returned with the same nonce, and the destination of the original message appears as the source of the returned message.

Routing Locator (RLOC):

An RLOC is an IPv4 address [RFC 0791] or IPv6 address [RFC 8200] of an Egress Tunnel Router (ETR). An RLOC is the output of an EID-to-RLOC mapping lookup. An EID maps to zero or more RLOCs. Typically, RLOCs are numbered from blocks that are assigned to a site at each point to which it attaches to the underlay network, where the topology is defined by the connectivity of provider networks. Multiple RLOCs can be assigned to the same ETR device or to multiple ETR devices at a site.

Server-side:

"Server-side" is a term used in this document to indicate that a connection initiation attempt is being accepted for a destination EID.

xTR:

An xTR is a reference to an ITR or ETR when direction of data flow is not part of the context description. "xTR" refers to the router that is the tunnel endpoint and is used synonymously with the term "Tunnel Router". For example, "An xTR can be located at the Customer Edge (CE) router" indicates both ITR and ETR functionality at the CE router.

• End-systems only send to addresses that are EIDs. EIDs are typically IP addresses assigned to hosts (other types of EIDs are supported by LISP; see [RFC 8060] for further information). End-systems don't know that addresses are EIDs versus RLOCs but assume that packets get to their intended destinations. In a system where LISP is deployed, LISP routers intercept EID-addressed packets and assist in delivering them across the network core where EIDs cannot be routed. The procedure a host uses to send IP packets does not change.
• LISP routers prepend and strip outer headers with RLOC addresses. See Section 4.2 for details.
• RLOCs are always IP addresses assigned to routers, preferably topologically oriented addresses from provider Classless Inter-Domain Routing (CIDR) blocks.
• When a router originates packets, it MAY use as a source address either an EID or RLOC. When acting as a host (e.g., when terminating a transport session such as Secure Shell (SSH), TELNET, or the Simple Network Management Protocol (SNMP)), it MAY use an EID that is explicitly assigned for that purpose. An EID that identifies the router as a host MUST NOT be used as an RLOC; an EID is only routable within the scope of a site. A typical BGP configuration might demonstrate this "hybrid" EID/RLOC usage where a router could use its "host-like" EID to terminate internal BGP (iBGP) sessions to other routers in a site while at the same time using RLOCs to terminate external BGP (eBGP) sessions to routers outside the site.
• Packets with EIDs in them are not expected to be delivered end to end in the absence of an EID-to-RLOC mapping operation. They are expected to be used locally for intra-site communication or to be encapsulated for inter-site communication.
• EIDs MAY also be structured (subnetted) in a manner suitable for local routing within an Autonomous System (AS).

• MUST set the N-, L-, E-, and V-bits in the LISP header (Section 5.1) to zero.
• MUST NOT use Locator-Status-Bits and Echo-Nonce, as described in Section 10, for RLOC reachability. Instead, they MUST rely solely on control plane methods.
• MUST NOT use gleaning or Locator-Status-Bits and Map-Versioning, as described in Section 13, to update the EID-to-RLOC mappings. Instead, they MUST rely solely on control plane methods.

• Source host "host1.abc.example.com" is sending a packet to "host2.xyz.example.com", exactly as it would if the site was not using LISP.
• Each site is multihomed, so each Tunnel Router has an address (RLOC) assigned from the service provider address block for each provider to which that particular Tunnel Router is attached.
• The ITR(s) and ETR(s) are directly connected to the source and destination, respectively, but the source and destination can be located anywhere in the LISP site.
• A Map-Request is sent for an external destination when the destination is not found in the forwarding table or matches a default route. Map-Requests are sent to the mapping database system by using the LISP control plane protocol documented in [RFC 9301].
• Map-Replies are sent on the underlying routing system topology, using the control plane protocol [RFC 9301].

1. host1.abc.example.com wants to open a TCP connection to host2.xyz.example.com. It does a DNS lookup on host2.xyz.example.com. An A/AAAA record is returned. This address is the destination EID. The locally assigned address of host1.abc.example.com is used as the source EID. An IPv4 or IPv6 packet is built and forwarded through the LISP site as a normal IP packet until it reaches a LISP ITR.
2. The LISP ITR must be able to map the destination EID to an RLOC of one of the ETRs at the destination site. A method for doing this is to send a LISP Map-Request, as specified in [RFC 9301].
3. The Mapping System helps forward the Map-Request to the corresponding ETR. When the Map-Request arrives at one of the ETRs at the destination site, it will process the packet as a control message.
4. The ETR looks at the destination EID of the Map-Request and matches it against the prefixes in the ETR's configured EID-to-RLOC mapping database. This is the list of EID-Prefixes the ETR is supporting for the site it resides in. If there is no match, the Map-Request is dropped. Otherwise, a LISP Map-Reply is returned to the ITR.
5. The ITR receives the Map-Reply message, parses the message, and stores the mapping information from the packet. This information is stored in the ITR's EID-to-RLOC Map-Cache. Note that the Map-Cache is an on-demand cache. An ITR will manage its Map-Cache in such a way that optimizes for its resource constraints.
6. Subsequent packets from host1.abc.example.com to host2.xyz.example.com will have a LISP header prepended by the ITR using the appropriate RLOC as the LISP header destination address learned from the ETR. Note that the packet MAY be sent to a different ETR than the one that returned the Map-Reply due to the source site's hashing policy or the destination site's Locator-Set policy.
7. The ETR receives these packets directly (since the destination address is one of its assigned IP addresses), checks the validity of the addresses, strips the LISP header, and forwards packets to the attached destination host.
8. In order to defer the need for a mapping lookup in the reverse direction, it is OPTIONAL for an ETR to create a cache entry that maps the source EID (inner-header source IP address) to the source RLOC (outer-header source IP address) in a received LISP packet. Such a cache entry is termed a "glean mapping" and only contains a single RLOC for the EID in question. More complete information about additional RLOCs SHOULD be verified by sending a LISP Map-Request for that EID. Both the ITR and the ETR MAY also influence the decision the other makes in selecting an RLOC.

Inner Header (IH):

The inner header is the header on the datagram received from the originating host [RFC 0791] [RFC 8200] [RFC 2474]. The source and destination IP addresses are EIDs.

Outer Header (OH):

The outer header is a new header prepended by an ITR. The address fields contain RLOCs obtained from the ingress router's EID-to-RLOC Map-Cache. The IP protocol number is "UDP (17)" from [RFC 0768]. The setting of the Don't Fragment (DF) bit 'Flags' field is according to rules listed in Sections [7.1] and [7.2].

UDP Header:

The UDP header contains an ITR-selected source port when encapsulating a packet. See Section 12 for details on the hash algorithm used to select a source port based on the 5-tuple of the inner header. The destination port MUST be set to the well-known IANA-assigned port value 4341.

UDP Checksum:

The 'UDP Checksum' field SHOULD be transmitted as zero by an ITR for either IPv4 [RFC 0768] or IPv6 encapsulation [RFC 6935] [RFC 6936]. When a packet with a zero UDP checksum is received by an ETR, the ETR MUST accept the packet for decapsulation. When an ITR transmits a non-zero value for the UDP checksum, it MUST send a correctly computed value in this field. When an ETR receives a packet with a non-zero UDP checksum, it MAY choose to verify the checksum value. If it chooses to perform such verification and the verification fails, the packet MUST be silently dropped. If the ETR either chooses not to perform the verification or performs the verification successfully, the packet MUST be accepted for decapsulation. The handling of UDP zero checksums over IPv6 for all tunneling protocols, including LISP, is subject to the applicability statement in [RFC 6936].

UDP Length:

The 'UDP Length' field is set for an IPv4-encapsulated packet to be the sum of the inner-header IPv4 Total Length plus the UDP and LISP header lengths. For an IPv6-encapsulated packet, the 'UDP Length' field is the sum of the inner-header IPv6 Payload Length, the size of the IPv6 header (40 octets), and the size of the UDP and LISP headers.

N:

The N-bit is the nonce-present bit. When this bit is set to 1, the low-order 24 bits of the first 32 bits of the LISP header contain a nonce. See Section 10.1 for details. Both N- and V-bits MUST NOT be set in the same packet. If they are, a decapsulating ETR MUST treat the 'Nonce/Map-Version' field as having a nonce value present.

L:

The L-bit is the 'Locator-Status-Bits' field enabled bit. When this bit is set to 1, the Locator-Status-Bits in the second 32 bits of the LISP header are in use.

 x 1 x x 0 x x x
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|N|L|E|V|I|R|K|K|            Nonce/Map-Version                  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      Locator-Status-Bits                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

E:

The E-bit is the Echo-Nonce-request bit. This bit MUST be ignored and has no meaning when the N-bit is set to 0. When the N-bit is set to 1 and this bit is set to 1, an ITR is requesting that the nonce value in the 'Nonce' field be echoed back in LISP-encapsulated packets when the ITR is also an ETR. See Section 10.1 for details.

V:

The V-bit is the Map-Version present bit. When this bit is set to 1, the N-bit MUST be 0. Refer to [RFC 9302] for more details on Database Map-Versioning. This bit indicates that the LISP header is encoded in this case as:

 0 x 0 1 x x x x
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|N|L|E|V|I|R|K|K|  Source Map-Version   |   Dest Map-Version    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                 Instance ID/Locator-Status-Bits               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

I:

The I-bit is the Instance ID bit. See Section 8 for more details. When this bit is set to 1, the 'Locator-Status-Bits' field is reduced to 8 bits and the high-order 24 bits are used as an Instance ID. If the L-bit is set to 0, then the low-order 8 bits are transmitted as zero and ignored on receipt. The format of the LISP header would look like this:

 x x x x 1 x x x
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|N|L|E|V|I|R|K|K|            Nonce/Map-Version                  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                 Instance ID                   |     LSBs      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

R:

The R-bit is a reserved and unassigned bit for future use. It MUST be set to 0 on transmit and MUST be ignored on receipt.

KK:

The KK-bits are a 2-bit field used when encapsulated packets are encrypted. The field is set to 00 when the packet is not encrypted. See [RFC 8061] for further information.

LISP Nonce:

The LISP 'Nonce' field is a 24-bit value that is randomly generated by an ITR when the N-bit is set to 1. Nonce generation algorithms are an implementation matter but are required to generate different nonces when sending to different RLOCs. The nonce is also used when the E-bit is set to request the nonce value to be echoed by the other side when packets are returned. When the E-bit is clear but the N-bit is set, a remote ITR is either echoing a previously requested Echo-Nonce or providing a random nonce. See Section 10.1 for more details. Finally, when both the N- and V-bits are not set (N=0, V=0), then both the 'Nonce' and 'Map-Version' fields are set to 0 and ignored on receipt.

LISP Locator-Status-Bits (LSBs):

When the L-bit is also set, the 'Locator-Status-Bits' field in the LISP header is set by an ITR to indicate to an ETR the up/down status of the Locators in the source site. Each RLOC in a Map-Reply is assigned an ordinal value from 0 to n-1 (when there are n RLOCs in a mapping entry). The Locator-Status-Bits are numbered from 0 to n-1 from the least significant bit of the field. The field is 32 bits when the I-bit is set to 0 and is 8 bits when the I-bit is set to 1. When a Locator-Status-Bit is set to 1, the ITR is indicating to the ETR that the RLOC associated with the bit ordinal has up status. See Section 10 for details on how an ITR can determine the status of the ETRs at the same site. When a site has multiple EID-Prefixes that result in multiple mappings (where each could have a different Locator-Set), the Locator-Status-Bits setting in an encapsulated packet MUST reflect the mapping for the EID-Prefix that the inner-header source EID address matches (longest-match). If the LSB for an anycast Locator is set to 1, then there is at least one RLOC with that address, and the ETR is considered 'up'.

• The outer-header 'Time to Live' field (or 'Hop Limit' field, in the case of IPv6) SHOULD be copied from the inner-header 'Time to Live' field.
• The outer-header IPv4 'Differentiated Services Code Point (DSCP)' field (or 'Traffic Class' field, in the case of IPv6) SHOULD be copied from the inner-header IPv4 'DSCP' field (or 'Traffic Class' field, in the case of IPv6) to the outer header. Guidelines for this can be found in [RFC 2983].
• The IPv4 'Explicit Congestion Notification (ECN)' field and bits 6 and 7 of the IPv6 'Traffic Class' field require special treatment in order to avoid discarding indications of congestion as specified in [RFC 6040].

• The inner-header IPv4 'Time to Live' field (or 'Hop Limit' field, in the case of IPv6) MUST be copied from the outer-header 'Time to Live'/'Hop Limit' field when the Time to Live / Hop Limit value of the outer header is less than the Time to Live / Hop Limit value of the inner header. Failing to perform this check can cause the Time to Live / Hop Limit of the inner header to increment across encapsulation/decapsulation cycles. This check is also performed when doing initial encapsulation, when a packet comes to an ITR or PITR destined for a LISP site.
• The outer-header IPv4 'Differentiated Services Code Point (DSCP)' field (or 'Traffic Class' field, in the case of IPv6) SHOULD be copied from the outer-header 'IPv4 DSCP' field (or 'Traffic Class' field, in the case of IPv6) to the inner header. Guidelines for this can be found in [RFC 2983].
• The IPv4 'Explicit Congestion Notification (ECN)' field and bits 6 and 7 of the IPv6 'Traffic Class' field require special treatment in order to avoid discarding indications of congestion as specified in [RFC 6040]. Note that implementations exist that copy the 'ECN' field from the outer header to the inner header, even though [RFC 6040] does not recommend this behavior. It is RECOMMENDED that implementations change to support the behavior discussed in [RFC 6040].

1. Define H to be the size, in octets, of the outer header an ITR prepends to a packet. This includes the UDP and LISP header lengths.
2. Define L to be the size, in octets, of the maximum-sized packet an ITR can send to an ETR without the need for the ITR or any intermediate routers to fragment the packet. The network administrator of the LISP deployment has to determine what the suitable value of L is, so as to make sure that no MTU issues arise.
3. Define an architectural constant S for the maximum size of a packet, in octets, an ITR MUST receive from the source so the effective MTU can be met. That is, L = S + H.

1. The ITR will keep state of the effective MTU for each Locator per Map-Cache entry. The effective MTU is what the core network can deliver along the path between the ITR and ETR.
2. When an IPv4-encapsulated packet with the DF bit set to 1 exceeds what the core network can deliver, one of the intermediate routers on the path will send an ICMPv4 Unreachable / Fragmentation Needed message to the ITR. The ITR will parse the ICMP message to determine which Locator is affected by the effective MTU change and then record the new effective MTU value in the Map-Cache entry.
3. When a packet is received by the ITR from a source inside of the site and the size of the packet is greater than the effective MTU stored with the Map-Cache entry associated with the destination EID the packet is for, the ITR will send an ICMPv4 Unreachable / Fragmentation Needed message back to the source. The packet size advertised by the ITR in the ICMP message is the effective MTU minus the LISP encapsulation length.

• The server-side returns one RLOC. The client-side can only use one RLOC. The server-side has complete control of the selection.
• The server-side returns a list of RLOCs where a subset of the list has the same best Priority. The client can only use the subset list according to the weighting assigned by the server-side. In this case, the server-side controls both the subset list and load splitting across its members. The client-side can use RLOCs outside of the subset list if it determines that the subset list is unreachable (unless RLOCs are set to a Priority of 255). Some sharing of control exists: the server-side determines the destination RLOC list and load distribution while the client-side has the option of using alternatives to this list if RLOCs in the list are unreachable.
• The server-side sets a Weight of zero for the RLOC subset list. In this case, the client-side can choose how the traffic load is spread across the subset list. See Section 12 for details on load-sharing mechanisms. Control is shared by the server-side determining the list and the client-side determining load distribution. Again, the client can use alternative RLOCs if the server-provided list of RLOCs is unreachable.
• Either side (more likely the server-side ETR) decides to "glean" the RLOCs. For example, if the server-side ETR gleans RLOCs, then the client-side ITR gives the server-side ETR responsibility for bidirectional RLOC reachability and preferability. Server-side ETR gleaning of the client-side ITR RLOC is done by caching the inner-header source EID and the outer-header source RLOC of received packets. The client-side ITR controls how traffic is returned and can, as an alternative, use an outer-header source RLOC, which then can be added to the list the server-side ETR uses to return traffic. Since no Priority or Weights are provided using this method, the server-side ETR MUST assume that each client-side ITR RLOC uses the same best Priority with a Weight of zero. In addition, since EID-Prefix encoding cannot be conveyed in data packets, the EID-to-RLOC Map-Cache on Tunnel Routers can grow very large. Gleaning has several important considerations. A "gleaned" Map-Cache entry is only stored and used for a RECOMMENDED period of 3 seconds, pending verification. Verification MUST be performed by sending a Map-Request to the source EID (the inner-header IP source address) of the received encapsulated packet. A reply to this "verifying Map-Request" is used to fully populate the Map-Cache entry for the "gleaned" EID and is stored and used for the time indicated in the 'Time to Live' field of a received Map-Reply. When a verified Map-Cache entry is stored, data gleaning no longer occurs for subsequent packets that have a source EID that matches the EID-Prefix of the verified entry. This "gleaning" mechanism MUST NOT be used over the public Internet and SHOULD only be used in trusted and closed deployments. Refer to Section 16 for security issues regarding this mechanism.

1. An ETR MAY examine the Locator-Status-Bits in the LISP header of an encapsulated data packet received from an ITR. If the ETR is also acting as an ITR and has traffic to return to the original ITR site, it can use this status information to help select an RLOC.
2. When an ETR receives an encapsulated packet from an ITR, the source RLOC from the outer header of the packet is likely to be reachable. Please note that in some scenarios the RLOC from the outer header can be a spoofable field.
3. An ITR/ETR pair can use the Echo-Noncing Locator reachability algorithms described in this section.

• Under normal circumstances, each ITR will advertise a default route into the site IGP.
• If an ITR fails or if the upstream link to its Provider Edge fails, its default route will either time out or be withdrawn.

1. Either a source and destination address hash or the commonly used 5-tuple hash can be used. The commonly used 5-tuple hash includes the source and destination addresses; source and destination TCP, UDP, or Stream Control Transmission Protocol (SCTP) port numbers; and the IP protocol number field or IPv6 next-protocol fields of a packet that a host originates from within a LISP site. When a packet is not a TCP, UDP, or SCTP packet, the source and destination addresses only from the header are used to compute the hash.
2. Take the hash value and divide it by the number of Locators stored in the Locator-Set for the EID-to-RLOC mapping.
3. The remainder will yield a value of 0 to "number of Locators minus 1". Use the remainder to select the Locator in the Locator-Set.

1. When a Locator record is added or removed from the Locator-Set, the source xTR will signal this by sending an SMR control plane message [RFC 9301] to the destination xTR. At this point, the source xTR MUST NOT use the LSB field, when the L-bit is 0, since the destination xTR site has outdated information. The source xTR will set up a 'use-LSB' timer.
2. As defined in [RFC 9301], upon reception of the SMR message, the destination xTR will retrieve the updated EID-to-RLOC mappings by sending a Map-Request.
3. When the 'use-LSB' timer expires, the source xTR can use the LSB again with the destination xTR to signal the Locator status (up or down). The specific value for the 'use-LSB' timer depends on the LISP deployment; the 'use-LSB' timer needs to be large enough for the destination xTR to retrieve the updated EID-to-RLOC mappings. A RECOMMENDED value for the 'use-LSB' timer is 5 minutes.

• When a tunnel-encapsulated packet is received by an ETR, the outer destination address may not be the address of the router. This makes it challenging for the control plane to get packets from the hardware. This may be mitigated by creating special Forwarding Information Base (FIB) entries for the EID-Prefixes of EIDs served by the ETR (those for which the router provides an RLOC translation). These FIB entries are marked with a flag indicating that control plane processing SHOULD be performed. The forwarding logic of testing for particular IP protocol number values is not necessary. There are a few proven cases where no changes to existing deployed hardware were needed to support the LISP data plane.
• On an ITR, prepending a new IP header consists of adding more octets to a Message Authentication Code (MAC) rewrite string and prepending the string as part of the outgoing encapsulation procedure. Routers that support Generic Routing Encapsulation (GRE) tunneling [RFC 2784] or 6to4 tunneling [RFC 3056] may already support this action.
• A packet's source address or the interface on which the packet was received can be used to select Virtual Routing and Forwarding (VRF). The VRF system's routing table can be used to find EID-to-RLOC mappings.

• It is no longer mandated that a maximum number of 2 LISP headers be prepended to a packet. If there is an application need for more than 2 LISP headers, an implementation can support more. However, it is RECOMMENDED that a maximum of 2 LISP headers can be prepended to a packet.
• The 3 reserved flag bits in the LISP header have been allocated for [RFC 8061]. The low-order 2 bits of the 3-bit field (now named the KK-bits) are used as a key identifier. The 1 remaining bit is still documented as reserved and unassigned.
• Data plane gleaning for creating Map-Cache entries has been made optional. Any ITR implementations that depend on or assume that the remote ETR is gleaning should not do so. This does not create any interoperability problems, since the control plane Map-Cache population procedures are unilateral and are the typical method for populating the Map-Cache.
• Most of the changes to this document, which reduce its length, are due to moving the LISP control plane messaging and procedures to [RFC 9301].

[RFC0768]

J. Postel, "User Datagram Protocol", STD 6, RFC 768, DOI 10.17487/RFC0768, August 1980,
<https://www.rfc-editor.org/info/rfc768>.

[RFC0791]

J. Postel, "Internet Protocol", STD 5, RFC 791, DOI 10.17487/RFC0791, September 1981,
<https://www.rfc-editor.org/info/rfc791>.

[RFC2119]

S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.

[RFC2474]

K. Nichols, S. Blake, F. Baker, and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, DOI 10.17487/RFC2474, December 1998,
<https://www.rfc-editor.org/info/rfc2474>.

[RFC2983]

D. Black, "Differentiated Services and Tunnels", RFC 2983, DOI 10.17487/RFC2983, October 2000,
<https://www.rfc-editor.org/info/rfc2983>.

[RFC6040]

B. Briscoe, "Tunnelling of Explicit Congestion Notification", RFC 6040, DOI 10.17487/RFC6040, November 2010,
<https://www.rfc-editor.org/info/rfc6040>.

[RFC6438]

B. Carpenter, and S. Amante, "Using the IPv6 Flow Label for Equal Cost Multipath Routing and Link Aggregation in Tunnels", RFC 6438, DOI 10.17487/RFC6438, November 2011,
<https://www.rfc-editor.org/info/rfc6438>.

[RFC6830]

D. Farinacci, V. Fuller, D. Meyer, and D. Lewis, "The Locator/ID Separation Protocol (LISP)", RFC 6830, DOI 10.17487/RFC6830, January 2013,
<https://www.rfc-editor.org/info/rfc6830>.

[RFC6831]

D. Farinacci, D. Meyer, J. Zwiebel, and S. Venaas, "The Locator/ID Separation Protocol (LISP) for Multicast Environments", RFC 6831, DOI 10.17487/RFC6831, January 2013,
<https://www.rfc-editor.org/info/rfc6831>.

[RFC8126]

M. Cotton, B. Leiba, and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.

[RFC8174]

B. Leiba, "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017,
<https://www.rfc-editor.org/info/rfc8174>.

[RFC8200]

S. Deering, and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017,
<https://www.rfc-editor.org/info/rfc8200>.

[RFC8378]

V. Moreno, and D. Farinacci, "Signal-Free Locator/ID Separation Protocol (LISP) Multicast", RFC 8378, DOI 10.17487/RFC8378, May 2018,
<https://www.rfc-editor.org/info/rfc8378>.

[RFC8704]

K. Sriram, D. Montgomery, and J. Haas, "Enhanced Feasible-Path Unicast Reverse Path Forwarding", BCP 84, RFC 8704, DOI 10.17487/RFC8704, February 2020,
<https://www.rfc-editor.org/info/rfc8704>.

[RFC9301]

D Farinacci, F Maino, V Fuller, and A Cabellos, "Locator/ID Separation Protocol (LISP) Control Plane", RFC 9301, DOI 10.17487/RFC9301, October 2022,
<https://www.rfc-editor.org/info/rfc9301>.

[RFC9302]

L Iannone, D Saucez, and O Bonaventure, "Locator/ID Separation Protocol (LISP) Map-Versioning", RFC 9302, DOI 10.17487/RFC9302, October 2022,
<https://www.rfc-editor.org/info/rfc9302>.

[AFN]

IANA, "Address Family Numbers",
<http://www.iana.org/assignments/address-family-numbers>.

[CHIAPPA]

J. Chiappa, "Endpoints and Endpoint Names: A Proposed Enhancement to the Internet Architecture", 1999,
<http://mercury.lcs.mit.edu/~jnc/tech/endpoints.txt>.

[LISP-VPN]

lispers.net, V. Moreno, and D. Farinacci, "LISP Virtual Private Networks (VPNs)", Internet-Draft draft-ietf-lisp-vpn-10, October 2022,
<https://datatracker.ietf.org/doc/html/draft-ietf-lisp-vpn-10>.

[RFC1034]

P. Mockapetris, "Domain names - concepts and facilities", STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
<https://www.rfc-editor.org/info/rfc1034>.

[RFC1191]

J. Mogul, and S. Deering, "Path MTU discovery", RFC 1191, DOI 10.17487/RFC1191, November 1990,
<https://www.rfc-editor.org/info/rfc1191>.

[RFC2453]

G. Malkin, "RIP Version 2", STD 56, RFC 2453, DOI 10.17487/RFC2453, November 1998,
<https://www.rfc-editor.org/info/rfc2453>.

[RFC2677]

M. Greene, J. Cucchiara, and J. Luciani, "Definitions of Managed Objects for the NBMA Next Hop Resolution Protocol (NHRP)", RFC 2677, DOI 10.17487/RFC2677, August 1999,
<https://www.rfc-editor.org/info/rfc2677>.

[RFC2784]

D. Farinacci, T. Li, S. Hanks, D. Meyer, and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, DOI 10.17487/RFC2784, March 2000,
<https://www.rfc-editor.org/info/rfc2784>.

[RFC3056]

B. Carpenter, and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, DOI 10.17487/RFC3056, February 2001,
<https://www.rfc-editor.org/info/rfc3056>.

[RFC3261]

J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261, June 2002,
<https://www.rfc-editor.org/info/rfc3261>.

[RFC4086]

D. Eastlake 3rd, J. Schiller, and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, DOI 10.17487/RFC4086, June 2005,
<https://www.rfc-editor.org/info/rfc4086>.

[RFC4459]

P. Savola, "MTU and Fragmentation Issues with In-the-Network Tunneling", RFC 4459, DOI 10.17487/RFC4459, April 2006,
<https://www.rfc-editor.org/info/rfc4459>.

[RFC4760]

T. Bates, R. Chandra, D. Katz, and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, DOI 10.17487/RFC4760, January 2007,
<https://www.rfc-editor.org/info/rfc4760>.

[RFC4821]

M. Mathis, and J. Heffner, "Packetization Layer Path MTU Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007,
<https://www.rfc-editor.org/info/rfc4821>.

[RFC4984]

D. Meyer, L. Zhang, and K. Fall, "Report from the IAB Workshop on Routing and Addressing", RFC 4984, DOI 10.17487/RFC4984, September 2007,
<https://www.rfc-editor.org/info/rfc4984>.

[RFC6832]

D. Lewis, D. Meyer, D. Farinacci, and V. Fuller, "Interworking between Locator/ID Separation Protocol (LISP) and Non-LISP Sites", RFC 6832, DOI 10.17487/RFC6832, January 2013,
<https://www.rfc-editor.org/info/rfc6832>.

[RFC6835]

D. Farinacci, and D. Meyer, "The Locator/ID Separation Protocol Internet Groper (LIG)", RFC 6835, DOI 10.17487/RFC6835, January 2013,
<https://www.rfc-editor.org/info/rfc6835>.

[RFC6935]

M. Eubanks, P. Chimento, and M. Westerlund, "IPv6 and UDP Checksums for Tunneled Packets", RFC 6935, DOI 10.17487/RFC6935, April 2013,
<https://www.rfc-editor.org/info/rfc6935>.

[RFC6936]

G. Fairhurst, and M. Westerlund, "Applicability Statement for the Use of IPv6 UDP Datagrams with Zero Checksums", RFC 6936, DOI 10.17487/RFC6936, April 2013,
<https://www.rfc-editor.org/info/rfc6936>.

[RFC7052]

G. Schudel, A. Jain, and V. Moreno, "Locator/ID Separation Protocol (LISP) MIB", RFC 7052, DOI 10.17487/RFC7052, October 2013,
<https://www.rfc-editor.org/info/rfc7052>.

[RFC7215]

L. Jakab, A. Cabellos-Aparicio, F. Coras, J. Domingo-Pascual, and D. Lewis, "Locator/Identifier Separation Protocol (LISP) Network Element Deployment Considerations", RFC 7215, DOI 10.17487/RFC7215, April 2014,
<https://www.rfc-editor.org/info/rfc7215>.

[RFC8060]

D. Farinacci, D. Meyer, and J. Snijders, "LISP Canonical Address Format (LCAF)", RFC 8060, DOI 10.17487/RFC8060, February 2017,
<https://www.rfc-editor.org/info/rfc8060>.

[RFC8061]

D. Farinacci, and B. Weis, "Locator/ID Separation Protocol (LISP) Data-Plane Confidentiality", RFC 8061, DOI 10.17487/RFC8061, February 2017,
<https://www.rfc-editor.org/info/rfc8061>.

[RFC8085]

L. Eggert, G. Fairhurst, and G. Shepherd, "UDP Usage Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, March 2017,
<https://www.rfc-editor.org/info/rfc8085>.

[RFC8201]

J. McCann, S. Deering, J. Mogul, and R. Hinden, "Path MTU Discovery for IP version 6", STD 87, RFC 8201, DOI 10.17487/RFC8201, July 2017,
<https://www.rfc-editor.org/info/rfc8201>.

[RFC8899]

G. Fairhurst, T. Jones, M. Tüxen, I. Rüngeler, and T. Völker, "Packetization Layer Path MTU Discovery for Datagram Transports", RFC 8899, DOI 10.17487/RFC8899, September 2020,
<https://www.rfc-editor.org/info/rfc8899>.

[RFC9299]

A Cabellos, and D Saucez, "An Architectural Introduction to the Locator/ID Separation Protocol (LISP)", RFC 9299, DOI 10.17487/RFC9299, October 2022,
<https://www.rfc-editor.org/info/rfc9299>.

Dino Farinacci

Vince Fuller

Dave Meyer

Darrel Lewis

Albert Cabellos