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 --> <!DOCTYPE rfc [
<!-- Edited by Luigi Iannone ggx@gigix.net --> <!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;">
<!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">
<?rfc toc="yes" ?> <!-- [rfced] Please note that the title of the document has been
<?rfc symrefs="yes" ?> updated as follows:
<?rfc sortrefs="yes" ?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<front> a) Abbreviations have been expanded per Section 3.6 of RFC 7322 ("RFC
<title>LISP Distinguished Name Encoding</title> Style Guide"). Please review.
<author initials='D' surname="Farinacci" fullname='Dino Farinacci'> Original:
<organization>lispers.net</organization> LISP Distinguished Name Encoding
<address>
<postal>
<street></street>
<city>San Jose</city> <region>CA</region>
<code></code>
<country>USA</country>
</postal>
<email>farinacci@gmail.com</email>
</address>
</author>
<author initials="L." surname="Iannone" fullname="Luigi Iannone" role="editor"
>
<organization abbrev="Huawei">Huawei Technologies France S.A.S.U.</organizat
ion>
<address>
<postal>
<street>18, Quai du Point du Jour</street>
<city>Boulogne-Billancourt</city>
<code>92100</code>
<country>France</country>
</postal>
<email>luigi.iannone@huawei.com</email>
</address>
</author>
<date /> Current:
<area>Routing Area</area> Locator/ID Separation Protocol (LISP) Distinguished Name Encoding
<workgroup>Internet Engineering Task Force</workgroup>
<keyword>template</keyword>
<abstract> b) Please note that we have added an abbreviated title that appears in
<t>This documents defines how to use the Address Family Identifier (AFI) 17 the running header of the pdf version. Please review and let us know
"Distinguished Names" in LISP. Distinguished Names can be used either in Endpoi if any updates are necessary.
nt Identifiers (EID) records or Routing Locators (RLOC) records in LISP control
messages to convey additional information.</t>
</abstract>
<note title="Requirements Language"> Original:
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL [nothing]
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> Current:
<section title="Introduction"> LISP Name Encoding
<t>The LISP architecture and protocols (<xref target="RFC9300"/>, <xref targ -->
et="RFC9301"/>) introduces two new numbering spaces, Endpoint Identifiers (EIDs)
and Routing Locators (RLOCs). To provide flexibility for current and future app
lications, these values can be encoded in
LISP control messages using a general syntax that includes Address
Family Identifier (AFI).</t>
<t>The length of addresses encoded in EID and RLOC records can be easily det <front>
ermined by the AFI field, as the size of the address is implicit in its AFI valu <title abbrev="LISP Name Encoding">Locator/ID Separation Protocol (LISP) Dis
e. For instance, for AFI = 1, which is IP version 4, the address length is known tinguished Name Encoding</title>
to be 4 octets. However, AFI 17 "Distinguished Name", is a variable length valu <seriesInfo name="RFC" value="9735"/>
e, so the length cannot be determined solely from the AFI value 17. This documen <author initials="D" surname="Farinacci" fullname="Dino Farinacci">
t defines a termination character, an 8-bit value of 0 to be used as a string te <organization>lispers.net</organization>
rminator so the length can be determined.</t> <address>
<postal>
<city>San Jose</city>
<region>CA</region>
<country>United States of America</country>
</postal>
<email>farinacci@gmail.com</email>
</address>
</author>
<author initials="L." surname="Iannone" fullname="Luigi Iannone" role="edito
r">
<organization abbrev="Huawei">Huawei Technologies France S.A.S.U.</organiz
ation>
<address>
<postal>
<street>18, Quai du Point du Jour</street>
<city>Boulogne-Billancourt</city>
<code>92100</code>
<country>France</country>
</postal>
<email>luigi.iannone@huawei.com</email>
</address>
</author>
<date month="February" year="2025"/>
<area>RTG</area>
<workgroup>lisp</workgroup>
<t>LISP Distinguished Names are useful when encoded either in <!-- [rfced] Please insert any keywords (beyond those that appear in
the title) for use on https://www.rfc-editor.org/search. -->
<keyword>example</keyword>
<abstract>
<t>This document defines how to use the "Distinguished Name" Address Famil
y Identifier (AFI) in the Locator/ID Separation Protocol (LISP). Distinguished N
ames (DNs) can be used in either Endpoint Identifier (EID) records or Routing Lo
cator (RLOC) records in LISP control messages to convey additional information.<
/t>
</abstract>
</front>
<middle>
<section numbered="true" toc="default">
<name>Introduction</name>
<!--[rfced] Neither RFC 9300 nor RFC 9301 have "architecture" in their
title. Are these document "nicknames" or concepts? Please
review this citation and sentence and let us know if any updates
are needed.
Original:
The LISP architecture and protocols ([RFC9300], [RFC9301]) introduces
two new numbering spaces,...
-->
<t>The LISP architecture and protocols (see <xref target="RFC9300" format=
"default"/> and <xref target="RFC9301" format="default"/>) introduce two new num
bering spaces: Endpoint Identifiers (EIDs) and Routing Locators (RLOCs). To prov
ide 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).</t>
<t>The length of addresses encoded in EID and RLOC records can easily be d
etermined by the AFI field, as the size of the address is implicit in its AFI va
lue. For instance, for AFI = 1, which is "IP (IP version 4)", the address length
is known to be 4 octets. However, AFI 17 "Distinguished Name", is a variable-le
ngth value, so the length cannot be determined solely from the AFI value 17 <xre
f target="IANA-ADDRESS-FAMILY-REGISTRY" format="default"/>. This document define
s a termination character, an 8-bit value of 0, to be used as a string terminato
r 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, 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 used as a self-documenting feature that services, or simply be used as a self-documenting feature that
accompany other address specific EIDs. As RLOCs, Distinguished accompanies other address-specific EIDs. As RLOCs, Distinguished
Names, along with RLOC specific 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 <!--[rfced] Is RFC 5280 to be read as one of a group of RFCs? Or is
similarly named field in the Public-Key Infrastructure using X.509 (PKIX) specif this the only RFC the reader is being pointed to?
ications <xref target="RFC5280"/>.</t>
</section>
<section title="Definition of Terms"> Original:
<t><list style="hanging"> The Distinguished Name field in this document has no relationship to
<t hangText="Address Family Identifier (AFI):">a term used to the similarly named field in the Public-Key Infrastructure using
describe an address encoding in a packet. An address family is X.509 (PKIX) specifications [RFC5280].
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"> Perhaps:
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., [RFC5280]).
-->
<figure> <t>The Distinguished Name field in this document has no relationship to th
<preamble>An AFI=17 Distinguished Name is encoded as:</preamble> e similarly named field in the Public-Key Infrastructure using X.509 (PKIX) spec
<artwork><![CDATA[ ifications <xref target="RFC5280" format="default"/>.</t>
</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="IANA-ADDRESS-FAMILY-REGISTRY" 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>
<t>
The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
"<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>
",
"<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
"<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
be
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 numbered="true" toc="default">
<name>Distinguished Name Format</name>
<t>An AFI=17 Distinguished Name is encoded as:</t>
<!--[rfced] Please review uses of NULL in this document.
Particularly:
a) Should these be updated to NUL? Please let us know any changes in
Old/New format or feel free to update the edited XML as desired.
b) We see the following similar uses. Should these be made uniform?
NULL Terminated vs.
NULL (0x00) terminated vs.
terminating NULL 0x00 octet vs.
NULL 0 octet vs.
NULL terminated vs.
NULL octet vs.
null octet
Further, we would expect NULL Terminated to be hyphenated in
attributive position (before a noun). Please see how (0x00) can fit
into that scheme.
-->
<artwork name="" type="" align="left" alt=""><![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 US-ASCII ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ String | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ String |
~ | ~ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
]]></artwork>
<postamble />
</figure>
<t>The variable length string of characters are encoded as a NULL (0x00) ter <t>The variable-length string of characters are encoded as a NULL (0x00) t
minated US-ASCII character-set as defined in <xref target="RFC3629" />, where UT erminated US-ASCII character set as defined in <xref target="RFC3629" format="de
F-8 has the characteristic of preserving the full US-ASCII fault"/>, where UTF-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 range. A NULL character <bcp14>MUST</bcp14> appear only once in the string
the end of the string.</t> and <bcp14>MUST</bcp14> be at the end of the string.</t>
<t>When Distinguished Names are encoded for EIDs, the EID Mask-Len <!--[rfced] We had a few questions about the following text:
Original:
When Distinguished Names are encoded for EIDs, the EID Mask-Len length
of the EIDs as they appear in EID-Records for all LISP control
messages [RFC9301] is the length of the string in bits (including the
terminating NULL 0x00 octet).
a) Might it be helpful to move this citation to RFC 9301 to a
previous/first use of LISP control messages (perhaps in the
Introduction)? Or is this citation covering another/more parts of the
sentence here?
b) Is it redundant to say "the EID Mask-Len length of the EIDs"?
-->
<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 length of the EIDs as they appear in EID-Records for all LISP
control messages <xref target="RFC9301"/> is the length of the control messages <xref target="RFC9301" format="default"/> is the length of the
string in bits (including the terminating NULL 0x00 octet).</t> string in bits (including the terminating NULL 0x00 octet).</t>
<t>Where Distinguished Names are encoded anywhere else (i.e., nested in LI
SP Canonical Address Format (LCAF) encodings <xref target="RFC8060" format="defa
ult"/>), an explicit length field can be used to indicate the length of the ASCI
I string in octets. The length field <bcp14>MUST</bcp14> include the NULL 0 oct
et. The string <bcp14>MUST</bcp14> still be NULL terminated. If a NULL 0 octet a
ppears before the end of the octet field, i.e., the NULL octet appears before th
e last position in the octet fields, then the string <bcp14>MAY</bcp14> be accep
ted and the octets after the NULL 0 octet <bcp14>MUST NOT</bcp14> be used as par
t 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 <bcp14>MUST</bcp14> be accepted. That is, an AFI
=17
encoded string <bcp14>MUST</bcp14> be at least 1 octet in length.</t>
</section>
<section numbered="true" toc="default">
<name>Mapping System Lookups for Distinguished Name EIDs</name>
<t>Where Distinguished Names are encoded anywhere else (i.e., nested in LCAF <!--[rfced] We are having trouble parsing this sentence. What MUST the
encodings <xref target="RFC8060"/>), then a explicit length field can be used t lookups carry?
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 Original:
string is a NULL string and MUST be accepted. That is, an AFI=17 Distinguished Name EID lookups MUST carry as an EID Mask-Len length
encoded string MUST be at least 1 octet in length.</t> equal to the length of the name string.
</section> -->
<section title="Mapping System Lookups for Distinguished Name EIDs"> <t>Distinguished Name EID lookups <bcp14>MUST</bcp14> carry as an EID Mask
<t>Distinguished Name EID lookups MUST carry as an EID Mask-Len length equa -Len length equal to the length of the name string. This instructs the mapping s
l to the length of the name string. This instructs the mapping system to do eith ystem to do either an exact-match or a longest-match lookup.</t>
er 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 spe
cific name is registered, then the Map-Server
returns the registered name with the registered EID Mask-Len length.</t>
<t>If the Distinguished Name EID is registered with the same length as the <!--[rfced] In the following, please clarify the parenthetical. What
length in a Map-Request, the Map-Server (when configured for proxy Map-Replying) is 5 octets? The null octet itself or the null octet plus
returns an exact match lookup with the same EID Mask-Len length. If a less spec "ietf"?
ific 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 4 Original:
0 bits (the length of string "ietf" plus the null octet is 5 octets), and a Map- For example, if the registered EID name is "ietf" with EID Mask-Len
Request is received for EID name "ietf.lisp" with an EID Mask-Len of 80 bits, th of 40 bits (the length of string "ietf" plus the null octet is 5
e Map-Server will return EID "ietf" with length of 40 bits.</t> octets), and a Map-Request is received for EID name "ietf.lisp" with
</section> an EID Mask-Len of 80 bits, the Map-Server will return EID "ietf"
with length of 40 bits.
<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 <t>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 null octet is 5 octe
ts), 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 bi
ts.</t>
</section>
<section anchor="USECASE" numbered="true" toc="default">
<name>Example Use Cases</name>
<t>This section identifies three specific use-case 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 and one for an RLOC-record encoding. When storing public keys in
the mapping system, as in <xref the mapping system, as in <xref target="I-D.ietf-lisp-ecdsa-auth" format="de
target="I-D.ietf-lisp-ecdsa-auth"/>, a well-known format for a fault"/>, a well-known format for a
public-key hash can be encoded as a Distinguished Name. When public-key hash can be encoded as a Distinguished Name. When
street location to GPS coordinate mappings exist in the mapping street-location-to-GPS-coordinate mappings exist in the mapping
system, as in <xref target="I-D.ietf-lisp-geo"/>, the street system, as in <xref target="I-D.ietf-lisp-geo" format="default"/>, the stree
location can be a free form UTF-8 ASCII representation (with whitespace t
location can be a free-form UTF-8 ASCII representation (with whitespace
characters) encoded as a Distinguished Name. An RLOC that characters) encoded as a Distinguished Name. 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 Distinguished Name 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 Distinguished Name 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 Dist
<t>It is RECOMMENDED that each use-case register their Distinguished inguished
Names with a unique Instance-ID. For any use-cases which require Names with a unique Instance-ID. Any use cases that require
different uses for Distinguish Names within an Instance-ID MUST different uses for Distinguished Names within an Instance-ID <bcp14>MUST</bc
define their own Instance-ID and structure syntax for the name p14>
define their own Instance-ID and syntax structure 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>Distinguished Names are used in mappings that are part of the LISP cont
rol plane and may be encoded using LCAF; thus, the security considerations of <x
ref target="RFC9301" format="default"/> and <xref target="RFC8060" format="defau
lt"/> 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 Distinguished Name (DN) Deployment Experience</name>
</section>
<section title="Sample LISP Distinguished Name (DN) Deployment Experience"> <!--[rfced] To what does "LISP Distinguished Name specification"
<t>Practical implementations of the LISP Distinguished Name refer? Is a citation necessary here?
Original:
Practical implementations of the LISP Distinguished Name
specification have been running in production networks for some time.
-->
<t>Practical implementations of the LISP Distinguished Name
specification have 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.).
b) We note some inconsistencies in the abbreviation for "Proxy Egress
Tunnel Routers":
[I-D.ietf-lisp-site-external-connectivity] seems to use pETR
This document uses Proxy-ETR
Past RFCs have used PETR.
Please review and let us know what, if any, updates are necessary.
-->
<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 Distinguished Name 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 <!--[rfced] What citation should be added to this sentence to point
the reader to the LISP Site External Connectivity document? Is
this draft-ietf-lisp-site-external-connectivity?
Original:
The Distinguished Name in this case serves as a common reference EID
that can be requested (or subscribed as per [RFC9437]) to dynamically
gather this Proxy-ETR list as specified in the LISP Site External
Connectivity document.
-->
<t>In this case, all Proxy-ETRs supporting this function register
a common Distinguished Name together with their own offered a common Distinguished Name 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 Distinguished Name 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.</t>
<t>The use of a Distinguished Name here provides
<t>The use of a Distinguished Name in this case 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 traditional 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 Distinguished
<t>In practice, LISP deployments use dedicated Distinguished
Names that are registered as 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"> <!--[rfced] We had a few questions about these similar sentences
<t>The open source lispers.net implementation has had 10 years of deployme appearing in Sections 9.3-9.5:
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> a) Perhaps we can update to avoid saying a website has had
</middle> experience in these sentences?
<back> b) Should the same citation appear in each of the sentences?
<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'> Original:
<?rfc include="reference.RFC.5280'?> The open source lispers.net NAT-Traversal implementation
<?rfc include="reference.RFC.8060'?> [I-D.farinacci-lisp-lispers-net-nat] has had 10 years of deployment
<?rfc include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf experience using Distinguished Names for documenting xTRs versus Re-
-lisp-ecdsa-auth.xml'?> encapsulating Tunnel Router (RTRs) as they appear in a locator-set.
<?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"> Perhaps:
<t>The author would like to thank the LISP WG for their review and At the time of writing, the open-source lispers.net NAT-Traversal
acceptance of this draft. And a special thank you goes to Marc implementation [I-D.farinacci-lisp-lispers-net-nat] has deployed
Portoles for moving this document through the process and providing deployme Distinguished Names for documenting xTRs versus Re-encapsulating
nt experience samples.</t> Tunnel Routers (RTRs) as they appear in a locator-set for 10 years.
</section>
<section title="Document Change Log"> Original:
The open source lispers.net implementation has had 10 years of self-
documenting RLOC names in production and pilot environments.
<section title="Changes to draft-ietf-lisp-name-encoding-17"> Perhaps:
<t><list style="symbols"> At the time of writing, the open-source lispers.net implementation
<t>Submitted 9 December 2024.</t> [I-D.farinacci-lisp-lispers-net-nat] has self-documented RLOC names in
<t>Refined wording for explicit length usage.</t> production and pilot environments.
</list></t>
</section>
<section title="Changes to draft-ietf-lisp-name-encoding-16"> Original:
<t><list style="symbols"> The open source lispers.net implementation has had 10 years of
<t>Submitted 6 December 2024.</t> deployment experience allowing xTRs to register EIDs as Distinguished
<t>Fixed wording for explicit length usage.</t> Names.
</list></t>
</section>
<section title="Changes to draft-ietf-lisp-name-encoding-15"> Perhaps:
<t><list style="symbols"> At the time of writing, the open-source lispers.net implementation
<t>Submitted 3 December 2024.</t> [I-D.farinacci-lisp-lispers-net-nat] has deployed xTRs that are
<t>Luigi Iannone joined as editor.</t> allowed to register EIDs as Distinguished Names for 10 years.
<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"> <name>DNs for NAT-Traversal</name>
<t><list style="symbols"> <t>The open source lispers.net NAT-Traversal implementation
<t>Submitted August 2024.</t> <xref target="I-D.farinacci-lisp-lispers-net-nat" format="default"/> has h
<t>Use Paul Wouters referene suggestion for RFC3629 to point ASCII refer ad 10
ences in this years of deployment experience using Distinguished Names for
document to UTF-8.</t> documenting xTRs versus Re-encapsulating Tunnel Routers (RTRs) as
</list></t> they appear in a locator-set.</t>
</section>
<section numbered="true" toc="default">
<name>DNs for Self-Documenting RLOC Names</name>
<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 numbered="true" toc="default">
<name>DNs used as EID Names</name>
<t>The open source lispers.net implementation has had 10 years of deploy
ment
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"
format="default"/>.</t>
</section>
</section> </section>
</middle>
<section title="Changes to draft-ietf-lisp-name-encoding-12"> <back>
<t><list style="symbols"> <displayreference target="I-D.ietf-lisp-ecdsa-auth" to="LISP-ECDSA"/>
<t>Submitted August 2024.</t> <displayreference target="I-D.ietf-lisp-geo" to="LISP-GEO"/>
<t>Made changes based on comments from Mahesh Jethanandani and Paul Wout <displayreference target="I-D.farinacci-lisp-lispers-net-nat" to="LISP-NET
ers during -NAT"/>
IESG review.</t> <displayreference target="I-D.ietf-lisp-vpn" to="LISP-VPN"/>
</list></t> <displayreference target="I-D.ietf-lisp-site-external-connectivity" to="LI
</section> SP-EXT"/>
<displayreference target="I-D.ietf-lisp-map-server-reliable-transport" to=
"LISP-MAP"/>
<section title="Changes to draft-ietf-lisp-name-encoding-11"> <references>
<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"> <name>References</name>
<t><list style="symbols"> <references>
<t>Submitted August 2024.</t> <name>Normative References</name>
<t>Change to "EID mask-len" per Roman Danyliw's comments.</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-ietf-lisp-name-encoding-09"> <reference anchor="IANA-ADDRESS-FAMILY-REGISTRY" target="https://www.ian
<t><list style="symbols"> a.org/assignments/address-family-numbers">
<t>Submitted July 2024.</t> <front>
<t>Added editorial suggestions from Acee Lindem.</t> <title>Address Family Numbers</title>
</list></t> <author>
</section> <organization>IANA</organization>
</author>
</front>
</reference>
<section title="Changes to draft-ietf-lisp-name-encoding-08"> </references>
<t><list style="symbols"> <references>
<t>Submitted June 2024.</t> <name>Informative References</name>
<t>Made changes to reflect AD Jim Guichard's comments.</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-ietf-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 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"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.
<t><list style="symbols"> ietf-lisp-vpn.xml"/>
<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"> <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 December 2023.</t>
<t>Update IANA AFI reference.</t>
</list></t>
</section>
<section title="Changes to draft-ietf-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 December 2023.</t> </references>
<t>More comments from Alberto. Change to standard spellings throughout.< </references>
/t> <section numbered="false" toc="default">
<t>Add RFC 2119 boilerplate.</t> <name>Acknowledgments</name>
<t>Update reference RFC1700 to RFC3232.</t> <t>The authors would like to thank the LISP WG for their review and
</list></t> 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-ietf-lisp-name-encoding-03"> <!-- [rfced] We had the following questions related to terminology use throughou
<t><list style="symbols"> t the document:
<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"> a) Please review the way that the AFI value is referred to throughout
<t><list style="symbols"> the text (e.g., using an equals sign, spacing around the equals sign,
<t>Submitted August 2023.</t> etc.). We see:
<t>Update references and document expiry timer.</t>
</list></t>
</section>
<section title="Changes to draft-ietf-lisp-name-encoding-01"> Address Family Identifier (AFI) 17 "Distinguished Names"
<t><list style="symbols"> AFI 17 "Distinguished Name"
<t>Submitted February 2023.</t> the AFI value 17
<t>Update references and document expiry timer.</t> An AFI=17 Distinguished Name
<t>Change 68**.bis references to proposed RFC references.</t> an AFI=17 encoded string
</list></t> AFI 17
</section>
<section title="Changes to draft-ietf-lisp-name-encoding-00"> See also: AFI = 1
<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"> How may we make these consistent throughout?
<t><list style="symbols">
<t>Submitted July 2022.</t>
<t>Added more clarity text about how using VPNs (instance-ID encoding) a
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"> b) We see variation in the way the term Distinguished Names is
<t><list style="symbols"> referred to (i.e., capitalization, pluralization, quotation, etc.).
<t>Submitted May 2022.</t> In addition to the examples in a) above, please also see:
<t>Update references and document expiry timer.</t>
</list></t>
</section>
<section title="Changes to draft-farinacci-lisp-name-encoding-13"> LISP Distinguished Names
<t><list style="symbols"> AFI 17 "Distinguished Name" and (AFI) 17 "Distinguished Names" (sg/pl)
<t>Submitted November 2021.</t> Distinguished Name (DN)
<t>Update references and document expiry timer.</t>
</list></t>
</section>
<section title="Changes to draft-farinacci-lisp-name-encoding-12"> Please consider if this is the name of the value or the concept in
<t><list style="symbols"> general during your review and send us updates in either Old/New form
<t>Submitted May 2021.</t> or update the edited XML file directly.
<t>Update references and document expiry timer.</t>
</list></t>
</section>
<section title="Changes to draft-farinacci-lisp-name-encoding-11"> c) We see that the abbreviation DN was used nearly at the end of the
<t><list style="symbols"> document. Might we reduce some of the inconsistencies by moving the
<t>Submitted November 2020.</t> abbreviation to first use (or the first use that is not to the direct
<t>Made changes to reflect working group comments.</t> name of the IANA-registered value) and then using DN thereafter?
<t>Update references and document expiry timer.</t>
</list></t>
</section>
<section title="Changes to draft-farinacci-lisp-name-encoding-10"> d) We see variations in the following forms. Should these be made
<t><list style="symbols"> consistent?
<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"> Mapping System vs. mapping system
<t><list style="symbols"> EID-Record vs. EID record
<t>Submitted March 2020.</t> RLOC-record vs. RLOC record
<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"> <!-- [rfced] FYI - We have added expansions for the following
<t><list style="symbols"> abbreviations per Section 3.6 of RFC 7322 ("RFC Style
<t>Submitted March 2019.</t> Guide"). Please review each expansion in the document carefully
<t>Update referenes and document expiry timer.</t> to ensure correctness.
</list></t>
</section>
<section title="Changes to draft-farinacci-lisp-name-encoding-06"> LISP - Locator/ID Separation Protocol
<t><list style="symbols"> LCAF - LISP Canonical Address Format
<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"> <!-- [rfced] Please review the "Inclusive Language" portion of the
<t><list style="symbols"> online Style Guide
<t>Submitted September 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-03"> For example, please consider whether the following should be updated:
<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"> whitespace
<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"> In addition, please consider whether "tradition" should be updated for
<t><list style="symbols"> clarity. While the NIST website
<t>Submitted October 2016.</t> <https://www.nist.gov/nist-research-library/nist-technical-series-publications-a
<t>Update document timer.</t> uthor-instructions#table1>
</list></t> indicates that this term is potentially biased, it is also ambiguous.
</section> "Tradition" is a subjective term, as it is not the same for everyone.
<section title="Changes to draft-farinacci-lisp-name-encoding-00"> Original:
<t><list style="symbols"> ...to start with traditional UDP registrations.
<t>Initial draft submitted April 2016.</t> -->
</list></t>
</section>
</section> </back>
</back>
</rfc> </rfc>
 End of changes. 93 change blocks. 
489 lines changed or deleted 536 lines changed or added

This html diff was produced by rfcdiff 1.48.