rfc9735.original   rfc9735.txt 
Internet Engineering Task Force D. Farinacci Internet Engineering Task Force (IETF) D. Farinacci
Internet-Draft lispers.net Request for Comments: 9735 lispers.net
Intended status: Standards Track L. Iannone, Ed. Category: Standards Track L. Iannone, Ed.
Expires: 12 June 2025 Huawei ISSN: 2070-1721 Huawei
9 December 2024 February 2025
LISP Distinguished Name Encoding Locator/ID Separation Protocol (LISP) Distinguished Name Encoding
draft-ietf-lisp-name-encoding-17
Abstract Abstract
This documents defines how to use the Address Family Identifier (AFI) This document defines how to use the "Distinguished Name" Address
17 "Distinguished Names" in LISP. Distinguished Names can be used Family Identifier (AFI) in the Locator/ID Separation Protocol (LISP).
either in Endpoint Identifiers (EID) records or Routing Locators Distinguished Names (DNs) can be used in either Endpoint Identifier
(RLOC) records in LISP control messages to convey additional (EID) records or Routing Locator (RLOC) records in LISP control
information. messages to convey additional information.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on 12 June 2025. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9735.
Copyright Notice Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the Copyright (c) 2025 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Revised BSD License text as to this document. Code Components extracted from this document must
described in Section 4.e of the Trust Legal Provisions and are include Revised BSD License text as described in Section 4.e of the
provided without warranty as described in the Revised BSD License. Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction
2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology
3. Distinguished Name Format . . . . . . . . . . . . . . . . . . 4 2.1. Definition
4. Mapping System Lookups for Distinguished Name EIDs . . . . . 5 2.2. Requirements Language
5. Example Use-Cases . . . . . . . . . . . . . . . . . . . . . . 5 3. Distinguished Name Format
6. Name Collision Considerations . . . . . . . . . . . . . . . . 5 4. Mapping System Lookups for Distinguished Name EIDs
7. Security Considerations . . . . . . . . . . . . . . . . . . . 6 5. Example Use Cases
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 6. Name-Collision Considerations
9. Sample LISP Distinguished Name (DN) Deployment Experience . . 6 7. Security Considerations
9.1. DNs to Advertise Specific Device Roles or Functions . . . 6 8. IANA Considerations
9.2. DNs to Drive xTR On-Boarding Procedures . . . . . . . . . 7 9. Sample LISP Distinguished Name (DN) Deployment Experience
9.3. DNs for NAT-Traversal . . . . . . . . . . . . . . . . . . 7 9.1. DNs to Advertise Specific Device Roles or Functions
9.4. DNs for Self-Documenting RLOC Names . . . . . . . . . . . 8 9.2. DNs to Drive xTR Onboarding Procedures
9.5. DNs used as EID Names . . . . . . . . . . . . . . . . . . 8 9.3. DNs for NAT-Traversal
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 9.4. DNs for Self-Documenting RLOC Names
10.1. Normative References . . . . . . . . . . . . . . . . . . 8 9.5. DNs used as EID Names
10.2. Informative References . . . . . . . . . . . . . . . . . 9 10. References
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 10 10.1. Normative References
Appendix B. Document Change Log . . . . . . . . . . . . . . . . 10 10.2. Informative References
B.1. Changes to draft-ietf-lisp-name-encoding-17 . . . . . . . 10 Acknowledgments
B.2. Changes to draft-ietf-lisp-name-encoding-16 . . . . . . . 10 Authors' Addresses
B.3. Changes to draft-ietf-lisp-name-encoding-15 . . . . . . . 10
B.4. Changes to draft-ietf-lisp-name-encoding-14 . . . . . . . 11
B.5. Changes to draft-ietf-lisp-name-encoding-13 . . . . . . . 11
B.6. Changes to draft-ietf-lisp-name-encoding-12 . . . . . . . 11
B.7. Changes to draft-ietf-lisp-name-encoding-11 . . . . . . . 11
B.8. Changes to draft-ietf-lisp-name-encoding-10 . . . . . . . 11
B.9. Changes to draft-ietf-lisp-name-encoding-09 . . . . . . . 11
B.10. Changes to draft-ietf-lisp-name-encoding-08 . . . . . . . 11
B.11. Changes to draft-ietf-lisp-name-encoding-07 . . . . . . . 12
B.12. Changes to draft-ietf-lisp-name-encoding-06 . . . . . . . 12
B.13. Changes to draft-ietf-lisp-name-encoding-05 . . . . . . . 12
B.14. Changes to draft-ietf-lisp-name-encoding-04 . . . . . . . 12
B.15. Changes to draft-ietf-lisp-name-encoding-03 . . . . . . . 12
B.16. Changes to draft-ietf-lisp-name-encoding-02 . . . . . . . 12
B.17. Changes to draft-ietf-lisp-name-encoding-01 . . . . . . . 13
B.18. Changes to draft-ietf-lisp-name-encoding-00 . . . . . . . 13
B.19. Changes to draft-farinacci-lisp-name-encoding-15 . . . . 13
B.20. Changes to draft-farinacci-lisp-name-encoding-14 . . . . 13
B.21. Changes to draft-farinacci-lisp-name-encoding-13 . . . . 13
B.22. Changes to draft-farinacci-lisp-name-encoding-12 . . . . 13
B.23. Changes to draft-farinacci-lisp-name-encoding-11 . . . . 13
B.24. Changes to draft-farinacci-lisp-name-encoding-10 . . . . 14
B.25. Changes to draft-farinacci-lisp-name-encoding-09 . . . . 14
B.26. Changes to draft-farinacci-lisp-name-encoding-08 . . . . 14
B.27. Changes to draft-farinacci-lisp-name-encoding-07 . . . . 14
B.28. Changes to draft-farinacci-lisp-name-encoding-06 . . . . 14
B.29. Changes to draft-farinacci-lisp-name-encoding-05 . . . . 14
B.30. Changes to draft-farinacci-lisp-name-encoding-04 . . . . 14
B.31. Changes to draft-farinacci-lisp-name-encoding-03 . . . . 14
B.32. Changes to draft-farinacci-lisp-name-encoding-02 . . . . 15
B.33. Changes to draft-farinacci-lisp-name-encoding-01 . . . . 15
B.34. Changes to draft-farinacci-lisp-name-encoding-00 . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction 1. Introduction
The LISP architecture and protocols ([RFC9300], [RFC9301]) introduces The LISP architecture and protocols (see [RFC9300] and [RFC9301])
two new numbering spaces, Endpoint Identifiers (EIDs) and Routing introduce two new numbering spaces: Endpoint Identifiers (EIDs) and
Locators (RLOCs). To provide flexibility for current and future Routing Locators (RLOCs). To provide flexibility for current and
applications, these values can be encoded in LISP control messages future applications, these values can be encoded in LISP control
using a general syntax that includes Address Family Identifier (AFI). messages using a general syntax that includes the Address Family
Identifier (AFI).
The length of addresses encoded in EID and RLOC records can be easily The length of addresses encoded in EID and RLOC records can easily be
determined by the AFI field, as the size of the address is implicit determined by the AFI field, as the size of the address is implicit
in its AFI value. For instance, for AFI = 1, which is IP version 4, in its AFI value. For instance, for AFI = 1, which is "IP (IP
the address length is known to be 4 octets. However, AFI 17 version 4)", the address length is known to be 4 octets. However,
"Distinguished Name", is a variable length value, so the length AFI 17 "Distinguished Name", is a variable-length value, so the
cannot be determined solely from the AFI value 17. This document length cannot be determined solely from the AFI value 17
defines a termination character, an 8-bit value of 0 to be used as a [IANA-ADDRESS-FAMILY-REGISTRY]. This document defines a termination
string terminator so the length can be determined. character, an 8-bit value of 0, to be used as a string terminator so
the length can be determined.
LISP Distinguished Names are useful when encoded either in EID- LISP Distinguished Names are useful when encoded either in EID-
Records or RLOC-records in LISP control messages. As EIDs, they can Records or RLOC-records in LISP control messages. As EIDs, they can
be registered in the mapping system to find resources, services, or be registered in the mapping system to find resources, services, or
simply used as a self-documenting feature that accompany other simply be used as a self-documenting feature that accompanies other
address specific EIDs. As RLOCs, Distinguished Names, along with address-specific EIDs. As RLOCs, Distinguished Names, along with
RLOC specific addresses and parameters, can be used as labels to RLOC-specific addresses and parameters, can be used as labels to
identify equipment type, location, or any self-documenting string a identify equipment type, location, or any self-documenting string a
registering device desires to convey. registering device desires 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 [RFC5280].
2. Definition of Terms 2. Terminology
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 [IANA-ADDRESS-FAMILY-REGISTRY] for
details on other types of information that can be AFI encoded. details on other types of information that can be AFI encoded.
2.2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
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 US-ASCII ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ String | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ String |
~ | ~ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The variable length string of characters are encoded as a NULL (0x00) The variable-length string of characters are encoded as a NULL (0x00)
terminated US-ASCII character-set as defined in [RFC3629], where terminated US-ASCII character set as defined in [RFC3629], where
UTF-8 has the characteristic of preserving the full US-ASCII range. UTF-8 has the characteristic of preserving the full US-ASCII range.
NULL character MUST be appear only once in the string and MUST be at A NULL character MUST appear only once in the string and MUST be at
the end of the string. the end of the string.
When Distinguished Names are encoded for EIDs, the EID Mask-Len When Distinguished Names are encoded for EIDs, the EID Mask-Len
length of the EIDs as they appear in EID-Records for all LISP control length of the EIDs as they appear in EID-Records for all LISP control
messages [RFC9301] is the length of the string in bits (including the messages [RFC9301] is the length of the string in bits (including the
terminating NULL 0x00 octet). terminating NULL 0x00 octet).
Where Distinguished Names are encoded anywhere else (i.e., nested in Where Distinguished Names are encoded anywhere else (i.e., nested in
LCAF encodings [RFC8060]), then a explicit length field can be used LISP Canonical Address Format (LCAF) encodings [RFC8060]), an
to indicate the length of the ASCII string in octets, the length explicit length field can be used to indicate the length of the ASCII
field MUST include the NULL 0 octet. The string MUST still be NULL string in octets. The length field MUST include the NULL 0 octet.
terminated. If a NULL 0 octet appears before the end of the octet The string MUST still be NULL terminated. If a NULL 0 octet appears
field, i.e., the NULL octet appears before the the last position in before the end of the octet field, i.e., the NULL octet appears
the octet fields, then the string MAY be accepted and the octets before the last position in the octet fields, then the string MAY be
after the NULL 0 octet MUST NOT be used as part of the octet string. accepted and the octets after the NULL 0 octet MUST NOT 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 0 octet, the string is a
NULL string and MUST be accepted. That is, an AFI=17 encoded string NULL string and MUST be accepted. That is, an AFI=17 encoded string
MUST be at least 1 octet in length. MUST be at least 1 octet in length.
4. Mapping System Lookups for Distinguished Name EIDs 4. Mapping System Lookups for Distinguished Name EIDs
Distinguished Name EID lookups MUST carry as an EID Mask-Len length Distinguished Name EID lookups MUST carry as an EID Mask-Len length
equal to the length of the name string. This instructs the mapping equal to the length of the name string. This instructs the mapping
system to do either an exact match or longest match lookup. 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 Distinguished Name EID is registered with the same length as
the length in a Map-Request, the Map-Server (when configured for the length in a Map-Request, the Map-Server (when configured for
proxy Map-Replying) returns an exact match lookup with the same EID proxy Map-Replying) returns an exact-match lookup with the same EID
Mask-Len length. If a less specific name is registered, then the Mask-Len length. If a less specific name is registered, then the
Map-Server returns the registered name with the registered EID Mask- Map-Server returns the registered name with the registered EID Mask-
Len length. Len length.
For example, if the registered EID name is "ietf" with EID Mask-Len For example, if the registered EID name is "ietf" with an EID Mask-
of 40 bits (the length of string "ietf" plus the null octet is 5 Len length of 40 bits (the length of the string "ietf" plus the null
octets), and a Map-Request is received for EID name "ietf.lisp" with octet is 5 octets), and a Map-Request is received for EID name
an EID Mask-Len of 80 bits, the Map-Server will return EID "ietf" "ietf.lisp" with an EID Mask-Len length of 80 bits, the Map-Server
with length of 40 bits. will return EID "ietf" with a length of 40 bits.
5. Example Use-Cases 5. Example Use Cases
This section identifies three specific use-cases examples for the This section identifies three specific use-case examples for the
Distinguished Name format. Two are used for an EID encoding and one Distinguished Name format: two are used for an EID encoding and one
for an RLOC-record encoding. When storing public keys in the mapping for an RLOC-record encoding. When storing public keys in the mapping
system, as in [I-D.ietf-lisp-ecdsa-auth], a well-known format for a system, as in [LISP-ECDSA], a well-known format for a public-key hash
public-key hash can be encoded as a Distinguished Name. When street can be encoded as a Distinguished Name. When street-location-to-GPS-
location to GPS coordinate mappings exist in the mapping system, as coordinate mappings exist in the mapping system, as in [LISP-GEO],
in [I-D.ietf-lisp-geo], the street location can be a free form UTF-8 the street location can be a free-form UTF-8 ASCII representation
ASCII representation (with whitespace characters) encoded as a (with whitespace characters) encoded as a Distinguished Name. An
Distinguished Name. An RLOC that describes an Ingress or Egress RLOC that describes an Ingress or Egress Tunnel Router (xTR) behind a
Tunnel Router (xTR) behind a NAT device can be identified by its NAT device can be identified by its router name, as in
router name, as in [I-D.farinacci-lisp-lispers-net-nat]. In this [LISP-NET-NAT]. In this case, Distinguished Name encoding is used in
case, Distinguished Name encoding is used in NAT Info-Request NAT Info-Request messages after the EID-prefix field of the message.
messages after the EID-prefix field of the message.
6. Name Collision Considerations 6. Name-Collision Considerations
When a Distinguished Name encoding is used to format an EID, the When a Distinguished Name encoding is used to format an EID, the
uniqueness and allocation concerns are no different than registering uniqueness and allocation concerns are no different than registering
IPv4 or IPv6 EIDs to the mapping system. See [RFC9301] for more IPv4 or IPv6 EIDs to the mapping system. See [RFC9301] for more
details. Also, the use-case documents specified in Section 5 of this details. Also, the use cases documented in Section 5 of this
specification provide allocation recommendations for their specific specification provide 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 Distinguished
Names with a unique Instance-ID. For any use-cases which require Names with a unique Instance-ID. Any use cases that require
different uses for Distinguish Names within an Instance-ID MUST different uses for Distinguished Names within an Instance-ID MUST
define their own Instance-ID and structure syntax for the name define their own Instance-ID and syntax structure for the name
registered to the Mapping System. See the encoding procedures in registered to the Mapping System. See the encoding procedures in
[I-D.ietf-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 Distinguished Names are used in mappings that are part of the LISP
control plane and may be encoded using LCAF, as such security control plane and may be encoded using LCAF; thus, the security
considerations of [RFC9301] and [RFC8060] apply. considerations of [RFC9301] and [RFC8060] apply.
8. IANA Considerations 8. IANA Considerations
The code-point value in this specification, namely AFI 17, is already This document has no IANA actions.
allocated in [IANA-ADDRESS-FAMILY-REGISTRY].
9. Sample LISP Distinguished Name (DN) Deployment Experience 9. Sample LISP Distinguished Name (DN) Deployment Experience
Practical implementations of the LISP Distinguished Name Practical implementations of the LISP Distinguished Name
specification have been running in production networks for some time. specification have been running in production networks for some time.
The following sections provide some examples of its usage and lessons The following sections provide some examples of its usage and lessons
gathered 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 In a practical implementation of [LISP-EXT] on LISP deployments,
[I-D.ietf-lisp-site-external-connectivity] 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 Distinguished Name as an EID to identify
the Proxy-ETR role in a Map-Registration. the Proxy-ETR 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 Distinguished Name together with their own offered locator.
The Mapping-System aggregates the locators received from all Proxy- The Mapping-System aggregates the locators received from all Proxy-
ETRs as a common locator-set that is associated with this DN EID. ETRs as a common locator-set that is associated with this DN EID. In
The Distinguished Name in this case serves as a common reference EID this scenario, the Distinguished Name serves as a common reference
that can be requested (or subscribed as per [RFC9437]) to dynamically EID that can be requested (or subscribed as per [RFC9437]) to
gather this Proxy-ETR list as specified in the LISP Site External dynamically gather this Proxy-ETR list as specified in the LISP Site
Connectivity document. External Connectivity document.
The use of a Distinguished Name in this case provides descriptive The use of a Distinguished Name here provides descriptive information
information about the role being registered and allows the Mapping about the role being registered and allows the Mapping System to form
System to form locator-sets associated to specific role. These locator-sets associated with a specific role. These locator-sets can
locator-sets can be distributed on-demand based on using the shared be distributed on-demand based on using the shared DN as EID. It
DN as EID. It also allows the network admin and the Mapping System also allows the network admin and the Mapping System to selectively
to selectively choose what roles and functions can be registered and choose what roles and functions can be registered and distributed to
distributed to the rest of the participants in the network. the rest of the participants in the network.
9.2. DNs to Drive xTR On-Boarding Procedures 9.2. DNs to Drive xTR Onboarding Procedures
Following the LISP reliable transport Following the LISP reliable transport [LISP-MAP], ETRs that plan to
[I-D.ietf-lisp-map-server-reliable-transport], 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 traditional UDP registrations. The UDP registration
allows the Map-Server to perform basic authentication of the ETR and allows the Map-Server to perform basic authentication of the ETR and
create the necessary state to permit the reliable transport session to create the necessary state to permit the reliable transport
to be established (e.g., establish a passive open on TCP port 4342 session to be established (e.g., establish a passive open on TCP port
and add the ETR RLOC to the list allowed to establish a session). 4342 and add the ETR RLOC to the list allowed to establish a
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 on-boarding 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 Distinguished Names that
are registered as soon as xTRs come online with all the necessary are registered as soon as xTRs come online with all the necessary
Map-Servers in the Mapping System. The mapping with the dedicated DN Map-Servers in the Mapping System. The mapping with the dedicated DN
together with the RLOCs of each Egress Tunnel Router (ETR) in the together with the RLOCs of each Egress Tunnel Router (ETR) in the
locator-set is used to drive the initial UDP registration and also to locator-set is used to drive the initial UDP registration and also to
keep the reliable transport state stable through network condition keep the reliable transport state stable through network condition
changes. On the Map-Server, these DN registrations facilitate changes. On the Map-Server, these DN registrations facilitate
setting up the necessary state to onboard new ETRs rapidly and in a setting up the necessary state to onboard new ETRs rapidly and in a
more deterministic manner. more deterministic manner.
9.3. DNs for NAT-Traversal 9.3. DNs for NAT-Traversal
The open source lispers.net NAT-Traversal implementation The open source lispers.net NAT-Traversal implementation
[I-D.farinacci-lisp-lispers-net-nat] has had 10 years of deployment [LISP-NET-NAT] has had 10 years of deployment experience using
experience using Distinguished Names for documenting xTRs versus Re- Distinguished Names for documenting xTRs versus Re-encapsulating
encapsulating Tunnel Router (RTRs) as they appear in a locator-set. Tunnel Routers (RTRs) as they appear in a locator-set.
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- The open source lispers.net implementation has had 10 years of self-
documenting RLOC names in production and pilot environments. The documenting RLOC names in production and pilot environments. The
RLOC name is encoded with the RLOC address in Distinguished Name RLOC name is encoded with the RLOC address in Distinguished Name
format. 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 The open source lispers.net implementation has had 10 years of
deployment experience allowing xTRs to register EIDs as Distinguished deployment experience allowing xTRs to register EIDs as Distinguished
Names. The LISP Mapping System can be used as a DNS proxy for Name- Names. The LISP Mapping System can be used as a DNS proxy for Name-
to-EID-address or Name-to-RLOC-address mappings. The implementation to-EID-address or Name-to-RLOC-address mappings. The implementation
also supports Name-to-Public-Key mappings to provide key management also supports Name-to-Public-Key mappings to provide key management
features in [I-D.ietf-lisp-ecdsa-auth]. features in [LISP-ECDSA].
10. References 10. References
10.1. Normative References 10.1. Normative References
[IANA-ADDRESS-FAMILY-REGISTRY] [IANA-ADDRESS-FAMILY-REGISTRY]
IANA, "IANA Address Family Numbers Registry", IANA, "Address Family Numbers",
https://www.iana.org/assignments/address-family-numbers/, <https://www.iana.org/assignments/address-family-numbers>.
December 2024.
[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
2003, <https://www.rfc-editor.org/info/rfc3629>. 2003, <https://www.rfc-editor.org/info/rfc3629>.
skipping to change at page 9, line 13 skipping to change at line 349
<https://www.rfc-editor.org/info/rfc9301>. <https://www.rfc-editor.org/info/rfc9301>.
[RFC9437] Rodriguez-Natal, A., Ermagan, V., Cabellos, A., Barkai, [RFC9437] Rodriguez-Natal, A., Ermagan, V., Cabellos, A., Barkai,
S., and M. Boucadair, "Publish/Subscribe Functionality for S., and M. Boucadair, "Publish/Subscribe Functionality for
the Locator/ID Separation Protocol (LISP)", RFC 9437, the Locator/ID Separation Protocol (LISP)", RFC 9437,
DOI 10.17487/RFC9437, August 2023, DOI 10.17487/RFC9437, August 2023,
<https://www.rfc-editor.org/info/rfc9437>. <https://www.rfc-editor.org/info/rfc9437>.
10.2. Informative References 10.2. Informative References
[I-D.farinacci-lisp-lispers-net-nat] [LISP-ECDSA]
Farinacci, D., "lispers.net LISP NAT-Traversal
Implementation Report", Work in Progress, Internet-Draft,
draft-farinacci-lisp-lispers-net-nat-08, 17 June 2024,
<https://datatracker.ietf.org/doc/html/draft-farinacci-
lisp-lispers-net-nat-08>.
[I-D.ietf-lisp-ecdsa-auth]
Farinacci, D. and E. Nordmark, "LISP Control-Plane ECDSA Farinacci, D. and E. Nordmark, "LISP Control-Plane ECDSA
Authentication and Authorization", Work in Progress, Authentication and Authorization", Work in Progress,
Internet-Draft, draft-ietf-lisp-ecdsa-auth-13, 18 August Internet-Draft, draft-ietf-lisp-ecdsa-auth-13, 18 August
2024, <https://datatracker.ietf.org/doc/html/draft-ietf- 2024, <https://datatracker.ietf.org/doc/html/draft-ietf-
lisp-ecdsa-auth-13>. lisp-ecdsa-auth-13>.
[I-D.ietf-lisp-geo] [LISP-EXT] Jain, P., Moreno, V., and S. Hooda, "LISP Site External
Farinacci, D., "LISP Geo-Coordinate Use-Cases", Work in Connectivity", Work in Progress, Internet-Draft, draft-
Progress, Internet-Draft, draft-ietf-lisp-geo-08, 21 July ietf-lisp-site-external-connectivity-01, 24 September
2024, <https://datatracker.ietf.org/doc/html/draft-ietf- 2024, <https://datatracker.ietf.org/doc/html/draft-ietf-
lisp-geo-08>. lisp-site-external-connectivity-01>.
[I-D.ietf-lisp-map-server-reliable-transport] [LISP-GEO] Farinacci, D., "LISP Geo-Coordinate Use-Cases", Work in
Venkatachalapathy, B., Portoles-Comeras, M., Lewis, D., Progress, Internet-Draft, draft-ietf-lisp-geo-09, 15
January 2025, <https://datatracker.ietf.org/doc/html/
draft-ietf-lisp-geo-09>.
[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>.
[I-D.ietf-lisp-site-external-connectivity] [LISP-NET-NAT]
Jain, P., Moreno, V., and S. Hooda, "LISP Site External Farinacci, D., "lispers.net LISP NAT-Traversal
Connectivity", Work in Progress, Internet-Draft, draft- Implementation Report", Work in Progress, Internet-Draft,
ietf-lisp-site-external-connectivity-01, 24 September draft-farinacci-lisp-lispers-net-nat-09, 8 December 2024,
2024, <https://datatracker.ietf.org/doc/html/draft-ietf- <https://datatracker.ietf.org/doc/html/draft-farinacci-
lisp-site-external-connectivity-01>. lisp-lispers-net-nat-09>.
[I-D.ietf-lisp-vpn] [LISP-VPN] Moreno, V. and D. Farinacci, "LISP Virtual Private
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>.
[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>.
Appendix A. Acknowledgments Acknowledgments
The author would like to thank the LISP WG for their review and The authors would like to thank the LISP WG for their review and
acceptance of this draft. And a special thank you goes to Marc acceptance of this document. A special thank you goes to Marc
Portoles for moving this document through the process and providing Portoles for moving this document through the process and providing
deployment experience samples. deployment-experience samples.
Appendix B. Document Change Log
B.1. Changes to draft-ietf-lisp-name-encoding-17
* Submitted 9 December 2024.
* Refined wording for explicit length usage.
B.2. Changes to draft-ietf-lisp-name-encoding-16
* Submitted 6 December 2024.
* Fixed wording for explicit length usage.
B.3. Changes to draft-ietf-lisp-name-encoding-15
* Submitted 3 December 2024.
* Luigi Iannone joined as editor.
* Re-wording some text for clarification and address Paul Wouters
concerns.
* Updated security consideration section.
* Updated abstract.
* Moved some references to avoid downref.
B.4. Changes to draft-ietf-lisp-name-encoding-14
* Submitted August 2024.
* Use Paul Wouters suggestion to draw packet format for AFI=17
encoding in Section 3.
B.5. Changes to draft-ietf-lisp-name-encoding-13
* Submitted August 2024.
* Use Paul Wouters referene suggestion for RFC3629 to point ASCII
references in this document to UTF-8.
B.6. Changes to draft-ietf-lisp-name-encoding-12
* Submitted August 2024.
* Made changes based on comments from Mahesh Jethanandani and Paul
Wouters during IESG review.
B.7. Changes to draft-ietf-lisp-name-encoding-11
* Submitted August 2024.
* Fix typo found by Erik Kline.
B.8. Changes to draft-ietf-lisp-name-encoding-10
* Submitted August 2024.
* Change to "EID mask-len" per Roman Danyliw's comments.
B.9. Changes to draft-ietf-lisp-name-encoding-09
* Submitted July 2024.
* Added editorial suggestions from Acee Lindem.
B.10. Changes to draft-ietf-lisp-name-encoding-08
* Submitted June 2024.
* Made changes to reflect AD Jim Guichard's comments.
B.11. Changes to draft-ietf-lisp-name-encoding-07
* Submitted May 2024.
* Changed document status to "Proposed Standard" and some rewording
per Alberto for the pETR use-case section.
B.12. Changes to draft-ietf-lisp-name-encoding-06
* Submitted April 2024.
* Add Deployment Experience section for standards track
requirements.
* Update references.
B.13. Changes to draft-ietf-lisp-name-encoding-05
* Submitted December 2023.
* Update IANA AFI reference.
B.14. Changes to draft-ietf-lisp-name-encoding-04
* Submitted December 2023.
* More comments from Alberto. Change to standard spellings
throughout.
* Add RFC 2119 boilerplate.
* Update reference RFC1700 to RFC3232.
B.15. Changes to draft-ietf-lisp-name-encoding-03
* Submitted December 2023.
* Address comments from Alberto, document shepherd.
* Update references.
B.16. Changes to draft-ietf-lisp-name-encoding-02
* Submitted August 2023.
* Update references and document expiry timer.
B.17. Changes to draft-ietf-lisp-name-encoding-01
* Submitted February 2023.
* Update references and document expiry timer.
* Change 68**.bis references to proposed RFC references.
B.18. Changes to draft-ietf-lisp-name-encoding-00
* Submitted August 2022.
* Move individual submission to LISP WG document.
B.19. Changes to draft-farinacci-lisp-name-encoding-15
* Submitted July 2022.
* Added more clarity text about how using VPNs (instance-ID
encoding) addresses name collisions from multiple use-cases.
* Update references and document expiry timer.
B.20. Changes to draft-farinacci-lisp-name-encoding-14
* Submitted May 2022.
* Update references and document expiry timer.
B.21. Changes to draft-farinacci-lisp-name-encoding-13
* Submitted November 2021.
* Update references and document expiry timer.
B.22. Changes to draft-farinacci-lisp-name-encoding-12
* Submitted May 2021.
* Update references and document expiry timer.
B.23. Changes to draft-farinacci-lisp-name-encoding-11
* Submitted November 2020.
* Made changes to reflect working group comments.
* Update references and document expiry timer.
B.24. Changes to draft-farinacci-lisp-name-encoding-10
* Submitted August 2020.
* Update references and document expiry timer.
B.25. Changes to draft-farinacci-lisp-name-encoding-09
* Submitted March 2020.
* Update references and document expiry timer.
B.26. Changes to draft-farinacci-lisp-name-encoding-08
* Submitted September 2019.
* Update references and document expiry timer.
B.27. Changes to draft-farinacci-lisp-name-encoding-07
* Submitted March 2019.
* Update referenes and document expiry timer.
B.28. Changes to draft-farinacci-lisp-name-encoding-06
* Submitted September 2018.
* Update document expiry timer.
B.29. Changes to draft-farinacci-lisp-name-encoding-05
* Submitted March 2018.
* Update document expiry timer.
B.30. Changes to draft-farinacci-lisp-name-encoding-04
* Submitted September 2017.
* Update document expiry timer.
B.31. Changes to draft-farinacci-lisp-name-encoding-03
* Submitted March 2017.
* Update document expiry timer.
B.32. Changes to draft-farinacci-lisp-name-encoding-02
* Submitted October 2016.
* Add a comment that the distinguished-name encoding is restricted
to ASCII character encodings only.
B.33. Changes to draft-farinacci-lisp-name-encoding-01
* Submitted October 2016.
* Update document timer.
B.34. Changes to draft-farinacci-lisp-name-encoding-00
* Initial draft submitted April 2016.
Authors' Addresses Authors' Addresses
Dino Farinacci Dino Farinacci
lispers.net lispers.net
San Jose, CA San Jose, CA
United States of America United States of America
Email: farinacci@gmail.com Email: farinacci@gmail.com
Luigi Iannone (editor) Luigi Iannone (editor)
 End of changes. 51 change blocks. 
441 lines changed or deleted 167 lines changed or added

This html diff was produced by rfcdiff 1.48.