lispers.net

San Jose CA United States of America farinacci@gmail.com

Huawei Technologies France S.A.S.U.

18, Quai du Point du Jour Boulogne-Billancourt 92100 France luigi.iannone@huawei.com

RTG lisp example This document defines how to use the Address Family Identifier (AFI) 17 "Distinguished Name" in the Locator/ID Separation Protocol (LISP). LISP introduces two new numbering spaces: Endpoint Identifiers (EIDs) and Routing Locators (RLOCs). Distinguished Names (DNs) can be used in either EID-Records or RLOC-Records in LISP control messages to convey additional information.

Status of This Memo This is an Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at .

Copyright Notice Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents () in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.

Table of Contents

• .  Introduction
• .  Terminology
  • .  Definition
  • .  Requirements Language
• .  Distinguished Name Format
• .  Mapping-System Lookups for DN EIDs
• .  Example Use Cases
• .  Name-Collision Considerations
• .  Security Considerations
• .  IANA Considerations
• .  Sample LISP DN Deployment Experience
  • .  DNs to Advertise Specific Device Roles or Functions
  • .  DNs to Drive xTR Onboarding Procedures
  • .  DNs for NAT-Traversal
  • .  DNs for Self-Documenting RLOC Names
  • .  DNs Used as EID Names
• . References
  • .  Normative References
  • .  Informative References
• Acknowledgments
• Authors' Addresses

Introduction LISP ( and ) introduces two new numbering spaces: Endpoint Identifiers (EIDs) and Routing Locators (RLOCs). To provide flexibility for current and future applications, these values can be encoded in LISP control messages using a general syntax that includes the Address Family Identifier (AFI). The length of addresses encoded in EID-Records and RLOC-Records can easily be determined by the AFI field, as the size of the address is implicit in its AFI value. For instance, for AFI equal to 1, which is "IP (IP version 4)", the address length is known to be 4 octets. However, AFI 17 "Distinguished Name", is a variable-length value, so the length cannot be determined solely from the AFI value 17 . This document defines a termination character, an 8-bit value of 0, to be used as a string terminator so the length can be determined. LISP DNs 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 be used as a self-documenting feature that accompanies other address-specific EIDs. As RLOCs, DNs, 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. The Distinguished Name field in this document has no relationship to the similarly named field in the Public-Key Infrastructure using X.509 (PKIX) specifications (e.g., ).

Terminology

Definition

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 for details on other types of information that can be AFI encoded.

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 when, and only when, they appear in all capitals, as shown here.

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 | NULL-Terminated (0x00) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ US-ASCII String | ~ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The variable-length string of characters are encoded as a NULL-terminated (0x00) US-ASCII character set as defined in , where UTF-8 has the characteristic of preserving the full US-ASCII range. A NULL character MUST appear only once in the string and MUST be at the end of the string. When DNs are encoded for EIDs, the EID Mask-Len length of the EID-Records, for all LISP control messages , is the length of the string in bits (including the NULL-terminated 0x00 octet). Where DNs are encoded anywhere else (i.e., nested in LISP Canonical Address Format (LCAF) encodings ), an explicit length field can be used to indicate the length of the ASCII string in octets. The length field MUST include the NULL octet (0x00). The string MUST still be NULL-terminated (0x00). If a NULL octet (0x00) appears before the end of the octet field, i.e., the NULL octet (0x00) appears before the last position in the octet fields, then the string MAY be accepted and the octets after the NULL octet (0x00) MUST NOT be used as part of the octet string. If the octet after the AFI field is the NULL octet (0x00), the string is a NULL string and MUST be accepted. That is, an AFI 17 "Distinguished Name" encoded string MUST be at least 1 octet in length.

Mapping-System Lookups for DN EIDs When performing DN-EID lookups, Map-Request messages MUST carry an EID Mask-Len length equal to the length of the name string in bits. This instructs the Mapping System to do either an exact-match or a longest-match lookup. If the DN 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 an EID Mask-Len length of 40 bits (the length of the string "ietf" plus the length of the NULL octet (0x00) makes 5 octets), and a Map-Request is received for EID name "ietf.lisp" with an EID Mask-Len length of 80 bits, the Map-Server will return EID "ietf" with a length of 40 bits.

Example Use Cases This section identifies three specific use-case examples for the DN 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 , a well-known format for a public-key hash can be encoded as a DN. When street-location-to-GPS-coordinate mappings exist in the Mapping System, as in , the street location can be a free-form UTF-8 ASCII representation (with whitespace characters) encoded as a DN. An RLOC that describes an Ingress or Egress Tunnel Router (xTR) behind a NAT device can be identified by its router name, as in . In this case, DN encoding is used in NAT Info-Request messages after the EID-prefix field of the message.

Name-Collision Considerations When a DN 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 for more details. Also, the use cases documented in of this specification provide allocation recommendations for their specific uses. It is RECOMMENDED that each use case register their DNs with a unique Instance-ID. Any use cases that require different uses for DNs within an Instance-ID MUST define their own Instance-ID and syntax structure for the name registered to the Mapping System. See the encoding procedures in for an example.

Security Considerations DNs are used in mappings that are part of the LISP control plane and may be encoded using LCAF; thus, the security considerations of and apply.

IANA Considerations This document has no IANA actions.

Sample LISP DN Deployment Experience Practical implementations of the LISP DN, defined in this document, have been running in production networks for some time. The following sections provide some examples of its usage and lessons learned out of this experience.

