LISP Distinguished Name Encoding
Dino Farinacci
lispers.net
San Jose
CA
USA
farinacci@gmail.com
Routing Area
Internet Engineering Task Force
template
This draft defines how to use the AFI=17 Distinguished Names in LISP.

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.

Introduction
The LISP architecture and protocols [RFC9300] introduces two new numbering spaces, Endpoint Identifiers (EIDs) and Routing Locators (RLOCs) which are intended to replace most use of IP addresses on the Internet. To provide flexibility for current and future applications, these values can be encoded in LISP control messages using a general syntax that includes Address Family Identifier (AFI).
The length of the value field, which represents the address encoding, is implicit in the type of address that follows. For AFI 17, a Distinguished Name can be encoded. A name can be a variable length field so the length cannot be determined solely from the AFI value 17. This draft defines a termination 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-Records or RLOC-records in LISP control messages. As EIDs, they can be registered in the mapping system to find resources, services, or simply used as a self-documenting feature that accompany other address specific EIDs. As RLOCs, Distinguished Names, along with RLOC specific addresses and parameters, can be used as labels to identify equipment type, location, or any self-documenting string a registering device desires to convey.

Definition of Terms
Address Family Identifier (AFI): a term used to describe an address encoding in a packet. An address family is currently defined for IPv4 or IPv6 addresses. See [IANA-ADDRESS-FAMILY-REGISTRY] for details on other types of information that can be AFI encoded.

Distinguished Name Format
An AFI=17 Distinguished Name is encoded as:

  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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |            AFI = 17           |    ASCII                      ~
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+    String   +-+-+-+-+-+-+-+-+-+
 ~                                             |      0x0        |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The variable length string of characters are encoded in the US-ASCII character-set definition [RFC3629], where UTF-8 has the characteristic of preserving the full US-ASCII range.
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 messages [RFC9301] is the length of the string in bits (including the null 0 octet). Where Distinguished Names are encoded anywhere else (i.e., nested in LCAF encodings [RFC8060]), then any length field is the length of the ASCII string including the null 0 octet in units of octets. If the null 0 octet appears before the end of the octet field (the last octet of the octet field is not 0), then the shortened string is accepted and the octets between the null 0 octet and the last octet of the octet field are ignored. If no null 0 octet is found within the octet field, then the string terminates at the last octet of the octet field.
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 MUST be at least 1 octet in length.

Mapping System Lookups for Distinguished Name EIDs
Distinguished Name EID lookups MUST carry as an EID Mask-Len length equal to the length of the name string. This instructs the mapping system to do either an exact match or longest match lookup.
If the Distinguished Name EID is registered with the same length as the length in a Map-Request, the Map-Server (when configured for proxy Map-Replying) returns an exact match lookup with the same EID Mask-Len length. If a less specific name is registered, then the Map-Server returns the registered name with the registered EID Mask-Len length.
For example, if the registered EID name is "ietf" with EID Mask-Len of 40 bits (the length of string "ietf" plus the null octet is 5 octets), and a Map-Request is received for EID name "ietf.lisp" with an EID Mask-Len of 80 bits, the Map-Server will return EID "ietf" with length of 40 bits.

Example Use-Cases
This section identifies three specific use-cases examples for the Distinguished Name format. Two are used for an EID encoding and one 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 public-key hash can be encoded as a Distinguished Name. When street location to GPS coordinate mappings exist in the mapping system, as in [I-D.ietf-lisp-geo], the street location can be a free form UTF-8 ASCII representation (with whitespace characters) encoded as a Distinguished Name. An RLOC that describes an Ingress or Egress Tunnel Router (xTR) behind a NAT device can be identified by its router name, as in [I-D.farinacci-lisp-lispers-net-nat]. In this case, Distinguished Name encoding is used in NAT Info-Request messages after the EID-prefix field of the message.

