<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<rfc category="std" ipr="trust200902" docName="draft-ietf-lisp-name-encoding-14">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
  
<!--  Edited by Dino Farinacci farinacci@gmail.com -->

<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes" ?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>

<front>
  <title>LISP Distinguished Name Encoding</title>

  <author initials='D' surname="Farinacci" fullname='Dino Farinacci'>
    <organization>lispers.net</organization>
    <address>
      <postal>
      <street></street>
      <city>San Jose</city> <region>CA</region>
      <code></code>
      <country>USA</country>
      </postal>
      <email>farinacci@gmail.com</email>
    </address>
  </author>

  <date />
  <area>Routing Area</area>
  <workgroup>Internet Engineering Task Force</workgroup>
  <keyword>template</keyword>

  <abstract>
    <t>This draft defines how to use the AFI=17 Distinguished Names in LISP.</t>
  </abstract>

  <note title="Requirements Language">
    <t>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 <xref target="RFC2119"/> <xref
    target="RFC8174"/> when, and only when, they appear in all
    capitals, as shown here.</t>
  </note>
</front>

<middle>
  <section title="Introduction">
    <t>The LISP architecture and protocols <xref target="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).</t>

    <t>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.</t>

    <t>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.</t>
    <t><vspace blankLines='30' /></t>
  </section>

  <section title="Definition of Terms">
    <t><list style="hanging">
      <t hangText="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 <xref
      target="IANA-ADDRESS-FAMILY-REGISTRY" /> for details on other
      types of information that can be AFI encoded.</t>
    </list></t>
  </section>

  <section title="Distinguished Name Format">
    <figure>
      <preamble>An AFI=17 Distinguished Name is encoded as:</preamble>
      <artwork><![CDATA[
  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        |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       ]]></artwork>
      <postamble />
    </figure>
	    
    <t>The variable length string of characters are encoded in the
    US-ASCII character-set definition <xref target="RFC3629" />, where
    UTF-8 has the characteristic of preserving the full US-ASCII
    range.</t>

    <t>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 <xref target="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
    <xref target="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.</t>

    <t>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.</t>
    <t><vspace blankLines='30' /></t>
  </section>

   <section title="Mapping System Lookups for Distinguished Name EIDs">
     <t>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.</t>

     <t>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.</t>

     <t>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.</t>
  </section>

  <section title="Example Use-Cases" anchor="USECASE">
    <t>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 <xref
    target="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 <xref target="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 <xref
    target="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.</t>
  </section>

  <section title="Name Collision Considerations">
    <t>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 <xref
    target="RFC9301"/> for more details. Also, the use-case documents
    specified in <xref target="USECASE"/> of this specification provide allocation
    recommendations for their specific uses.</t>

    <t>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
    <xref target="I-D.ietf-lisp-vpn"/> for an example.</t>
  </section>

  <section title="Security Considerations">
    <t>There are no security considerations.</t>
  </section>

  <section title="IANA Considerations">
    <t>The code-point values in this specification are already
    allocated in <xref target="IANA-ADDRESS-FAMILY-REGISTRY" />.</t>
  </section>

  <section title="Sample LISP Distinguished Name (DN) Deployment Experience">
    <t>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.</t>

    <section title="DNs to Advertise Specific Device Roles or Functions">
      <t>In a practical implementation of <xref
      target="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.</t>
    
      <t>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
      <xref target="RFC9437"/>) to dynamically gather this Proxy-ETR
      list as specified in the LISP Site External Connectivity
      document.</t>

      <t>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.</t>
    </section>

    <section title="DNs to Drive xTR On-Boarding Procedures">
      <t>Following the LISP reliable transport <xref
      target="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).</t>
      
      <t>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.</t>
      
      <t>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.</t>
      
      <t>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.</t>
    </section>

    <section title="DNs for NAT-Traversal">
      <t>The open source lispers.net NAT-Traversal implementation
      <xref target="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.</t>
    </section>

    <section title="DNs for Self-Documenting RLOC Names">
      <t>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.</t>
    </section>

    <section title="DNs used as EID Names">
      <t>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 <xref
      target="I-D.ietf-lisp-ecdsa-auth" />.</t>
    </section>

  </section>
</middle>

