rfc9735xml2.original.xml   rfc9735.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<rfc category="std" ipr="trust200902" docName="draft-ietf-lisp-name-encoding-17"
>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- Edited by Dino Farinacci farinacci@gmail.com -->
<!-- Edited by Luigi Iannone ggx@gigix.net -->
<?rfc toc="yes" ?> <!DOCTYPE rfc [
<?rfc symrefs="yes" ?> <!ENTITY nbsp "&#160;">
<?rfc sortrefs="yes" ?> <!ENTITY zwsp "&#8203;">
<?rfc iprnotified="no" ?> <!ENTITY nbhy "&#8209;">
<?rfc strict="yes" ?> <!ENTITY wj "&#8288;">
]>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" ipr="trust200902"
docName="draft-ietf-lisp-name-encoding-17" number="9735" consensus="true" obsol
etes="" updates="" submissionType="IETF" xml:lang="en" tocInclude="true" symRefs
="true" sortRefs="true" version="3">
<front> <front>
<title>LISP Distinguished Name Encoding</title> <title abbrev="LISP Name Encoding">Locator/ID Separation Protocol (LISP) Dis
tinguished Name Encoding</title>
<author initials='D' surname="Farinacci" fullname='Dino Farinacci'> <seriesInfo name="RFC" value="9735"/>
<organization>lispers.net</organization> <author initials="D" surname="Farinacci" fullname="Dino Farinacci">
<address> <organization>lispers.net</organization>
<postal> <address>
<street></street> <postal>
<city>San Jose</city> <region>CA</region> <city>San Jose</city>
<code></code> <region>CA</region>
<country>USA</country> <country>United States of America</country>
</postal> </postal>
<email>farinacci@gmail.com</email> <email>farinacci@gmail.com</email>
</address> </address>
</author> </author>
<author initials="L." surname="Iannone" fullname="Luigi Iannone" role="editor" <author initials="L." surname="Iannone" fullname="Luigi Iannone" role="edito
> r">
<organization abbrev="Huawei">Huawei Technologies France S.A.S.U.</organizat <organization abbrev="Huawei">Huawei Technologies France S.A.S.U.</organiz
ion> ation>
<address> <address>
<postal> <postal>
<street>18, Quai du Point du Jour</street> <street>18, Quai du Point du Jour</street>
<city>Boulogne-Billancourt</city> <city>Boulogne-Billancourt</city>
<code>92100</code> <code>92100</code>
<country>France</country> <country>France</country>
</postal> </postal>
<email>luigi.iannone@huawei.com</email> <email>luigi.iannone@huawei.com</email>
</address> </address>
</author> </author>
<date month="February" year="2025"/>
<area>RTG</area>
<workgroup>lisp</workgroup>
<date /> <!-- [rfced] Please insert any keywords (beyond those that appear in
<area>Routing Area</area> the title) for use on https://www.rfc-editor.org/search. -->
<workgroup>Internet Engineering Task Force</workgroup>
<keyword>template</keyword>
<abstract> <keyword>example</keyword>
<t>This documents defines how to use the Address Family Identifier (AFI) 17
"Distinguished Names" in LISP. Distinguished Names can be used either in Endpoi
nt Identifiers (EID) records or Routing Locators (RLOC) records in LISP control
messages to convey additional information.</t>
</abstract>
<note title="Requirements Language"> <abstract>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL <t>This document defines how to use the Address Family Identifier (AFI) 17
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "Distinguished Name" in the Locator/ID Separation Protocol (LISP). LISP introd
"MAY", and "OPTIONAL" in this document are to be interpreted as uces two new numbering spaces: Endpoint Identifiers (EIDs) and Routing Locators
described in BCP 14 <xref target="RFC2119"/> <xref (RLOCs). Distinguished Names (DNs) can be used in either EID-Records or RLOC-Rec
target="RFC8174"/> when, and only when, they appear in all ords in LISP control messages to convey additional information.</t>
capitals, as shown here.</t> </abstract>
</note> </front>
</front> <middle>
<section numbered="true" toc="default">
<name>Introduction</name>
<middle> <t>LISP (<xref target="RFC9300" format="default"/> and <xref target="RFC93
<section title="Introduction"> 01" format="default"/>) introduces two new numbering spaces: Endpoint Identifier
<t>The LISP architecture and protocols (<xref target="RFC9300"/>, <xref targ s (EIDs) and Routing Locators (RLOCs). To provide flexibility for current and fu
et="RFC9301"/>) introduces two new numbering spaces, Endpoint Identifiers (EIDs) ture applications, these values can be encoded in
and Routing Locators (RLOCs). To provide flexibility for current and future app LISP control messages using a general syntax that includes the Address
lications, these values can be encoded in
LISP control messages using a general syntax that includes Address
Family Identifier (AFI).</t> Family Identifier (AFI).</t>
<t>The length of addresses encoded in EID-Records and RLOC-Records can eas
<t>The length of addresses encoded in EID and RLOC records can be easily det ily be determined by the AFI field, as the size of the address is implicit in it
ermined by the AFI field, as the size of the address is implicit in its AFI valu s AFI value. For instance, for AFI equal to 1, which is "IP (IP version 4)", the
e. For instance, for AFI = 1, which is IP version 4, the address length is known address length is known to be 4 octets. However, AFI 17 "Distinguished Name", i
to be 4 octets. However, AFI 17 "Distinguished Name", is a variable length valu s a variable-length value, so the length cannot be determined solely from the AF
e, so the length cannot be determined solely from the AFI value 17. This documen I value 17 <xref target="ADDRESS-FAMILY" format="default"/>. This document defin
t defines a termination character, an 8-bit value of 0 to be used as a string te es a termination character, an 8-bit value of 0, to be used as a string terminat
rminator so the length can be determined.</t> or so the length can be determined.</t>
<t>LISP DNs are useful when encoded either in
<t>LISP Distinguished Names are useful when encoded either in EID-Records or RLOC-Records in LISP control messages. As EIDs,
EID-Records or RLOC-records in LISP control messages. As EIDs, they can be registered in the Mapping System to find resources,
they can be registered in the mapping system to find resources, services, or simply be used as a self-documenting feature that
services, or simply used as a self-documenting feature that accompanies other address-specific EIDs. As RLOCs, DNs, along with RLOC-spec
accompany other address specific EIDs. As RLOCs, Distinguished ific addresses and parameters, can be
Names, along with RLOC specific addresses and parameters, can be
used as labels to identify equipment type, location, or any used as labels to identify equipment type, location, or any
self-documenting string a registering device desires to self-documenting string a registering device desires to
convey.</t> convey.</t>
<t>The Distinguished Name field in this document has no relationship to the <t>The Distinguished Name field in this document has no relationship to th
similarly named field in the Public-Key Infrastructure using X.509 (PKIX) specif e similarly named field in the Public-Key Infrastructure using X.509 (PKIX) spec
ications <xref target="RFC5280"/>.</t> ifications (e.g., <xref target="RFC5280" format="default"/>).</t>
</section> </section>
<section numbered="true" toc="default">
<name>Terminology</name>
<section numbered="true" toc="default">
<name>Definition</name>
<dl newline="false" spacing="normal">
<dt>Address Family Identifier (AFI):</dt>
<dd>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="ADDRESS-FAMILY" format="default"/> for
details on other types of information that can be AFI encoded.</dd>
</dl>
</section>
<section numbered="true" toc="default">
<name>Requirements Language</name>
<section title="Definition of Terms"> <t>
<t><list style="hanging"> The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
<t hangText="Address Family Identifier (AFI):">a term used to "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>
describe an address encoding in a packet. An address family is ",
currently defined for IPv4 or IPv6 addresses. See <xref "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
target="IANA-ADDRESS-FAMILY-REGISTRY" /> for details on other "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
types of information that can be AFI encoded.</t> "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
</list></t> be
</section> interpreted as described in BCP&nbsp;14 <xref target="RFC2119"/> <xref
target="RFC8174"/> when, and only when, they appear in all capitals, as
shown here.
</t>
</section>
</section>
<section title="Distinguished Name Format"> <section numbered="true" toc="default">
<name>Distinguished Name Format</name>
<t>An AFI 17 "Distinguished Name" is encoded as:</t>
<figure> <artwork name="" type="" align="left" alt=""><![CDATA[
<preamble>An AFI=17 Distinguished Name is encoded as:</preamble>
<artwork><![CDATA[
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 (0x00) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ String | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ US-ASCII String |
~ | ~ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
]]></artwork>
<postamble />
</figure>
<t>The variable length string of characters are encoded as a NULL (0x00) ter
minated US-ASCII character-set as defined in <xref target="RFC3629" />, where UT
F-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
the end of the string.</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 terminating NULL 0x00 octet).</t>
<t>Where Distinguished Names are encoded anywhere else (i.e., nested in LCAF
encodings <xref target="RFC8060"/>), then a explicit length field can be used t
o indicate the length of the ASCII string in octets, the length field MUST inclu
de the NULL 0 octet. The string MUST still be NULL terminated. If a NULL 0 octet
appears before the end of the octet field, i.e., the NULL octet appears before
the the last position in the octet fields, then the string MAY be accepted and t
he octets after the NULL 0 octet MUST NOT be used as part of the octet string.</
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>
</section>
<section title="Mapping System Lookups for Distinguished Name EIDs"> <t>The variable-length string of characters are encoded as a NULL-terminat
<t>Distinguished Name EID lookups MUST carry as an EID Mask-Len length equa ed (0x00) US-ASCII character set as defined in <xref target="RFC3629" format="de
l to the length of the name string. This instructs the mapping system to do eith fault"/>, where UTF-8 has the characteristic of preserving the full US-ASCII
er an exact match or longest match lookup.</t> range. A NULL character <bcp14>MUST</bcp14> appear only once in the string
and <bcp14>MUST</bcp14> be at the end of the string.</t>
<t>If the Distinguished Name EID is registered with the same length as the <t>When DNs are encoded for EIDs, the EID Mask-Len
length in a Map-Request, the Map-Server (when configured for proxy Map-Replying) length of the EID-Records, for all LISP
returns an exact match lookup with the same EID Mask-Len length. If a less spec control messages <xref target="RFC9301" format="default"/>, is the length of
ific name is registered, then the Map-Server the
returns the registered name with the registered EID Mask-Len length.</t> string in bits (including the NULL-terminated 0x00 octet).</t>
<t>Where DNs are encoded anywhere else (i.e., nested in LISP Canonical Add
ress Format (LCAF) encodings <xref target="RFC8060" format="default"/>), an expl
icit length field can be used to indicate the length of the ASCII string in octe
ts. The length field <bcp14>MUST</bcp14> include the NULL octet (0x00). The str
ing <bcp14>MUST</bcp14> 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 b
efore the last position in the octet fields, then the string <bcp14>MAY</bcp14>
be accepted and the octets after the NULL octet (0x00) <bcp14>MUST NOT</bcp14> b
e used as part of the octet string.</t>
<t>If the octet after the AFI field is the NULL octet (0x00), the
string is a NULL string and <bcp14>MUST</bcp14> be accepted. That is, an AFI
17 "Distinguished Name"
encoded string <bcp14>MUST</bcp14> be at least 1 octet in length.</t>
</section>
<section numbered="true" toc="default">
<name>Mapping-System Lookups for DN EIDs</name>
<t>For example, if the registered EID name is "ietf" with EID Mask-Len of 4 <t>When performing DN-EID lookups, Map-Request messages <bcp14>MUST</bcp14
0 bits (the length of string "ietf" plus the null octet is 5 octets), and a Map- > carry an EID Mask-Len length equal to the length of the name string in bits. T
Request is received for EID name "ietf.lisp" with an EID Mask-Len of 80 bits, th his instructs the Mapping System to do either an exact-match or a longest-match
e Map-Server will return EID "ietf" with length of 40 bits.</t> lookup.</t>
</section> <t>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 exa
ct-match lookup with the same EID Mask-Len length. If a less specific name is re
gistered, then the Map-Server
returns the registered name with the registered EID Mask-Len length.</t>
<section title="Example Use-Cases" anchor="USECASE"> <t>For example, if the registered EID name is "ietf" with an EID Mask-Len
<t>This section identifies three specific use-cases examples for length of 40 bits (the length of the string "ietf" plus the length of the NULL o
the Distinguished Name format. Two are used for an EID encoding ctet (0x00) makes 5 octets), and a Map-Request is received for EID name "ietf.li
and one for an RLOC-record encoding. When storing public keys in sp" with an EID Mask-Len length of 80 bits, the Map-Server will return EID "ietf
the mapping system, as in <xref " with a length of 40 bits.</t>
target="I-D.ietf-lisp-ecdsa-auth"/>, a well-known format for a </section>
public-key hash can be encoded as a Distinguished Name. When <section anchor="USECASE" numbered="true" toc="default">
street location to GPS coordinate mappings exist in the mapping <name>Example Use Cases</name>
system, as in <xref target="I-D.ietf-lisp-geo"/>, the street <t>This section identifies three specific use-case examples for
location can be a free form UTF-8 ASCII representation (with whitespace the DN format: two are used for an EID encoding
characters) encoded as a Distinguished Name. An RLOC that 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" format="de
fault"/>, 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 <xref target="I-D.ietf-lisp-geo" format="default"/>, the stree
t
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 describes an Ingress or Egress Tunnel Router (xTR) behind a NAT
device can be identified by its router name, as in <xref device can be identified by its router name, as in <xref target="I-D.farinac
target="I-D.farinacci-lisp-lispers-net-nat"/>. In this case, ci-lisp-lispers-net-nat" format="default"/>. In this case,
Distinguished Name encoding is used in NAT Info-Request messages DN encoding is used in NAT Info-Request messages
after the EID-prefix field of the message.</t> after the EID-prefix field of the message.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Name Collision Considerations"> <name>Name-Collision Considerations</name>
<t>When a Distinguished Name encoding is used to format an EID, <t>When a DN encoding is used to format an EID,
the uniqueness and allocation concerns are no different than the uniqueness and allocation concerns are no different than
registering IPv4 or IPv6 EIDs to the mapping system. See <xref registering IPv4 or IPv6 EIDs to the Mapping System. See <xref target="RFC93
target="RFC9301"/> for more details. Also, the use-case documents 01" format="default"/> for more details. Also, the use cases documented in <xref
specified in <xref target="USECASE"/> of this specification provide allocati target="USECASE" format="default"/> of this specification provide allocation re
on recommendations for their specific uses.</t> commendations for their specific uses.</t>
<t>It is <bcp14>RECOMMENDED</bcp14> that each use case register their DNs
<t>It is RECOMMENDED that each use-case register their Distinguished with a unique Instance-ID. Any use cases that require
Names with a unique Instance-ID. For any use-cases which require different uses for DNs within an Instance-ID <bcp14>MUST</bcp14>
different uses for Distinguish Names within an Instance-ID MUST define their own Instance-ID and syntax structure for the name
define their own Instance-ID and structure syntax for the name
registered to the Mapping System. See the encoding procedures in registered to the Mapping System. See the encoding procedures in
<xref target="I-D.ietf-lisp-vpn"/> for an example.</t> <xref target="I-D.ietf-lisp-vpn" format="default"/> for an example.</t>
</section> </section>
<section numbered="true" toc="default">
<name>Security Considerations</name>
<t>DNs are used in mappings that are part of the LISP control plane and ma
y be encoded using LCAF; thus, the security considerations of <xref target="RFC9
301" format="default"/> and <xref target="RFC8060" format="default"/> apply.</t>
</section>
<section numbered="true" toc="default">
<name>IANA Considerations</name>
<section title="Security Considerations"> <t>This document has no IANA actions.</t>
<t>Distinguished Names are used in mappings that are part of the LISP contro
l plane and may be encoded using LCAF, as such security considerations of <xref
target="RFC9301"/> and <xref target="RFC8060"/> apply.</t>
</section>
<section title="IANA Considerations"> </section>
<t>The code-point value in this specification, namely AFI 17, is already <section numbered="true" toc="default">
allocated in <xref target="IANA-ADDRESS-FAMILY-REGISTRY" />.</t> <name>Sample LISP DN Deployment Experience</name>
</section>
<section title="Sample LISP Distinguished Name (DN) Deployment Experience"> <t>Practical implementations of the LISP DN, defined in this document, hav
<t>Practical implementations of the LISP Distinguished Name e been running in production networks for some
specification have been running in production networks for some
time. The following sections provide some examples of its usage time. The following sections provide some examples of its usage
and lessons gathered out of this experience.</t> and lessons learned out of this experience.</t>
<section numbered="true" toc="default">
<name>DNs to Advertise Specific Device Roles or Functions</name>
<section title="DNs to Advertise Specific Device Roles or Functions"> <!--[rfced] We had a few questions regarding this text:
<t>In a practical implementation of <xref
target="I-D.ietf-lisp-site-external-connectivity" /> on LISP Original:
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.
a) Is there an update we can make to describe which part/concept of
the cited document is being practically implemented (e.g., the
registration procedures, requirements, etc.).
-->
<t>In a practical implementation of <xref target="I-D.ietf-lisp-site-ext
ernal-connectivity" format="default"/> on LISP
deployments, routers running as Proxy Egress Tunnel Routers deployments, routers running as Proxy Egress Tunnel Routers
(Proxy-ETRs) register their role with the Mapping System in (Proxy-ETRs) register their role with the Mapping System in
order to attract traffic destined for external order to attract traffic destined for external
networks. Practical implementations of this functionality make networks. Practical implementations of this functionality make
use of a Distinguished Name as an EID to identify the Proxy-ETR use of a DN as an EID to identify the Proxy-ETR
role in a Map-Registration.</t> role in a Map-Registration.</t>
<t>In this case all Proxy-ETRs supporting this function register <t>In this case, all Proxy-ETRs supporting this function register
a common Distinguished Name together with their own offered a common DN together with their own offered
locator. The Mapping-System aggregates the locators received locator. The Mapping System aggregates the locators received
from all Proxy-ETRs as a common locator-set that is associated 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 with this DN EID. In this scenario, the DN serves as a
common reference EID that can be requested (or subscribed as per common reference EID that can be requested (or subscribed as per
<xref target="RFC9437"/>) to dynamically gather this Proxy-ETR <xref target="RFC9437" format="default"/>) to dynamically gather this Prox y-ETR
list as specified in the LISP Site External Connectivity list as specified in the LISP Site External Connectivity
document.</t> document <xref target="I-D.ietf-lisp-site-external-connectivity" format="d
efault"/>.</t>
<t>The use of a Distinguished Name in this case provides <t>The use of a DN here provides
descriptive information about the role being registered and descriptive information about the role being registered and
allows the Mapping System to form locator-sets associated to allows the Mapping System to form locator-sets associated with a
specific role. These locator-sets can be distributed on-demand specific role. These locator-sets can be distributed on-demand
based on using the shared DN as EID. It also allows the network based on using the shared DN as EID. It also allows the network
admin and the Mapping System to selectively choose what roles admin and the Mapping System to selectively choose what roles
and functions can be registered and distributed to the rest of and functions can be registered and distributed to the rest of
the participants in the network.</t> the participants in the network.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="DNs to Drive xTR On-Boarding Procedures"> <name>DNs to Drive xTR Onboarding Procedures</name>
<t>Following the LISP reliable transport <xref <t>Following the LISP reliable transport <xref target="I-D.ietf-lisp-map
target="I-D.ietf-lisp-map-server-reliable-transport" />, ETRs -server-reliable-transport" format="default"/>, ETRs
that plan to switch to using reliable transport to hold that plan to switch to using reliable transport to hold
registrations first need to start with traditional UDP registrations first need to start with UDP
registrations. The UDP registration allows the Map-Server to registrations. The UDP registration allows the Map-Server to
perform basic authentication of the ETR and create the necessary perform basic authentication of the ETR and to create the necessary
state to permit the reliable transport session to be established state to permit the reliable transport session to be established
(e.g., establish a passive open on TCP port 4342 and add the ETR (e.g., establish a passive open on TCP port 4342 and add the ETR
RLOC to the list allowed to establish a session).</t> RLOC to the list allowed to establish a session).</t>
<t>In the basic implementation of this process, the ETRs need to
<t>In the basic implementation of this process, the ETRs need to
wait until local mappings are available and ready to be wait until local mappings are available and ready to be
registered with the Mapping System. Furthermore, when the mapping registered with the Mapping System. Furthermore, when the Mapping
system is distributed, the ETR requires having one specific System is distributed, the ETR requires having one specific
mapping ready to be registered with each one of the relevant mapping ready to be registered with each one of the relevant
Map-Servers. This process may delay the onboarding of ETRs with Map-Servers. This process may delay the onboarding of ETRs with
the Mapping System so that they can switch to using reliable the Mapping System so that they can switch to using reliable
transport. This can also lead to generating unnecessary transport. This can also lead to generating unnecessary
signaling as a reaction to certain triggers like local port signaling as a reaction to certain triggers like local port
flaps and device failures.</t> flaps and device failures.</t>
<t>The use of dedicated name registrations allows driving this
<t>The use of dedicated name registrations allows driving this initial ETR onboarding on the Mapping System as a deterministic
initial ETR on-boarding on the Mapping System as a deterministic
process that does not depend on the availability of other process that does not depend on the availability of other
mappings. It also provides more stability to the reliable mappings. It also provides more stability to the reliable
transport session to survive through transient events.</t> transport session to survive through transient events.</t>
<t>In practice, LISP deployments use dedicated DNs that are registered a
<t>In practice, LISP deployments use dedicated Distinguished s soon as xTRs come online with all
Names that are registered as soon as xTRs come online with all
the necessary Map-Servers in the Mapping System. The mapping the necessary Map-Servers in the Mapping System. The mapping
with the dedicated DN together with the RLOCs of each Egress with the dedicated DN together with the RLOCs of each Egress
Tunnel Router (ETR) in the locator-set is used to drive the Tunnel Router (ETR) in the locator-set is used to drive the
initial UDP registration and also to keep the reliable transport initial UDP registration and also to keep the reliable transport
state stable through network condition changes. On the state stable through network condition changes. On the
Map-Server, these DN registrations facilitate setting up the Map-Server, these DN registrations facilitate setting up the
necessary state to onboard new ETRs rapidly and in a more necessary state to onboard new ETRs rapidly and in a more
deterministic manner.</t> deterministic manner.</t>
</section> </section>
<section numbered="true" toc="default">
<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 deployme
nt
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.9437'?>
<?rfc include="reference.RFC.3629'?>
<reference anchor="IANA-ADDRESS-FAMILY-REGISTRY">
<front>
<title>IANA Address Family Numbers Registry</title>
<author fullname="IANA"/>
<date year="2024" month="December" />
</front>
<refcontent>https://www.iana.org/assignments/address-family-numbers/</refc
ontent>
</reference>
</references>
<references title='Informative References'>
<?rfc include="reference.RFC.5280'?>
<?rfc include="reference.RFC.8060'?>
<?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.fari
nacci-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 deployme
nt experience samples.</t>
</section>
<section title="Document Change Log">
<section title="Changes to draft-ietf-lisp-name-encoding-17">
<t><list style="symbols">
<t>Submitted 9 December 2024.</t>
<t>Refined wording for explicit length usage.</t>
</list></t>
</section>
<section title="Changes to draft-ietf-lisp-name-encoding-16">
<t><list style="symbols">
<t>Submitted 6 December 2024.</t>
<t>Fixed wording for explicit length usage.</t>
</list></t>
</section>
<section title="Changes to draft-ietf-lisp-name-encoding-15">
<t><list style="symbols">
<t>Submitted 3 December 2024.</t>
<t>Luigi Iannone joined as editor.</t>
<t>Re-wording some text for clarification and address Paul Wouters concer
ns.</t>
<t> Updated security consideration section.</t>
<t> Updated abstract.</t>
<t> Moved some references to avoid downref.</t>
</list></t>
</section>
<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 refer
ences 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 Wout
ers 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"> <!--[rfced] We had a few questions about these similar sentences
<t><list style="symbols"> appearing in Sections 9.3-9.5:
<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"> a) Perhaps we can update to avoid saying a website has had
<t><list style="symbols"> experience in these sentences?
<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"> b) Should the same citation appear in each of the sentences?
<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"> Original:
<t><list style="symbols"> The open source lispers.net NAT-Traversal implementation
<t>Submitted December 2023.</t> [I-D.farinacci-lisp-lispers-net-nat] has had 10 years of deployment
<t>More comments from Alberto. Change to standard spellings throughout.< experience using Distinguished Names for documenting xTRs versus Re-
/t> encapsulating Tunnel Router (RTRs) as they appear in a locator-set.
<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"> Perhaps:
<t><list style="symbols"> At the time of writing, the open-source lispers.net NAT-Traversal
<t>Submitted December 2023.</t> implementation [I-D.farinacci-lisp-lispers-net-nat] has deployed
<t>Address comments from Alberto, document shepherd.</t> Distinguished Names for documenting xTRs versus Re-encapsulating
<t>Update references.</t> Tunnel Routers (RTRs) as they appear in a locator-set for 10 years.
</list></t>
</section>
<section title="Changes to draft-ietf-lisp-name-encoding-02"> Original:
<t><list style="symbols"> The open source lispers.net implementation has had 10 years of self-
<t>Submitted August 2023.</t> documenting RLOC names in production and pilot environments.
<t>Update references and document expiry timer.</t>
</list></t>
</section>
<section title="Changes to draft-ietf-lisp-name-encoding-01"> Perhaps:
<t><list style="symbols"> At the time of writing, the open-source lispers.net implementation
<t>Submitted February 2023.</t> [I-D.farinacci-lisp-lispers-net-nat] has self-documented RLOC names in
<t>Update references and document expiry timer.</t> production and pilot environments.
<t>Change 68**.bis references to proposed RFC references.</t>
</list></t>
</section>
<section title="Changes to draft-ietf-lisp-name-encoding-00"> Original:
<t><list style="symbols"> The open source lispers.net implementation has had 10 years of
<t>Submitted August 2022.</t> deployment experience allowing xTRs to register EIDs as Distinguished
<t>Move individual submission to LISP WG document.</t> Names.
</list></t>
</section>
<section title="Changes to draft-farinacci-lisp-name-encoding-15"> Perhaps:
<t><list style="symbols"> At the time of writing, the open-source lispers.net implementation
<t>Submitted July 2022.</t> [I-D.farinacci-lisp-lispers-net-nat] has deployed xTRs that are
<t>Added more clarity text about how using VPNs (instance-ID encoding) a allowed to register EIDs as Distinguished Names for 10 years.
ddresses 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"> <name>DNs for NAT-Traversal</name>
<t><list style="symbols"> <t>At the time of writing, the open-source lispers.net NAT-Traversal imp
<t>Submitted November 2021.</t> lementation
<t>Update references and document expiry timer.</t> <xref target="I-D.farinacci-lisp-lispers-net-nat" format="default"/> has d
</list></t> eployed DNs for
documenting xTRs versus Re-encapsulating Tunnel Routers (RTRs) as
they appear in a locator-set for 10 years.</t>
</section>
<section numbered="true" toc="default">
<name>DNs for Self-Documenting RLOC Names</name>
<t>At the time of writing, the open-source lispers.net implementation <x
ref target="I-D.farinacci-lisp-lispers-net-nat" format="default"/> has self-docu
mented RLOC names in production and pilot
environments for 10 years. The RLOC name is encoded with the RLOC address
in
DN format.</t>
</section>
<section numbered="true" toc="default">
<name>DNs Used as EID Names</name>
<t>At the time of writing, the open-source lispers.net implementation <x
ref target="I-D.farinacci-lisp-lispers-net-nat" format="default"/> has deployed
xTRs that are allowed to register EIDs as DNs for 10 years. The LISP Mapping Sys
tem 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"
format="default"/>.</t>
</section>
</section> </section>
</middle>
<section title="Changes to draft-farinacci-lisp-name-encoding-12"> <back>
<t><list style="symbols"> <displayreference target="I-D.ietf-lisp-ecdsa-auth" to="LISP-ECDSA"/>
<t>Submitted May 2021.</t> <displayreference target="I-D.ietf-lisp-geo" to="LISP-GEO"/>
<t>Update references and document expiry timer.</t> <displayreference target="I-D.farinacci-lisp-lispers-net-nat" to="LISPERS-
</list></t> NET-NAT"/>
</section> <displayreference target="I-D.ietf-lisp-vpn" to="LISP-VPN"/>
<displayreference target="I-D.ietf-lisp-site-external-connectivity" to="LI
SP-EXT"/>
<displayreference target="I-D.ietf-lisp-map-server-reliable-transport" to=
"LISP-MAP"/>
<section title="Changes to draft-farinacci-lisp-name-encoding-11"> <references>
<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"> <name>References</name>
<t><list style="symbols"> <references>
<t>Submitted August 2020.</t> <name>Normative References</name>
<t>Update references and document expiry timer.</t> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
</list></t> 119.xml"/>
</section> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
174.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
300.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
301.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
437.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
629.xml"/>
<section title="Changes to draft-farinacci-lisp-name-encoding-09"> <reference anchor="ADDRESS-FAMILY" target="https://www.iana.org/assignme
<t><list style="symbols"> nts/address-family-numbers">
<t>Submitted March 2020.</t> <front>
<t>Update references and document expiry timer.</t> <title>Address Family Numbers</title>
</list></t> <author>
</section> <organization>IANA</organization>
</author>
</front>
</reference>
<section title="Changes to draft-farinacci-lisp-name-encoding-08"> </references>
<t><list style="symbols"> <references>
<t>Submitted September 2019.</t> <name>Informative References</name>
<t>Update references and document expiry timer.</t> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
</list></t> 280.xml"/>
</section> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
060.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.
ietf-lisp-ecdsa-auth.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.
ietf-lisp-geo.xml"/>
<section title="Changes to draft-farinacci-lisp-name-encoding-07"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.
<t><list style="symbols"> farinacci-lisp-lispers-net-nat.xml"/>
<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"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.
<t><list style="symbols"> ietf-lisp-vpn.xml"/>
<t>Submitted September 2018.</t>
<t>Update document expiry timer.</t>
</list></t>
</section>
<section title="Changes to draft-farinacci-lisp-name-encoding-05"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.
<t><list style="symbols"> ietf-lisp-site-external-connectivity.xml"/>
<t>Submitted March 2018.</t>
<t>Update document expiry timer.</t>
</list></t>
</section>
<section title="Changes to draft-farinacci-lisp-name-encoding-04"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.
<t><list style="symbols"> ietf-lisp-map-server-reliable-transport.xml"/>
<t>Submitted September 2017.</t> </references>
<t>Update document expiry timer.</t> </references>
</list></t> <section numbered="false" toc="default">
<name>Acknowledgments</name>
<t>The authors would like to thank the LISP WG for their review and
acceptance of this document. A special thank you goes to <contact
fullname="Marc Portoles"/> for moving this document through the process
and providing deployment-experience samples.</t>
</section> </section>
<section title="Changes to draft-farinacci-lisp-name-encoding-03"> <!-- [rfced] Please review the "Inclusive Language" portion of the
<t><list style="symbols"> online Style Guide
<t>Submitted March 2017.</t> <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
<t>Update document expiry timer.</t> and let us know if any changes are needed. Updates of this
</list></t> nature typically result in more precise language, which is
</section> helpful for readers.
<section title="Changes to draft-farinacci-lisp-name-encoding-02"> For example, please consider whether the following should be updated:
<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"> whitespace
<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>
</back>
</rfc> </rfc>
 End of changes. 68 change blocks. 
530 lines changed or deleted 377 lines changed or added

This html diff was produced by rfcdiff 1.48.