Name Collision Considerations
When a Distinguished Name encoding is used to format an EID, the uniqueness and allocation concerns are no different than registering IPv4 or IPv6 EIDs to the mapping system. See [RFC9301] for more details. Also, the use-case documents specified in Section 5 of this specification provide allocation recommendations for their specific uses.
It is RECOMMENDED that each use-case register their Distinguished Names with a unique Instance-ID. For any use-cases which require different uses for Distinguish Names within an Instance-ID MUST define their own Instance-ID and structure syntax for the name registered to the Mapping System. See the encoding procedures in [I-D.ietf-lisp-vpn] for an example.

Security Considerations
There are no security considerations.

IANA Considerations
The code-point values in this specification are already allocated in [IANA-ADDRESS-FAMILY-REGISTRY].

Sample LISP Distinguished Name (DN) Deployment Experience
Practical implementations of the LISP Distinguished Name specification have been running in production networks for some time. The following sections provide some examples of its usage and lessons gathered out of this experience.

DNs to Advertise Specific Device Roles or Functions
In a practical implementation of [I-D.ietf-lisp-site-external-connectivity] on LISP deployments, routers running as Proxy Egress Tunnel Routers (Proxy-ETRs) register their role with the Mapping System in order to attract traffic destined for external networks. Practical implementations of this functionality make use of a Distinguished Name as an EID to identify the Proxy-ETR role in a Map-Registration.
In this case all Proxy-ETRs supporting this function register a common Distinguished Name together with their own offered locator. The Mapping-System aggregates the locators received from all Proxy-ETRs as a common locator-set that is associated with this DN EID. The Distinguished Name in this case serves as a common reference EID that can be requested (or subscribed as per [RFC9437]) to dynamically gather this Proxy-ETR list as specified in the LISP Site External Connectivity document.
The use of a Distinguished Name in this case provides descriptive information about the role being registered and allows the Mapping System to form locator-sets associated to specific role. These locator-sets can be distributed on-demand based on using the shared DN as EID. It also allows the network admin and the Mapping System to selectively choose what roles and functions can be registered and distributed to the rest of the participants in the network.