<back>
  <references title='Normative References'>
    <?rfc include="reference.RFC.2119'?>
    <?rfc include="reference.RFC.8174'?>
    <?rfc include="reference.RFC.9300'?>
    <?rfc include="reference.RFC.9301'?>
    <?rfc include="reference.RFC.0020'?>
    <?rfc include="reference.RFC.9437'?>
    <?rfc include="reference.RFC.8060'?>
    <?rfc include="reference.RFC.3629'?>
  </references>

  <references title='Informative References'>
    <reference anchor="IANA-ADDRESS-FAMILY-REGISTRY">
      <front>
	    <title>IANA Address Family Numbers Registry</title>
        <author fullname="IANA"/>
	    <date year="2023" month="December" />
      </front>
      <refcontent>https://www.iana.org/assignments/address-family-numbers/</refcontent>
    </reference>

    <?rfc include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-lisp-ecdsa-auth.xml'?>
    <?rfc include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-lisp-geo.xml'?>
    <?rfc include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.farinacci-lisp-lispers-net-nat.xml'?>
    <?rfc include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-lisp-vpn.xml'?>
    <?rfc include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-lisp-site-external-connectivity.xml'?>
    <?rfc include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-lisp-map-server-reliable-transport.xml'?>
  </references>

  <section title="Acknowledgments">
    <t>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.</t>
  </section>

  <section title="Document Change Log">

    <section title="Changes to draft-ietf-lisp-name-encoding-14">
      <t><list style="symbols">
        <t>Submitted August 2024.</t>
       <t>Use Paul Wouters suggestion to draw packet format for AFI=17 encoding in Section 3.</t>
      </list></t>
    </section>

    <section title="Changes to draft-ietf-lisp-name-encoding-13">
      <t><list style="symbols">
        <t>Submitted August 2024.</t>
        <t>Use Paul Wouters referene suggestion for RFC3629 to point ASCII references in this
        document to UTF-8.</t>
      </list></t>
    </section>

    <section title="Changes to draft-ietf-lisp-name-encoding-12">
      <t><list style="symbols">
        <t>Submitted August 2024.</t>
        <t>Made changes based on comments from Mahesh Jethanandani and Paul Wouters during
        IESG review.</t>
      </list></t>
    </section>

    <section title="Changes to draft-ietf-lisp-name-encoding-11">
      <t><list style="symbols">
        <t>Submitted August 2024.</t>
        <t>Fix typo found by Erik Kline.</t>
      </list></t>
    </section>

    <section title="Changes to draft-ietf-lisp-name-encoding-10">
      <t><list style="symbols">
        <t>Submitted August 2024.</t>
        <t>Change to "EID mask-len" per Roman Danyliw's comments.</t>
      </list></t>
    </section>

    <section title="Changes to draft-ietf-lisp-name-encoding-09">
      <t><list style="symbols">
        <t>Submitted July 2024.</t>
        <t>Added editorial suggestions from Acee Lindem.</t>
      </list></t>
    </section>

    <section title="Changes to draft-ietf-lisp-name-encoding-08">
      <t><list style="symbols">
        <t>Submitted June 2024.</t>
        <t>Made changes to reflect AD Jim Guichard's comments.</t>
      </list></t>
    </section>

    <section title="Changes to draft-ietf-lisp-name-encoding-07">
      <t><list style="symbols">
        <t>Submitted May 2024.</t>
        <t>Changed document status to "Proposed Standard" and some rewording per Alberto
        for the pETR use-case section.</t>
      </list></t>
    </section>

    <section title="Changes to draft-ietf-lisp-name-encoding-06">
      <t><list style="symbols">
        <t>Submitted April 2024.</t>
        <t>Add Deployment Experience section for standards track requirements.</t>
	    <t>Update references.</t>
      </list></t>
    </section>

    <section title="Changes to draft-ietf-lisp-name-encoding-05">
      <t><list style="symbols">
        <t>Submitted December 2023.</t>
	    <t>Update IANA AFI reference.</t>
      </list></t>
    </section>

    <section title="Changes to draft-ietf-lisp-name-encoding-04">
      <t><list style="symbols">
        <t>Submitted December 2023.</t>
        <t>More comments from Alberto. Change to standard spellings throughout.</t>
        <t>Add RFC 2119 boilerplate.</t>
	    <t>Update reference RFC1700 to RFC3232.</t>
      </list></t>
    </section>

    <section title="Changes to draft-ietf-lisp-name-encoding-03">
      <t><list style="symbols">
        <t>Submitted December 2023.</t>
        <t>Address comments from Alberto, document shepherd.</t>
	    <t>Update references.</t>
      </list></t>
    </section>

    <section title="Changes to draft-ietf-lisp-name-encoding-02">
      <t><list style="symbols">
        <t>Submitted August 2023.</t>
	    <t>Update references and document expiry timer.</t>
      </list></t>
    </section>

    <section title="Changes to draft-ietf-lisp-name-encoding-01">
      <t><list style="symbols">
        <t>Submitted February 2023.</t>
	    <t>Update references and document expiry timer.</t>
	    <t>Change 68**.bis references to proposed RFC references.</t>
      </list></t>
    </section>

    <section title="Changes to draft-ietf-lisp-name-encoding-00">
      <t><list style="symbols">
        <t>Submitted August 2022.</t>
        <t>Move individual submission to LISP WG document.</t>
      </list></t>
    </section>

    <section title="Changes to draft-farinacci-lisp-name-encoding-15">
      <t><list style="symbols">
        <t>Submitted July 2022.</t>
        <t>Added more clarity text about how using VPNs (instance-ID encoding) addresses name
        collisions from multiple use-cases.</t>
	    <t>Update references and document expiry timer.</t>
      </list></t>
    </section>

    <section title="Changes to draft-farinacci-lisp-name-encoding-14">
      <t><list style="symbols">
        <t>Submitted May 2022.</t>
	    <t>Update references and document expiry timer.</t>
      </list></t>
    </section>

    <section title="Changes to draft-farinacci-lisp-name-encoding-13">
      <t><list style="symbols">
        <t>Submitted November 2021.</t>
	    <t>Update references and document expiry timer.</t>
      </list></t>
    </section>

    <section title="Changes to draft-farinacci-lisp-name-encoding-12">
      <t><list style="symbols">
        <t>Submitted May 2021.</t>
	    <t>Update references and document expiry timer.</t>
      </list></t>
    </section>

    <section title="Changes to draft-farinacci-lisp-name-encoding-11">
      <t><list style="symbols">
        <t>Submitted November 2020.</t>
        <t>Made changes to reflect working group comments.</t>
	    <t>Update references and document expiry timer.</t>
      </list></t>
    </section>

    <section title="Changes to draft-farinacci-lisp-name-encoding-10">
      <t><list style="symbols">
        <t>Submitted August 2020.</t>
	    <t>Update references and document expiry timer.</t>
      </list></t>
    </section>

    <section title="Changes to draft-farinacci-lisp-name-encoding-09">
      <t><list style="symbols">
        <t>Submitted March 2020.</t>
	    <t>Update references and document expiry timer.</t>
      </list></t>
    </section>

    <section title="Changes to draft-farinacci-lisp-name-encoding-08">
      <t><list style="symbols">
        <t>Submitted September 2019.</t>
	    <t>Update references and document expiry timer.</t>
      </list></t>
    </section>

    <section title="Changes to draft-farinacci-lisp-name-encoding-07">
      <t><list style="symbols">
        <t>Submitted March 2019.</t>
	    <t>Update referenes and document expiry timer.</t>
      </list></t>
    </section>

    <section title="Changes to draft-farinacci-lisp-name-encoding-06">
      <t><list style="symbols">
        <t>Submitted September 2018.</t>
	    <t>Update document expiry timer.</t>
      </list></t>
    </section>

    <section title="Changes to draft-farinacci-lisp-name-encoding-05">
      <t><list style="symbols">
        <t>Submitted March 2018.</t>
	    <t>Update document expiry timer.</t>
      </list></t>
    </section>

    <section title="Changes to draft-farinacci-lisp-name-encoding-04">
      <t><list style="symbols">
        <t>Submitted September 2017.</t>
	    <t>Update document expiry timer.</t>
      </list></t>
    </section>

    <section title="Changes to draft-farinacci-lisp-name-encoding-03">
      <t><list style="symbols">
        <t>Submitted March 2017.</t>
	<t>Update document expiry timer.</t>
      </list></t>
    </section>

    <section title="Changes to draft-farinacci-lisp-name-encoding-02">
      <t><list style="symbols">
        <t>Submitted October 2016.</t>
	<t>Add a comment that the distinguished-name encoding is 
	restricted to ASCII character encodings only.</t>
      </list></t>
    </section>

    <section title="Changes to draft-farinacci-lisp-name-encoding-01">
      <t><list style="symbols">
        <t>Submitted October 2016.</t>
	<t>Update document timer.</t>
      </list></t>
    </section>

    <section title="Changes to draft-farinacci-lisp-name-encoding-00">
      <t><list style="symbols">
        <t>Initial draft submitted April 2016.</t>
      </list></t>
    </section>

  </section>
</back>
</rfc>
