rfc9300v3.txt   rfc9300.txt 
Internet Engineering Task Force (IETF) D. Farinacci Internet Engineering Task Force (IETF) D. Farinacci
Request for Comments: 9300 lispers.net Request for Comments: 9300 lispers.net
Obsoletes: 6830 V. Fuller Obsoletes: 6830 V. Fuller
Category: Standards Track vaf.net Internet Consulting Category: Standards Track vaf.net Internet Consulting
ISSN: 2070-1721 D. Meyer ISSN: 2070-1721 D. Meyer
1-4-5.net 1-4-5.net
D. Lewis D. Lewis
Cisco Systems Cisco Systems
A. Cabellos, Ed. A. Cabellos, Ed.
UPC/BarcelonaTech Universitat Politecnica de Catalunya
September 2022 October 2022
The Locator/ID Separation Protocol (LISP) The Locator/ID Separation Protocol (LISP)
Abstract Abstract
This document describes the data plane protocol for the Locator/ID This document describes the data plane protocol for the Locator/ID
Separation Protocol (LISP). LISP defines two namespaces: Endpoint Separation Protocol (LISP). LISP defines two namespaces: Endpoint
Identifiers (EIDs), which identify end hosts; and Routing Locators Identifiers (EIDs), which identify end hosts; and Routing Locators
(RLOCs), which identify network attachment points. With this, LISP (RLOCs), which identify network attachment points. With this, LISP
effectively separates control from data and allows routers to create effectively separates control from data and allows routers to create
skipping to change at line 81 skipping to change at line 81
5.1. LISP IPv4-in-IPv4 Header Format 5.1. LISP IPv4-in-IPv4 Header Format
5.2. LISP IPv6-in-IPv6 Header Format 5.2. LISP IPv6-in-IPv6 Header Format
5.3. Tunnel Header Field Descriptions 5.3. Tunnel Header Field Descriptions
6. LISP EID-to-RLOC Map-Cache 6. LISP EID-to-RLOC Map-Cache
7. Dealing with Large Encapsulated Packets 7. Dealing with Large Encapsulated Packets
7.1. A Stateless Solution to MTU Handling 7.1. A Stateless Solution to MTU Handling
7.2. A Stateful Solution to MTU Handling 7.2. A Stateful Solution to MTU Handling
8. Using Virtualization and Segmentation with LISP 8. Using Virtualization and Segmentation with LISP
9. Routing Locator Selection 9. Routing Locator Selection
10. Routing Locator Reachability 10. Routing Locator Reachability
10.1. Echo Nonce Algorithm 10.1. Echo-Nonce Algorithm
11. EID Reachability within a LISP Site 11. EID Reachability within a LISP Site
12. Routing Locator Hashing 12. Routing Locator Hashing
13. Changing the Contents of EID-to-RLOC Mappings 13. Changing the Contents of EID-to-RLOC Mappings
13.1. Locator-Status-Bits 13.1. Locator-Status-Bits
13.2. Database Map-Versioning 13.2. Database Map-Versioning
14. Multicast Considerations 14. Multicast Considerations
15. Router Performance Considerations 15. Router Performance Considerations
16. Security Considerations 16. Security Considerations
17. Network Management Considerations 17. Network Management Considerations
18. Changes since RFC 6830 18. Changes since RFC 6830
skipping to change at line 168 skipping to change at line 168
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
3. Definitions of Terms 3. Definitions of Terms
Address Family Identifier (AFI): "AFI" is a term used to describe an Address Family Identifier (AFI): "AFI" is a term used to describe an
address encoding in a packet. An address family is an address address encoding in a packet. An address family is an address
format found in data plane packet headers, for example, an IPv4 format found in data plane packet headers, for example, an IPv4
address or an IPv6 address. See [AFN], [RFC2453], [RFC2677], and address or an IPv6 address. See [AFN], [RFC2453], [RFC2677], and
[RFC2858] for details. An AFI value of 0 used in this [RFC4760] for details. An AFI value of 0 used in this
specification indicates an unspecified encoded address where the specification indicates an unspecified encoded address where the
length of the address is 0 octets following the 16-bit AFI value length of the address is 0 octets following the 16-bit AFI value
of 0. of 0.
Anycast Address: "Anycast address" refers to the same IPv4 or IPv6 Anycast Address: "Anycast address" refers to the same IPv4 or IPv6
address configured and used on multiple systems at the same time. 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 An EID or RLOC can be an anycast address in each of their own
address spaces. address spaces.
Client-side: "Client-side" is a term used in this document to Client-side: "Client-side" is a term used in this document to
skipping to change at line 215 skipping to change at line 215
that stores, tracks, and is responsible for timing out and that stores, tracks, and is responsible for timing out and
otherwise validating EID-to-RLOC mappings. This cache is distinct otherwise validating EID-to-RLOC mappings. This cache is distinct
from the full "database" of EID-to-RLOC mappings; it is dynamic, from the full "database" of EID-to-RLOC mappings; it is dynamic,
local to the ITR(s), and relatively small, while the database is local to the ITR(s), and relatively small, while the database is
distributed, relatively static, and much more widely scoped to distributed, relatively static, and much more widely scoped to
LISP nodes. LISP nodes.
EID-Prefix: An EID-Prefix is a power-of-two block of EIDs that are 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- allocated to a site by an address allocation authority. EID-
Prefixes are associated with a set of RLOC addresses. EID-Prefix Prefixes are associated with a set of RLOC addresses. EID-Prefix
allocations can be broken up into smaller blocks when an RLOC set allocations can be broken up into smaller blocks when an RLOC-Set
is to be associated with the larger EID-Prefix block. is to be associated with the larger EID-Prefix block.
End-System: An end-system is an IPv4 or IPv6 device that originates End-System: An end-system is an IPv4 or IPv6 device that originates
packets with a single IPv4 or IPv6 header. The end-system packets with a single IPv4 or IPv6 header. The end-system
supplies an EID value for the destination address field of the IP supplies an EID value for the destination address field of the IP
header when communicating outside of its routing domain. An end- header when communicating outside of its routing domain. An end-
system can be a host computer, a switch or router device, or any system can be a host computer, a switch or router device, or any
network appliance. network appliance.
Endpoint ID (EID): An EID is a 32-bit (for IPv4) or 128-bit (for Endpoint ID (EID): An EID is a 32-bit (for IPv4) or 128-bit (for
skipping to change at line 380 skipping to change at line 380
that packets get to their intended destinations. In a system that packets get to their intended destinations. In a system
where LISP is deployed, LISP routers intercept EID-addressed where LISP is deployed, LISP routers intercept EID-addressed
packets and assist in delivering them across the network core packets and assist in delivering them across the network core
where EIDs cannot be routed. The procedure a host uses to send IP where EIDs cannot be routed. The procedure a host uses to send IP
packets does not change. packets does not change.
* LISP routers prepend and strip outer headers with RLOC addresses. * LISP routers prepend and strip outer headers with RLOC addresses.
See Section 4.2 for details. See Section 4.2 for details.
* RLOCs are always IP addresses assigned to routers, preferably * RLOCs are always IP addresses assigned to routers, preferably
topologically oriented addresses from provider CIDR (Classless topologically oriented addresses from provider Classless Inter-
Inter-Domain Routing) blocks. Domain Routing (CIDR) blocks.
* When a router originates packets, it MAY use as a source address * 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 either an EID or RLOC. When acting as a host (e.g., when
terminating a transport session such as Secure Shell (SSH), terminating a transport session such as Secure Shell (SSH),
TELNET, or the Simple Network Management Protocol (SNMP)), it MAY TELNET, or the Simple Network Management Protocol (SNMP)), it MAY
use an EID that is explicitly assigned for that purpose. An EID 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; 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 an EID is only routable within the scope of a site. A typical BGP
configuration might demonstrate this "hybrid" EID/RLOC usage where configuration might demonstrate this "hybrid" EID/RLOC usage where
a router could use its "host-like" EID to terminate internal BGP a router could use its "host-like" EID to terminate internal BGP
skipping to change at line 443 skipping to change at line 443
4.1. Deployment on the Public Internet 4.1. Deployment on the Public Internet
Several of the mechanisms in this document are intended for Several of the mechanisms in this document are intended for
deployment in controlled, trusted environments and are insecure for deployment in controlled, trusted environments and are insecure for
use over the public Internet. In particular, on the public Internet, use over the public Internet. In particular, on the public Internet,
xTRs: xTRs:
* MUST set the N-, L-, E-, and V-bits in the LISP header * MUST set the N-, L-, E-, and V-bits in the LISP header
(Section 5.1) to zero. (Section 5.1) to zero.
* MUST NOT use Locator-Status-Bits and echo-nonce, as described in * MUST NOT use Locator-Status-Bits and Echo-Nonce, as described in
Section 10, for RLOC reachability. Instead, they MUST rely solely Section 10, for RLOC reachability. Instead, they MUST rely solely
on control plane methods. on control plane methods.
* MUST NOT use gleaning or Locator-Status-Bits and Map-Versioning, * MUST NOT use gleaning or Locator-Status-Bits and Map-Versioning,
as described in Section 13, to update the EID-to-RLOC mappings. as described in Section 13, to update the EID-to-RLOC mappings.
Instead, they MUST rely solely on control plane methods. Instead, they MUST rely solely on control plane methods.
4.2. Packet Flow Sequence 4.2. Packet Flow Sequence
This section provides an example of the unicast packet flow, also This section provides an example of the unicast packet flow, also
skipping to change at line 493 skipping to change at line 493
host2.xyz.example.com. An A/AAAA record is returned. This host2.xyz.example.com. An A/AAAA record is returned. This
address is the destination EID. The locally assigned address of address is the destination EID. The locally assigned address of
host1.abc.example.com is used as the source EID. An IPv4 or IPv6 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 packet is built and forwarded through the LISP site as a normal
IP packet until it reaches a LISP ITR. IP packet until it reaches a LISP ITR.
2. The LISP ITR must be able to map the destination EID to an RLOC 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 of one of the ETRs at the destination site. A method for doing
this is to send a LISP Map-Request, as specified in [RFC9301]. this is to send a LISP Map-Request, as specified in [RFC9301].
3. The mapping system helps forward the Map-Request to the 3. The Mapping System helps forward the Map-Request to the
corresponding ETR. When the Map-Request arrives at one of the corresponding ETR. When the Map-Request arrives at one of the
ETRs at the destination site, it will process the packet as a ETRs at the destination site, it will process the packet as a
control message. control message.
4. The ETR looks at the destination EID of the Map-Request and 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- matches it against the prefixes in the ETR's configured EID-to-
RLOC mapping database. This is the list of EID-Prefixes the ETR 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, is supporting for the site it resides in. If there is no match,
the Map-Request is dropped. Otherwise, a LISP Map-Reply is the Map-Request is dropped. Otherwise, a LISP Map-Reply is
returned to the ITR. returned to the ITR.
skipping to change at line 665 skipping to change at line 665
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5.3. Tunnel Header Field Descriptions 5.3. Tunnel Header Field Descriptions
Inner Header (IH): The inner header is the header on the datagram Inner Header (IH): The inner header is the header on the datagram
received from the originating host [RFC0791] [RFC8200] [RFC2474]. received from the originating host [RFC0791] [RFC8200] [RFC2474].
The source and destination IP addresses are EIDs. The source and destination IP addresses are EIDs.
Outer Header (OH): The outer header is a new header prepended by an Outer Header (OH): The outer header is a new header prepended by an
ITR. The address fields contain RLOCs obtained from the ingress ITR. The address fields contain RLOCs obtained from the ingress
router's EID-to-RLOC Cache. The IP protocol number is "UDP (17)" router's EID-to-RLOC Map-Cache. The IP protocol number is "UDP
from [RFC0768]. The setting of the Don't Fragment (DF) bit (17)" from [RFC0768]. The setting of the Don't Fragment (DF) bit
'Flags' field is according to rules listed in Sections 7.1 and 'Flags' field is according to rules listed in Sections 7.1 and
7.2. 7.2.
UDP Header: The UDP header contains an ITR-selected source port when UDP Header: The UDP header contains an ITR-selected source port when
encapsulating a packet. See Section 12 for details on the hash 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 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 inner header. The destination port MUST be set to the well-known
IANA-assigned port value 4341. IANA-assigned port value 4341.
UDP Checksum: The 'UDP Checksum' field SHOULD be transmitted as zero UDP Checksum: The 'UDP Checksum' field SHOULD be transmitted as zero
skipping to change at line 716 skipping to change at line 716
this bit is set to 1, the Locator-Status-Bits in the second this bit is set to 1, the Locator-Status-Bits in the second
32 bits of the LISP header are in use. 32 bits of the LISP header are in use.
x 1 x x 0 x x x x 1 x x 0 x x x
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|N|L|E|V|I|R|K|K| Nonce/Map-Version | |N|L|E|V|I|R|K|K| Nonce/Map-Version |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Locator-Status-Bits | | Locator-Status-Bits |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
E: The E-bit is the echo-nonce-request bit. This bit MUST be 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 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 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- that the nonce value in the 'Nonce' field be echoed back in LISP-
encapsulated packets when the ITR is also an ETR. See encapsulated packets when the ITR is also an ETR. See
Section 10.1 for details. Section 10.1 for details.
V: The V-bit is the Map-Version present bit. When this bit is set 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 [RFC9302] for more details on to 1, the N-bit MUST be 0. Refer to [RFC9302] for more details on
Database Map-Versioning. This bit indicates that the LISP header Database Map-Versioning. This bit indicates that the LISP header
is encoded in this case as: is encoded in this case as:
skipping to change at line 763 skipping to change at line 763
encrypted. The field is set to 00 when the packet is not encrypted. The field is set to 00 when the packet is not
encrypted. See [RFC8061] for further information. encrypted. See [RFC8061] for further information.
LISP Nonce: The LISP 'Nonce' field is a 24-bit value that is 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 randomly generated by an ITR when the N-bit is set to 1. Nonce
generation algorithms are an implementation matter but are generation algorithms are an implementation matter but are
required to generate different nonces when sending to different required to generate different nonces when sending to different
RLOCs. The nonce is also used when the E-bit is set to request 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 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 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 ITR is either echoing a previously requested Echo-Nonce or
providing a random nonce. See Section 10.1 for more details. 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 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 both the 'Nonce' and 'Map-Version' fields are set to 0 and ignored
on receipt. on receipt.
LISP Locator-Status-Bits (LSBs): When the L-bit is also set, the 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 '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 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 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). value from 0 to n-1 (when there are n RLOCs in a mapping entry).
skipping to change at line 862 skipping to change at line 862
LISP control plane [RFC9301] allows an ETR to register data plane LISP control plane [RFC9301] allows an ETR to register data plane
capabilities by means of new LISP Canonical Address Format (LCAF) capabilities by means of new LISP Canonical Address Format (LCAF)
types [RFC8060]. In this way, an ITR can be made aware of the data types [RFC8060]. In this way, an ITR can be made aware of the data
plane capabilities of an ETR and encapsulate accordingly. The plane capabilities of an ETR and encapsulate accordingly. The
specification of the new LCAF types, the new LCAF mechanisms, and specification of the new LCAF types, the new LCAF mechanisms, and
their use are out of the scope of this document. their use are out of the scope of this document.
6. LISP EID-to-RLOC Map-Cache 6. LISP EID-to-RLOC Map-Cache
ITRs and PITRs maintain an on-demand cache, referred to as the LISP ITRs and PITRs maintain an on-demand cache, referred to as the LISP
EID-to-RLOC Map-Cache, that contains mappings from EID-prefixes to EID-to-RLOC Map-Cache, that contains mappings from EID-Prefixes to
Locator-Sets. The cache is used to encapsulate packets from the EID Locator-Sets. The cache is used to encapsulate packets from the EID
space to the corresponding RLOC network attachment point. space to the corresponding RLOC network attachment point.
When an ITR/PITR receives a packet from inside of the LISP site to When an ITR/PITR receives a packet from inside of the LISP site to
destinations outside of the site, a longest-prefix match lookup of destinations outside of the site, a longest-prefix match lookup of
the EID is done to the Map-Cache. the EID is done to the Map-Cache.
When the lookup succeeds, the Locator-Set retrieved from the Map- When the lookup succeeds, the Locator-Set retrieved from the Map-
Cache is used to send the packet to the EID's topological location. Cache is used to send the packet to the EID's topological location.
If the lookup fails, the ITR/PITR needs to retrieve the mapping using If the lookup fails, the ITR/PITR needs to retrieve the mapping using
the LISP control plane protocol [RFC9301]. While the mapping is the LISP control plane protocol [RFC9301]. While the mapping is
being retrieved, the ITR/PITR can either drop or buffer the packets. being retrieved, the ITR/PITR can either drop or buffer the packets.
This document does not have specific recommendations about the action This document does not have specific recommendations about the action
to be taken. It is up to the deployer to consider whether or not it to be taken. It is up to the deployer to consider whether or not it
is desirable to buffer packets and deploy a LISP implementation that is desirable to buffer packets and deploy a LISP implementation that
offers the desired behavior. Once the mapping is resolved, it is offers the desired behavior. Once the mapping is resolved, it is
then stored in the local Map-Cache to forward subsequent packets then stored in the local Map-Cache to forward subsequent packets
addressed to the same EID-prefix. addressed to the same EID-Prefix.
The Map-Cache is a local cache of mappings; entries are expired based The Map-Cache is a local cache of mappings; entries are expired based
on the associated Time to Live. In addition, entries can be updated on the associated Time to Live. In addition, entries can be updated
with more current information; see Section 13 for further information with more current information; see Section 13 for further information
on this. Finally, the Map-Cache also contains reachability on this. Finally, the Map-Cache also contains reachability
information about EIDs and RLOCs and uses LISP reachability information about EIDs and RLOCs and uses LISP reachability
information mechanisms to determine the reachability of RLOCs; see information mechanisms to determine the reachability of RLOCs; see
Section 10 for the specific mechanisms. Section 10 for the specific mechanisms.
7. Dealing with Large Encapsulated Packets 7. Dealing with Large Encapsulated Packets
skipping to change at line 1085 skipping to change at line 1085
bidirectional RLOC reachability and preferability. Server-side bidirectional RLOC reachability and preferability. Server-side
ETR gleaning of the client-side ITR RLOC is done by caching the ETR gleaning of the client-side ITR RLOC is done by caching the
inner-header source EID and the outer-header source RLOC of inner-header source EID and the outer-header source RLOC of
received packets. The client-side ITR controls how traffic is received packets. The client-side ITR controls how traffic is
returned and can, as an alternative, use an outer-header source 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 RLOC, which then can be added to the list the server-side ETR uses
to return traffic. Since no Priority or Weights are provided to return traffic. Since no Priority or Weights are provided
using this method, the server-side ETR MUST assume that each using this method, the server-side ETR MUST assume that each
client-side ITR RLOC uses the same best Priority with a Weight of client-side ITR RLOC uses the same best Priority with a Weight of
zero. In addition, since EID-Prefix encoding cannot be conveyed zero. In addition, since EID-Prefix encoding cannot be conveyed
in data packets, the EID-to-RLOC Cache on Tunnel Routers can grow in data packets, the EID-to-RLOC Map-Cache on Tunnel Routers can
very large. Gleaning has several important considerations. A grow very large. Gleaning has several important considerations.
"gleaned" Map-Cache entry is only stored and used for a A "gleaned" Map-Cache entry is only stored and used for a
RECOMMENDED period of 3 seconds, pending verification. RECOMMENDED period of 3 seconds, pending verification.
Verification MUST be performed by sending a Map-Request to the Verification MUST be performed by sending a Map-Request to the
source EID (the inner-header IP source address) of the received source EID (the inner-header IP source address) of the received
encapsulated packet. A reply to this "verifying Map-Request" is encapsulated packet. A reply to this "verifying Map-Request" is
used to fully populate the Map-Cache entry for the "gleaned" EID 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 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 Live' field of a received Map-Reply. When a verified Map-Cache
entry is stored, data gleaning no longer occurs for subsequent entry is stored, data gleaning no longer occurs for subsequent
packets that have a source EID that matches the EID-Prefix of the packets that have a source EID that matches the EID-Prefix of the
verified entry. This "gleaning" mechanism MUST NOT be used over verified entry. This "gleaning" mechanism MUST NOT be used over
the public Internet and SHOULD only be used in trusted and closed the public Internet and SHOULD only be used in trusted and closed
deployments. Refer to Section 16 for security issues regarding deployments. Refer to Section 16 for security issues regarding
this mechanism. this mechanism.
RLOCs that appear in EID-to-RLOC Map-Reply messages are assumed to be RLOCs that appear in EID-to-RLOC Map-Reply messages are assumed to be
reachable when the R-bit [RFC9301] for the Locator record is set to reachable when the R-bit [RFC9301] for the Locator record is set to
1. When the R-bit is set to 0, an ITR or PITR MUST NOT encapsulate 1. When the R-bit is set to 0, an ITR or PITR MUST NOT encapsulate
to the RLOC. Neither the information contained in a Map-Reply nor to the RLOC. Neither the information contained in a Map-Reply nor
that stored in the mapping database system provides reachability that stored in the mapping database system provides reachability
information for RLOCs. Note that reachability is not part of the information for RLOCs. Note that reachability is not part of the
mapping system and is determined using one or more of the RLOC Mapping System and is determined using one or more of the RLOC
reachability algorithms described in the next section. reachability algorithms described in the next section.
10. Routing Locator Reachability 10. Routing Locator Reachability
Several data plane mechanisms for determining RLOC reachability are Several data plane mechanisms for determining RLOC reachability are
currently defined. Please note that additional reachability currently defined. Please note that additional reachability
mechanisms based on the control plane are defined in [RFC9301]. mechanisms based on the control plane are defined in [RFC9301].
1. An ETR MAY examine the Locator-Status-Bits in the LISP header of 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 an encapsulated data packet received from an ITR. If the ETR is
skipping to change at line 1194 skipping to change at line 1194
possibility of path asymmetry. In the presence of unidirectional possibility of path asymmetry. In the presence of unidirectional
traffic flow from an ITR to an ETR, the ITR SHOULD NOT use the lack traffic flow from an ITR to an ETR, the ITR SHOULD NOT use the lack
of return traffic as an indication that the ETR is unreachable. of return traffic as an indication that the ETR is unreachable.
Instead, it MUST use an alternate mechanism to determine Instead, it MUST use an alternate mechanism to determine
reachability. reachability.
The security considerations of Section 16 related to data plane The security considerations of Section 16 related to data plane
reachability apply to the data plane RLOC reachability mechanisms reachability apply to the data plane RLOC reachability mechanisms
described in this section. described in this section.
10.1. Echo Nonce Algorithm 10.1. Echo-Nonce Algorithm
When data flows bidirectionally between Locators from different When data flows bidirectionally between Locators from different
sites, a data plane mechanism called "nonce echoing" can be used to sites, a data plane mechanism called "nonce echoing" can be used to
determine reachability between an ITR and ETR. When an ITR wants to determine reachability between an ITR and ETR. When an ITR wants to
solicit a nonce echo, it sets the N- and E-bits and places a 24-bit solicit a nonce echo, it sets the N- and E-bits and places a 24-bit
nonce [RFC4086] in the LISP header of the next encapsulated data nonce [RFC4086] in the LISP header of the next encapsulated data
packet. packet.
When this packet is received by the ETR, the encapsulated packet is When this packet is received by the ETR, the encapsulated packet is
forwarded as normal. When the ETR is an xTR (co-located as an ITR), forwarded as normal. When the ETR is an xTR (co-located as an ITR),
it then sends a data packet to the ITR (when it is an xTR co-located it then sends a data packet to the ITR (when it is an xTR co-located
as an ETR) and includes the nonce received earlier with the N-bit set as an ETR) and includes the nonce received earlier with the N-bit set
and E-bit cleared. The ITR sees this "echoed nonce" and knows that and E-bit cleared. The ITR sees this "echoed nonce" and knows that
the path to and from the ETR is up. the path to and from the ETR is up.
The ITR will set the E-bit and N-bit for every packet it sends while The ITR will set the E-bit and N-bit for every packet it sends while
in the echo-nonce-request state. The time the ITR waits to process in the Echo-Nonce-request state. The time the ITR waits to process
the echoed nonce before it determines that the path is unreachable is the echoed nonce before it determines that the path is unreachable is
variable and is a choice left for the implementation. variable and is a choice left for the implementation.
If the ITR is receiving packets from the ETR but does not see the If the ITR is receiving packets from the ETR but does not see the
nonce echoed while being in the echo-nonce-request state, then the nonce echoed while being in the Echo-Nonce-request state, then the
path to the ETR is unreachable. This decision MAY be overridden by path to the ETR is unreachable. This decision MAY be overridden by
other Locator reachability algorithms. Once the ITR determines that other Locator reachability algorithms. Once the ITR determines that
the path to the ETR is down, it can switch to another Locator for the path to the ETR is down, it can switch to another Locator for
that EID-Prefix. that EID-Prefix.
Note that "ITR" and "ETR" are relative terms here. Both devices MUST Note that "ITR" and "ETR" are relative terms here. Both devices MUST
be implementing both ITR and ETR functionality for the echo nonce be implementing both ITR and ETR functionality for the Echo-Nonce
mechanism to operate. mechanism to operate.
The ITR and ETR MAY both go into the echo-nonce-request state at the The ITR and ETR MAY both go into the Echo-Nonce-request state at the
same time. The number of packets sent or the time during which echo- same time. The number of packets sent or the time during which Echo-
nonce request packets are sent is an implementation-specific setting. Nonce request packets are sent is an implementation-specific setting.
In this case, an xTR receiving the echo-nonce request packets will In this case, an xTR receiving the Echo-Nonce request packets will
suspend the echo-nonce state and set up an 'echo-nonce-request-state' suspend the Echo-Nonce state and set up an 'Echo-Nonce-request-state'
timer. After the 'echo-nonce-request-state' timer expires, it will timer. After the 'Echo-Nonce-request-state' timer expires, it will
resume the echo-nonce state. resume the Echo-Nonce state.
This mechanism does not completely solve the forward path This mechanism does not completely solve the forward path
reachability problem, as traffic may be unidirectional. That is, the reachability problem, as traffic may be unidirectional. That is, the
ETR receiving traffic at a site MAY not be the same device as an ITR ETR receiving traffic at a site MAY not be the same device as an ITR
that transmits traffic from that site, or the site-to-site traffic is that transmits traffic from that site, or the site-to-site traffic is
unidirectional so there is no ITR returning traffic. unidirectional so there is no ITR returning traffic.
The echo-nonce algorithm is bilateral. That is, if one side sets the The Echo-Nonce algorithm is bilateral. That is, if one side sets the
E-bit and the other side is not enabled for echo-noncing, then the E-bit and the other side is not enabled for Echo-Noncing, then the
echoing of the nonce does not occur and the requesting side may echoing of the nonce does not occur and the requesting side may
erroneously consider the Locator unreachable. An ITR SHOULD set the erroneously consider the Locator unreachable. An ITR SHOULD set the
E-bit in an encapsulated data packet when it knows the ETR is enabled E-bit in an encapsulated data packet when it knows the ETR is enabled
for echo-noncing. This is conveyed by the E-bit in the Map-Reply for Echo-Noncing. This is conveyed by the E-bit in the Map-Reply
message. message.
Many implementations default to not advertising that they are echo- Many implementations default to not advertising that they are Echo-
nonce capable in Map-Reply messages, and so RLOC-Probing tends to be Nonce capable in Map-Reply messages, and so RLOC-Probing tends to be
used for RLOC reachability. used for RLOC reachability.
The echo-nonce mechanism MUST NOT be used over the public Internet The Echo-Nonce mechanism MUST NOT be used over the public Internet
and MUST only be used in trusted and closed deployments. Refer to and MUST only be used in trusted and closed deployments. Refer to
Section 16 for security issues regarding this mechanism. Section 16 for security issues regarding this mechanism.
11. EID Reachability within a LISP Site 11. EID Reachability within a LISP Site
A site MAY be multihomed using two or more ETRs. The hosts and A site MAY be multihomed using two or more ETRs. The hosts and
infrastructure within a site will be addressed using one or more EID- infrastructure within a site will be addressed using one or more EID-
Prefixes that are mapped to the RLOCs of the relevant ETRs in the Prefixes that are mapped to the RLOCs of the relevant ETRs in the
mapping system. One possible failure mode is for an ETR to lose Mapping System. One possible failure mode is for an ETR to lose
reachability to one or more of the EID-Prefixes within its own site. reachability to one or more of the EID-Prefixes within its own site.
When this occurs when the ETR sends Map-Replies, it can clear the When this occurs when the ETR sends Map-Replies, it can clear the
R-bit associated with its own Locator. And when the ETR is also an R-bit associated with its own Locator. And when the ETR is also an
ITR, it can clear its Locator-Status-Bit in the encapsulation data ITR, it can clear its Locator-Status-Bit in the encapsulation data
header. header.
It is recognized that there are no simple solutions to the site It is recognized that there are no simple solutions to the site
partitioning problem because it is hard to know which part of the partitioning problem because it is hard to know which part of the
EID-Prefix range is partitioned and which Locators can reach any sub- EID-Prefix range is partitioned and which Locators can reach any sub-
ranges of the EID-Prefixes. Note that this is not a new problem ranges of the EID-Prefixes. Note that this is not a new problem
introduced by the LISP architecture. At the time of this writing, introduced by the LISP architecture. At the time of this writing,
this problem exists when a multihomed site uses BGP to advertise its this problem exists when a multihomed site uses BGP to advertise its
reachability upstream. reachability upstream.
12. Routing Locator Hashing 12. Routing Locator Hashing
When an ETR provides an EID-to-RLOC mapping in a Map-Reply message When an ETR provides an EID-to-RLOC mapping in a Map-Reply message
that is stored in the Map-Cache of a requesting ITR, the Locator-Set that is stored in the Map-Cache of a requesting ITR, the Locator-Set
for the EID-Prefix MAY contain different Priority and Weight values for the EID-Prefix MAY contain different Priority and Weight values
for each Locator address. When more than one best Priority Locator for each Routing Locator Address. When more than one best Priority
exists, the ITR can decide how to load-share traffic against the Locator exists, the ITR can decide how to load-share traffic against
corresponding Locators. the corresponding Locators.
The following hash algorithm MAY be used by an ITR to select a The following hash algorithm MAY be used by an ITR to select a
Locator for a packet destined to an EID for the EID-to-RLOC mapping: Locator for a packet destined to an EID for the EID-to-RLOC mapping:
1. Either a source and destination address hash or the commonly used 1. Either a source and destination address hash or the commonly used
5-tuple hash can be used. The commonly used 5-tuple hash 5-tuple hash can be used. The commonly used 5-tuple hash
includes the source and destination addresses; source and includes the source and destination addresses; source and
destination TCP, UDP, or Stream Control Transmission Protocol destination TCP, UDP, or Stream Control Transmission Protocol
(SCTP) port numbers; and the IP protocol number field or IPv6 (SCTP) port numbers; and the IP protocol number field or IPv6
next-protocol fields of a packet that a host originates from next-protocol fields of a packet that a host originates from
skipping to change at line 1384 skipping to change at line 1384
minutes. minutes.
13.2. Database Map-Versioning 13.2. Database Map-Versioning
When there is unidirectional packet flow between an ITR and ETR, and When there is unidirectional packet flow between an ITR and ETR, and
the EID-to-RLOC mappings change on the ETR, it needs to inform the the EID-to-RLOC mappings change on the ETR, it needs to inform the
ITR so encapsulation to a removed Locator can stop and can instead be ITR so encapsulation to a removed Locator can stop and can instead be
started to a new Locator in the Locator-Set. started to a new Locator in the Locator-Set.
An ETR can send Map-Reply messages carrying a Map-Version Number An ETR can send Map-Reply messages carrying a Map-Version Number
[RFC9302] in an EID record. This is known as the Destination Map- [RFC9302] in an EID-Record. This is known as the Destination Map-
Version Number. ITRs include the Destination Map-Version Number in Version Number. ITRs include the Destination Map-Version Number in
packets they encapsulate to the site. packets they encapsulate to the site.
An ITR, when it encapsulates packets to ETRs, can convey its own Map- An ITR, when it encapsulates packets to ETRs, can convey its own Map-
Version Number. This is known as the Source Map-Version Number. Version Number. This is known as the Source Map-Version Number.
When presented in EID records of Map-Register messages [RFC9301], a When presented in EID-Records of Map-Register messages [RFC9301], a
Map-Version Number is a good way for the Map-Server [RFC9301] to Map-Version Number is a good way for the Map-Server [RFC9301] to
assure that all ETRs for a site registering to it are synchronized assure that all ETRs for a site registering to it are synchronized
according to the Map-Version Number. according to the Map-Version Number.
See [RFC9302] for a more detailed analysis and description of See [RFC9302] for a more detailed analysis and description of
Database Map-Versioning. Database Map-Versioning.
14. Multicast Considerations 14. Multicast Considerations
A multicast group address, as defined in the original Internet A multicast group address, as defined in the original Internet
skipping to change at line 1459 skipping to change at line 1459
plane. plane.
* On an ITR, prepending a new IP header consists of adding more * On an ITR, prepending a new IP header consists of adding more
octets to a Message Authentication Code (MAC) rewrite string and octets to a Message Authentication Code (MAC) rewrite string and
prepending the string as part of the outgoing encapsulation prepending the string as part of the outgoing encapsulation
procedure. Routers that support Generic Routing Encapsulation procedure. Routers that support Generic Routing Encapsulation
(GRE) tunneling [RFC2784] or 6to4 tunneling [RFC3056] may already (GRE) tunneling [RFC2784] or 6to4 tunneling [RFC3056] may already
support this action. support this action.
* A packet's source address or the interface on which the packet was * A packet's source address or the interface on which the packet was
received can be used to select VRF (Virtual Routing and received can be used to select Virtual Routing and Forwarding
Forwarding). The VRF system's routing table can be used to find (VRF). The VRF system's routing table can be used to find EID-to-
EID-to-RLOC mappings. RLOC mappings.
For performance issues related to Map-Cache management, see For performance issues related to Map-Cache management, see
Section 16. Section 16.
16. Security Considerations 16. Security Considerations
In what follows, we highlight security considerations that apply when In what follows, we highlight security considerations that apply when
LISP is deployed in environments such as those specified in LISP is deployed in environments such as those specified in
Section 1.1. Section 1.1.
skipping to change at line 1484 skipping to change at line 1484
learn the EID-to-RLOC mapping by inspecting the source RLOC and learn the EID-to-RLOC mapping by inspecting the source RLOC and
source EID of an encapsulated packet and insert this new mapping into source EID of an encapsulated packet and insert this new mapping into
its Map-Cache. An off-path attacker can spoof the source EID address its Map-Cache. An off-path attacker can spoof the source EID address
to divert the traffic sent to the victim's spoofed EID. If the to divert the traffic sent to the victim's spoofed EID. If the
attacker spoofs the source RLOC, it can mount a DoS attack by attacker spoofs the source RLOC, it can mount a DoS attack by
redirecting traffic to the spoofed victim's RLOC, potentially redirecting traffic to the spoofed victim's RLOC, potentially
overloading it. overloading it.
The LISP data plane defines several mechanisms to monitor RLOC data The LISP data plane defines several mechanisms to monitor RLOC data
plane reachability; in this context, Locator-Status-Bits, nonce- plane reachability; in this context, Locator-Status-Bits, nonce-
present bits, and echo-nonce bits of the LISP encapsulation header present bits, and Echo-Nonce bits of the LISP encapsulation header
can be manipulated by an attacker to mount a DoS attack. An off-path can be manipulated by an attacker to mount a DoS attack. An off-path
attacker able to spoof the RLOC and/or nonce of a victim's xTR can attacker able to spoof the RLOC and/or nonce of a victim's xTR can
manipulate such mechanisms to declare false information about the manipulate such mechanisms to declare false information about the
RLOC's reachability status. RLOC's reachability status.
An example of such attacks is when an off-path attacker can exploit An example of such attacks is when an off-path attacker can exploit
the echo-nonce mechanism by sending data packets to an ITR with a the Echo-Nonce mechanism by sending data packets to an ITR with a
random nonce from an ETR's spoofed RLOC. Note that the attacker only random nonce from an ETR's spoofed RLOC. Note that the attacker only
has a small window of time within which to guess a valid nonce that has a small window of time within which to guess a valid nonce that
the ITR is requesting to be echoed. The goal is to convince the ITR the ITR is requesting to be echoed. The goal is to convince the ITR
that the ETR's RLOC is reachable even when it may not be reachable. that the ETR's RLOC is reachable even when it may not be reachable.
If the attack is successful, the ITR believes the wrong reachability If the attack is successful, the ITR believes the wrong reachability
status of the ETR's RLOC until RLOC-Probing detects the correct status of the ETR's RLOC until RLOC-Probing detects the correct
status. This time frame is on the order of tens of seconds. This status. This time frame is on the order of tens of seconds. This
specific attack can be mitigated by preventing RLOC spoofing in the specific attack can be mitigated by preventing RLOC spoofing in the
network by deploying Unicast Reverse Path Forwarding (uRPF) per BCP network by deploying Unicast Reverse Path Forwarding (uRPF) per BCP
84 [RFC8704]. In order to exploit this vulnerability, the off-path 84 [RFC8704]. In order to exploit this vulnerability, the off-path
attacker must also send echo-nonce packets at a high rate. If the attacker must also send Echo-Nonce packets at a high rate. If the
nonces have never been requested by the ITR, it can protect itself nonces have never been requested by the ITR, it can protect itself
from erroneous reachability attacks. from erroneous reachability attacks.
A LISP-specific uRPF check is also possible. When decapsulating, an A LISP-specific uRPF check is also possible. When decapsulating, an
ETR can check that the source EID and RLOC are valid EID-to-RLOC ETR can check that the source EID and RLOC are valid EID-to-RLOC
mappings by checking the Mapping System. mappings by checking the Mapping System.
Map-Versioning is a data plane mechanism used to signal to a peering Map-Versioning is a data plane mechanism used to signal to a peering
xTR that a local EID-to-RLOC mapping has been updated so that the xTR that a local EID-to-RLOC mapping has been updated so that the
peering xTR uses a LISP control plane signaling message to retrieve a peering xTR uses a LISP control plane signaling message to retrieve a
fresh mapping. This can be used by an attacker to forge the 'Map- fresh mapping. This can be used by an attacker to forge the 'Map-
Version' field of a LISP-encapsulated header and force an excessive Version' field of a LISP-encapsulated header and force an excessive
amount of signaling between xTRs that may overload them. Further amount of signaling between xTRs that may overload them. Further
security considerations on Map-Versioning can be found in [RFC9302]. security considerations on Map-Versioning can be found in [RFC9302].
Locator-Status-Bits, the echo-nonce mechanism, and Map-Versioning Locator-Status-Bits, the Echo-Nonce mechanism, and Map-Versioning
MUST NOT be used over the public Internet and SHOULD only be used in MUST NOT be used over the public Internet and SHOULD only be used in
trusted and closed deployments. In addition, Locator-Status-Bits trusted and closed deployments. In addition, Locator-Status-Bits
SHOULD be coupled with Map-Versioning to prevent race conditions SHOULD be coupled with Map-Versioning to prevent race conditions
where Locator-Status-Bits are interpreted as referring to different where Locator-Status-Bits are interpreted as referring to different
RLOCs than intended. RLOCs than intended.
LISP implementations and deployments that permit outer header LISP implementations and deployments that permit outer header
fragments of IPv6 LISP-encapsulated packets as a means of dealing fragments of IPv6 LISP-encapsulated packets as a means of dealing
with MTU issues should also use implementation techniques in ETRs to with MTU issues should also use implementation techniques in ETRs to
prevent this from being a DoS attack vector. Limits on the number of prevent this from being a DoS attack vector. Limits on the number of
skipping to change at line 1658 skipping to change at line 1658
DOI 10.17487/RFC8378, May 2018, DOI 10.17487/RFC8378, May 2018,
<https://www.rfc-editor.org/info/rfc8378>. <https://www.rfc-editor.org/info/rfc8378>.
[RFC8704] Sriram, K., Montgomery, D., and J. Haas, "Enhanced [RFC8704] Sriram, K., Montgomery, D., and J. Haas, "Enhanced
Feasible-Path Unicast Reverse Path Forwarding", BCP 84, Feasible-Path Unicast Reverse Path Forwarding", BCP 84,
RFC 8704, DOI 10.17487/RFC8704, February 2020, RFC 8704, DOI 10.17487/RFC8704, February 2020,
<https://www.rfc-editor.org/info/rfc8704>. <https://www.rfc-editor.org/info/rfc8704>.
[RFC9301] Farinacci, D., Maino, F., Fuller, V., and A. Cabellos, [RFC9301] Farinacci, D., Maino, F., Fuller, V., and A. Cabellos,
Ed., "Locator/ID Separation Protocol (LISP) Control Ed., "Locator/ID Separation Protocol (LISP) Control
Plane", RFC 9301, DOI 10.17487/RFC9301, September 2022, Plane", RFC 9301, DOI 10.17487/RFC9301, October 2022,
<https://www.rfc-editor.org/info/rfc9301>. <https://www.rfc-editor.org/info/rfc9301>.
[RFC9302] Iannone, L., Saucez, D., and O. Bonaventure, "Locator/ID [RFC9302] Iannone, L., Saucez, D., and O. Bonaventure, "Locator/ID
Separation Protocol (LISP) Map-Versioning", RFC 9302, Separation Protocol (LISP) Map-Versioning", RFC 9302,
DOI 10.17487/RFC9302, 15 October 2020, DOI 10.17487/RFC9302, October 2022,
<https://www.rfc-editor.org/info/rfc9302>. <https://www.rfc-editor.org/info/rfc9302>.
20.2. Informative References 20.2. Informative References
[AFN] IANA, "Address Family Numbers", [AFN] IANA, "Address Family Numbers",
<http://www.iana.org/assignments/address-family-numbers>. <http://www.iana.org/assignments/address-family-numbers>.
[CHIAPPA] Chiappa, J., "Endpoints and Endpoint Names: A Proposed [CHIAPPA] Chiappa, J., "Endpoints and Endpoint Names: A Proposed
Enhancement to the Internet Architecture", 1999, Enhancement to the Internet Architecture", 1999,
<http://mercury.lcs.mit.edu/~jnc/tech/endpoints.txt>. <http://mercury.lcs.mit.edu/~jnc/tech/endpoints.txt>.
[LISP-VPN] Moreno, V. and D. Farinacci, "LISP Virtual Private [LISP-VPN] Moreno, V. and D. Farinacci, "LISP Virtual Private
Networks (VPNs)", Work in Progress, Internet-Draft, draft- Networks (VPNs)", Work in Progress, Internet-Draft, draft-
ietf-lisp-vpn-09, 10 July 2022, ietf-lisp-vpn-10, 3 October 2022,
<https://datatracker.ietf.org/doc/html/draft-ietf-lisp- <https://datatracker.ietf.org/doc/html/draft-ietf-lisp-
vpn-09>. vpn-10>.
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
<https://www.rfc-editor.org/info/rfc1034>. <https://www.rfc-editor.org/info/rfc1034>.
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
DOI 10.17487/RFC1191, November 1990, DOI 10.17487/RFC1191, November 1990,
<https://www.rfc-editor.org/info/rfc1191>. <https://www.rfc-editor.org/info/rfc1191>.
[RFC2453] Malkin, G., "RIP Version 2", STD 56, RFC 2453, [RFC2453] Malkin, G., "RIP Version 2", STD 56, RFC 2453,
skipping to change at line 1703 skipping to change at line 1703
[RFC2677] Greene, M., Cucchiara, J., and J. Luciani, "Definitions of [RFC2677] Greene, M., Cucchiara, J., and J. Luciani, "Definitions of
Managed Objects for the NBMA Next Hop Resolution Protocol Managed Objects for the NBMA Next Hop Resolution Protocol
(NHRP)", RFC 2677, DOI 10.17487/RFC2677, August 1999, (NHRP)", RFC 2677, DOI 10.17487/RFC2677, August 1999,
<https://www.rfc-editor.org/info/rfc2677>. <https://www.rfc-editor.org/info/rfc2677>.
[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.
Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, Traina, "Generic Routing Encapsulation (GRE)", RFC 2784,
DOI 10.17487/RFC2784, March 2000, DOI 10.17487/RFC2784, March 2000,
<https://www.rfc-editor.org/info/rfc2784>. <https://www.rfc-editor.org/info/rfc2784>.
[RFC2858] Bates, T., Rekhter, Y., Chandra, R., and D. Katz,
"Multiprotocol Extensions for BGP-4", RFC 2858,
DOI 10.17487/RFC2858, June 2000,
<https://www.rfc-editor.org/info/rfc2858>.
[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains
via IPv4 Clouds", RFC 3056, DOI 10.17487/RFC3056, February via IPv4 Clouds", RFC 3056, DOI 10.17487/RFC3056, February
2001, <https://www.rfc-editor.org/info/rfc3056>. 2001, <https://www.rfc-editor.org/info/rfc3056>.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
DOI 10.17487/RFC3261, June 2002, DOI 10.17487/RFC3261, June 2002,
<https://www.rfc-editor.org/info/rfc3261>. <https://www.rfc-editor.org/info/rfc3261>.
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106, RFC 4086, "Randomness Requirements for Security", BCP 106, RFC 4086,
DOI 10.17487/RFC4086, June 2005, DOI 10.17487/RFC4086, June 2005,
<https://www.rfc-editor.org/info/rfc4086>. <https://www.rfc-editor.org/info/rfc4086>.
[RFC4459] Savola, P., "MTU and Fragmentation Issues with In-the- [RFC4459] Savola, P., "MTU and Fragmentation Issues with In-the-
Network Tunneling", RFC 4459, DOI 10.17487/RFC4459, April Network Tunneling", RFC 4459, DOI 10.17487/RFC4459, April
2006, <https://www.rfc-editor.org/info/rfc4459>. 2006, <https://www.rfc-editor.org/info/rfc4459>.
[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
"Multiprotocol Extensions for BGP-4", RFC 4760,
DOI 10.17487/RFC4760, January 2007,
<https://www.rfc-editor.org/info/rfc4760>.
[RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU
Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007, Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007,
<https://www.rfc-editor.org/info/rfc4821>. <https://www.rfc-editor.org/info/rfc4821>.
[RFC4984] Meyer, D., Ed., Zhang, L., Ed., and K. Fall, Ed., "Report [RFC4984] Meyer, D., Ed., Zhang, L., Ed., and K. Fall, Ed., "Report
from the IAB Workshop on Routing and Addressing", from the IAB Workshop on Routing and Addressing",
RFC 4984, DOI 10.17487/RFC4984, September 2007, RFC 4984, DOI 10.17487/RFC4984, September 2007,
<https://www.rfc-editor.org/info/rfc4984>. <https://www.rfc-editor.org/info/rfc4984>.
[RFC6832] Lewis, D., Meyer, D., Farinacci, D., and V. Fuller, [RFC6832] Lewis, D., Meyer, D., Farinacci, D., and V. Fuller,
skipping to change at line 1793 skipping to change at line 1793
DOI 10.17487/RFC8201, July 2017, DOI 10.17487/RFC8201, July 2017,
<https://www.rfc-editor.org/info/rfc8201>. <https://www.rfc-editor.org/info/rfc8201>.
[RFC8899] Fairhurst, G., Jones, T., Tüxen, M., Rüngeler, I., and T. [RFC8899] Fairhurst, G., Jones, T., Tüxen, M., Rüngeler, I., and T.
Völker, "Packetization Layer Path MTU Discovery for Völker, "Packetization Layer Path MTU Discovery for
Datagram Transports", RFC 8899, DOI 10.17487/RFC8899, Datagram Transports", RFC 8899, DOI 10.17487/RFC8899,
September 2020, <https://www.rfc-editor.org/info/rfc8899>. September 2020, <https://www.rfc-editor.org/info/rfc8899>.
[RFC9299] Cabellos, A. and D. Saucez, Ed., "An Architectural [RFC9299] Cabellos, A. and D. Saucez, Ed., "An Architectural
Introduction to the Locator/ID Separation Protocol Introduction to the Locator/ID Separation Protocol
(LISP)", RFC 9299, DOI 10.17487/RFC9299, September 2022, (LISP)", RFC 9299, DOI 10.17487/RFC9299, October 2022,
<https://www.rfc-editor.org/info/rfc9299>. <https://www.rfc-editor.org/info/rfc9299>.
Acknowledgments Acknowledgments
An initial thank you goes to Dave Oran for planting the seeds for the An initial thank you goes to Dave Oran for planting the seeds for the
initial ideas for LISP. His consultation continues to provide value initial ideas for LISP. His consultation continues to provide value
to the LISP authors. to the LISP authors.
A special and appreciative thank you goes to Noel Chiappa for A special and appreciative thank you goes to Noel Chiappa for
providing architectural impetus over the past decades on separation providing architectural impetus over the past decades on separation
skipping to change at line 1852 skipping to change at line 1852
Kaduk, Eric Rescorla, Alvaro Retana, Alexey Melnikov, Alissa Cooper, Kaduk, Eric Rescorla, Alvaro Retana, Alexey Melnikov, Alissa Cooper,
Suresh Krishnan, Alberto Rodriguez-Natal, Vina Ermagan, Mohamed Suresh Krishnan, Alberto Rodriguez-Natal, Vina Ermagan, Mohamed
Boucadair, Brian Trammell, Sabrina Tanamal, and John Drake. The Boucadair, Brian Trammell, Sabrina Tanamal, and John Drake. The
contributions they offered greatly added to the security, scale, and contributions they offered greatly added to the security, scale, and
robustness of the LISP architecture and protocols. robustness of the LISP architecture and protocols.
Authors' Addresses Authors' Addresses
Dino Farinacci Dino Farinacci
lispers.net lispers.net
San Jose, CA
United States of America
Email: farinacci@gmail.com Email: farinacci@gmail.com
Vince Fuller Vince Fuller
vaf.net Internet Consulting vaf.net Internet Consulting
Email: vince.fuller@gmail.com Email: vince.fuller@gmail.com
Dave Meyer Dave Meyer
1-4-5.net 1-4-5.net
Email: dmm@1-4-5.net Email: dmm@1-4-5.net
Darrel Lewis Darrel Lewis
Cisco Systems Cisco Systems
170 Tasman Drive
San Jose, CA San Jose, CA
United States of America United States of America
Email: darlewis@cisco.com Email: darlewis@cisco.com
Albert Cabellos (editor) Albert Cabellos (editor)
UPC/BarcelonaTech Universitat Politecnica de Catalunya
Campus Nord c/ Jordi Girona s/n
C. Jordi Girona 1-3 08034 Barcelona
Barcelona Catalunya
Spain Spain
Email: acabello@ac.upc.edu Email: acabello@ac.upc.edu
 End of changes. 42 change blocks. 
64 lines changed or deleted 64 lines changed or added

This html diff was produced by rfcdiff 1.48.