DNs to Advertise Specific Device Roles or Functions In a practical implementation of 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 DN 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 DN 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. In this scenario, the DN serves as a common reference EID that can be requested (or subscribed as per ) to dynamically gather this Proxy-ETR list as specified in the LISP Site External Connectivity document . The use of a DN here provides descriptive information about the role being registered and allows the Mapping System to form locator-sets associated with a 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 Onboarding Procedures Following the LISP reliable transport , ETRs that plan to switch to using reliable transport to hold registrations first need to start with UDP registrations. The UDP registration allows the Map-Server to perform basic authentication of the ETR and to 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 onboarding 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 DNs 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 At the time of writing, the open-source lispers.net NAT-Traversal implementation has deployed DNs for documenting xTRs versus Re-encapsulating Tunnel Routers (RTRs) as they appear in a locator-set for 10 years.

DNs for Self-Documenting RLOC Names At the time of writing, the open-source lispers.net implementation has self-documented RLOC names in production and pilot environments for 10 years. The RLOC name is encoded with the RLOC address in DN format.

DNs Used as EID Names At the time of writing, the open-source lispers.net implementation has deployed xTRs that are allowed to register EIDs as DNs for 10 years. 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 .

References Normative References IANA In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. ISO/IEC 10646-1 defines a large character set called the Universal Character Set (UCS) which encompasses most of the world's writing systems. The originally proposed encodings of the UCS, however, were not compatible with many current applications and protocols, and this has led to the development of UTF-8, the object of this memo. UTF-8 has the characteristic of preserving the full US-ASCII range, providing compatibility with file systems, parsers and other software that rely on US-ASCII values but are transparent to other values. This memo obsoletes and replaces RFC 2279. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This document describes the data plane protocol for the Locator/ID Separation Protocol (LISP). LISP defines two namespaces: Endpoint Identifiers (EIDs), which identify end hosts; and Routing Locators (RLOCs), which identify network attachment points. With this, LISP effectively separates control from data and allows routers to create overlay networks. LISP-capable routers exchange encapsulated packets according to EID-to-RLOC mappings stored in a local Map-Cache. LISP requires no change to either host protocol stacks or underlay routers and offers Traffic Engineering (TE), multihoming, and mobility, among other features. This document obsoletes RFC 6830. This document describes the control plane and Mapping Service for the Locator/ID Separation Protocol (LISP), implemented by two types of LISP-speaking devices -- the LISP Map-Resolver and LISP Map-Server -- that provide a simplified "front end" for one or more Endpoint IDs (EIDs) to Routing Locator mapping databases. By using this control plane service interface and communicating with Map-Resolvers and Map-Servers, LISP Ingress Tunnel Routers (ITRs) and Egress Tunnel Routers (ETRs) are not dependent on the details of mapping database systems; this behavior facilitates modularity with different database designs. Since these devices implement the "edge" of the LISP control plane infrastructure, connecting EID addressable nodes of a LISP site, the implementation and operational complexity of the overall cost and effort of deploying LISP is reduced. This document obsoletes RFCs 6830 and 6833. This document specifies an extension to the Locator/ID Separation Protocol (LISP) control plane to enable Publish/Subscribe (PubSub) operation. Informative References lispers.net Zededa This draft describes how LISP control-plane messages can be individually authenticated and authorized without a a priori shared- key configuration. Public-key cryptography is used with no new PKI infrastructure required. Work in Progress Cisco Systems Google Cisco Systems This draft defines how to register/retrieve pETR mapping information in LISP when the destination is not registered/known to the local site and its mapping system (e.g. the destination is an internet or external site destination). Work in Progress lispers.net This document describes how Geo-Coordinates can be used in the LISP Architecture and Protocols. The functionality proposes a new LISP Canonical Address Format (LCAF) encoding for such Geo-Coordinates, which is compatible with the Global Positioning Satellite (GPS) encodings used by other routing protocols. This document updates [RFC8060]. Work in Progress Cisco Systems Cisco Systems ICANN Arista Networks Inc. Rivian Automotive The communication between LISP ETRs and Map-Servers is based on unreliable UDP message exchange coupled with periodic message transmission in order to maintain soft state. The drawback of periodic messaging is the constant load imposed on both the ETR and the Map-Server. New use cases for LISP have increased the amount of state that needs to be communicated with requirements that are not satisfied by the current mechanism. This document introduces the use of a reliable transport for ETR to Map-Server communication in order to eliminate the periodic messaging overhead, while providing reliability, flow-control and endpoint liveness detection. Work in Progress Google LLC lispers.net This document describes the use of the Locator/ID Separation Protocol (LISP) to create Virtual Private Networks (VPNs). LISP is used to provide segmentation in both the LISP data plane and control plane. These VPNs can be created over the top of the Internet or over private transport networks, and can be implemented by Enterprises or Service Providers. The goal of these VPNs is to leverage the characteristics of LISP - routing scalability, simply expressed Ingress site TE Policy, IP Address Family traversal, and mobility, in ways that provide value to network operators. Work in Progress lispers.net This memo documents the lispers.net implementation of LISP NAT traversal functionality. The document describes message formats and protocol semantics necessary to interoperate with the implementation. This memo is not a standard and does not reflect IETF consensus. Work in Progress This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [STANDARDS-TRACK] This document defines a canonical address format encoding used in Locator/ID Separation Protocol (LISP) control messages and in the encoding of lookup keys for the LISP Mapping Database System.

Acknowledgments The authors would like to thank the LISP WG for their review and acceptance of this document. A special thank you goes to for moving this document through the process and providing deployment-experience samples.

Authors' Addresses lispers.net

San Jose CA United States of America farinacci@gmail.com

Huawei Technologies France S.A.S.U.

18, Quai du Point du Jour Boulogne-Billancourt 92100 France luigi.iannone@huawei.com