rfc9735v1.txt   rfc9735.txt 
skipping to change at line 12 skipping to change at line 12
Internet Engineering Task Force (IETF) D. Farinacci Internet Engineering Task Force (IETF) D. Farinacci
Request for Comments: 9735 lispers.net Request for Comments: 9735 lispers.net
Category: Standards Track L. Iannone, Ed. Category: Standards Track L. Iannone, Ed.
ISSN: 2070-1721 Huawei ISSN: 2070-1721 Huawei
February 2025 February 2025
Locator/ID Separation Protocol (LISP) Distinguished Name Encoding Locator/ID Separation Protocol (LISP) Distinguished Name Encoding
Abstract Abstract
This document defines how to use the "Distinguished Name" Address This document defines how to use the Address Family Identifier (AFI)
Family Identifier (AFI) in the Locator/ID Separation Protocol (LISP). 17 "Distinguished Name" in the Locator/ID Separation Protocol (LISP).
Distinguished Names (DNs) can be used in either Endpoint Identifier LISP introduces two new numbering spaces: Endpoint Identifiers (EIDs)
(EID) records or Routing Locator (RLOC) records in LISP control and Routing Locators (RLOCs). Distinguished Names (DNs) can be used
messages to convey additional information. in either EID-Records or RLOC-Records in LISP control messages to
convey additional information.
Status of This Memo Status of This Memo
This is an Internet Standards Track document. This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has (IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841. Internet Standards is available in Section 2 of RFC 7841.
skipping to change at line 54 skipping to change at line 55
Trust Legal Provisions and are provided without warranty as described Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License. in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction 1. Introduction
2. Terminology 2. Terminology
2.1. Definition 2.1. Definition
2.2. Requirements Language 2.2. Requirements Language
3. Distinguished Name Format 3. Distinguished Name Format
4. Mapping System Lookups for Distinguished Name EIDs 4. Mapping-System Lookups for DN EIDs
5. Example Use Cases 5. Example Use Cases
6. Name-Collision Considerations 6. Name-Collision Considerations
7. Security Considerations 7. Security Considerations
8. IANA Considerations 8. IANA Considerations
9. Sample LISP Distinguished Name (DN) Deployment Experience 9. Sample LISP DN Deployment Experience
9.1. DNs to Advertise Specific Device Roles or Functions 9.1. DNs to Advertise Specific Device Roles or Functions
9.2. DNs to Drive xTR Onboarding Procedures 9.2. DNs to Drive xTR Onboarding Procedures
9.3. DNs for NAT-Traversal 9.3. DNs for NAT-Traversal
9.4. DNs for Self-Documenting RLOC Names 9.4. DNs for Self-Documenting RLOC Names
9.5. DNs used as EID Names 9.5. DNs Used as EID Names
10. References 10. References
10.1. Normative References 10.1. Normative References
10.2. Informative References 10.2. Informative References
Acknowledgments Acknowledgments
Authors' Addresses Authors' Addresses
1. Introduction 1. Introduction
The LISP architecture and protocols (see [RFC9300] and [RFC9301]) LISP ([RFC9300] and [RFC9301]) introduces two new numbering spaces:
introduce two new numbering spaces: Endpoint Identifiers (EIDs) and Endpoint Identifiers (EIDs) and Routing Locators (RLOCs). To provide
Routing Locators (RLOCs). To provide flexibility for current and flexibility for current and future applications, these values can be
future applications, these values can be encoded in LISP control encoded in LISP control messages using a general syntax that includes
messages using a general syntax that includes the Address Family the Address Family Identifier (AFI).
Identifier (AFI).
The length of addresses encoded in EID and RLOC records can easily be The length of addresses encoded in EID-Records and RLOC-Records can
determined by the AFI field, as the size of the address is implicit easily be determined by the AFI field, as the size of the address is
in its AFI value. For instance, for AFI = 1, which is "IP (IP implicit in its AFI value. For instance, for AFI equal to 1, which
version 4)", the address length is known to be 4 octets. However, is "IP (IP version 4)", the address length is known to be 4 octets.
AFI 17 "Distinguished Name", is a variable-length value, so the However, AFI 17 "Distinguished Name", is a variable-length value, so
length cannot be determined solely from the AFI value 17 the length cannot be determined solely from the AFI value 17
[IANA-ADDRESS-FAMILY-REGISTRY]. This document defines a termination [ADDRESS-FAMILY]. This document defines a termination character, an
character, an 8-bit value of 0, to be used as a string terminator so 8-bit value of 0, to be used as a string terminator so the length can
the length can be determined. be determined.
LISP Distinguished Names are useful when encoded either in EID- LISP DNs are useful when encoded either in EID-Records or RLOC-
Records or RLOC-records in LISP control messages. As EIDs, they can Records in LISP control messages. As EIDs, they can be registered in
be registered in the mapping system to find resources, services, or the Mapping System to find resources, services, or simply be used as
simply be used as a self-documenting feature that accompanies other a self-documenting feature that accompanies other address-specific
address-specific EIDs. As RLOCs, Distinguished Names, along with EIDs. As RLOCs, DNs, along with RLOC-specific addresses and
RLOC-specific addresses and parameters, can be used as labels to parameters, can be used as labels to identify equipment type,
identify equipment type, location, or any self-documenting string a location, or any self-documenting string a registering device desires
registering device desires to convey. to convey.
The Distinguished Name field in this document has no relationship to The Distinguished Name field in this document has no relationship to
the similarly named field in the Public-Key Infrastructure using the similarly named field in the Public-Key Infrastructure using
X.509 (PKIX) specifications [RFC5280]. X.509 (PKIX) specifications (e.g., [RFC5280]).
2. Terminology 2. Terminology
2.1. Definition 2.1. Definition
Address Family Identifier (AFI): a term used to describe an address Address Family Identifier (AFI): a term used to describe an address
encoding in a packet. An address family is currently defined for encoding in a packet. An address family is currently defined for
IPv4 or IPv6 addresses. See [IANA-ADDRESS-FAMILY-REGISTRY] for IPv4 or IPv6 addresses. See [ADDRESS-FAMILY] for details on other
details on other types of information that can be AFI encoded. types of information that can be AFI encoded.
2.2. Requirements Language 2.2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"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. Distinguished Name Format 3. Distinguished Name Format
An AFI=17 Distinguished Name is encoded as: An AFI 17 "Distinguished Name" is encoded as:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AFI = 17 | NULL Terminated US-ASCII ~ | AFI = 17 | NULL-Terminated (0x00) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ String | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ US-ASCII String |
~ | ~ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The variable-length string of characters are encoded as a NULL (0x00) The variable-length string of characters are encoded as a NULL-
terminated US-ASCII character set as defined in [RFC3629], where terminated (0x00) US-ASCII character set as defined in [RFC3629],
UTF-8 has the characteristic of preserving the full US-ASCII range. where UTF-8 has the characteristic of preserving the full US-ASCII
A NULL character MUST appear only once in the string and MUST be at range. A NULL character MUST appear only once in the string and MUST
the end of the string. be at the end of the string.
When Distinguished Names are encoded for EIDs, the EID Mask-Len When DNs are encoded for EIDs, the EID Mask-Len length of the EID-
length of the EIDs as they appear in EID-Records for all LISP control Records, for all LISP control messages [RFC9301], is the length of
messages [RFC9301] is the length of the string in bits (including the the string in bits (including the NULL-terminated 0x00 octet).
terminating NULL 0x00 octet).
Where Distinguished Names are encoded anywhere else (i.e., nested in Where DNs are encoded anywhere else (i.e., nested in LISP Canonical
LISP Canonical Address Format (LCAF) encodings [RFC8060]), an Address Format (LCAF) encodings [RFC8060]), an explicit length field
explicit length field can be used to indicate the length of the ASCII can be used to indicate the length of the ASCII string in octets.
string in octets. The length field MUST include the NULL 0 octet. The length field MUST include the NULL octet (0x00). The string MUST
The string MUST still be NULL terminated. If a NULL 0 octet appears still be NULL-terminated (0x00). If a NULL octet (0x00) appears
before the end of the octet field, i.e., the NULL octet appears before the end of the octet field, i.e., the NULL octet (0x00)
before the last position in the octet fields, then the string MAY be appears before the last position in the octet fields, then the string
accepted and the octets after the NULL 0 octet MUST NOT be used as MAY be accepted and the octets after the NULL octet (0x00) MUST NOT
part of the octet string. be used as part of the octet string.
If the octet after the AFI field is the NULL 0 octet, the string is a If the octet after the AFI field is the NULL octet (0x00), the string
NULL string and MUST be accepted. That is, an AFI=17 encoded string is a NULL string and MUST be accepted. That is, an AFI 17
MUST be at least 1 octet in length. "Distinguished Name" encoded string MUST be at least 1 octet in
length.
4. Mapping System Lookups for Distinguished Name EIDs 4. Mapping-System Lookups for DN EIDs
Distinguished Name EID lookups MUST carry as an EID Mask-Len length When performing DN-EID lookups, Map-Request messages MUST carry an
equal to the length of the name string. This instructs the mapping EID Mask-Len length equal to the length of the name string in bits.
system to do either an exact-match or a longest-match lookup. This instructs the Mapping System to do either an exact-match or a
longest-match lookup.
If the Distinguished Name EID is registered with the same length as If the DN EID is registered with the same length as the length in a
the length in a Map-Request, the Map-Server (when configured for Map-Request, the Map-Server (when configured for proxy Map-Replying)
proxy Map-Replying) returns an exact-match lookup with the same EID returns an exact-match lookup with the same EID Mask-Len length. If
Mask-Len length. If a less specific name is registered, then the a less specific name is registered, then the Map-Server returns the
Map-Server returns the registered name with the registered EID Mask- registered name with the registered EID Mask-Len length.
Len length.
For example, if the registered EID name is "ietf" with an EID Mask- For example, if the registered EID name is "ietf" with an EID Mask-
Len length of 40 bits (the length of the string "ietf" plus the null Len length of 40 bits (the length of the string "ietf" plus the
octet is 5 octets), and a Map-Request is received for EID name length of the NULL octet (0x00) makes 5 octets), and a Map-Request is
"ietf.lisp" with an EID Mask-Len length of 80 bits, the Map-Server received for EID name "ietf.lisp" with an EID Mask-Len length of 80
will return EID "ietf" with a length of 40 bits. bits, the Map-Server will return EID "ietf" with a length of 40 bits.
5. Example Use Cases 5. Example Use Cases
This section identifies three specific use-case examples for the This section identifies three specific use-case examples for the DN
Distinguished Name format: two are used for an EID encoding and one format: two are used for an EID encoding and one for an RLOC-Record
for an RLOC-record encoding. When storing public keys in the mapping encoding. When storing public keys in the Mapping System, as in
system, as in [LISP-ECDSA], a well-known format for a public-key hash [LISP-ECDSA], a well-known format for a public-key hash can be
can be encoded as a Distinguished Name. When street-location-to-GPS- encoded as a DN. When street-location-to-GPS-coordinate mappings
coordinate mappings exist in the mapping system, as in [LISP-GEO], exist in the Mapping System, as in [LISP-GEO], the street location
the street location can be a free-form UTF-8 ASCII representation can be a free-form UTF-8 ASCII representation (with whitespace
(with whitespace characters) encoded as a Distinguished Name. An characters) encoded as a DN. An RLOC that describes an Ingress or
RLOC that describes an Ingress or Egress Tunnel Router (xTR) behind a Egress Tunnel Router (xTR) behind a NAT device can be identified by
NAT device can be identified by its router name, as in its router name, as in [LISPERS-NET-NAT]. In this case, DN encoding
[LISP-NET-NAT]. In this case, Distinguished Name encoding is used in is used in NAT Info-Request messages after the EID-prefix field of
NAT Info-Request messages after the EID-prefix field of the message. the message.
6. Name-Collision Considerations 6. Name-Collision Considerations
When a Distinguished Name encoding is used to format an EID, the When a DN encoding is used to format an EID, the uniqueness and
uniqueness and allocation concerns are no different than registering allocation concerns are no different than registering IPv4 or IPv6
IPv4 or IPv6 EIDs to the mapping system. See [RFC9301] for more EIDs to the Mapping System. See [RFC9301] for more details. Also,
details. Also, the use cases documented in Section 5 of this the use cases documented in Section 5 of this specification provide
specification provide allocation recommendations for their specific allocation recommendations for their specific uses.
uses.
It is RECOMMENDED that each use case register their Distinguished It is RECOMMENDED that each use case register their DNs with a unique
Names with a unique Instance-ID. Any use cases that require Instance-ID. Any use cases that require different uses for DNs
different uses for Distinguished Names within an Instance-ID MUST within an Instance-ID MUST define their own Instance-ID and syntax
define their own Instance-ID and syntax structure for the name structure for the name registered to the Mapping System. See the
registered to the Mapping System. See the encoding procedures in encoding procedures in [LISP-VPN] for an example.
[LISP-VPN] for an example.
7. Security Considerations 7. Security Considerations
Distinguished Names are used in mappings that are part of the LISP DNs are used in mappings that are part of the LISP control plane and
control plane and may be encoded using LCAF; thus, the security may be encoded using LCAF; thus, the security considerations of
considerations of [RFC9301] and [RFC8060] apply. [RFC9301] and [RFC8060] apply.
8. IANA Considerations 8. IANA Considerations
This document has no IANA actions. This document has no IANA actions.
9. Sample LISP Distinguished Name (DN) Deployment Experience 9. Sample LISP DN Deployment Experience
Practical implementations of the LISP Distinguished Name Practical implementations of the LISP DN, defined in this document,
specification have been running in production networks for some time. have been running in production networks for some time. The
The following sections provide some examples of its usage and lessons following sections provide some examples of its usage and lessons
learned out of this experience. learned out of this experience.
9.1. DNs to Advertise Specific Device Roles or Functions 9.1. DNs to Advertise Specific Device Roles or Functions
In a practical implementation of [LISP-EXT] on LISP deployments, In a practical implementation of [LISP-EXT] on LISP deployments,
routers running as Proxy Egress Tunnel Routers (Proxy-ETRs) register routers running as Proxy Egress Tunnel Routers (Proxy-ETRs) register
their role with the Mapping System in order to attract traffic their role with the Mapping System in order to attract traffic
destined for external networks. Practical implementations of this destined for external networks. Practical implementations of this
functionality make use of a Distinguished Name as an EID to identify functionality make use of a DN as an EID to identify the Proxy-ETR
the Proxy-ETR role in a Map-Registration. role in a Map-Registration.
In this case, all Proxy-ETRs supporting this function register a In this case, all Proxy-ETRs supporting this function register a
common Distinguished Name together with their own offered locator. common DN together with their own offered locator. The Mapping
The Mapping-System aggregates the locators received from all Proxy- System aggregates the locators received from all Proxy-ETRs as a
ETRs as a common locator-set that is associated with this DN EID. In common locator-set that is associated with this DN EID. In this
this scenario, the Distinguished Name serves as a common reference scenario, the DN serves as a common reference EID that can be
EID that can be requested (or subscribed as per [RFC9437]) to requested (or subscribed as per [RFC9437]) to dynamically gather this
dynamically gather this Proxy-ETR list as specified in the LISP Site Proxy-ETR list as specified in the LISP Site External Connectivity
External Connectivity document. document [LISP-EXT].
The use of a Distinguished Name here provides descriptive information The use of a DN here provides descriptive information about the role
about the role being registered and allows the Mapping System to form being registered and allows the Mapping System to form locator-sets
locator-sets associated with a specific role. These locator-sets can associated with a specific role. These locator-sets can be
be distributed on-demand based on using the shared DN as EID. It distributed on-demand based on using the shared DN as EID. It also
also allows the network admin and the Mapping System to selectively allows the network admin and the Mapping System to selectively choose
choose what roles and functions can be registered and distributed to what roles and functions can be registered and distributed to the
the rest of the participants in the network. rest of the participants in the network.
9.2. DNs to Drive xTR Onboarding Procedures 9.2. DNs to Drive xTR Onboarding Procedures
Following the LISP reliable transport [LISP-MAP], ETRs that plan to Following the LISP reliable transport [LISP-MAP], ETRs that plan to
switch to using reliable transport to hold registrations first need switch to using reliable transport to hold registrations first need
to start with traditional UDP registrations. The UDP registration to start with UDP registrations. The UDP registration allows the
allows the Map-Server to perform basic authentication of the ETR and Map-Server to perform basic authentication of the ETR and to create
to create the necessary state to permit the reliable transport the necessary state to permit the reliable transport session to be
session to be established (e.g., establish a passive open on TCP port established (e.g., establish a passive open on TCP port 4342 and add
4342 and add the ETR RLOC to the list allowed to establish a the ETR RLOC to the list allowed to establish a session).
session).
In the basic implementation of this process, the ETRs need to wait In the basic implementation of this process, the ETRs need to wait
until local mappings are available and ready to be registered with until local mappings are available and ready to be registered with
the Mapping System. Furthermore, when the mapping system is the Mapping System. Furthermore, when the Mapping System is
distributed, the ETR requires having one specific mapping ready to be distributed, the ETR requires having one specific mapping ready to be
registered with each one of the relevant Map-Servers. This process registered with each one of the relevant Map-Servers. This process
may delay the onboarding of ETRs with the Mapping System so that they may delay the onboarding of ETRs with the Mapping System so that they
can switch to using reliable transport. This can also lead to can switch to using reliable transport. This can also lead to
generating unnecessary signaling as a reaction to certain triggers generating unnecessary signaling as a reaction to certain triggers
like local port flaps and device failures. like local port flaps and device failures.
The use of dedicated name registrations allows driving this initial The use of dedicated name registrations allows driving this initial
ETR onboarding on the Mapping System as a deterministic process that ETR onboarding on the Mapping System as a deterministic process that
does not depend on the availability of other mappings. It also does not depend on the availability of other mappings. It also
provides more stability to the reliable transport session to survive provides more stability to the reliable transport session to survive
through transient events. through transient events.
In practice, LISP deployments use dedicated Distinguished Names that In practice, LISP deployments use dedicated DNs that are registered
are registered as soon as xTRs come online with all the necessary as soon as xTRs come online with all the necessary Map-Servers in the
Map-Servers in the Mapping System. The mapping with the dedicated DN Mapping System. The mapping with the dedicated DN together with the
together with the RLOCs of each Egress Tunnel Router (ETR) in the RLOCs of each Egress Tunnel Router (ETR) in the locator-set is used
locator-set is used to drive the initial UDP registration and also to to drive the initial UDP registration and also to keep the reliable
keep the reliable transport state stable through network condition transport state stable through network condition changes. On the
changes. On the Map-Server, these DN registrations facilitate Map-Server, these DN registrations facilitate setting up the
setting up the necessary state to onboard new ETRs rapidly and in a necessary state to onboard new ETRs rapidly and in a more
more deterministic manner. deterministic manner.
9.3. DNs for NAT-Traversal 9.3. DNs for NAT-Traversal
The open source lispers.net NAT-Traversal implementation At the time of writing, the open-source lispers.net NAT-Traversal
[LISP-NET-NAT] has had 10 years of deployment experience using implementation [LISPERS-NET-NAT] has deployed DNs for documenting
Distinguished Names for documenting xTRs versus Re-encapsulating xTRs versus Re-encapsulating Tunnel Routers (RTRs) as they appear in
Tunnel Routers (RTRs) as they appear in a locator-set. a locator-set for 10 years.
9.4. DNs for Self-Documenting RLOC Names 9.4. DNs for Self-Documenting RLOC Names
The open source lispers.net implementation has had 10 years of self- At the time of writing, the open-source lispers.net implementation
documenting RLOC names in production and pilot environments. The [LISPERS-NET-NAT] has self-documented RLOC names in production and
RLOC name is encoded with the RLOC address in Distinguished Name pilot environments for 10 years. The RLOC name is encoded with the
format. RLOC address in DN format.
9.5. DNs used as EID Names 9.5. DNs Used as EID Names
The open source lispers.net implementation has had 10 years of At the time of writing, the open-source lispers.net implementation
deployment experience allowing xTRs to register EIDs as Distinguished [LISPERS-NET-NAT] has deployed xTRs that are allowed to register EIDs
Names. The LISP Mapping System can be used as a DNS proxy for Name- as DNs for 10 years. The LISP Mapping System can be used as a DNS
to-EID-address or Name-to-RLOC-address mappings. The implementation proxy for Name-to-EID-address or Name-to-RLOC-address mappings. The
also supports Name-to-Public-Key mappings to provide key management implementation also supports Name-to-Public-Key mappings to provide
features in [LISP-ECDSA]. key management features in [LISP-ECDSA].
10. References 10. References
10.1. Normative References 10.1. Normative References
[IANA-ADDRESS-FAMILY-REGISTRY] [ADDRESS-FAMILY]
IANA, "Address Family Numbers", IANA, "Address Family Numbers",
<https://www.iana.org/assignments/address-family-numbers>. <https://www.iana.org/assignments/address-family-numbers>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
skipping to change at line 374 skipping to change at line 371
January 2025, <https://datatracker.ietf.org/doc/html/ January 2025, <https://datatracker.ietf.org/doc/html/
draft-ietf-lisp-geo-09>. draft-ietf-lisp-geo-09>.
[LISP-MAP] Venkatachalapathy, B., Portoles-Comeras, M., Lewis, D., [LISP-MAP] Venkatachalapathy, B., Portoles-Comeras, M., Lewis, D.,
Kouvelas, I., and C. Cassar, "LISP Map Server Reliable Kouvelas, I., and C. Cassar, "LISP Map Server Reliable
Transport", Work in Progress, Internet-Draft, draft-ietf- Transport", Work in Progress, Internet-Draft, draft-ietf-
lisp-map-server-reliable-transport-05, 4 November 2024, lisp-map-server-reliable-transport-05, 4 November 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-lisp- <https://datatracker.ietf.org/doc/html/draft-ietf-lisp-
map-server-reliable-transport-05>. map-server-reliable-transport-05>.
[LISP-NET-NAT]
Farinacci, D., "lispers.net LISP NAT-Traversal
Implementation Report", Work in Progress, Internet-Draft,
draft-farinacci-lisp-lispers-net-nat-09, 8 December 2024,
<https://datatracker.ietf.org/doc/html/draft-farinacci-
lisp-lispers-net-nat-09>.
[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-12, 19 September 2023, ietf-lisp-vpn-12, 19 September 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-lisp- <https://datatracker.ietf.org/doc/html/draft-ietf-lisp-
vpn-12>. vpn-12>.
[LISPERS-NET-NAT]
Farinacci, D., "lispers.net LISP NAT-Traversal
Implementation Report", Work in Progress, Internet-Draft,
draft-farinacci-lisp-lispers-net-nat-09, 8 December 2024,
<https://datatracker.ietf.org/doc/html/draft-farinacci-
lisp-lispers-net-nat-09>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<https://www.rfc-editor.org/info/rfc5280>. <https://www.rfc-editor.org/info/rfc5280>.
[RFC8060] Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical [RFC8060] Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical
Address Format (LCAF)", RFC 8060, DOI 10.17487/RFC8060, Address Format (LCAF)", RFC 8060, DOI 10.17487/RFC8060,
February 2017, <https://www.rfc-editor.org/info/rfc8060>. February 2017, <https://www.rfc-editor.org/info/rfc8060>.
 End of changes. 38 change blocks. 
158 lines changed or deleted 155 lines changed or added

This html diff was produced by rfcdiff 1.48.