Internet-Draft LISP Distinguished Name Encoding December 2023
Farinacci Expires 30 June 2024 [Page]
Internet Engineering Task Force
Intended Status:
D. Farinacci

LISP Distinguished Name Encoding


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", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].

Status of This Memo

This Internet-Draft is submitted in full conformance with the 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

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on 30 June 2024.

Table of Contents

1. 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) [RFC3232].

The length of the value field 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.

2. Definition of Terms

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

3. 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 ...        |
 |               ...  ASCII String             |       0         |

The string of characters are encoded in the ASCII character-set definition [RFC0020].

When Distinguished Names are encoded for EIDs, the EID-Prefix length of the EIDs as they appear in EID-Records for all LISP control messages is the length of the string in bits (include the null 0 byte). Where Distinguished Names are encoded anywhere else (i.e. nested in LCAF encodings), then any length field is the length of the ASCII string including the null 0 byte in units of bytes.

4. Mapping System Lookups for Distinguished Name EIDs

Distinguished Name EID lookups MUST carry as an EID-Prefix 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-Prefix length. If a less specific name is registered, then the Map-Server returns the registered name with the registered EID-Prefix length.

For example, if the registered EID name is "ietf" with EID-prefix length of 40 bits (the length of string "ietf" plus the null byte is 5 bytes), and a Map-Request is received for EID name "ietf.lisp" with an EID-prefix length of 80 bits, the Map-Server will return EID "ietf" with length of 40 bits.

5. 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 a 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 ASCII representation (with whitespace characters) encoded as a Distinguished Name. An RLOC that describes an xTR behind a NAT device can be identified by its router name, as in [I-D.farinacci-lisp-lispers-net-nat], uses a Distinguished Name encoding. As well as identifying the router name (neither an EID or an RLOC) in NAT Info-Request messages uses Distinguished Name encodings.

6. 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 provide allocation recommendations for their specific uses.

It is RECOMMENDED that each use-case register their Distinguish 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.

7. Security Considerations

There are no security considerations.

8. IANA Considerations

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

9. References

9.1. Normative References

IANA, "IANA Address Family Numbers Registry",, .
Cerf, V., "ASCII format for network interchange", STD 80, RFC 20, DOI 10.17487/RFC0020, , <>.
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <>.
Reynolds, J., Ed., "Assigned Numbers: RFC 1700 is Replaced by an On-line Database", RFC 3232, DOI 10.17487/RFC3232, , <>.
Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A. Cabellos, Ed., "The Locator/ID Separation Protocol (LISP)", RFC 9300, DOI 10.17487/RFC9300, , <>.
Farinacci, D., Maino, F., Fuller, V., and A. Cabellos, Ed., "Locator/ID Separation Protocol (LISP) Control Plane", RFC 9301, DOI 10.17487/RFC9301, , <>.

9.2. Informative References

Farinacci, D., " LISP NAT-Traversal Implementation Report", Work in Progress, Internet-Draft, draft-farinacci-lisp-lispers-net-nat-07, , <>.
Farinacci, D. and E. Nordmark, "LISP Control-Plane ECDSA Authentication and Authorization", Work in Progress, Internet-Draft, draft-ietf-lisp-ecdsa-auth-11, , <>.
Farinacci, D., "LISP Geo-Coordinate Use-Cases", Work in Progress, Internet-Draft, draft-ietf-lisp-geo-03, , <>.
Moreno, V. and D. Farinacci, "LISP Virtual Private Networks (VPNs)", Work in Progress, Internet-Draft, draft-ietf-lisp-vpn-12, , <>.

Appendix A. 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.

Appendix B. Document Change Log

B.1. Changes to draft-ietf-lisp-name-encoding-05

B.2. Changes to draft-ietf-lisp-name-encoding-04

B.3. Changes to draft-ietf-lisp-name-encoding-03

B.4. Changes to draft-ietf-lisp-name-encoding-02

B.5. Changes to draft-ietf-lisp-name-encoding-01

B.6. Changes to draft-ietf-lisp-name-encoding-00

B.7. Changes to draft-farinacci-lisp-name-encoding-15

B.8. Changes to draft-farinacci-lisp-name-encoding-14

B.9. Changes to draft-farinacci-lisp-name-encoding-13

B.10. Changes to draft-farinacci-lisp-name-encoding-12

B.11. Changes to draft-farinacci-lisp-name-encoding-11

B.12. Changes to draft-farinacci-lisp-name-encoding-10

B.13. Changes to draft-farinacci-lisp-name-encoding-09

B.14. Changes to draft-farinacci-lisp-name-encoding-08

B.15. Changes to draft-farinacci-lisp-name-encoding-07

B.16. Changes to draft-farinacci-lisp-name-encoding-06

B.17. Changes to draft-farinacci-lisp-name-encoding-05

B.18. Changes to draft-farinacci-lisp-name-encoding-04

B.19. Changes to draft-farinacci-lisp-name-encoding-03

B.20. Changes to draft-farinacci-lisp-name-encoding-02

B.21. Changes to draft-farinacci-lisp-name-encoding-01

B.22. Changes to draft-farinacci-lisp-name-encoding-00

Author's Address

Dino Farinacci
San Jose, CA
United States of America