One document matched: draft-ietf-hip-rfc4843-bis-03.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY % RFC4843 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4843.xml" >
<!ENTITY % RFC4773 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4773.xml" >
<!ENTITY % RFC4270 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4270.xml" >
<!ENTITY % RFC4291 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4291.xml" >
<!ENTITY % RFC3972 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3972.xml" >
<!ENTITY % RFC3174 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3174.xml" >
<!ENTITY % RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml" >
<!ENTITY % RFC1918 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1918.xml" >
<!ENTITY % I-D.ietf-hip-rfc5201-bis SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-hip-rfc5201-bis.xml" >
]>
<?rfc rfcedstyle="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc sortrefs="yes" ?>
<?rfc toc="yes" ?>
<?rfc tocompact="yes"?>
<rfc category="std" obsoletes="4843" ipr="trust200902">
<front>
<title abbrev="Cryptographic Hash IDentifiers(ORCHIDv2)">
An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers Version 2 (ORCHIDv2)
</title>
<author initials="J." surname="Laganier" fullname="Julien Laganier">
<organization abbrev="Juniper Networks">
Juniper Networks
</organization>
<address> <postal>
<street>1094 North Mathilda Avenue
</street>
<city>Sunnyvale</city>
<region>CA</region>
<code>94089</code>
<country>USA</country>
</postal>
<phone>+1 408 936 0385</phone>
<email>julien.ietf@gmail.com</email>
</address>
</author>
<author initials="F." surname="Dupont"
fullname="Francis Dupont">
<organization>Internet Systems Consortium</organization>
<address>
<email>fdupont@isc.org</email>
</address>
</author>
<date year="2012"/>
<area>Internet</area>
<keyword>I-D</keyword>
<keyword>Internet Draft</keyword>
<abstract>
<t>
This document specifies an updated Overlay Routable Cryptographich Hash Identifiers format that obsoletes the earlier format defined in <xref
target="RFC4843"/>. These identifiers are intended to be used as
endpoint identifiers at applications and Application Programming Interfaces
(API) and not as identifiers for network location at the IP layer, i.e.,
locators. They are designed to appear as application layer entities and at
the existing IPv6 APIs, but they should not appear in actual IPv6 headers. To
make them more like vanilla IPv6 addresses, they are expected to be routable
at an overlay level. Consequently, while they are considered non-routable
addresses from the IPv6 layer point-of-view, all existing IPv6 applications
are expected to be able to use them in a manner compatible with current IPv6
addresses.
</t>
<t>
The Overlay Routable Cryptographic Hash Identifiers originally
defined in <xref target="RFC4843"/> lacked a mechanism for cryptographic algorithm agility. The updated ORCHID format specified in this document removes this limitation by encoding in the identifier itself an index to the suite
of cryptographic algorithms in use.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t> This document introduces Overlay Routable Cryptographic Hash Identifiers
(ORCHID), a new class of IP address-like identifiers. These
identifiers are intended to be globally unique in a statistical
sense (see <xref target="sec-API-issues" />), non-routable at the IP
layer, and routable at some overlay layer. The identifiers are
securely bound, via a secure hash function, to the concatenation of
an input bitstring and a context tag. Typically, but not
necessarily, the input bitstring will include a suitably encoded
public cryptographic key. </t>
<section title="Rationale and Intent">
<t> These identifiers are expected to be used at the existing IPv6
Application Programming Interfaces (API) and application protocols between consenting hosts. They may be
defined and used in different contexts, suitable for different
overlay protocols. Examples of these include Host Identity Tags
(HIT) in the <xref target="I-D.ietf-hip-rfc5201-bis"> Host Identity Protocol
(HIP) </xref> and <xref target="PRIVACYTEXT">
Temporary Mobile Identifiers (TMI) for Mobile IPv6 Privacy Extension
</xref>. </t>
<t> As these identifiers are expected to be used along with IPv6
addresses at both applications and APIs, co-ordination is desired
to make sure that an ORCHID is not inappropriately taken for a
vanilla IPv6 address and vice versa. In practice, allocation of a
separate prefix for ORCHIDs seems to suffice, making them compatible
with IPv6 addresses at the upper layers while simultaneously making
it trivial to prevent their usage at the IP layer. </t>
<t> While being technically possible to use ORCHIDs between
consenting hosts without any co-ordination with the IETF and the
IANA, the authors would consider such practice
potentially dangerous. A specific danger would be realised if the
IETF community later decided to use the ORCHID prefix for some
different purpose. In that case, hosts using the ORCHID prefix would
be, for practical purposes, unable to use the prefix for the other
new purpose. That would lead to partial balkanisation of the
Internet, similar to what has happened as a result of historical
hijackings of non-<xref target="RFC1918"> RFC 1918 </xref> IPv4
addresses for private use.</t>
<t> The whole need for the proposed allocation grows from the desire
to be able to use ORCHIDs with existing applications and APIs. This
desire leads to the potential conflict, mentioned above. Resolving
the conflict requires the proposed allocation.</t>
<t> One can argue that the desire to use these kinds of identifiers
via existing APIs is architecturally wrong, and there is some truth
in that argument. Indeed, it would be more desirable to introduce a
new API and update all applications to use identifiers, rather than
locators, via that new API. That is exactly what we expect to happen
in the long run.</t>
<t> However, given the current state of the Internet, we do not
consider it viable to introduce any changes that, at once, require
applications to be rewritten and host stacks to be updated. Rather
than that, we believe in piece-wise architectural changes that
require only one of the existing assets to be touched. ORCHIDs are
designed to address this situation: to allow people to experiment
with protocol stack extensions, such as secure overlay routing, HIP,
or Mobile IP privacy extensions, without requiring them to update
their applications. The goal is to facilitate large-scale
experiments with minimum user effort.</t>
<t> For example, there already exists, at the time of this writing,
HIP implementations that run fully in user space, using the
operating system to divert a certain part of the IPv6 address space
to a user level daemon for HIP processing. In practical terms, these
implementations are already using a certain IPv6 prefix for
differentiating HIP identifiers from IPv6 addresses, allowing them
both to be used by the existing applications via the existing
APIs.</t>
<t>
The Overlay Routable Cryptographic Hash Identifiers originally
defined in <xref target="RFC4843"/> lacked a mechanism for cryptographic algorithm agility. The updated ORCHID format specified in this document removes this limitation by encoding in the identifier itself an index to the suite
of cryptographic algorithms in use.
</t>
<t>
Because the updated ORCHIDv2 format is not backward compatible with
the earlier one, IANA is requested to allocate a new 28-bit prefix out of the IANA IPv6 Special Purpose Address Block, namely
2001:0000::/23, as per <xref target="RFC4773"/>. The prefix
that was temporarily allocated for the experimental ORCHID is to
be returned to IANA in 2014 <xref target="RFC4843"/>.
</t>
</section>
<section title="ORCHID Properties">
<t>ORCHIDs are designed to have the following properties:
<t></t>
<list style="symbols">
<t> Statistical uniqueness; also see <xref
target="sec-API-issues" /> </t>
<t> Secure binding to the input parameters used in their
generation (i.e., the context identifier and a bitstring). </t>
<t> Aggregation under a single IPv6 prefix. Note that this is
only needed due to the co-ordination need as indicated above.
Without such co-ordination need, the ORCHID namespace could
potentially be completely flat. </t>
<t> Non-routability at the IP layer, by design. </t>
<t> Routability at some overlay layer, making them, from an
application point of view, semantically similar to IPv6
addresses. </t> </list> </t>
<t> As mentioned above, ORCHIDs are intended to be generated and
used in different contexts, as suitable for different mechanisms and
protocols. The context identifier is meant to be used to
differentiate between the different contexts; see <xref
target="sec-API-issues" /> for a discussion of the related API and
kernel level implementation issues, and <xref target="sec-design" />
for the design choices explaining why the context identifiers are
used. </t>
</section>
<section title="Expected use of ORCHIDs">
<t>
Examples of identifiers and protocols that are expected to adopt
the ORCHID format include Host Identity Tags (HIT) in
the
<xref target="I-D.ietf-hip-rfc5201-bis">
Host Identity Protocol
</xref>
and the Temporary Mobile Identifiers (TMI) in the
<xref target="PRIVACYTEXT">
Simple Privacy Extension for Mobile IPv6
</xref>.
The format is designed to be extensible to allow other
experimental proposals to share the same namespace.
</t>
</section>
<section title="Action Plan">
<t> This document requests IANA to allocate a prefix
out of the IPv6 addressing space for Overlay Routable Cryptographic
Hash Identifiers. </t>
</section>
<section title="Terminology">
<t>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <xref target="RFC2119"/>.
</t>
</section>
</section>
<section title="Cryptographic Hash Identifier Construction">
<t>
An ORCHID is generated using the ORCHID Generation Algorithm (OGA) below. The algorithm takes a bitstring and a context identifier as input and produces an ORCHID as output. The hash function used in the ORCHID Generation Algorithm is defined for each OGA identifier by the specification for the respective usage context (e.g., HIPv2).
</t>
<figure>
<artwork><![CDATA[
Input := any bitstring
OGA ID := 4-bits Orchid Generation Algorithm identifier
Hash Input := Context ID | Input
Hash := Hash_function( Hash Input )
ORCHID := Prefix | Encode_96( Hash )
where:
| : Denotes concatenation of bitstrings
Input : A bitstring that is unique or statistically unique
within a given context. The bitstring is intended
to be associated with the to-be-created ORCHID in
the given context.
Context ID : A randomly generated value defining the expected
usage context for the particular ORCHID and the
hash function to be used for generation of ORCHIDs
in this context. These values are allocated out of
the namespace introduced for CGA Type Tags; see RFC
3972 and
http://www.iana.org/assignments/cga-message-types.
OGA ID : A 4-bit long identifier for the Hash_function
in use within the specific usage context.
Hash_function : The one-way hash function (i.e., hash function
with pre-image resistance and second pre-image
resistance) to be used as identified by the
value for the OGA ID according document
defining the context usage identified by the
Context ID. For example, the version 2 of the
HIP specification defines SHA1 [RFC3174] as
the hash function to be used to generate
ORCHIDv2 used in the HIPv2 protocol when the
OGA ID is 3 [I-D.ietf-hip-rfc5201-bis].
Encode_96( ) : An extraction function in which output is obtained
by extracting the middle 96-bit-long bitstring
from the argument bitstring.
Prefix : A constant 28-bit-long bitstring value
(IANA TBD 2001:11::/28 ?).
]]></artwork>
</figure>
<t>To form an ORCHID, two pieces of input data are needed. The first
piece can be any bitstring, but is typically expected to contain a
public cryptographic key and some other data. The second piece is a
context identifier, which is a 128-bit-long datum, allocated as
specified in <xref target="sec-IANA" />. Each specific experiment
(such as HIP HITs or MIP6 TMIs) is expected to allocate their own,
specific context identifier.</t>
<t>The input bitstring and context identifier are concatenated to
form an input datum, which is then fed to the cryptographic hash
function to be used for the value of the OGA identifier according to the document defining the
context usage identified by the Context ID.
The result of the hash function is processed by an
encoding function, resulting in a 96-bit-long value. This value is
prepended with the concatenation of the 28-bit ORCHID prefix and the 4-bit OGA ID. The result is the ORCHID, a
128-bit-long bitstring that can be used at the IPv6 APIs in hosts
participating to the particular experiment.</t>
<t>The ORCHID prefix is allocated under the IPv6 global unicast address
block. Hence, ORCHIDs are indistinguishable from IPv6 global unicast addresses.
However, it should be noted that ORCHIDs do not conform with the IPv6 global
unicast address format defined in Section 2.5.4 of <xref target="RFC4291"/> since
they do not have a 64-bit Interface ID formatted as
described in Section 2.5.1. of <xref target="RFC4291"/>. </t>
</section>
<section title="Routing Considerations">
<t> ORCHIDs are designed to serve as location independent
endpoint-identifiers rather than IP-layer locators. Therefore,
routers MAY be configured not to forward any packets containing an
ORCHID as a source or a destination address. If the destination
address is an ORCHID but the source address is a valid unicast source
address, routers MAY be configured to generate an ICMP Destination
Unreachable, Administratively Prohibited message. </t>
<t> Due to the experimental nature of ORCHIDs, router software MUST
NOT include any special handling code for ORCHIDs. In other words,
the non-routability property of ORCHIDs, if implemented, MUST be
implemented via configuration and NOT by hardwired software code.
At this time, it is RECOMMENDED that the default router
configuration not handle ORCHIDs in any special way. In other
words, there is no need to touch existing or new routers due to this
experiment. If such a reason should later appear, for example, due to
a faulty implementation leaking ORCHIDs to the IP layer, the prefix
can be and should be blocked by a simple configuration rule. </t>
<section title="Overlay Routing">
<t> As mentioned multiple times, ORCHIDs are designed to be
non-routable at the IP layer. However, there are multiple ongoing
research efforts for creating various overlay routing and
resolution mechanisms for flat identifiers. For example, <xref
target="Hi3">the Host Identity Indirection Infrastructure
(Hi3)</xref> and <xref
target="NodeID">Node
Identity Internetworking Architecture (NodeID)</xref> proposals, outline ways for using a Distributed Hash
Table to forward HIP packets based on the Host Identity Tag.</t>
<t> What is common to the various research proposals is that they
create a new kind of resolution or routing infrastructure on
top of the existing Internet routing structure. In practical
terms, they allow delivery of packets based on flat, non-routable
identifiers, utilising information stored in a distributed
database. Usually, the database used is based on Distributed Hash
Tables. This effectively creates a new routing network on top
of the existing IP-based routing network, capable of routing
packets that are not addressed by IP addresses but some other kind
of identifiers.</t>
<t> Typical benefits from overlay routing include location
independence, more scalable multicast, anycast, and multihoming
support than in IP, and better DoS resistance than in the vanilla
Internet. The main drawback is typically an order of magnitude of
slower performance, caused by an easily largish number of extra
look-up or forwarding steps needed. Consequently, in most
practical cases, the overlay routing system is used only during
initial protocol state set-up (cf. TCP handshake), after which the
communicating endpoints exchange packets directly with IP,
bypassing the overlay network.</t>
<t> The net result of the typical overlay routing approaches is a
communication service whose basic functionality is comparable to
that provided by classical IP but provides considerably
better resilience that vanilla IP in dynamic networking
environments. Some experiments also introduce additional
functionality, such as enhanced security or ability to effectively
route through several IP addressing domains.</t>
<t> The authors expect ORCHIDs to become fully routable, via one
or more overlay systems, before the end of the experiment. </t>
</section>
</section>
<section anchor="sec-API-issues" title="Collision Considerations">
<!--<section anchor="sec-API-issues" title="API, ULP and Related
Considerations">-->
<t> As noted above, the aim is that ORCHIDs are globally unique in a
statistical sense. That is, given the ORCHID referring to a given
entity, the probability of the same ORCHID being used to refer to
another entity elsewhere in the Internet must be sufficiently low so
that it can be ignored for most practical purposes. We believe that
the presented design meets this goal; see <xref target="sec-design"
/>.</t>
<t>Consider next the very rare case that some ORCHID happens to
refer to two different entities at the same time, at two different
locations in the Internet. Even in this case, the probability of this
fact becoming visible (and therefore a matter of consideration) at
any single location in the Internet is negligible. For the vast
majority of cases, the two simultaneous uses of the ORCHID will never
cross each other. However, while rare, such collisions are still
possible. This section gives reasonable guidelines on how to
mitigate the consequences in the case that such a collision happens. </t>
<t> As mentioned above, ORCHIDs are expected to be used at the
legacy IPv6 APIs between consenting hosts. The context ID is
intended to differentiate between the various experiments, or
contexts, sharing the ORCHID namespace. However, the context ID is
not present in the ORCHID itself, but only in front of the input
bitstring as an input to the hash function. While this may lead to
certain implementation-related complications, we believe that the
trade-off of allowing the hash result part of an ORCHID being longer
more than pays off the cost. </t>
<t> Because ORCHIDs are not routable at the IP layer, in order
to send packets using ORCHIDs at the API level, the sending host
must have additional overlay state within the stack to
determine which parameters (e.g., what locators) to use in the outgoing
packet. An underlying assumption here, and a matter of fact in the
proposals that the authors are aware of, is that there is an overlay
protocol for setting up and maintaining this additional state. It is
assumed that the state-set-up protocol carries the input bitstring,
and that the resulting ORCHID-related state in the stack can be
associated back with the appropriate context and state-set-up
protocol. </t>
<!--
<t>
In some cases hosts may receive ORCHIDs without having an
appropriate additional state in the stack. In such cases the
API or ULP operations SHOULD fail, with an implementation dependent
error code.
</t>
-->
<t> Even though ORCHID collisions are expected to be extremely rare,
two kinds of collisions may still happen. First, it is possible that
two different input bitstrings within the same context may map to
the same ORCHID. In this case, the state-set-up mechanism is
expected to resolve the conflict, for example, by indicating to the
peer that the ORCHID in question is already in use.</t>
<t> A second type of collision may happen if two input
bitstrings, used in different usage contexts, map to the same
ORCHID. In this case, the main confusion is about which context to
use. In order to prevent these types of collisions, it is
RECOMMENDED that implementations that simultaneously support
multiple different contexts maintain a node-wide unified database of
known ORCHIDs, and indicate a conflict if any of the mechanisms
attempt to register an ORCHID that is already in use. For example, if
a given ORCHID is already being used as a HIT in HIP, it cannot
simultaneously be used as a TMI in Mobile IP. Instead, if Mobile IP
attempts to use the ORCHID, it will be notified (by the kernel) that
the ORCHID in question is already in use. </t>
<!--
<t>
According to the current understanding of the authors, it may
not be possible to avoid all collisions. For example, an
application level protocol may transfer a ORCHID to a new host
before the state-set-up protocol has a chance to set up the
needed additional state and detect a possible ORCHID collision.
If there is already state associated
with the given ORCHID, the host may interpret its semantics
wrongly. This is considered acceptable given the expected
rarity of the situation and the experimental nature of the name
space.
</t>
-->
</section>
<section anchor="sec-design" title="Design Choices">
<t>
The design of this namespace faces two competing forces:
<t></t>
<list style="symbols">
<t>As many bits as possible should be preserved for the hash
result.</t>
<t>It should be possible to share the namespace
between multiple mechanisms.</t>
</list>
</t>
<t>
The desire to have a long hash result requires that the prefix be
as short as possible, and use few (if any) bits for
additional encoding. The present design takes this desire to
the maximum: all the bits beyond the prefix and the ORCHID generation algorithm identifier are used as hash
output. This leaves no bits in the ORCHID itself available for
identifying the context, however the 4 bits used to encode the ORCHID generation algorithm identifier provides cryptographich agility with respect to the hash function in use for a given context; see
<xref target="sec-security" />.
</t>
<t>
The desire to allow multiple mechanisms to share the namespace
has been resolved by including the context identifier in the
hash-function input. While this does not allow the mechanism to
be directly inferred from a ORCHID, it allows one to verify that a
given input bitstring and ORCHID belong to a given context, with
high-probability; but also see <xref target="sec-security" />.
</t>
</section>
<section anchor="sec-security" title="Security Considerations">
<t> ORCHIDs are designed to be securely bound to the Context ID
and the bitstring used as the input parameters during
their generation. To provide this property, the ORCHID generation
algorithm relies on the second-preimage resistance (a.k.a. one-way)
property of the hash function used in the generation <xref
target="RFC4270"/>. To have this property and to avoid collisions,
it is important that the allocated prefix is as short as possible,
leaving as many bits as possible for the hash output. </t>
<t> For a given Context ID, all mechanisms using ORCHIDs MUST use
exactly the same mechanism for generating an ORCHID from the input
bitstring. Allowing different mechanisms, without explicitly encoding the
mechanism in the Context ID or the ORCHID itself, would allow
so-called bidding-down attacks. That is, if multiple different
hash functions were allowed to construct ORCHIDs valid for the same Context ID,
and if one of the hash functions became insecure, that would allow attacks
against even those ORCHIDs valid for the same Context ID that had
been constructed using the other, still secure hash functions. </t>
<t> An identifier for the hash function to be used for the ORCHID generation is encoded in the ORCHID itself, while the semantic for the values taken by this identifier are defined separately for each
Context ID. Therefore, the present design allows to use different hash functions to be used per given
Context ID for constructing ORCHIDs from input bitstrings. If more secure hash functions are later needed, newer values for the ORCHID generation algorithm can be defined for the given Context ID. </t>
<t> In order to preserve a low enough probability of collisions (see
<xref target="sec-API-issues" />), each method MUST utilize a
mechanism that makes sure that the distinct input bitstrings are
either unique or statistically unique within that context. There are
several possible methods to ensure this; for example, one can include
into the input bitstring a globally maintained counter value, a
pseudo-random number of sufficient entropy (minimum 96 bits), or a
randomly generated public cryptographic key.
The Context ID makes sure that input bitstrings from different
contexts never overlap. These together make sure that the probability
of collisions is determined only by the probability of natural
collisions in the hash space and is not increased by a possibility of
colliding input bitstrings. </t>
</section>
<section anchor="sec-IANA" title="IANA Considerations">
<t>
Because the updated ORCHIDv2 format is not backward compatible with
the earlier one, IANA is requested to allocate a new 28-bit prefix out of the IANA IPv6 Special Purpose Address Block, namely
2001:0000::/23, as per <xref target="RFC4773"/>. The prefix
that was temporarily allocated for the experimental ORCHID is to
be returned to IANA in 2014 <xref target="RFC4843"/>.
</t>
<t> The Context Identifier (or Context ID) is a randomly generated
value defining the usage context of an ORCHID and the hash function to
be used for generation of ORCHIDs in this context. This document defines
no specific value. The Context ID shares the name
space introduced for CGA Type Tags. Hence, defining new values follows the rules of Section 8 of <xref target="RFC3972" />, i.e., First Come First Served.
</t>
</section>
<section title="Contributors">
<t>
Pekka Nikander (pekka.nikander@nomadiclab.com) co-authored an earlier, experimental version of this specification <xref target="RFC4843"/>.
</t>
</section>
<section title="Acknowledgments">
<t> Special thanks to Geoff Huston for his sharp but constructive
critique during the development of this memo. Tom Henderson helped to
clarify a number of issues. This document has also been improved by reviews, comments,
and discussions originating from the IPv6,
Internet Area, and IETF communities.</t>
</section>
<!--
<section title="Version history">
<section title="-00 to -01">
<t> The name Keyed Hash Identifier (KHI) was replaced with Overlay
Routable Cryptographic Hash Identifier (ORCHID). However, the
draft name was not changed.</t>
<t> More text added to explain the rationale behind the proposed
allocation.</t>
<t> Text changed to emphasise that while ORCHIDs are expected to
be non-routable at the IP-layer, they are expected to become fully
routable and/or resolvable at some upper, overlay layer, thereby
making their basic semantics fully compatible with IPv6 addresses.
</t>
<t> Removed the proposed expiration date. If such an expiration
date is needed, it can be added later during the discussions.</t>
</section>
</section>
-->
</middle>
<back>
<references title="Normative references">
&RFC2119;
&RFC3972;
<!-- <reference anchor="I-D.irtf-cfrg-sha1-ime">
<front>
<title>SHA1-IME: A SHA-1 Variant with Provably Good Message
Expansion Code</title>
<author initials="U." surname="Blumenthal"
fullname="Uri Blumenthal">
<organization>Intel</organization>
</author>
<author initials="C.S." surname="Jutla">
<organization>IBM</organization>
</author>
<author initials="A.C." surname="Patthak">
<organization>UT Austin</organization>
</author>
<date year="2005" month="November" />
</front>
</reference>-->
</references>
<references title="Informative references">
<!-- &RFC3587; -->
<?rfc linefile="685:/tmp/CGI51128.1"?> -->
<?rfc linefile="1:http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-hip-base.xml"?>
&I-D.ietf-hip-rfc5201-bis;
<reference anchor='PRIVACYTEXT'>
<front>
<title>A Simple Privacy Extension for Mobile IPv6</title>
<author initials='F' surname='Dupont' fullname='Francis Dupont'>
<organization />
</author>
<date month='July' day='20' year='2006' />
<abstract><t>This draft presents a simple privacy extension for Mobile
IPv6 that prevents eavesdroppers from identifying the packets sent or
received from a particular mobile node. This extension also allows a
mobile node to hide its identity from correspondent nodes when the
mobile node initiates the communication.</t></abstract>
</front>
<seriesInfo name='Work in' value='Progress' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-dupont-mip6-privacyext-04.txt' />
</reference>
&RFC1918;
&RFC3174;
&RFC4270;
&RFC4291;
&RFC4773;
&RFC4843;
<reference anchor="Hi3">
<front>
<title> Host Identity Indirection Infrastructure (Hi3)</title>
<author initials="P." surname="Nikander">
<organization>Ericsson Research</organization>
</author>
<author initials="J." surname="Arkko">
<organization>Ericsson Research</organization>
</author>
<author initials="B." surname="Ohlman">
<organization>Ericsson Research</organization>
</author>
<date year="2004" month="November" />
</front>
</reference>
<reference anchor="NodeID">
<front>
<title> A Node Identity Internetworking Architecture (NodeID)</title>
<author initials="B." surname="Ahlgren">
<organization></organization>
</author>
<author initials="J." surname="Arkko">
<organization></organization>
</author>
<author initials="L." surname="Eggert">
<organization></organization>
</author>
<author initials="J." surname="Rajahalme">
<organization></organization>
</author>
<date year="2006" month="April" />
</front>
</reference>
</references>
<section title="Changes from RFC 4843">
<list style="symbols">
<t>
Updated HIP references to revised HIP specifications.
</t>
<t>
The Overlay Routable Cryptographic Hash Identifiers originally
defined in <xref target="RFC4843"/> lacked a mechanism for cryptographic algorithm agility. The updated ORCHID format specified in this document removes this limitation by encoding in the identifier itself an index to the suite
of cryptographic algorithms in use.
</t>
</list>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 20:56:47 |