rfc9236xml2.original.xml   rfc9236.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [ <!DOCTYPE rfc [
<!ENTITY rfc1498 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/referenc <!ENTITY nbsp "&#160;">
e.RFC.1498.xml"> <!ENTITY zwsp "&#8203;">
<!ENTITY rfc2119 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference. <!ENTITY nbhy "&#8209;">
RFC.2119.xml"> <!ENTITY wj "&#8288;">
<!ENTITY rfc2460 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.
RFC.2460.xml">
<!ENTITY rfc4919 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.
RFC.4919.xml">
<!ENTITY rfc4944 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.
RFC.4944.xml">
<!ENTITY rfc5826 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.
RFC.5826.xml">
<!ENTITY rfc6282 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.
RFC.6282.xml">
<!ENTITY rfc6568 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.
RFC.6568.xml">
<!ENTITY rfc6775 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/referenc
e.RFC.6775.xml">
<!ENTITY rfc6830 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/referenc
e.RFC.6830.xml">
<!ENTITY rfc6833 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/referenc
e.RFC.6833.xml">
<!ENTITY rfc7252 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/referenc
e.RFC.7252.xml">
<!ENTITY rfc7228 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.
RFC.7228.xml">
<!ENTITY rfc7428 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.
RFC.7428.xml">
<!ENTITY rfc7668 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.
RFC.7668.xml">
<!ENTITY rfc7927 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.
RFC.7927.xml">
]> ]>
<rfc category="info" docName="draft-irtf-icnrg-nrsarch-considerations-07" ipr="t rust200902">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" docName="draft-irtf-icnrg-nrsarc
<!-- used by XSLT processors --> h-considerations-07" number="9236" ipr="trust200902" obsoletes="" updates="" sub
<!-- For a complete list and description of processing instructions (PIs), missionType="IRTF" category="info" consensus="true" xml:lang="en" tocInclude="tr
please see http://xml.resource.org/authoring/README.html. --> ue" tocDepth="4" symRefs="true" sortRefs="true" version="3">
<!-- Below are generally applicable Processing Instructions (PIs) that most I-
Ds might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="no" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="no" ?>
<!-- do not start each<ul><li></li></ul><ul><li></li></ul> main section on a n
ew page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<!-- ***** FRONT MATTER ***** -->
<front> <front>
<!-- The abbreviated title is used in the page header - it is only necessa
ry if the
full title is longer than 39 characters -->
<title abbrev="Arch Considerations of ICN using NRS">Architectural Considera <title abbrev="Arch Considerations of ICN Using NRS">Architectural Considera
tions of ICN using Name Resolution Service</title> tions of Information-Centric Networking (ICN) Using a Name Resolution Service</t
itle>
<seriesInfo name="RFC" value="9236"/>
<!-- add 'role="editor"' below for the editors if appropriate -->
<!-- Another author who claims to be an editor -->
<author fullname="Jungha Hong" initials="J." surname="Hong"> <author fullname="Jungha Hong" initials="J." surname="Hong">
<organization>ETRI</organization> <organization>ETRI</organization>
<address>
<postal>
<street>218 Gajeong-ro</street>
<extaddr>Yuseung-Gu</extaddr>
<address>
<postal>
<street>218 Gajeong-ro, Yuseung-Gu</street>
<!-- Reorder these if your country does things differently -->
<city>Daejeon</city> <city>Daejeon</city>
<region></region> <region/>
<code>34129</code> <code>34129</code>
<country>Korea</country> <country>Republic of Korea</country>
</postal> </postal>
<phone></phone> <phone/>
<email>jhong@etri.re.kr</email> <email>jhong@etri.re.kr</email>
<!-- uri and facsimile elements may also be added -->
</address> </address>
</author> </author>
<author fullname="Tae-Wan You" initials="T." surname="You"> <author fullname="Tae-Wan You" initials="T." surname="You">
<organization>ETRI</organization> <organization>ETRI</organization>
<address>
<postal>
<street>218 Gajeong-ro</street>
<extaddr>Yuseung-Gu</extaddr>
<address>
<postal>
<street>218 Gajeong-ro, Yuseung-Gu</street>
<!-- Reorder these if your country does things differently -->
<city>Daejeon</city> <city>Daejeon</city>
<region></region> <region/>
<code>34129</code> <code>34129</code>
<country>Korea</country> <country>Republic of Korea</country>
</postal> </postal>
<phone></phone> <phone/>
<email>twyou@etri.re.kr</email> <email>twyou@etri.re.kr</email>
<!-- uri and facsimile elements may also be added -->
</address> </address>
</author> </author>
<author fullname="Ved Kafle" initials="V." surname="Kafle"> <author fullname="Ved Kafle" initials="V." surname="Kafle">
<organization>NICT</organization> <organization>NICT</organization>
<address>
<postal>
<street>4-2-1 Nukui-Kitamachi</street>
<extaddr>Koganei</extaddr>
<region>Tokyo</region>
<code>184-8795</code>
<country>Japan</country>
</postal>
<phone/>
<email>kafle@nict.go.jp</email>
<address>
<postal>
<street>4-2-1 Nukui-Kitamachi</street>
<!-- Reorder these if your country does things differently -->
<city>Koganei</city>
<region>Tokyo</region>
<code>184-8795</code>
<country>Japan</country>
</postal>
<phone></phone>
<email>kafle@nict.go.jp</email>
<!-- uri and facsimile elements may also be added -->
</address> </address>
</author> </author>
<date month="April" year="2022"/>
<date day="15" month="December" year="2021" /> <workgroup>Information-Centric Networking</workgroup>
<!-- If the month and year are both specified and are the current ones, xml2
rfc will fill
in the current day for you. If only the current year is specified, xml2rfc
will fill
in the current day and month for you. If the year is not the current one
, it is
necessary to specify at least a month (xml2rfc assumes day="1" if not sp
ecified for the
purpose of calculating the expiry date). With drafts it is normally suf
ficient to
specify just the year. -->
<!-- Meta-data Declarations -->
<area>ICNRG</area>
<workgroup>ICN Research Group</workgroup>
<!-- WG name at the upperleft corner of the doc,
IETF is fine for individual submissions.
If this element is not present, the default is "Network Working Group",
which is used by the RFC Editor as a nod to the history of the IETF. -->
<keyword>Internet Draft</keyword>
<!-- Keywords will be incorporated into HTML output <keyword>Information-Centric Networking </keyword>
files in a meta tag but they have no effect on text or nroff <keyword>Name Resolution Service </keyword>
output. If you submit your draft to the RFC Editor, the <keyword>Name to location mapping </keyword>
keywords will be used for the search engine. -->
<abstract> <abstract>
<t> <t>
This document describes architectural considerations and implications This document describes architectural considerations and implications
related to the use of a Name Resolution Service (NRS) in Information-Cen tric Networking (ICN). related to the use of a Name Resolution Service (NRS) in Information-Cen tric Networking (ICN).
It explains how the ICN architecture can change when an NRS is utilized It explains how the ICN architecture can change when an NRS is utilized
and how its use influences the ICN routing system. This document is a pr oduct and how its use influences the ICN routing system. This document is a pr oduct
of the Information-Centric Networking Research Group (ICNRG). of the Information-Centric Networking Research Group (ICNRG).
</t> </t>
</abstract> </abstract>
skipping to change at line 147 skipping to change at line 85
<abstract> <abstract>
<t> <t>
This document describes architectural considerations and implications This document describes architectural considerations and implications
related to the use of a Name Resolution Service (NRS) in Information-Cen tric Networking (ICN). related to the use of a Name Resolution Service (NRS) in Information-Cen tric Networking (ICN).
It explains how the ICN architecture can change when an NRS is utilized It explains how the ICN architecture can change when an NRS is utilized
and how its use influences the ICN routing system. This document is a pr oduct and how its use influences the ICN routing system. This document is a pr oduct
of the Information-Centric Networking Research Group (ICNRG). of the Information-Centric Networking Research Group (ICNRG).
</t> </t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section numbered="true" toc="default">
<name>Introduction</name>
<section title="Introduction"> <t>
<t>
Information-Centric Networking (ICN) is an approach to evolving the Information-Centric Networking (ICN) is an approach to evolving the
Internet infrastructure to provide direct access to Named Data Objects Internet infrastructure to provide direct access to Named Data
(NDOs) Objects (NDOs) by names. In two common ICN architectures, Named Data
by names. In two common ICN architectures, NDN <xref target="NDN"></xr Networking (NDN) <xref target="NDN" format="default"/> and
ef> and Content-Centric Networking (CCNx) <xref target="CCNx"
CCNx <xref target="CCNx"></xref>, the name of an NDO is used directly format="default"/>, the name of an NDO is used directly to route a
to route a request to retrieve the data object. Such direct name- request to retrieve the data object. Such direct name-based routing
based has inherent challenges in enabling a globally scalable routing
routing has inherent challenges in enabling a globally scalable routin system, accommodating producer mobility, and supporting off-path
g system, caching. These specific issues are discussed in detail in <xref
accommodating producer mobility, and supporting off-path caching. target="background"/>. In order to address these challenges, a Name
These specific issues are discussed in detail in Section 3. In order Resolution Service (NRS) has been utilized in the literature as well
to address these challenges, a Name Resolution Service (NRS) has been as the proposals of several ICN projects <xref target="Afanasyev"
utilized in the literature as well as the proposals of several ICN pro format="default"/> <xref target="Zhang2" format="default"/> <xref
jects target="I-D.ravi-icnrg-ccn-forwarding-label" format="default"/>
<xref target="Afanasyev"></xref> <xref target="Zhang2"></xref> <xref target="SAIL" format="default"/> <xref target="MF"
<xref target="Ravindran"></xref> <xref target="SAIL"></xref> format="default"/> <xref target="Bayhan" format="default"/>.
<xref target="MF"></xref> <xref target="Bayhan"></xref>. </t>
</t> <t>
<t> This document describes the potential changes in the ICN
This document describes the potential changes in the ICN architecture architecture caused by the introduction of an NRS and the
caused by the introduction of NRS and the corresponding implication to corresponding implication to the ICN routing system. It also
the ICN routing system. It also describes ICN architectural consi describes ICN architectural considerations for the integration of an
derations NRS. The scope of this document includes considerations from the
for the integration of an NRS. The scope of this document includ perspective of an ICN architecture and routing system when using an NR
es S
considerations from the perspective of ICN architecture and routing in ICN. A description of the NRS itself is provided in the companion
system when using an NRS in ICN. A description of the NRS itself i NRS design considerations document <xref target="RFC9138"
s format="default"/>, which provides the NRS approaches, functions, and
provided in the companion NRS design considerations document design considerations.
<xref target="RFC9138"></xref>, which provides the NRS approaches, </t>
functions and design considerations. <t>
</t>
<t>
This document represents the consensus of the Information-Centric This document represents the consensus of the Information-Centric
Networking Research Group (ICNRG). It has been reviewed extensively Networking Research Group (ICNRG). It has been reviewed extensively
by the Research Group (RG) members who are actively involved in the by the Research Group (RG) members who are actively involved in the
research and development of the technology covered by this document. research and development of the technology covered by this document.
It is not an IETF product and is not a standard. It is not an IETF product and is not a standard.
</t> </t>
<!-- <t>
<list style="symbols">
<t> global scalability of
routing </t>
<t> Producer mobility </t
>
<t> Finding off-path cach
ed objects </t>
<t> Security of routing i
nformation injected from outside the routing system.</t>
</list>
</t> -->
</section> </section>
<section numbered="true" toc="default">
<name>Terminology</name>
<dl>
<dt>Name Resolution Service (NRS):
</dt>
<dd>An NRS in ICN is defined as a service that provides the function
of translating a content name or a data object name into some other
information such as a routable prefix, a locator, an off-path-cache
pointer, or an alias name that is more amenable than the input name to
forwarding the object request toward the target destination storing
the NDO <xref target="RFC9138" format="default"/>. An NRS is most
likely implemented through the use of a distributed mapping database
system. The Domain Name System (DNS) may be used as an NRS. However, in
this case, the requirements of frequent updates of NRS records due to
the creations of a lot of new NDOs and changes in their locations in
the network need to be considered.
</dd>
<section title="Terminology"> <dt>NRS server:
<!-- <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", </dt>
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document a <dd>An NRS comprises the distributed NRS servers storing the mapping
re to be interpreted as described in <xref target="RFC2119"></xref>.</t> records in their databases. NRS servers store and maintain the
--> mapping records that keep the mappings of content or object name to
<t> some other information that is used for forwarding the content request
<list style="symbols"> or the content itself.
<t> </dd>
Name Resolution Service (NRS): An NRS in ICN is defined as
a service that provides the function of translating a conten
t
name or a data object name into some other information such
as
a routable prefix, a locator, an off-path-cache pointer, or
an alias name that is
more amenable than the input name to forwarding the object r
equest
toward the target destination storing the NDO <xref target="
RFC9138"></xref>.
An NRS is most likely implemented through the use of a distr
ibuted
mapping database system. Domain Name System (DNS) may be use
d as an NRS.
However, in this case, the requirements of frequent updates
of NRS records
due to the creations of a lot of new NDOs and changes in the
ir
locations in the network need to be considered.
</t>
<t>
NRS server: An NRS comprises the distributed NRS servers
storing the mapping records in their databases. NRS serve
rs
store and maintain the mapping records that keep the mapping
s
of content or object name to some other information that is
used for forwarding the content request or the content itsel
f.
</t>
<t>
NRS resolver: The client side function of an NRS is called a
n NRS resolver.
The NRS resolver is responsible for initiating name resoluti
on
request queries that ultimately lead to a name resolution of
the target data objects. NRS resolvers can be located in t
he
consumer (or client) nodes and/or ICN routers. An NRS re
solver
may also cache the mapping records obtained through the name
resolution for later usage.
</t>
<t>
Name registration: In order to populate the NRS, the content
names and their mapping records must be registered in the NR
S
system by a publisher who has access right to at least one
authoritative NRS server or by a producer who generates name
d
data objects. The records contain the mapping of an obj
ect
name to some information such as other alias names, routable
prefixes and locators,
which are used for forwarding the content request. Thus, a
publisher or producer of contents creates an NRS registratio
n request and
sends it to an NRS server. On registration, the NRS server
stores (or updates) the name mapping record in the database
and sends an acknowledgement back to the producer or publish
er
that made the registration request.
</t>
<t>
Name resolution: Name resolution is the main function of the
NRS system. It is performed by an NRS resolver which
can be
deployed on a consumer node or an ICN router. R
esolvers are
responsible for either returning a cached mapping record
(whose lifetime has not expired or alternatively sending a
name resolution request toward an NRS server. The NRS s
erver
searches for the content name in its mapping record database
,
and if found, retrieves the mapping record and returns it in
a
name resolution response message to the NRS resolver.
</t>
<t>
NRS node: NRS servers are also referred to as NRS nodes that
maintain the name records. The terms are used interchangeabl
y.
</t>
<t>
NRS client: A node that uses the NRS is called an NRS client
.
Any node that initiates a name registration, resolution,
or update procedure is an NRS client. That is, NRS reso
lvers,
ICN client nodes, ICN routers, or producers can be NRS clien
ts.
</t>
</list>
</t>
</section>
<section title="Background"> <dt>NRS resolver:
</dt>
<dd>The client-side function of an NRS is called an NRS resolver. The
NRS resolver is responsible for initiating name resolution request
queries that ultimately lead to a name resolution of the target data
objects. NRS resolvers can be located in the consumer (or client)
nodes and/or ICN routers. An NRS resolver may also cache the mapping
records obtained through the name resolution for later usage.
</dd>
<t> <dt>Name registration:
</dt>
<dd>In order to populate the NRS, the content names and their mapping
records must be registered in the NRS system by a publisher who has
access rights to at least one authoritative NRS server or by a producer
who generates named data objects. The records contain the mapping of
an object name to some information such as other alias names, routable
prefixes, and locators, which are used for forwarding the content
request. Thus, a publisher or producer of content creates an NRS
registration request and sends it to an NRS server. On registration,
the NRS server stores (or updates) the name mapping record in the
database and sends an acknowledgement back to the producer or
publisher that made the registration request.
</dd>
<dt>Name resolution:
</dt>
<dd>Name resolution is the main function of the NRS system. It is
performed by an NRS resolver, which can be deployed on a consumer node
or an ICN router. Resolvers are responsible for either returning a
cached mapping record (whose lifetime has not expired) or
alternatively sending a name resolution request toward an NRS server.
The NRS server searches for the content name in its mapping record
database and, if found, retrieves the mapping record and returns it in
a name resolution response message to the NRS resolver.
</dd>
<dt>NRS node:
</dt>
<dd>NRS servers are also referred to as NRS nodes that maintain the
name records. The terms are used interchangeably.
</dd>
<dt>NRS client:
</dt>
<dd>A node that uses the NRS is called an NRS client. Any node that
initiates a name registration, resolution, or update procedure is an
NRS client; that is, NRS resolvers, ICN client nodes, ICN routers, or
producers can be NRS clients.
</dd>
</dl>
</section>
<section numbered="true" toc="default" anchor="background">
<name>Background</name>
<t>
A pure name-based routing approach in ICN has inherent challenges in enabl ing A pure name-based routing approach in ICN has inherent challenges in enabl ing
a globally scalable routing system, accommodating producer mobility, and a globally scalable routing system, accommodating producer mobility, and
supporting off-path caching. In order to address these challenges, an NRS supporting off-path caching. In order to address these challenges, an NRS
has been utilized in proposals and literature of several ICN projects as f ollows: has been utilized in proposals and literature of several ICN projects as f ollows:
</t> </t>
<t> <dl>
<list style="symbols">
<t>
Routing scalability: In ICN, application names identifying conte
nts
are intended to be used directly for packet delivery, so ICN rou
ters
run a name-based routing protocol to build name-based routing an
d
forwarding tables. Similar to the scalability challenge of I
P
routing, if non-aggregatable name prefixes are injected into the
Default Route Free Zone (DFZ) of ICN routers, they would be driv
ing
the uncontrolled growth of the DFZ routing table size. Thus, pro
viding
the level of indirection enabled by an NRS in ICN can be an appr
oach
to keeping the routing table size under control. The NRS system
resolves name prefixes which do not exist in the DFZ forwarding
table into globally routable prefixes such as one proposed in
NDN <xref target="Afanasyev"></xref>. Another approach dealing
with routing scalability is the Multi-level Distributed Hash Tab
le
(MDHT) used in NetInf <xref target="Dannewitz"></xref>. I
t provides
name-based anycast routing that can support a non-hierarchical
namespace and can be adopted on a global scale <xref target="Dan
newitz2"></xref>.
</t>
<t>
Producer mobility: In ICN, if a producer moves into a different
name domain that uses a different name prefix, the request for a
content produced by the moving producer with the origin content
name must be forwarded to the moving producer's new location.
Especially in a hierarchical naming scheme, producer mobility
support is much harder than in a flat naming scheme since the ro
uting
tables in a broader area need to be updated to track the produce
r
movement. Therefore, various ICN architectures such as NetI
nf <xref target="Dannewitz"></xref>
and MobilityFirst <xref target="MF"></xref> have adopted NRS sys
tems
to tackle the issues of producers whose location changes.
</t>
<t>
Off-path caching: In-network caching is a common feature of an
ICN architecture. Caching approaches can be categorized int
o
on-path caching and off-path caching, according to the location
of caches in relation to the forwarding path from the original
content store to a consumer. Off-path caching, sometimes also
referred to as content replication or content storing, aims to
replicate a Named Data Object in various locations within a netw
ork
in order to increase the availability of contents, reduce access
latency,
or both. These caching locations may not be lying along the
content forwarding path. Thus, finding off-path cached con
tents
requires more complex forwarding procedures if a pure name-based
routing is employed. In order to support access to off-path cach
es,
the locations of replicas are usually advertised into a name-bas
ed
routing system or into an NRS as described in <xref target="Bayh
an"></xref>.
</t>
</list>
</t>
<t> <dt>Routing scalability:
</dt>
<dd>In ICN, application names identifying content are intended to be
used directly for packet delivery, so ICN routers run a name-based
routing protocol to build name-based routing and forwarding tables.
Similar to the scalability challenge of IP routing, if
non-aggregatable name prefixes are injected into the Default Route
Free Zone (DFZ) of ICN routers, they would be driving the uncontrolled
growth of the DFZ routing table size. Thus, providing the level of
indirection enabled by an NRS in ICN can be an approach to keeping the
routing table size under control. The NRS system resolves name
prefixes that do not exist in the DFZ forwarding table into globally
routable prefixes such as the one proposed in NDN <xref target="Afanasyev
"
format="default"/>. Another approach dealing with routing scalability
is the Multi-level Distributed Hash Table (MDHT) used in NetInf <xref
target="Dannewitz" format="default"/>. It provides name-based anycast
routing that can support a non-hierarchical namespace and can be
adopted on a global scale <xref target="Dannewitz2"
format="default"/>.
</dd>
<dt>Producer mobility:
</dt>
<dd>In ICN, if a producer moves into a different name domain that uses
a different name prefix, the request for a content produced by the
moving producer with the origin content name must be forwarded to the
moving producer's new location. Especially in a hierarchical naming
scheme, producer mobility support is much harder than in a flat naming
scheme since the routing tables in a broader area need to be updated
to track the producer movement. Therefore, various ICN architectures
such as NetInf <xref target="Dannewitz" format="default"/> and
MobilityFirst <xref target="MF" format="default"/> have adopted NRS
systems to tackle the issues of producers whose location changes.
</dd>
<dt>Off-path caching:
</dt>
<dd>In-network caching is a common feature of an ICN architecture.
Caching approaches can be categorized into on-path caching and
off-path caching, according to the location of caches in relation to
the forwarding path from the original content store to a consumer.
Off-path caching, sometimes also referred to as content replication or
content storing, aims to replicate a Named Data Object in various
locations within a network in order to increase the availability of
content, reduce access latency, or both. These caching locations may
not be lying along the content forwarding path. Thus, finding
off-path cached content requires more complex forwarding procedures
if a pure name-based routing is employed. In order to support access
to off-path caches, the locations of replicas are usually advertised
into a name-based routing system or into an NRS as described in <xref
target="Bayhan" format="default"/>.
</dd>
</dl>
<t>
This document discusses architectural considerations and implications This document discusses architectural considerations and implications
of ICN when an NRS is utilized to solve such challenges facing a name- based of ICN when an NRS is utilized to solve such challenges facing a name- based
routing in ICN. routing in ICN.
</t> </t>
</section> </section>
<section numbered="true" toc="default">
<section title="Implications of NRS in ICN"> <name>Implications of an NRS in ICN</name>
<t>
<t>
An NRS is not a mandatory part of an ICN architecture, as the majority An NRS is not a mandatory part of an ICN architecture, as the majority
of ICN architectures uses name-based routing that avoids the need for of ICN architectures uses name-based routing that avoids the need for
a name resolution procedure. Therefore, the utilization of an NRS in a name resolution procedure. Therefore, the utilization of an NRS in
an ICN architecture changes some architectural aspects at least with an ICN architecture changes some architectural aspects at least with
respect to forwarding procedures, latency, and security, as discussed below: respect to forwarding procedures, latency, and security, as discussed below:
</t> </t>
<t> <dl>
<list style="symbols">
<t>Forwarding pro
cedure: When an NRS is included in an ICN architecture,
the name resolution procedure has to be included in the ICN
overall routing and forwarding architectural procedures.
To integrate an NRS into an ICN architecture, there are certai
n
things that have to be decided and specified such as where, wh
en and how
the name resolution task is performed.
</t>
<t>Latency: When
an NRS is included in an ICN architecture,
additional latency introduced by the name resolution process
is incurred by the routing and forwarding system. Although
the
latency due to the name resolution is added, the total latency
of individual requests being served could be lower if the near
est copies or
off-path caches can be located by the NRS lookup procedure.
Additionally, there might be a favorable trade-off between
the name resolution latency and inter-domain traffic reduction
by finding the nearest off-path cached copy of the content.
Finding the nearest cache holding the content might significan
tly
reduce the content discovery as well as delivery latency.
</t>
<t>Security: When
any new component such as an NRS is introduced
in the ICN architecture, the attack surface may increase. Prot
ection of the NRS system
itself against attacks such as Distributed Denial of Service
(DDoS) and spoofing or alteration of name mapping records and
related signaling messages may be challenging.
</t>
</list>
</t>
</section> <dt>Forwarding procedure:
</dt>
<dd>When an NRS is included in an ICN architecture, the name
resolution procedure has to be included in the ICN overall routing and
forwarding architectural procedures. To integrate an NRS into an ICN
architecture, there are certain things that have to be decided and
specified such as where, when, and how the name resolution task is
performed.
</dd>
<section title="ICN Architectural Considerations for NRS"> <dt>Latency:
<t> </dt>
<dd>When an NRS is included in an ICN architecture, additional latency
introduced by the name resolution process is incurred by the routing
and forwarding system. Although the latency due to the name
resolution is added, the total latency of individual requests being
served could be lower if the nearest copies or off-path caches can be
located by the NRS lookup procedure. Additionally, there might be a
favorable trade-off between the name resolution latency and
inter-domain traffic reduction by finding the nearest off-path cached
copy of the content. Finding the nearest cache holding the content
might significantly reduce the content discovery as well as delivery
latency.
</dd>
<dt>Security:
</dt>
<dd>When any new component such as an NRS is introduced in the ICN
architecture, the attack surface may increase. Protection of the NRS
system itself against attacks such as Distributed Denial of Service
(DDoS) and spoofing or alteration of name mapping records and related
signaling messages may be challenging.
</dd>
</dl>
</section>
<section numbered="true" toc="default">
<name>ICN Architectural Considerations for NRS</name>
<t>
This section discusses the various items that can be considered from This section discusses the various items that can be considered from
the perspective of ICN architecture when employing an NRS system. the perspective of ICN architecture when employing an NRS system.
These items are related to the registration, resolution, and update of These items are related to the registration, resolution, and update of
name mapping records, protocols and messages, and integration with the name mapping records, protocols and messages, and integration with the
routing system. routing system.
</t> </t>
<section numbered="true" toc="default">
<section title="Name mapping records registration, resolution, and update <name>Name Mapping Records Registration, Resolution, and Update</name>
"> <t>
<t>
When an NRS is integrated in ICN architecture, the functions related to When an NRS is integrated in ICN architecture, the functions related to
the registration, resolution and update of name mapping records have to the registration, resolution, and update of name mapping records have t o
be considered. The NRS nodes maintain the name mapping records a nd may be considered. The NRS nodes maintain the name mapping records a nd may
exist as an overlay network over the ICN routers, that is, they communi cate exist as an overlay network over the ICN routers, that is, they communi cate
to each other through ICN routers. Figure 1 shows the NRS nodes and NRS to each other through ICN routers. <xref target="rl-fig1"/> shows the N RS nodes and NRS
clients connected through an underlying network. The NRS nodes sho uld be clients connected through an underlying network. The NRS nodes sho uld be
deployed in such a manner that an NRS node is always available at a sho rt distance from deployed in such a manner that an NRS node is always available at a sho rt distance from
an NRS client so that communication latency for the name registration a nd an NRS client so that communication latency for the name registration a nd
resolution requested by the NRS client remains very low. The name registration, resolution requested by the NRS client remains very low. The name registration,
name resolution and name record update procedures are briefly discussed name resolution, and name record update procedures are briefly discusse
below. d below.
</t> </t>
<figure anchor="rl-fig1">
<name>NRS Nodes and NRS Clients Connected through an Underlying Networ
k</name>
<artwork align="center" name="" type="" alt=""><![CDATA[
+------------+ +------------+
| NRS Node | | NRS Node |
+------------+ +------------+
| |
| |
+------------+ | | +------------+
| NRS Client |--------------------------------------| NRS Client |
+------------+ underlying network +------------+
]]></artwork>
</figure>
<t keepWithPrevious="true"/>
<figure anchor="rl-fig1" <dl>
title="NRS nodes and NRS clients connected through an underlyi
ng network">
<artwork align="center">
+------------+ +------------+ <dt>Name registration:
| NRS Node | | NRS Node | </dt>
+------------+ +------------+ <dd>Name registration is performed by the producer (as an
| | NRS client) when it creates a new content. When a producer creates content
| | and assigns a name from its name prefix space to the content, the producer
+------------+ | | +------------+ performs the name registration in an NRS node. Name registration may be
| NRS Client |--------------------------------------| NRS Client | performed by an ICN router when the ICN architecture supports off-path caching
+------------+ underlying network +------------+ or cooperative caching since involving an NRS may be a good idea for off-path
caching. The ICN routers with forwarder caches do not require name
registration for their cached content because they lie on the path toward an
upstream content store or producer. They will be hit when a future request is
forwarded to the content producer by an ICN router lying downstream toward the
ICN client node. However, ICN routers performing off-path caching of content
must invoke the name registration procedure so that other ICN routers can
depend on name resolutions to know about the off-path cache locations. If a
content gets cached in many off-path ICN routers, all of them may register the
same content names in the same NRS node, resulting in multiple registration
actions. In this case, the NRS node adds the new location of the content to
the name record together with the previous locations. In this way, each of the
name records stored in the NRS node may contain multiple locations of the
content. Assigning validity time or a lifetime of each mapping record may be
considered especially for the off-path caching content and managing mobility.
</dd>
</artwork> <dt>Name resolution:
<postamble> </dt>
</postamble> <dd>Name resolution is performed by an NRS client to obtain the name record
</figure> from an NRS node by sending a name resolution request message and getting a
response containing the record. In the name-based ICN routing context, the
name resolution is needed by any ICN router whose forwarding information base
(FIB) does not contain the requested name prefix. Name resolution may also be
performed by the consumer (especially in the case where the consumer is
multihomed) to forward the content request in a better direction so that it
obtains the content from the nearest cache. If the consumer is single homed,
it may not bother to perform name resolution, instead depending on either
straightforward name-based routing or name resolution by an upstream ICN
router. In this case, the consumer creates the content request packet
containing the content name and forwards to the nearest ICN router. The ICN
router checks its FIB table to see where to forward the content request. If
the ICN router fails to identify whether the requested content is reachable,
it performs name resolution to obtain the name mapping record and adds this
information to its FIB. The ICN router may also perform name resolution even
before the arrival of a content request to use the name mapping record to
configure its FIB.
</dd>
<t> <dt>Name record update:
<list style="symbols"> </dt>
<t> <dd>Name record update is carried out when a content name mapping record
Name registration: Name registration is performed by the produ changes, e.g., the content is not available in one or more of the previous
cer locations. The name record update includes the substitution and deletion of
(as an NRS client) when it creates a new content. When a pr the name mapping records. The name record update may take place explicitly by
oducer the exchange of name record update messages or implicitly when a timeout
creates content and assigns a name from its name prefix space occurs and a name record is deemed to be invalid. The implicit update is
to the content, the producer performs the name registration in possible when each record is accompanied by a lifetime value. The lifetime
an NRS node. Name registration may be performed by an ICN rout can be renewed only by the authoritative producer or node. The cached mapping
er records get erased after the lifetime expires unless a lifetime extension
when the ICN architecture supports off-path caching or coopera indication is obtained from the authoritative producer.
tive caching since involving </dd>
an NRS may be a good idea for off-path caching. The ICN r
outers
with forwarder caches do not require name registration for the
ir
cached content because they lie on the path toward an upstream
content store or producer. They will be hit when a future re
quest
is forwarded to the content producer by an ICN router lying
downstream toward the ICN client node. However, ICN rout
ers
performing off-path caching of content must invoke the name
registration procedure so that other ICN routers can depend on
name resolutions to know about the off-path cache locations.
If a content gets cached in many off-path ICN routers, all of
them
may register the same content names in the same NRS node,
resulting in multiple registration actions. In this case, the
NRS
node adds the new location of the content to the name record
together with the previous locations. In this way, each of the
name records stored in the NRS node may contain multiple locat
ions
of the content. Assigning validity time or a lifetime of each
mapping record may be considered especially for the off-path
caching contents and managing mobility.
</t>
<t>
Name resolution: Name resolution is performed by an NRS client
to obtain the name record from an NRS node by sending a name
resolution request message and getting a response containing
the record. In the name-based ICN routing context, the name
resolution is needed by any ICN router whose forwarding
information base (FIB) does not contain
the requested name prefix. Name resolution may also be perfo
rmed
by the consumer (especially in the case where the consumer is
multihomed) to forward the content request in a better directi
on
so that it obtains the content from the nearest cache. If the
consumer is single homed, it may not bother to perform name
resolution, instead depending on either straightforward name-b
ased
routing or name resolution by an upstream ICN router. O
n this case,
the consumer creates the content request packet containing the
content name and forwards to the nearest ICN router. The ICN
router checks its FIB table to see where to forward the conten
t
request. If the ICN router fails to know the requested con
tent
reachable, it performs name resolution to obtain the name mapp
ing
record and adds this information to its FIB. The ICN router
may also perform name resolution even before the arrival of a
content request to use the name mapping record to configure
its FIB.
</t>
<t>
Name record update: Name record update is carried out when a
content name mapping record changes, e.g. the content is not
available in one or more of previous locations. The name
record
update includes the substitution and deletion of the name mapp
ing
records. The name record update may take place explicitly by t
he exchange of name
record update messages or implicitly when a timeout occurs and
a name record is deemed to be invalid. The implicit upda
te is
possible when each record is accompanied by a lifetime value.
The lifetime can be renewed only by the authoritative producer
or node. The cached mapping records get erased after the lifet
ime
expires unless a lifetime extension indication is obtained fro
m
the authoritative producer.
</t>
</list>
</t>
<!--
<t>
The name resolution in ICN can be performed by consumer, routers, or b
oth. Once it is decided where the name resolution will take place, it has to be
considered how the name resolution will be performed.
The name provided by a consumer might be always resolved to identifier
s in a differnet namespace just like a DNS lookup.
Conversely, an NRS is always needed to map names to a different namesp
ace. </t>
</section>
<section title="Protocols and Semantics"> </dl>
<t>
</section>
<section numbered="true" toc="default">
<name>Protocols and Semantics</name>
<t>
In order to develop an NRS system within a local ICN network domain or In order to develop an NRS system within a local ICN network domain or
global ICN network domain, new protocols and semantics must be designed global ICN network domain, new protocols and semantics must be designed
and implemented to manage and resolve names among different name spaces and implemented to manage and resolve names among different namespaces.
. </t>
</t> <t>
<t>
One way of implementing an NRS for CCNx is by extending the basic TLV One way of implementing an NRS for CCNx is by extending the basic TLV
format and semantics <xref target="RFC8569"></xref> <xref target="RFC86 09"></xref>. format and semantics <xref target="RFC8569" format="default"/> <xref ta rget="RFC8609" format="default"/>.
For instance, name resolution and response messages can be implemented For instance, name resolution and response messages can be implemented
by defining new type fields in the Interest and Content Object by defining new type fields in the Interest and Content Object
messages <xref target="CCNxNRS"></xref>. By leveraging the existing CCN x messages <xref target="I-D.hong-icnrg-ccnx-nrs" format="default"/>. By leveraging the existing CCNx
Interest and Content Object packets for name resolution and registratio n, Interest and Content Object packets for name resolution and registratio n,
the NRS system can be deployed with a few ICN protocol changes. H owever, the NRS system can be deployed with a few ICN protocol changes. H owever,
because of confining the changes to the basic ICN protocol and semantic s, because of confining the changes to the basic ICN protocol and semantic s,
the NRS system may not be able to exploit more flexible and scalable de signs. the NRS system may not be able to exploit more flexible and scalable de signs.
</t> </t>
<t> <t>
On the other hand, an NRS system can be designed independently with its On the other hand, an NRS system can be designed independently with its
own protocol and semantics like the NRS system described in <xref targe t="Hong"></xref>. own protocol and semantics like the NRS system described in <xref targe t="Hong" format="default"/>.
For instance, the NRS protocol and messages can be implemented by using For instance, the NRS protocol and messages can be implemented by using
a RESTful API and the NRS can be operated as an application protocol a RESTful API, and the NRS can be operated as an application protocol
independent of the rest of the ICN protocol. independent of the rest of the ICN protocol.
</t> </t>
</section> </section>
<section numbered="true" toc="default">
<section title="Routing System"> <name>Routing System</name>
<t> <t>
An NRS reduces the routing complexity of ICN architecture compared to p ure An NRS reduces the routing complexity of ICN architecture compared to p ure
name-based routing. It does so by permitting the routing system to upda te name-based routing. It does so by permitting the routing system to upda te
the routing table on demand through the help of name records obtained the routing table on demand with the help of name records obtained
from NRS. The routing system therefore needs to make name resolutio n from NRS. The routing system therefore needs to make name resolutio n
requests and process the information returned, such as a prefix, a loca tor, an requests and process the information returned, such as a prefix, a loca tor, an
off-path-cache pointer, or an alias name, obtained from the name resolu tion. off-path-cache pointer, or an alias name, obtained from the name resolu tion.
</t> </t>
<t> <t>
No matter what kind of information is obtained from the name resolution , No matter what kind of information is obtained from the name resolution ,
as long as it is in the form of a name, the content request message in as long as it is in the form of a name, the content request message in
the routing system may be reformatted with the obtained information. the routing system may be reformatted with the obtained information.
In this case, the content name requested originally by a consumer needs In this case, the content name requested originally by a consumer needs
to be involved in the reformatted content request to check the integrit y to be involved in the reformatted content request to check the integrit y
of the binding between the name and the requested content. In other words, of the binding between the name and the requested content. In other words,
the information obtained from the name resolution is used to forward the information obtained from the name resolution is used to forward
the content request and the original content name requested by a consum er the content request, and the original content name requested by a consu mer
is used to identify the content. Alternatively, the resolved infor mation is used to identify the content. Alternatively, the resolved infor mation
may be used to build the routing table. may be used to build the routing table.
</t> </t>
<t> <t>
The information obtained from name resolution may not be in the form of The information obtained from name resolution may not be in the form of
a name. For example, it may identify tunnel endpoints by IP addre ss a name. For example, it may identify tunnel endpoints by IP addre ss
and instead be used to construct an IP protocol tunnel through which and instead be used to construct an IP protocol tunnel through which
to forward the content request. to forward the content request.
</t> </t>
</section>
</section>
</section> </section>
<section numbered="true" toc="default">
<section title="Conclusion"> <name>Conclusion</name>
<t> <t>
A Name Resolution Service (NRS) is not a mandatory part in an ICN architec ture, A Name Resolution Service (NRS) is not a mandatory part in an ICN architec ture,
as the majority of ICN architectures use name-based routing which does not as the majority of ICN architectures use name-based routing that does not
employ a name resolution procedure. However, such name-based routing in ICN employ a name resolution procedure. However, such name-based routing in ICN
has inherent challenges in enabling a globally scalable routing system, has inherent challenges in enabling a globally scalable routing system,
accommodating producer mobility, and supporting off-path caching. accommodating producer mobility, and supporting off-path caching.
In order to address these challenges, an NRS system has been introduced in In order to address these challenges, an NRS system has been introduced in
several ICN projects. Therefore, this document describes how the ICN ar chitecture several ICN projects. Therefore, this document describes how the ICN ar chitecture
changes when an NRS is utilized and how this affects the ICN routing syste m. changes when an NRS is utilized and how this affects the ICN routing syste m.
</t> </t>
<t> <t>
The document defines a few terminologies related to an NRS and explains The document defines a few terminologies related to an NRS and explains
some inherent challenges of pure name-based routing in ICN such as routing some inherent challenges of pure name-based routing in ICN such as routing
skipping to change at line 577 skipping to change at line 511
The document defines a few terminologies related to an NRS and explains The document defines a few terminologies related to an NRS and explains
some inherent challenges of pure name-based routing in ICN such as routing some inherent challenges of pure name-based routing in ICN such as routing
scalability, producer mobility, and off-path caching. This document descri bes scalability, producer mobility, and off-path caching. This document descri bes
how the ICN architecture would change with respect to procedures, latency, how the ICN architecture would change with respect to procedures, latency,
and security when an NRS is utilized. According to the ICN architectural and security when an NRS is utilized. According to the ICN architectural
changes, this document describes ICN architectural considerations for NRS changes, this document describes ICN architectural considerations for NRS
such as the functions related to the registration, resolution and update such as the functions related to the registration, resolution and update
of name mapping records, protocols and semantics to implement an NRS syste m, of name mapping records, protocols and semantics to implement an NRS syste m,
and the routing system involving the name resolution. and the routing system involving the name resolution.
</t> </t>
</section> </section>
<section anchor="IANA" numbered="true" toc="default">
<section anchor="IANA" title="IANA Considerations"> <name>IANA Considerations</name>
<t>There are no IANA actions required by this document.</t> <t>This document has no IANA actions.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Security Considerations"> <name>Security Considerations</name>
<t> <t>
When any new component such as an NRS is introduced in the ICN architect ure, When any new component such as an NRS is introduced in the ICN architect ure,
the attack surface increases. The related security vulnerability issues the attack surface increases. The related security vulnerability issues
are discussed below: are discussed below:
</t> </t>
<t> <dl>
<list style="symbols">
<t>
Name space security: In order to deploy an NRS system in ICN
architecture, ICN name spaces, which may be assigned by
authoritative entities, must be securely mapped to the content
publishers and securely managed by them. According to the
ICN
research challenges [RFC7927], a new name space can also provide
an integrity verification function to authenticate its publisher
.
The issues of namespace authentication and the mapping among dif
ferent
name spaces require further investigation.
</t>
<t>
NRS system security: An NRS requires the deployment of new entit
ies
(e.g. NRS servers) to build distributed and scalable NRS system
s.
Thus, the entities, e.g., NRS server maintaining a mapping datab
ase,
could be the focus of attacks by receiving malicious requests
from innumerable adversaries comprising a Denial of Service or
Distributed Denial of service attacks. In addition, NRS clients
in general must trust the NRS nodes in other network domains to
some degree and communication among them must also be protected
securely to prevent malicious entities from participating in thi
s
communication. The history of name resolution data requires to b
e
stored and analyzed as in passive DNS to uncover potential secur
ity
incidents or discover malicious infrastructures.
</t>
<t>
NRS protocol and message security: In an NRS system, the protoco
ls
to generate, transmit and receive NRS messages related to the na
me
registration, resolution, and record update should be protected
by proper security mechanisms. Proper security measures must be
provided so that only legitimate nodes can initiate and read NRS
messages. These messages must have secured by integrity protecti
on
and authentication mechanism so that unauthorized parties cannot
manipulate them when being forwarded through the network. Securi
ty
measures to encrypt these messages should also be developed to
thwart all threats to both security and privacy. Numerous proble
ms
similar to the security issues of an IP network and DNS can affe
ct the
overall ICN architecture. The DNS QNAME minimization type o
f approach
would be suitable for preserving privacy in the name resolution
process.
Therefore, security mechanisms such as accessibility, authentica
tion,
etc., for the NRS system <xref target="RFC9138"></xref> should b
e
considered to protect not only the NRS system, but also the ICN
architecture overall.
</t>
</list>
</t>
</section>
</middle> <dt>Namespace security:
</dt>
<dd>In order to deploy an NRS system in ICN architecture, ICN namespaces,
which may be assigned by authoritative entities, must be securely mapped to
the content publishers and securely managed by them. According to the ICN
research challenges <xref target="RFC7927" format="default"/>, a new namespace c
an also provide an integrity verification function to authenticate its
publisher. The issues of namespace authentication and the mapping among
different namespaces require further investigation.
</dd>
<!-- *****BACK MATTER ***** --> <dt>NRS system security:
<back> </dt>
<!-- References split into informative and normative --> <dd>An NRS requires the deployment of new entities (e.g., NRS servers) to
build distributed and scalable NRS systems. Thus, the entities, e.g., an NRS
server maintaining a mapping database, could be the focus of attacks by
receiving malicious requests from innumerable adversaries comprising of
Denial-of-Service or Distributed-Denial-of-Service attacks. In addition, NRS
clients in general must trust the NRS nodes in other network domains to some
degree, and communication among them must also be protected securely to prevent
malicious entities from participating in this communication. The history of
name resolution data requires to be stored and analyzed as in passive DNS to
uncover potential security incidents or discover malicious infrastructures.
</dd>
<!-- There are 2 ways to insert reference entries from the citation librarie <dt>NRS protocol and message security:
s: </dt>
1. define an ENTITY at the top, and use "ampersand character"RFC2629; here <dd>In an NRS system, the protocols to generate, transmit, and receive NRS
(as shown) messages related to the name registration, resolution, and record update
2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xm should be protected by proper security mechanisms. Proper security measures
l"?> here must be provided so that only legitimate nodes can initiate and read NRS
(for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml messages. These messages must be secured by integrity protection and
") authentication mechanisms so that unauthorized parties cannot manipulate them
when being forwarded through the network. Security measures to encrypt these
messages should also be developed to thwart all threats to both security and
privacy. Numerous problems similar to the security issues of an IP network and
DNS can affect the overall ICN architecture. The DNS QNAME minimization type
of approach would be suitable for preserving privacy in the name resolution
process. Therefore, security mechanisms such as accessibility,
authentication, etc., for the NRS system <xref target="RFC9138"
format="default"/> should be considered to protect not only the NRS system but
also the ICN architecture overall.
</dd>
Both are cited textually in the same manner: by using xref elements. </dl>
If you use the PI option, xml2rfc will, by default, try to find included fi
les in the same
directory as the including file. You can also define the XML_LIBRARY enviro
nment variable
with a value containing a set of directories to search. These can be eithe
r in the local
filing system or remote ones accessed by http (http://domain/dir/... ).-->
<references title="Normative References"> </section>
</middle>
&rfc2119; <back>
&rfc7927;
<reference anchor='RFC8569'> <displayreference target="I-D.ravi-icnrg-ccn-forwarding-label" to="Ravindran"/>
<front> <displayreference target="I-D.hong-icnrg-ccnx-nrs" to="CCNxNRS"/>
<title>Content-Centric Networking (CCNx) Semantics</title>
<author initials='M.' surname='Mosko' fullname='M. Mosko'></author>
<author initials='I.' surname='Solis' fullname='I. Solis'></author>
<author initials='C.' surname='Wood' fullname='C. Wood'></author>
<date month='July' year='2019' /> <references>
</front> <name>References</name>
<seriesInfo name='https://www.rfc-editor.org/info/rfc8569' value='' /> <references>
</reference> <name>Normative References</name>
<reference anchor='RFC8609'> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<front> FC.7927.xml"/>
<title>CCNx Messages in TLV Format </title> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<author initials='M.' surname='Mosko' fullname='M. Mosko'></author> FC.8569.xml"/>
<author initials='I.' surname='Solis' fullname='I. Solis'></author> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<author initials='C.' surname='Wood' fullname='C. Wood'></author> FC.8609.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.9138.xml"/>
</references>
<references>
<name>Informative References</name>
<date month='July' year='2019' /> <reference anchor="NDN" target="https://www.named-data.net">
<front>
<title>Named Data Networking</title>
<author>
<organization>NDN</organization>
</author>
<date month="September" year="2010"/>
</front> </front>
<seriesInfo name='https://www.rfc-editor.org/info/rfc8609' value='' />
</reference>
<reference anchor='RFC9138'>
<front>
<title>Design Considerations for Name Resolution Service in Infor
mation-Centric Networking (ICN)</title>
<author initials='' surname='Hong, J. et al.' fullname='J. Hong e
t al' ></author>
<date month='November' year='2021' />
</front>
<seriesInfo name='https://www.rfc-editor.org/info/rfc9138' value=
'' />
</reference>
</references>
<references title="Informative References">
<reference anchor='NDN'>
<front>
<title>NSF Named Data Networking project.</title>
<author initials='' surname='' fullname=''></author>
<date month='' year='' />
</front>
<seriesInfo name='http://www.named-data.net' value='' />
</reference>
<reference anchor='CCNx'>
<front>
<title>Content Centric Networking project.</title>
<author initials='' surname='' fullname=''></author>
<date month='' year='' />
</front>
<seriesInfo name='https://wiki.fd.io/view/Cicn' value='' />
</reference>
<reference anchor='Afanasyev'>
<front>
<title>SNAMP: Secure Namespace Mapping to Scale NDN Forwarding </title>
<author initials='' surname='Afanasyev, A. et al.' fullname='A. Afanasyev et
al' ></author>
<date month='April' year='2015' />
</front>
<seriesInfo name='IEEE Global Internet Symposium' value='' />
</reference>
<reference anchor='Zhang2'>
<front>
<title>A Survey of Mobility Support in Named Data Networking</title>
<author initials='Y.' surname='Zhang' fullname='Y. Zhang et al.'></aut
hor>
<date month='' year='2016' />
</front>
<seriesInfo name='NAMED-ORIENTED MOBILITY: ARCHITECTURES, ALGORITHMS, AN
D APPLICATIONS(NOM)' value='' />
</reference>
<reference anchor='Ravindran'> </reference>
<front>
<title>Forwarding-Label support in CCN Protocol </title>
<author initials='' surname='Ravindran, R. et al.' fullname='R. Ravindran
et al' ></author>
<date month='July' year='2017' />
</front>
<seriesInfo name='draft-ravi-icnrg-ccn-forwarding-label-01' value='' />
</reference>
<reference anchor='SAIL'> <reference anchor="CCNx" target="https://wiki.fd.io/view/Cicn">
<front> <front>
<title>FP7 SAIL project.</title> <title>Cicn</title>
<author initials='' surname='' fullname=''></author> <author>
<date month='' year='' /> <organization/>
</author>
<date/>
</front> </front>
<seriesInfo name='http://www.sail-project.eu/' value='' />
</reference>
<reference anchor='MF'> </reference>
<front>
<title>NSF Mobility First project.</title>
<author initials='' surname='' fullname=''></author>
<date month='' year='' />
</front>
<seriesInfo name='http://mobilityfirst.winlab.rutgers.edu/' value='' />
</reference>
<reference anchor='Bayhan'>
<front>
<title>On Content Indexing for Off-Path Caching in Information-Centric Ne
tworks </title>
<author initials='' surname='Bayhan, S. et al.' fullname='S. Bayhan et al
' ></author>
<date month='September' year='2016' />
</front>
<seriesInfo name='ACM ICN' value='' />
</reference>
<reference anchor='CCNxNRS'>
<front>
<title>CCNx Extension for Name Resolution Service</title>
<author initials='' surname='Hong, J. et al.' fullname='J. Hong et al.
' ></author>
<date month='July' year='2018' />
</front>
<seriesInfo name='draft-hong-icnrg-ccnx-nrs-02' value='' />
</reference>
<reference anchor='Hong'>
<front>
<title>Demonstrating a Scalable Name Resolution System for Information-Centr
ic Networking </title>
<author initials='J.' surname='Hong' fullname='J. Hong' ></author>
<author initials='W.' surname='Chun' fullname='W. Chun' ></author>
<author initials='H.' surname='Jung' fullname='H. Jung' ></author>
<date month='September' year='2015' />
</front>
<seriesInfo name='ACM ICN' value='' />
</reference>
<!--
<reference anchor='Jung'>
<front>
<title>IDNet: Beyond All-IP Network</title>
<author initials='' surname='Jung, H. et al.' fullname='H. Jung et al.
' ></author>
<date month='October' year='2015' />
</front>
<seriesInfo name='ETRI Jouranl' value='vol. 37, no. 5' />
</reference>
<reference anchor='Jacobson'>
<front>
<title>Networking Named Content</title>
<author initials='V.' surname='Jacobson' fullname='V. Jacobson'></auth
or>
<author initials='D. K.' surname='Smetters' fullname='D. K. Smetters'>
</author>
<author initials='J. D.' surname='Thornton' fullname='J. D. Thornton'>
</author>
<author initials='M. F.' surname='Plass' fullname='M. F. Plass'></auth
or>
<author initials='N. H.' surname='Briggs' fullname='N. H. Briggs'></au
thor>
<author initials='R. L.' surname='Braynard' fullname='R. L. Braynard'>
</author>
<date month='' year='2009' />
</front>
<seriesInfo name='ACM CoNEXT' value='' />
</reference>
<reference anchor='Baid'>
<front>
<title>Comparing Alternative Approaches for Networking of Named Object
s in the Future Internet</title>
<author initials='A.' surname='Baid' fullname='A. Baid'></author>
<author initials='T.' surname='Vu' fullname='T. Vu'></author>
<author initials='D.' surname='Raychaudhuri' fullname='D. Raychaudhuri
'></author>
<date month='' year='2012' />
</front>
<seriesInfo name='IEEE Workshop on Emerging Design Choices in Name-Orien
ted Networking (NOMEN)' value='' />
</reference>
<reference anchor='Bari'>
<front>
<title>A Survey of Naming and Routing in Information-Centric Networks<
/title>
<author initials='M. F.' surname='Bari' fullname='M. F. Bari'></author
>
<author initials='S. R.' surname='Chowdhury' fullname='S. R. Chowdhury
'></author>
<author initials='R.' surname='Ahmed' fullname='R. Ahmed'></author>
<author initials='R.' surname='Boutaba' fullname='R. Boutaba'></author
>
<author initials='B.' surname='Mathieu' fullname='B. Mathieu'></author
>
<date month='' year='2012' />
</front>
<seriesInfo name='IEEE Communications Magazine' value='Vol. 50, No. 12,
P.44-53' />
</reference>
<reference anchor='Rajahalme'>
<front>
<title>On Name-based Inter-domain Routing</title>
<author initials='J.' surname='Rajahalme' fullname='J. Rajahalme'></au
thor>
<author initials='M.' surname='Sarela' fullname='M. Sarela'></author>
<author initials='K.' surname='Visala' fullname='K. Visala'></author>
<author initials='J.' surname='Riihijarvi' fullname='J. Riihijarvi'></
author>
<date month='March' year='2011' />
</front>
<seriesInfo name='Computer Networks' value='Vol. 55, No. 4, P. 975-986'
/>
</reference>
<reference anchor='Katsaros'>
<front>
<title>On Inter-Domain Name Resolution for Information-Centric Network
s</title>
<author initials='K. V.' surname='Katsaros' fullname='K. V. Katsaros'>
</author>
<author initials='N.' surname='Fotiou' fullname='N. Fotiou'></author>
<author initials='X.' surname='Vasilakos' fullname='X. Vasilakos'></au
thor>
<author initials='C. N.' surname='Ververidis' fullname='C. N. Ververid
is'></author>
<author initials='C.' surname='Tsilopoulos' fullname='C. Tsilopoulos'>
</author>
<author initials='G.' surname='Xylomenos' fullname='G. Xylomenos'></au
thor>
<author initials='G. C.' surname='Polyzos' fullname='G. C. Polyzos'></
author>
<date month='' year='2012' />
</front>
<seriesInfo name='Proc.IFIP-TC6 Networking Conference' value='' />
</reference>
<reference anchor='ID.Wang'>
<front>
<title>Namespace Resolution in Future Internet Architectures</title>
<author initials='J.' surname='Wang' fullname='J. Wang'></author>
<author initials='S.' surname='Li' fullname='S. Li'></author>
<author initials='C.' surname='Wetphal' fullname='C. Wetphal'></author
>
<date month='October' year='2015' />
</front>
<seriesInfo name='draft-wang-fia-namespace-01' value='' />
</reference>
<reference anchor='ID.Zhang'>
<front>
<title>PID: A Generic Naming Schema for Information-centric Network</t
itle>
<author initials='X.' surname='Zhang' fullname='X. Zhang'></author>
<author initials='R.' surname='Ravindran' fullname='R. Ravindran'></au
thor>
<author initials='H.' surname='Xie' fullname='H. Xie'></author>
<author initials='G.' surname='Wang' fullname='G. Wang'></author>
<date month='August' year='2013' />
</front>
<seriesInfo name='draft-zhang-icnrg-pid-naming-scheme-03' value='' />
</reference>
<reference anchor='D.Zhang'>
<front>
<title>Routing and Name Resolution in Information-Centric Networks</ti
tle>
<author initials='D.' surname='Zhang' fullname='D. Zhang'></author>
<author initials='H.' surname='Liu' fullname='H. Liu'></author>
<date month='' year='2013' />
</front>
<seriesInfo name='22nd International Conference on Computer Communicatio
ns and Networks (ICCCN)' value='' />
</reference>
<reference anchor='Sevilla'>
<front>
<title>iDNS: Enabling Information Centric Networking Through The DNS</
title>
<author initials='S.' surname='Sevilla' fullname='S. Sevilla'></author
>
<author initials='P.' surname='Mahadevan' fullname='P. Mahadevan'></au
thor>
<author initials='J.' surname='Garcia-Luna-Aceves' fullname='J. Garcia
-Luna-Aceves'></author>
<date month='' year='2014' />
</front>
<seriesInfo name='Name Oriented Mobility (workshop co-located with Infoc
om 2014)' value='' />
</reference>
&rfc1498;
<reference anchor='oneM2M'>
<front>
<title>oneM2M Functional Architecture TS 0001.</title>
<author initials='' surname='' fullname=''></author>
<date month='' year='' />
</front>
<seriesInfo name='http://www.onem2m.org/technical/published-documents.'
value='' />
</reference>
&rfc7252;
<reference anchor='ID.Shelby'>
<front>
<title>CoRE Resource Directory</title>
<author initials='Z.' surname='Shelby' fullname='Z. Shelby'></au
thor>
<date month='March' year='2017' />
</front>
<seriesInfo name='draft-ietf-core-resource-directory-10' value='' />
</reference>
<reference anchor='CoRE'>
<front>
<title>Constrained RESTful Environments, CoRE</title>
<author initials='' surname='' fullname=''></author>
<date month='March' year='2013' />
</front>
<seriesInfo name='https://datatracker.ietf.org/wg/core/charter/' value='
' />
</reference>
<reference anchor='Westphal'> <reference anchor="Afanasyev">
<front> <front>
<title>An IP-based Manifest Architecture for ICN</title> <title>SNAMP: Secure namespace mapping to scale NDN forwarding</titl
<author initials='C.' surname='Westphal' fullname='C. Westphal'> e>
</author> <author initials="A." surname="Afanasyev" fullname="Alexander Afanas
<author initials='E.' surname='Demirors' fullname='E. Demirors'> yev"/>
</author> <author initials="C." surname="Yi" fullname="Cheng Yi"/>
<date month='' year='2015' /> <author initials="L." surname="Wang" fullname="Lan Wang"/>
</front> <author initials="B." surname="Zhang" fullname="Beichuan Zhang"/>
<seriesInfo name='ACM ICN' value='' /> <author initials="L." surname="Zhang" fullname="Lixia Zhang"/>
</reference> <date month="April" year="2015"/>
</front>
<refcontent>2015 IEEE Conference on Computer Communications
Workshops (INFOCOM WKSHPS)</refcontent>
<seriesInfo name="DOI" value="10.1109/INFCOMW.2015.7179398"/>
</reference>
<reference anchor='Mosko'> <reference anchor="Zhang2">
<front> <front>
<title>CCNx Manifest Specification</title> <title>A Survey of Mobility Support in Named Data Networking</title>
<author initials='M.' surname='Mosko' fullname='M. Mosko'></author> <author initials="Y." surname="Zhang" fullname="Yu Zhang"/>
<author initials='G.' surname='Scott' fullname='G. Scott'></author> <author initials="A." surname="Afanasyev" fullname="Alexander Afanas
<author initials='I.' surname='Solis' fullname='I. Solis'></author> yev"/>
<author initials='C.' surname='Wood' fullname='C. Wood'></author> <author initials="J." surname="Burke" fullname="Jeff Burke"/>
<date month='July' year='2015' /> <author initials="L." surname="Zhang" fullname="Lixia Zhang"/>
</front> <date month="April" year="2016"/>
<seriesInfo name='draft-wood-icnrg-ccnxmanifests-00' value='' /> </front>
</reference> <refcontent>Named Data Networking</refcontent>
--> <refcontent>Workshop on Name-Oriented Mobility: Architecture,
<!-- Algorithms and Applications (NOM)</refcontent>
&rfc6830; </reference>
&rfc6833;
--> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ravi-ic nrg-ccn-forwarding-label.xml"/>
<!-- <reference anchor="SAIL" target="https://www.sail-project.eu/">
<front>
<title>Scalable and Adaptive Internet Solutions (SAIL)</title>
<author/>
</front>
</reference>
<reference anchor='Zhang'> <reference anchor="MF" target="http://mobilityfirst.cs.umass.edu/">
<front> <front>
<title>Named data networking</title> <title>MobilityFirst</title>
<author initials='' surname='Zhang, L. et al.' fullname='L. Zhang et al.'></au <author>
thor> <organization>Future Internet Architecture (FIA)</organization>
<date month='July' year='2014' /> </author>
</front> <date/>
<seriesInfo name='ACM SIGCOMM Computer Communication Review' value='vol. 44, </front>
no. 3' /> </reference>
</reference>
<reference anchor='Zhang2'> <reference anchor="Bayhan">
<front> <front>
<title>A Survey of Mobility Support in Named Data Networking</title> <title>On Content Indexing for Off-Path Caching in Information-Centr
<author initials='Y.' surname='Zhang' fullname='Y. Zhang et al.'></aut ic Networks </title>
hor> <author initials="S." surname="Bayhan" fullname="Suzan Bayhan"/>
<date month='' year='2016' /> <author initials="" surname="" fullname="Liang Wang"/>
</front> <author initials="J." surname="Ott" fullname="Jörg Ott"/>
<seriesInfo name='NAMED-ORIENTED MOBILITY: ARCHITECTURES, ALGORITHMS, AN <author initials="J." surname="Kangasharju" fullname="Jussi Kangashar
D APPLICATIONS(NOM)' value='' /> ju"/>
</reference> <author initials="A." surname="Sathiaseelan" fullname="Arjuna Sathias
eelan"/>
<author initials="J." surname="Crowcroft" fullname="Jon Crowcroft"/>
<date month="September" year="2016"/>
</front>
<refcontent>ACM ICN</refcontent>
<seriesInfo name="DOI" value="10.1145/2984356.2984372"/>
</reference>
<reference anchor='Dannewitz'> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.hong-ic
<front> nrg-ccnx-nrs.xml"/>
<title> Network of Information (NetInf)-An information centric networking ar
chitecture </title>
<author initials='' surname='Dannewitz, C. et al.' fullname='C. Dannewitz et
al.' ></author>
<date month='April' year='2013' />
</front>
<seriesInfo name='Computer Communications' value='vol. 36, no. 7' />
</reference>
<!-- <reference anchor="Hong">
<reference anchor='Seskar'> <front>
<front> <title>Demonstrating a Scalable Name Resolution System for Informati
<title>MobilityFirst Future Internet Architecture Project</title> on-Centric Networking </title>
<author initials='I.' surname='Seskar' fullname='I. Seskar' ></author> <author initials="J." surname="Hong" fullname="J. Hong"/>
<author initials='K.' surname='Nagaraja' fullname='K. Nagaraja' ></author> <author initials="W." surname="Chun" fullname="W. Chun"/>
<author initials='S.' surname='Nelson' fullname='S. Nelson' ></author> <author initials="H." surname="Jung" fullname="H. Jung"/>
<author initials='D.' surname='Raychaudhuri' fullname='D. Raychaudhurin' >< <date month="September" year="2015"/>
/author> </front>
<date month='November' year='2011' /> <refcontent>ACM ICN</refcontent>
</front> <seriesInfo name="DOI" value="10.1145/2810156.2812617"/>
<seriesInfo name='7th Asian Internet Engineering Conference' value='' /> </reference>
</reference>
<reference anchor='Dannewitz2'>
<front>
<title>Hierarchical DHT-based name resolution for Information-Centric Networ
ks</title>
<author initials='C.' surname='Dannewitz' fullname='C. Dannewitz' ></author>
<author initials='M.' surname='DAmbrosio' fullname='M. DAmbrosio' ></author>
<author initials='V.' surname='Vercellone' fullname='V. Vercellone' ></autho
r>
<date month='April' year='2013' />
</front>
<seriesInfo name='Computer Communications' value='vol. 36, no. 7' />
</reference>
<!--
<reference anchor='Vu'>
<front>
<title>DMap: A Shared Hosting Scheme for Dynamic Identifier to Locator Mappi
ng in the Global Internet </title>
<author initials='' surname='Vu, T. et al.' fullname='T. Vu et al' ></author
>
<date month='' year='2012' />
</front>
<seriesInfo name='IEEE 32nd International Conference on Distributed Computin
g Systems' value='' />
</reference>
<reference anchor='Hong'> <reference anchor="Dannewitz">
<front> <front>
<title>Demonstrating a Scalable Name Resolution System for Information-Centr <title>Network of Information (NetInf) – An information-centric
ic Networking </title> networking architecture</title>
<author initials='J.' surname='Hong' fullname='J. Hong' ></author> <author initials="" surname="" fullname="ChristianDannewitz"/>
<author initials='W.' surname='Chun' fullname='W. Chun' ></author> <author initials="" surname="" fullname="Dirk Kutscher"/>
<author initials='H.' surname='Jung' fullname='H. Jung' ></author> <author initials="" surname="" fullname="Börje Ohlman"/>
<date month='September' year='2015' /> <author initials="" surname="" fullname="Stephen Farrell"/>
</front> <author initials="" surname="" fullname="Bengt Ahlgren"/>
<seriesInfo name='ACM ICN' value='' /> <author initials="" surname="" fullname="Holger Karl"/>
<date month="April" year="2013"/>
</front>
<seriesInfo name="Computer Communications" value="vol. 36, issue 7"/>
<seriesInfo name="DOI" value="10.1016/j.comcom.2013.01.009"/>
</reference> </reference>
<reference anchor='Ravindran'> <reference anchor="Dannewitz2">
<front> <front>
<title>Forwarding-Label support in CCN Protocol </title> <title>Hierarchical DHT-based name resolution for information-centri
<author initials='' surname='Ravindran, R. et al.' fullname='R. Ravindran et c networks</title>
al' ></author> <author initials="C." surname="Dannewitz" fullname="Christian Dannew
<date month='July' year='2017' /> itz"/>
</front> <author initials="M." surname="D'Ambrosio" fullname="Matteo D’Ambros
<seriesInfo name='draft-ravi-icnrg-ccn-forwarding-label-01' value='' /> io"/>
<author initials="V." surname="Vercellone" fullname="Vinicio Vercell
one"/>
<date month="April" year="2013"/>
</front>
<seriesInfo name="Computer Communications" value="vol. 36, issue 7"/>
<seriesInfo name="DOI" value="10.1016/j.comcom.2013.01.014"/>
</reference> </reference>
<reference anchor='Mosko2'>
<front>
<title>Nameless Objects </title>
<author initials='M.' surname='Mosko' fullname='M. Mosko' ></author>
<date month='July' year='2015' />
</front>
<seriesInfo name='' value='' />
</reference>
-->
</references> </references>
</references>
<section anchor="Acknowledgments" title="Acknowledgements" numbered="false" <section anchor="Acknowledgements" numbered="false" toc="include">
toc="include"> <name>Acknowledgements</name>
<t> <t>
The authors would like to thank Dave Oran (ICNRG Co-chair) The authors would like to thank <contact fullname="Dave Oran"/> (ICNRG C
for very useful reviews and comments on the document and they helped to o-chair)
immeasurably improve the document. for very useful reviews and comments, which helped to
immeasurably improve this document.
</t> </t>
</section>
</back>
</rfc> <!--
< </reference>
title>Networking named content</title> <sInfo name='IEEE Network' va
lue='vol. 30, no. 2' />
</reference>
&id.draft-winter-energy-efficient-internet;
</reference>
&i
d.draft-cheshire-edns0-owner-option;
<reference anchor='ITU'>
<front>
<title>Resolution 73 - Information and communication technologies an
d climate change</title>
<author></author>
<date month='October' year='2008' />
</front>
</reference>
<reference anchor='EPC'>
<front>
<title>The Case for Energy-Proportional Computing</title>
<author initials='L.' surname='Barroso' fullname='Luiz Andre Barroso
'></author>
<author initials='U.' surname='Holzle' fullname='Urs Holzle'></autho
r>
<date month='December' year='2007'/>
</front>
<seriesInfo name='Proc. IEEE International Conference on Network Protoco
ls (ICNP)' value=''/>
</reference>
<reference anchor='GreenSurvey'>
<front>
<title>A survey of green networking research</title>
<author initials='A.P.' surname='Bianzino' fullname='Aruna Prem Bian
zino'></author>
<author initials='C.' surname='Chaudet' fullname='Claude Chaudet'></
author>
<author initials='D.' surname='Rossi' fullname='Dario Rossi'></autho
r>
<author initials='J.-L.' surname='Rougier' fullname='Jean-Louis Roug
ier'></author> <date month='' year='2012' />
</front>
<seriesInfo name='IEEE Communications Surveys Tutorials' value='' />
</reference>
<reference anchor='EEE'>
<front>
<title>802.3az-2010</title>
<author></author>
<date month='' year='2010' />
</front>
<seriesInfo name='IEEE std' value='' />
</reference>
<reference anchor='PROXZZZY'> </section>
<front> </back>
<title>ProxZZZy for sleeping hosts</title> </rfc>
<author></author>
<date month='June' year='2012' />
</front>
<seriesInfo name='ECMA International' value='ECMA-393' />
</reference>
<reference anchor='EEEC'>
<front>
<title>Improving the Energy Efficiency of Ethernet-Connected:
A Proposal for Proxying</title>
<author initials='B.' surname='Nordman' fullname='Bbuce Nordman'></a
uthor>
<author initials='K.' surname='Christensen' fullname='Ken Christense
n'></author>
<date month='September' year='2007' />
</front>
<seriesInfo name='Ethernet Alliance' value='' />
</reference>
<reference anchor='NCP'>
<front>
<title>A Network Connection Proxy to Enable Hosts to Sleep and Save
Energy</title>
<author initials='M.' surname='Jimeno' fullname='M. Jimeno'></author
>
<author initials='K.' surname='Christensen' fullname='K. Christensen
'></author>
<author initials='B.' surname='Nordman' fullname='B. Nordman'></autho
r>
<date month='' year='2008' />
</front>
<seriesInfo name='Proc. IEEE Internat. Performance Computing and Communi
cations Conf' value='' />
</reference>
<reference anchor='SKILL'>
<front>
<title>Skilled in the Art of Being Idle: Reducing Energy Waste in Ne
tworked Systems</title>
<author initials='S.' surname='Nedevschi' fullname='S. Nedevschi'></
author>
<author initials='J.' surname='Liu' fullname='J. Liu'></author>
<author initials='B.' surname='Nordman' fullname='B. Nord
man'></author>
<author initials='S.' surname='Ratnasamy' fullname='S. Ratnas
amy'></author>
<author initials='N.' surname='Taft' fullname='N. Taft'><
/author>
<date month='' year='2009' />
</front>
<seriesInfo name='Proc. USENIX Symposium on Networked Systems Design and
Implementation' value='' />
</reference>
-->
 End of changes. 97 change blocks. 
1177 lines changed or deleted 583 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/