DNs to Drive xTR On-Boarding Procedures
Following the LISP reliable transport [I-D.ietf-lisp-map-server-reliable-transport], ETRs that plan to switch to using reliable transport to hold registrations first need to start with traditional UDP registrations. The UDP registration allows the Map-Server to perform basic authentication of the ETR and create the necessary state to permit the reliable transport session to be established (e.g., establish a passive open on TCP port 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 until local mappings are available and ready to be registered with the Mapping System. Furthermore, when the mapping system is distributed, the ETR requires having one specific mapping ready to be registered with each one of the relevant Map-Servers. This process may delay the onboarding of ETRs with the Mapping System so that they can switch to using reliable transport. This can also lead to generating unnecessary signaling as a reaction to certain triggers like local port flaps and device failures.
The use of dedicated name registrations allows driving this initial ETR on-boarding on the Mapping System as a deterministic process that does not depend on the availability of other mappings. It also provides more stability to the reliable transport session to survive through transient events.
In practice, LISP deployments use dedicated Distinguished Names that are registered as soon as xTRs come online with all the necessary Map-Servers in the Mapping System. The mapping with the dedicated DN 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 keep the reliable transport state stable through network condition changes. On the Map-Server, these DN registrations facilitate setting up the necessary state to onboard new ETRs rapidly and in a more deterministic manner.

DNs for NAT-Traversal
The open source lispers.net NAT-Traversal implementation [I-D.farinacci-lisp-lispers-net-nat] has had 10 years of deployment experience using Distinguished Names for documenting xTRs versus Re-encapsulating Tunnel Router (RTRs) as they appear in a locator-set.

DNs for Self-Documenting RLOC Names
The open source lispers.net implementation has had 10 years of self-documenting RLOC names in production and pilot environments. The RLOC name is encoded with the RLOC address in Distinguished Name format.

DNs used as EID Names
The open source lispers.net implementation has had 10 years of deployment experience allowing xTRs to register EIDs as Distinguished 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 also supports Name-to-Public-Key mappings to provide key management features in [I-D.ietf-lisp-ecdsa-auth].

Normative References

Informative References
[IANA-ADDRESS-FAMILY-REGISTRY]

IANA Address Family Numbers Registry
IANA
December 2023
https://www.iana.org/assignments/address-family-numbers/
[RFC2119]
[RFC8174]
[RFC9300]
[RFC3629]
[RFC9301]
[RFC8060]
[I-D.ietf-lisp-ecdsa-auth]
[I-D.ietf-lisp-geo]
[I-D.farinacci-lisp-lispers-net-nat]
[I-D.ietf-lisp-vpn]
[I-D.ietf-lisp-site-external-connectivity]
[RFC9437]
[I-D.ietf-lisp-map-server-reliable-transport]

Acknowledgments
The author would like to thank the LISP WG for their review and acceptance of this draft. And a special thank you goes to Marc Portoles for moving this document through the process and providing deployment experience samples.

Document Change Log

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.

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.

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.

Changes to draft-ietf-lisp-name-encoding-11
- Submitted August 2024.
- Fix typo found by Erik Kline.

Changes to draft-ietf-lisp-name-encoding-10
- Submitted August 2024.
- Change to "EID mask-len" per Roman Danyliw's comments.

Changes to draft-ietf-lisp-name-encoding-09
- Submitted July 2024.
- Added editorial suggestions from Acee Lindem.

Changes to draft-ietf-lisp-name-encoding-08
- Submitted June 2024.
- Made changes to reflect AD Jim Guichard's comments.

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.

Changes to draft-ietf-lisp-name-encoding-06
- Submitted April 2024.
- Add Deployment Experience section for standards track requirements.
- Update references.

Changes to draft-ietf-lisp-name-encoding-05
- Submitted December 2023.
- Update IANA AFI reference.

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.

Changes to draft-ietf-lisp-name-encoding-03
- Submitted December 2023.
- Address comments from Alberto, document shepherd.
- Update references.

Changes to draft-ietf-lisp-name-encoding-02
- Submitted August 2023.
- Update references and document expiry timer.

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.

Changes to draft-ietf-lisp-name-encoding-00
- Submitted August 2022.
- Move individual submission to LISP WG document.

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.

Changes to draft-farinacci-lisp-name-encoding-14
- Submitted May 2022.
- Update references and document expiry timer.

Changes to draft-farinacci-lisp-name-encoding-13
- Submitted November 2021.
- Update references and document expiry timer.

Changes to draft-farinacci-lisp-name-encoding-12
- Submitted May 2021.
- Update references and document expiry timer.

Changes to draft-farinacci-lisp-name-encoding-11
- Submitted November 2020.
- Made changes to reflect working group comments.
- Update references and document expiry timer.

Changes to draft-farinacci-lisp-name-encoding-10
- Submitted August 2020.
- Update references and document expiry timer.

Changes to draft-farinacci-lisp-name-encoding-09
- Submitted March 2020.
- Update references and document expiry timer.

Changes to draft-farinacci-lisp-name-encoding-08
- Submitted September 2019.
- Update references and document expiry timer.

Changes to draft-farinacci-lisp-name-encoding-07
- Submitted March 2019.
- Update referenes and document expiry timer.

Changes to draft-farinacci-lisp-name-encoding-06
- Submitted September 2018.
- Update document expiry timer.

Changes to draft-farinacci-lisp-name-encoding-05
- Submitted March 2018.
- Update document expiry timer.

Changes to draft-farinacci-lisp-name-encoding-04
- Submitted September 2017.
- Update document expiry timer.

Changes to draft-farinacci-lisp-name-encoding-03
- Submitted March 2017.
- Update document expiry timer.

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.

Changes to draft-farinacci-lisp-name-encoding-01
- Submitted October 2016.
- Update document timer.

Changes to draft-farinacci-lisp-name-encoding-00
- Initial draft submitted April 2016.