draft-ietf-hip-rfc4843-bis-01.txt   draft-ietf-hip-rfc4843-bis-02.txt 
Network Working Group J. Laganier Network Working Group J. Laganier
Internet-Draft Juniper Networks Internet-Draft Juniper Networks
Obsoletes: 4843 (if approved) F. Dupont Obsoletes: 4843 (if approved) F. Dupont
Intended status: Standards Track ISC Intended status: Standards Track Internet Systems Consortium
Expires: September 15, 2011 March 14, 2011 Expires: March 23, 2013 September 19, 2012
An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers
(ORCHID) Version 2 (ORCHIDv2)
draft-ietf-hip-rfc4843-bis-01 draft-ietf-hip-rfc4843-bis-02
Abstract Abstract
This document introduces Overlay Routable Cryptographic Hash This document specifies an updated Overlay Routable Cryptographich
Identifiers (ORCHID) as a new, experimental class of IPv6-address- Hash Identifiers format that obsoletes the earlier format defined in
like identifiers. These identifiers are intended to be used as [RFC4843]. These identifiers are intended to be used as endpoint
endpoint identifiers at applications and Application Programming identifiers at applications and Application Programming Interfaces
Interfaces (API) and not as identifiers for network location at the (API) and not as identifiers for network location at the IP layer,
IP layer, i.e., locators. They are designed to appear as application i.e., locators. They are designed to appear as application layer
layer entities and at the existing IPv6 APIs, but they should not entities and at the existing IPv6 APIs, but they should not appear in
appear in actual IPv6 headers. To make them more like vanilla IPv6 actual IPv6 headers. To make them more like vanilla IPv6 addresses,
addresses, they are expected to be routable at an overlay level. they are expected to be routable at an overlay level. Consequently,
Consequently, while they are considered non-routable addresses from while they are considered non-routable addresses from the IPv6 layer
the IPv6 layer point-of-view, all existing IPv6 applications are point-of-view, all existing IPv6 applications are expected to be able
expected to be able to use them in a manner compatible with current to use them in a manner compatible with current IPv6 addresses.
IPv6 addresses.
This document requests IANA to allocate a temporary prefix out of the The Overlay Routable Cryptographic Hash Identifiers originally
IPv6 addressing space for Overlay Routable Cryptographic Hash defined in [RFC4843] lacked a mechanism for cryptographic algorithm
Identifiers. By default, the prefix will be returned to IANA in agility. The updated ORCHID format specified in this document
2014, with continued use requiring IETF consensus. removes this limitation by encoding in the identifier itself an index
to the suite of cryptographic algorithms in use.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 15, 2011. This Internet-Draft will expire on March 23, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 32 skipping to change at page 2, line 32
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Rationale and Intent . . . . . . . . . . . . . . . . . . . 3 1.1. Rationale and Intent . . . . . . . . . . . . . . . . . . . 3
1.2. ORCHID Properties . . . . . . . . . . . . . . . . . . . . 4 1.2. ORCHID Properties . . . . . . . . . . . . . . . . . . . . 4
1.3. Expected use of ORCHIDs . . . . . . . . . . . . . . . . . 5 1.3. Expected use of ORCHIDs . . . . . . . . . . . . . . . . . 5
1.4. Action Plan . . . . . . . . . . . . . . . . . . . . . . . 5 1.4. Action Plan . . . . . . . . . . . . . . . . . . . . . . . 5
1.5. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 1.5. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
2. Cryptographic Hash Identifier Construction . . . . . . . . . . 5 2. Cryptographic Hash Identifier Construction . . . . . . . . . . 5
3. Routing Considerations . . . . . . . . . . . . . . . . . . . . 7 3. Routing Considerations . . . . . . . . . . . . . . . . . . . . 7
3.1. Overlay Routing . . . . . . . . . . . . . . . . . . . . . 7 3.1. Overlay Routing . . . . . . . . . . . . . . . . . . . . . 7
4. Collision Considerations . . . . . . . . . . . . . . . . . . . 8 4. Collision Considerations . . . . . . . . . . . . . . . . . . . 8
5. Design Choices . . . . . . . . . . . . . . . . . . . . . . . . 9 5. Design Choices . . . . . . . . . . . . . . . . . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 12 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 12
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
10.1. Normative references . . . . . . . . . . . . . . . . . . . 12 10.1. Normative references . . . . . . . . . . . . . . . . . . . 12
10.2. Informative references . . . . . . . . . . . . . . . . . . 12 10.2. Informative references . . . . . . . . . . . . . . . . . . 12
Appendix A. Changes from RFC 4843 . . . . . . . . . . . . . . . . 13 Appendix A. Changes from RFC 4843 . . . . . . . . . . . . . . . . 13
1. Introduction 1. Introduction
skipping to change at page 4, line 27 skipping to change at page 4, line 27
experiments with minimum user effort. experiments with minimum user effort.
For example, there already exists, at the time of this writing, HIP For example, there already exists, at the time of this writing, HIP
implementations that run fully in user space, using the operating implementations that run fully in user space, using the operating
system to divert a certain part of the IPv6 address space to a user system to divert a certain part of the IPv6 address space to a user
level daemon for HIP processing. In practical terms, these level daemon for HIP processing. In practical terms, these
implementations are already using a certain IPv6 prefix for implementations are already using a certain IPv6 prefix for
differentiating HIP identifiers from IPv6 addresses, allowing them differentiating HIP identifiers from IPv6 addresses, allowing them
both to be used by the existing applications via the existing APIs. both to be used by the existing applications via the existing APIs.
This document argues for allocating an experimental prefix for such The Overlay Routable Cryptographic Hash Identifiers originally
purposes, thereby paving the way for large-scale experiments with defined in [RFC4843] lacked a mechanism for cryptographic algorithm
cryptographic identifiers without the dangers caused by address-space agility. The updated ORCHID format specified in this document
hijacking. removes this limitation by encoding in the identifier itself an index
to the suite of cryptographic algorithms in use.
Becase the updated ORCHID format is not backward compatible with the
earlier one, IANA is requested to allocate a new prefix out of the
IPv6 addressing space. The prefix that was temporarily allocated for
the experimental ORCHID is to be returned to IANA in 2014 [RFC4843].
1.2. ORCHID Properties 1.2. ORCHID Properties
ORCHIDs are designed to have the following properties: ORCHIDs are designed to have the following properties:
o Statistical uniqueness; also see Section 4 o Statistical uniqueness; also see Section 4
o Secure binding to the input parameters used in their generation o Secure binding to the input parameters used in their generation
(i.e., the context identifier and a bitstring). (i.e., the context identifier and a bitstring).
skipping to change at page 5, line 22 skipping to change at page 5, line 29
Examples of identifiers and protocols that are expected to adopt the Examples of identifiers and protocols that are expected to adopt the
ORCHID format include Host Identity Tags (HIT) in the Host Identity ORCHID format include Host Identity Tags (HIT) in the Host Identity
Protocol [I-D.ietf-hip-rfc5201-bis] and the Temporary Mobile Protocol [I-D.ietf-hip-rfc5201-bis] and the Temporary Mobile
Identifiers (TMI) in the Simple Privacy Extension for Mobile IPv6 Identifiers (TMI) in the Simple Privacy Extension for Mobile IPv6
[PRIVACYTEXT]. The format is designed to be extensible to allow [PRIVACYTEXT]. The format is designed to be extensible to allow
other experimental proposals to share the same namespace. other experimental proposals to share the same namespace.
1.4. Action Plan 1.4. Action Plan
This document requests IANA to allocate an experimental prefix out of This document requests IANA to allocate a prefix out of the IPv6
the IPv6 addressing space for Overlay Routable Cryptographic Hash addressing space for Overlay Routable Cryptographic Hash Identifiers.
Identifiers.
1.5. Terminology 1.5. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
2. Cryptographic Hash Identifier Construction 2. Cryptographic Hash Identifier Construction
An ORCHID is generated using the algorithm below. The algorithm An ORCHID is generated using the ORCHID Generation Algorithm (OGA)
takes a bitstring and a context identifier as input and produces an below. The algorithm takes a bitstring and a context identifier as
ORCHID as output. 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).
Input := any bitstring Input := any bitstring
Hash Input := Context ID | Input OGA ID := 4-bits Orchid Generation Algorithm identifier
Hash := Hash_function( Hash Input ) Hash Input := Context ID | Input
ORCHID := Prefix | Encode_100( Hash ) Hash := Hash_function( Hash Input )
ORCHID := Prefix | Encode_96( Hash )
where: where:
| : Denotes concatenation of bitstrings | : Denotes concatenation of bitstrings
Input : A bitstring that is unique or statistically unique Input : A bitstring that is unique or statistically unique
within a given context. The bitstring is intended within a given context. The bitstring is intended
to be associated with the to-be-created ORCHID in to be associated with the to-be-created ORCHID in
the given context. the given context.
Context ID : A randomly generated value defining the expected Context ID : A randomly generated value defining the expected
usage context for the particular ORCHID and the usage context for the particular ORCHID and the
hash function to be used for generation of ORCHIDs hash function to be used for generation of ORCHIDs
in this context. These values are allocated out of in this context. These values are allocated out of
the namespace introduced for CGA Type Tags; see RFC the namespace introduced for CGA Type Tags; see RFC
3972 and 3972 and
http://www.iana.org/assignments/cga-message-types. http://www.iana.org/assignments/cga-message-types.
Hash_function : The one-way hash function (i.e., hash function with OGA ID : A 4-bit long identifier for the Hash_function
pre-image resistance and second pre-image in use within the specific usage context.
resistance) to be used according to the document
defining the context usage identified by the
Context ID. For example, the current version of
the HIP specification defines SHA1 [RFC3174] as
the hash function to be used to generate ORCHIDs
used in the HIP protocol [I-D.ietf-hip-rfc5201-bis].
Encode_100( ) : An extraction function in which output is obtained Hash_function : The one-way hash function (i.e., hash function
by extracting the middle 100-bit-long bitstring with pre-image resistance and second pre-image
from the argument bitstring. 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].
Prefix : A constant 28-bit-long bitstring value Encode_96( ) : An extraction function in which output is obtained
(2001:10::/28). 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 ?).
To form an ORCHID, two pieces of input data are needed. The first 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 piece can be any bitstring, but is typically expected to contain a
public cryptographic key and some other data. The second piece is a public cryptographic key and some other data. The second piece is a
context identifier, which is a 128-bit-long datum, allocated as context identifier, which is a 128-bit-long datum, allocated as
specified in Section 7. Each specific experiment (such as HIP HITs specified in Section 7. Each specific experiment (such as HIP HITs
or MIP6 TMIs) is expected to allocate their own, specific context or MIP6 TMIs) is expected to allocate their own, specific context
identifier. identifier.
The input bitstring and context identifier are concatenated to form The input bitstring and context identifier are concatenated to form
an input datum, which is then fed to the cryptographic hash function an input datum, which is then fed to the cryptographic hash function
to be used according to the document defining the context usage to be used for the value of the OGA identifier according to the
identified by the Context ID. The result of the hash function is document defining the context usage identified by the Context ID.
processed by an encoding function, resulting in a 100-bit-long value. The result of the hash function is processed by an encoding function,
This value is prepended with the 28-bit ORCHID prefix. The result is resulting in a 96-bit-long value. This value is prepended with the
the ORCHID, a 128-bit-long bitstring that can be used at the IPv6 concatenation of the 28-bit ORCHID prefix and the 4-bit OGA ID. The
APIs in hosts participating to the particular experiment. result is the ORCHID, a 128-bit-long bitstring that can be used at
the IPv6 APIs in hosts participating to the particular experiment.
The ORCHID prefix is allocated under the IPv6 global unicast address The ORCHID prefix is allocated under the IPv6 global unicast address
block. Hence, ORCHIDs are indistinguishable from IPv6 global unicast block. Hence, ORCHIDs are indistinguishable from IPv6 global unicast
addresses. However, it should be noted that ORCHIDs do not conform addresses. However, it should be noted that ORCHIDs do not conform
with the IPv6 global unicast address format defined in Section 2.5.4 with the IPv6 global unicast address format defined in Section 2.5.4
of [RFC4291] since they do not have a 64-bit Interface ID formatted of [RFC4291] since they do not have a 64-bit Interface ID formatted
as described in Section 2.5.1. of [RFC4291]. as described in Section 2.5.1. of [RFC4291].
3. Routing Considerations 3. Routing Considerations
skipping to change at page 10, line 10 skipping to change at page 10, line 16
The design of this namespace faces two competing forces: The design of this namespace faces two competing forces:
o As many bits as possible should be preserved for the hash result. o As many bits as possible should be preserved for the hash result.
o It should be possible to share the namespace between multiple o It should be possible to share the namespace between multiple
mechanisms. mechanisms.
The desire to have a long hash result requires that the prefix be as 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. short as possible, and use few (if any) bits for additional encoding.
The present design takes this desire to the maxim: all the bits The present design takes this desire to the maximum: all the bits
beyond the prefix are used as hash output. This leaves no bits in beyond the prefix and the ORCHID generation algorithm identifier are
the ORCHID itself available for identifying the context. used as hash output. This leaves no bits in the ORCHID itself
Additionally, due to security considerations, the present design available for identifying the context, however the 4 bits used to
REQUIRES that the hash function used in constructing ORCHIDs be encode the ORCHID generation algorithm identifier provides
constant; see Section 6. cryptographich agility with respect to the hash function in use for a
given context; see Section 6.
The authors explicitly considered including a hash-extension
mechanism, similar to the one in CGA [RFC3972], but decided to leave
it out. There were two reasons: desire for simplicity, and the
somewhat unclear IPR situation around the hash-extension mechanism.
If there is a future revision of this document, we strongly advise
the future authors to reconsider the decision.
The desire to allow multiple mechanisms to share the namespace has The desire to allow multiple mechanisms to share the namespace has
been resolved by including the context identifier in the hash- been resolved by including the context identifier in the hash-
function input. While this does not allow the mechanism to be function input. While this does not allow the mechanism to be
directly inferred from a ORCHID, it allows one to verify that a given directly inferred from a ORCHID, it allows one to verify that a given
input bitstring and ORCHID belong to a given context, with high- input bitstring and ORCHID belong to a given context, with high-
probability; but also see Section 6. probability; but also see Section 6.
6. Security Considerations 6. Security Considerations
skipping to change at page 11, line 5 skipping to change at page 11, line 5
the same mechanism for generating an ORCHID from the input bitstring. the same mechanism for generating an ORCHID from the input bitstring.
Allowing different mechanisms, without explicitly encoding the Allowing different mechanisms, without explicitly encoding the
mechanism in the Context ID or the ORCHID itself, would allow so- mechanism in the Context ID or the ORCHID itself, would allow so-
called bidding-down attacks. That is, if multiple different hash called bidding-down attacks. That is, if multiple different hash
functions were allowed to construct ORCHIDs valid for the same functions were allowed to construct ORCHIDs valid for the same
Context ID, and if one of the hash functions became insecure, that Context ID, and if one of the hash functions became insecure, that
would allow attacks against even those ORCHIDs valid for the same would allow attacks against even those ORCHIDs valid for the same
Context ID that had been constructed using the other, still secure Context ID that had been constructed using the other, still secure
hash functions. hash functions.
Due to the desire to keep the hash output value as long as possible, An identifier for the hash function to be used for the ORCHID
the hash function is not encoded in the ORCHID itself, but rather in generation is encoded in the ORCHID itself, while the semantic for
the Context ID. Therefore, the present design allows only one method the values taken by this identifier are defined separately for each
per given Context ID for constructing ORCHIDs from input bitstrings. Context ID. Therefore, the present design allows to use different
If other methods (perhaps using more secure hash functions) are later hash functions to be used per given Context ID for constructing
needed, they MUST use a different Context ID. Consequently, the ORCHIDs from input bitstrings. If more secure hash functions are
suggested method to react to the hash result becoming too short, due later needed, newer values for the ORCHID generation algorithm can be
to increased computational power, or to the used hash function defined for the given Context ID.
becoming insecure due to advances in cryptology, is to allocate a new
Context ID and cease to use the present one.
As of today, SHA1 [RFC3174] is considered as satisfying the second-
preimage resistance requirement. The current version of the HIP
specification defines SHA1 [RFC3174] as the hash function to be used
to generate ORCHIDs for the Context ID used by the HIP protocol
[I-D.ietf-hip-rfc5201-bis].
In order to preserve a low enough probability of collisions (see In order to preserve a low enough probability of collisions (see
Section 4), each method MUST utilize a mechanism that makes sure that Section 4), each method MUST utilize a mechanism that makes sure that
the distinct input bitstrings are either unique or statistically the distinct input bitstrings are either unique or statistically
unique within that context. There are several possible methods to unique within that context. There are several possible methods to
ensure this; for example, one can include into the input bitstring a ensure this; for example, one can include into the input bitstring a
globally maintained counter value, a pseudo-random number of globally maintained counter value, a pseudo-random number of
sufficient entropy (minimum 100 bits), or a randomly generated public sufficient entropy (minimum 96 bits), or a randomly generated public
cryptographic key. The Context ID makes sure that input bitstrings cryptographic key. The Context ID makes sure that input bitstrings
from different contexts never overlap. These together make sure that from different contexts never overlap. These together make sure that
the probability of collisions is determined only by the probability the probability of collisions is determined only by the probability
of natural collisions in the hash space and is not increased by a of natural collisions in the hash space and is not increased by a
possibility of colliding input bitstrings. possibility of colliding input bitstrings.
7. IANA Considerations 7. IANA Considerations
IANA allocated a temporary non-routable 28-bit prefix from the IPv6 IANA allocated a temporary non-routable 28-bit prefix from the IPv6
address space. By default, the prefix will be returned to IANA in address space. By default, the prefix will be returned to IANA in
2014, continued use requiring IETF consensus. As per [RFC4773], the 2014, continued use requiring IETF consensus. As per [RFC4773], the
28-bit prefix was drawn out of the IANA Special Purpose Address 28-bit prefix was drawn out of the IANA Special Purpose Address
Block, namely 2001:0000::/23, in support of the experimental usage Block, namely 2001:0000::/23, in support of the experimental usage
described in this document. IANA has updated the IPv6 Special described in this document. IANA has updated the IPv6 Special
Purpose Address Registry. Purpose Address Registry.
During the discussions related to this document, it was suggested Becase the updated ORCHIDv2 format is not backward compatible with
that other identifier spaces may be allocated from this block later. the earlier one, IANA is requested to allocate a new prefix out of
However, this document does not define such a policy or allocations. the IPv6 addressing space. The prefix that was temporarily allocated
for the experimental ORCHID is to be returned to IANA in 2014
[RFC4843].
The Context Identifier (or Context ID) is a randomly generated value The Context Identifier (or Context ID) is a randomly generated value
defining the usage context of an ORCHID and the hash function to be defining the usage context of an ORCHID and the hash function to be
used for generation of ORCHIDs in this context. This document used for generation of ORCHIDs in this context. This document
defines no specific value. defines no specific value. The Context ID shares the name space
introduced for CGA Type Tags. Hence, defining new values follows the
We propose sharing the name space introduced for CGA Type Tags. rules of Section 8 of [RFC3972], i.e., First Come First Served.
Hence, defining new values would follow the rules of Section 8 of
[RFC3972], i.e., on a First Come First Served basis.
8. Contributors 8. Contributors
Pekka Nikander (pekka.nikander@nomadiclab.com) co-authored an Pekka Nikander (pekka.nikander@nomadiclab.com) co-authored an
earlier, experimental version of this specification [RFC4843]. earlier, experimental version of this specification [RFC4843].
9. Acknowledgments 9. Acknowledgments
Special thanks to Geoff Huston for his sharp but constructive Special thanks to Geoff Huston for his sharp but constructive
critique during the development of this memo. Tom Henderson helped critique during the development of this memo. Tom Henderson helped
skipping to change at page 12, line 42 skipping to change at page 12, line 38
10.2. Informative references 10.2. Informative references
[Hi3] Nikander, P., Arkko, J., and B. Ohlman, [Hi3] Nikander, P., Arkko, J., and B. Ohlman,
"Host Identity Indirection Infrastructure "Host Identity Indirection Infrastructure
(Hi3)", November 2004. (Hi3)", November 2004.
[I-D.ietf-hip-rfc5201-bis] Moskowitz, R., Heer, T., Jokela, P., and [I-D.ietf-hip-rfc5201-bis] Moskowitz, R., Heer, T., Jokela, P., and
T. Henderson, "Host Identity Protocol T. Henderson, "Host Identity Protocol
Version 2 (HIPv2)", Version 2 (HIPv2)",
draft-ietf-hip-rfc5201-bis-05 (work in draft-ietf-hip-rfc5201-bis-09 (work in
progress), March 2011. progress), July 2012.
[NodeID] Ahlgren, B., Arkko, J., Eggert, L., and [NodeID] Ahlgren, B., Arkko, J., Eggert, L., and
J. Rajahalme, "A Node Identity J. Rajahalme, "A Node Identity
Internetworking Architecture (NodeID)", Internetworking Architecture (NodeID)",
April 2006. April 2006.
[PRIVACYTEXT] Dupont, F., "A Simple Privacy Extension [PRIVACYTEXT] Dupont, F., "A Simple Privacy Extension
for Mobile IPv6", Work in Progress, for Mobile IPv6", Work in Progress,
July 2006. July 2006.
skipping to change at page 13, line 35 skipping to change at page 13, line 31
[RFC4843] Nikander, P., Laganier, J., and F. [RFC4843] Nikander, P., Laganier, J., and F.
Dupont, "An IPv6 Prefix for Overlay Dupont, "An IPv6 Prefix for Overlay
Routable Cryptographic Hash Identifiers Routable Cryptographic Hash Identifiers
(ORCHID)", RFC 4843, April 2007. (ORCHID)", RFC 4843, April 2007.
Appendix A. Changes from RFC 4843 Appendix A. Changes from RFC 4843
o Updated HIP references to revised HIP specifications. o Updated HIP references to revised HIP specifications.
o The Overlay Routable Cryptographic Hash Identifiers originally
defined in [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.
Authors' Addresses Authors' Addresses
Julien Laganier Julien Laganier
Juniper Networks Juniper Networks
1094 North Mathilda Avenue 1094 North Mathilda Avenue
Sunnyvale, CA 94089 Sunnyvale, CA 94089
USA USA
Phone: +1 408 936 0385 Phone: +1 408 936 0385
EMail: julien.ietf@gmail.com EMail: julien.ietf@gmail.com
skipping to change at page 13, line 45 skipping to change at page 14, line 4
Authors' Addresses Authors' Addresses
Julien Laganier Julien Laganier
Juniper Networks Juniper Networks
1094 North Mathilda Avenue 1094 North Mathilda Avenue
Sunnyvale, CA 94089 Sunnyvale, CA 94089
USA USA
Phone: +1 408 936 0385 Phone: +1 408 936 0385
EMail: julien.ietf@gmail.com EMail: julien.ietf@gmail.com
Francis Dupont Francis Dupont
ISC Internet Systems Consortium
EMail: Francis.Dupont@fdupont.fr EMail: fdupont@isc.org
 End of changes. 29 change blocks. 
112 lines changed or deleted 117 lines changed or added

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