draft-laganier-ipv6-khi-04.txt   draft-laganier-ipv6-khi-05.txt 
Network Working Group P. Nikander Network Working Group P. Nikander
Internet-Draft Ericsson Research Nomadic Lab Internet-Draft Ericsson Research Nomadic Lab
Expires: February 12, 2007 J. Laganier Expires: March 12, 2007 J. Laganier
DoCoMo Euro-Labs DoCoMo Euro-Labs
F. Dupont F. Dupont
CELAR CELAR
August 11, 2006 September 8, 2006
An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers
(ORCHID) (ORCHID)
draft-laganier-ipv6-khi-04 draft-laganier-ipv6-khi-05
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 38 skipping to change at page 1, line 38
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."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on February 12, 2007. This Internet-Draft will expire on March 12, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2006).
Abstract Abstract
This document introduces Overlay Routable Cryptographic Hash This document introduces Overlay Routable Cryptographic Hash
Identifiers (ORCHID) as a new, experimental class of IPv6-address- Identifiers (ORCHID) as a new, experimental class of IPv6-address-
like identifiers. These identifiers are intended to be used as end- like identifiers. These identifiers are intended to be used as end-
point identifiers at applications and APIs and not as identifiers for point identifiers at applications and Application Programming
network location at the IP layer, i.e., locators. They are designed Interfaces (API) and not as identifiers for network location at the
to appear as application layer entities and at the existing IPv6 IP layer, i.e., locators. They are designed to appear as application
APIs, but they should not appear in actual IPv6 headers. To make layer entities and at the existing IPv6 APIs, but they should not
them more like vanilla IPv6 addresses, they are expected to be appear in actual IPv6 headers. To make them more like vanilla IPv6
routable at an overlay level. Consequently, while they are addresses, they are expected to be routable at an overlay level.
considered as non-routable addresses from the IPv6 layer point of Consequently, while they are considered as non-routable addresses
view, all existing IPv6 applications are expected to be able to use from the IPv6 layer point of view, all existing IPv6 applications are
them in a manner compatible with current IPv6 addresses. expected to be able to use them in a manner compatible with current
IPv6 addresses.
This document requests IANA to allocate a temporary prefix out of the This document requests IANA to allocate a temporary prefix out of the
IPv6 addressing space for Overlay Routable Cryptographic Hash IPv6 addressing space for Overlay Routable Cryptographic Hash
Identifiers. Identifiers.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Rationale and intent . . . . . . . . . . . . . . . . . . . 3
1.2. ORCHID properties . . . . . . . . . . . . . . . . . . . . 4
1.3. Expected use of ORCHIDs . . . . . . . . . . . . . . . . . 5
1.4. Action plan . . . . . . . . . . . . . . . . . . . . . . . 5
1.5. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
2. Cryptographic Hash Identifier Construction . . . . . . . . . . 5
3. Routing Considerations . . . . . . . . . . . . . . . . . . . . 6
3.1. Overlay Routing . . . . . . . . . . . . . . . . . . . . . 7
4. Collision Considerations . . . . . . . . . . . . . . . . . . . 8
5. Design Choices . . . . . . . . . . . . . . . . . . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
9.1. Normative references . . . . . . . . . . . . . . . . . . . 12
9.2. Informative references . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
Intellectual Property and Copyright Statements . . . . . . . . . . 14
1. Introduction 1. Introduction
This document introduces Overlay Routable Cryptographic Hash This document introduces Overlay Routable Cryptographic Hash
Identifiers (ORCHID), a new class of IP-address-like identifiers. Identifiers (ORCHID), a new class of IP-address-like identifiers.
These identifiers are intended to be globally unique in a statistical These identifiers are intended to be globally unique in a statistical
sense (see Section 4), non-routable at the IP layer, and routable at sense (see Section 4), non-routable at the IP layer, and routable at
some overlay layer. The identifiers are securely bound, via a secure some overlay layer. The identifiers are securely bound, via a secure
hash function, to the concatenation of an input bitstring and a hash function, to the concatenation of an input bitstring and a
context tag. Typically, but not necessarily, the input bitstring context tag. Typically, but not necessarily, the input bitstring
will include a suitably encoded public cryptographic key. will include a suitably encoded public cryptographic key.
1.1. Rationale and intent 1.1. Rationale and intent
These identifiers are expected to be used at the existing IPv6 APIs These identifiers are expected to be used at the existing IPv6
and application protocols between consenting hosts. They may be Application Programming Interfaces (API) and application protocols
defined and used in different contexts, suitable for different between consenting hosts. They may be defined and used in different
overlay protocols. Examples of these include Host Identity Tags contexts, suitable for different overlay protocols. Examples of
(HIT) in the Host Identity Protocol (HIP) [I-D.ietf-hip-base] and these include Host Identity Tags (HIT) in the Host Identity Protocol
Temporary Mobile Identifiers (TMI) for Mobile IPv6 Privacy Extension (HIP) [I-D.ietf-hip-base] and Temporary Mobile Identifiers (TMI) for
[I-D.dupont-mip6-privacyext]. Mobile IPv6 Privacy Extension [I-D.dupont-mip6-privacyext].
As these identifiers are expected to be used alongside with IPv6 As these identifiers are expected to be used alongside with IPv6
addresses at both applications and APIs, co-ordination is desired to addresses at both applications and APIs, co-ordination is desired to
make sure that an ORCHID is not inappropriately taken for a vanilla make sure that an ORCHID is not inappropriately taken for a vanilla
IPv6 address and vice versa. In practice, allocation of a separate IPv6 address and vice versa. In practice, allocation of a separate
prefix for ORCHIDs seems to suffice, making them compatible with IPv6 prefix for ORCHIDs seems to suffice, making them compatible with IPv6
addresses at the upper layers while simultaneously making it trivial addresses at the upper layers while simultaneously making it trivial
to prevent their usage at the IP layer. to prevent their usage at the IP layer.
While being technically possible to use ORCHIDs between consenting While being technically possible to use ORCHIDs between consenting
skipping to change at page 10, line 17 skipping to change at page 11, line 17
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 bit strings. possibility of colliding input bit strings.
7. IANA Considerations 7. IANA Considerations
IANA is requested to allocate a temporary non-routable prefix from IANA is requested to allocate a temporary non-routable prefix from
the IPv6 address space. As per [I-D.huston-ipv6-iana-specials], the the IPv6 address space. As per [I-D.huston-ipv6-iana-specials], the
prefix shall be drawn out of the 2001:0000::/23 block in support of prefix shall be drawn out of the IANA Special Purpose Address Block,
the experimental usage described in this document. The allocation namely 2001:0000::/23, in support of the experimental usage described
will require updating in this document. The allocation will require updating the IANA IPv6
http://www.iana.org/assignments/ipv6-address-space Special Purpose Address Registry.
During the discussions related to this draft, it was suggested that During the discussions related to this draft, it was suggested that
other identifier spaces may be later allocated from this block. other identifier spaces may be later allocated from this block.
However, this document does not define such a policy or allocations. However, this document does not define such a policy or allocations.
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 a ORCHID. This document defines no defining the usage context of a ORCHID. This document defines no
specific value. specific value.
We propose sharing the name space introduced for CGA Type Tags. We propose sharing the name space introduced for CGA Type Tags.
Hence, defining new values would follow the rules of Section 8 of Hence, defining new values would follow the rules of Section 8 of
[RFC3972], i.e., on a First Come First Served basis. The policy will [RFC3972], i.e., on a First Come First Served basis. The policy will
require updating the policy for require updating the policy for assignment in the CGA Message Type
http://www.iana.org/assignments/cga-message-types name space.
8. Acknowledgments 8. Acknowledgments
Special thanks to Geoff Huston for his sharp but constructive critic Special thanks to Geoff Huston for his sharp but constructive critic
during the development of this memo. Tom Henderson helped to clarify during the development of this memo. Tom Henderson helped to clarify
a number of issues. a number of issues. This document has also been improved by reviews,
comments and discussions originating from the IPv6, Internet Area,
and IETF communities.
Julien Laganier is partly funded by Ambient Networks, a research Julien Laganier is partly funded by Ambient Networks, a research
project supported by the European Commission under its Sixth project supported by the European Commission under its Sixth
Framework Program. The views and conclusions contained herein are Framework Program. The views and conclusions contained herein are
those of the authors and should not be interpreted as necessarily those of the authors and should not be interpreted as necessarily
representing the official policies or endorsements, either expressed representing the official policies or endorsements, either expressed
or implied, of the Ambient Networks project or the European or implied, of the Ambient Networks project or the European
Commission. Commission.
9. References 9. References
 End of changes. 10 change blocks. 
27 lines changed or deleted 52 lines changed or added

This html diff was produced by rfcdiff 1.32. The latest version is available from http://www.levkowetz.com/ietf/tools/rfcdiff/