Skip to main content

An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers (ORCHID)
RFC 4843

Revision differences

Document history

Date Rev. By Action
2018-12-20
07 (System)
Received changes through RFC Editor sync (changed abstract to 'This document introduces Overlay Routable Cryptographic Hash Identifiers (ORCHID) as a new, experimental class of IPv6-address- …
Received changes through RFC Editor sync (changed abstract to 'This document introduces Overlay Routable Cryptographic Hash Identifiers (ORCHID) as a new, experimental class of IPv6-address- like identifiers. 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.

This document requests IANA to allocate a temporary prefix out of the IPv6 addressing space for Overlay Routable Cryptographic Hash Identifiers. By default, the prefix will be returned to IANA in 2014, with continued use requiring IETF consensus. This memo defines an Experimental Protocol for the Internet community.')
2015-10-14
07 (System) Notify list changed from Pekka.Nikander@ericsson.com,julien.ietf@laposte.net,Francis.Dupont@point6.net to (None)
2012-08-22
07 (System) post-migration administrative database adjustment to the No Record position for Cullen Jennings
2012-08-22
07 (System) post-migration administrative database adjustment to the Abstain position for Ted Hardie
2007-04-27
07 Amy Vezza State Changes to RFC Published from RFC Ed Queue by Amy Vezza
2007-04-27
07 Amy Vezza [Note]: 'RFC 4843' added by Amy Vezza
2007-04-26
07 (System) RFC published
2007-03-28
07 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2007-03-27
07 (System) IANA Action state changed to Waiting on RFC Editor from In Progress
2007-03-27
07 (System) IANA Action state changed to In Progress from Waiting on Authors
2007-03-26
07 (System) IANA Action state changed to Waiting on Authors from In Progress
2007-02-26
07 Amy Vezza State Changes to RFC Ed Queue from Approved-announcement sent by Amy Vezza
2007-02-22
07 (System) IANA Action state changed to In Progress
2007-02-21
07 Amy Vezza IESG state changed to Approved-announcement sent
2007-02-21
07 Amy Vezza IESG has approved the document
2007-02-21
07 Amy Vezza Closed "Approve" ballot
2007-02-21
07 Amy Vezza State Changes to Approved-announcement to be sent from IESG Evaluation::AD Followup by Amy Vezza
2007-02-14
07 (System) New version available: draft-laganier-ipv6-khi-07.txt
2007-02-13
07 (System) Sub state has been changed to AD Follow up from New Id Needed
2007-02-13
06 (System) New version available: draft-laganier-ipv6-khi-06.txt
2006-12-15
07 Amy Vezza State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation by Amy Vezza
2006-12-15
07 (System) Removed from agenda for telechat - 2006-12-14
2006-12-14
07 Ted Hardie [Ballot Position Update] Position for Ted Hardie has been changed to Abstain from Discuss by Ted Hardie
2006-12-14
07 Cullen Jennings [Ballot Position Update] Position for Cullen Jennings has been changed to Undefined from No Objection by Cullen Jennings
2006-12-13
07 Mark Townsley [Ballot Position Update] New position, No Objection, has been recorded by Mark Townsley
2006-12-08
07 Jari Arkko State Changes to IESG Evaluation from Waiting for AD Go-Ahead by Jari Arkko
2006-12-08
07 Jari Arkko Placed on agenda for telechat - 2006-12-14 by Jari Arkko
2006-12-08
07 Jari Arkko [Note]: 'Back on the agenda to review input from 2nd LC and decide next steps.' added by Jari Arkko
2006-11-30
07 Yoshiko Fong
IANA Additional Comment:

If you don't want it routed on the Internet, then it isn't clear 
that it should be allocated in 2000::/3.

Could any …
IANA Additional Comment:

If you don't want it routed on the Internet, then it isn't clear 
that it should be allocated in 2000::/3.

Could any of you clarify?
2006-11-29
07 Yoshiko Fong
IANA Last Call Comment:

Upon approval of this document, the IANA will make the following assignments
in the "IANA IPv6 Special Purpose Address Registry" registry …
IANA Last Call Comment:

Upon approval of this document, the IANA will make the following assignments
in the "IANA IPv6 Special Purpose Address Registry" registry located at
http://www.iana.org/assignments/iana-ipv6-special-registry

Date Termination Contact
Routing
Prefix Assignment Designated Date Purpose Details
Scope Referenc
----- ---------- ---------- ------------- ------- 
---- ---------
2001:001/28 ORCHID 2006/mm/dd 2011/12/31 Overlay non-
routable [RFC-laganier-ipv6-khi-05]

We understand the above to be the only IANA Action for
this document.
2006-11-24
07 (System) State has been changed to Waiting for AD Go-Ahead from In Last Call by system
2006-11-08
07 (System) Requested Last Call review by SECDIR
2006-10-27
07 Amy Vezza Last call sent
2006-10-27
07 Amy Vezza State Changes to In Last Call from Last Call Requested by Amy Vezza
2006-10-27
07 Jari Arkko Last Call was requested by Jari Arkko
2006-10-27
07 Jari Arkko State Changes to Last Call Requested from IESG Evaluation::AD Followup by Jari Arkko
2006-09-14
07 Amy Vezza State Changes to IESG Evaluation::AD Followup from IESG Evaluation by Amy Vezza
2006-09-14
07 Cullen Jennings [Ballot Position Update] Position for Cullen Jennings has been changed to No Objection from Discuss by Cullen Jennings
2006-09-14
07 Cullen Jennings
[Ballot comment]
It seems like 100 bits is far more than is needed for an experiment. If there is some analysis on this is the …
[Ballot comment]
It seems like 100 bits is far more than is needed for an experiment. If there is some analysis on this is the right size, I am glad to clear.

I did not understand the explanation I got about why a 100 was needed but it does not seem that allocating a /28 causes harm in this case so I have cleared on the basis it causes no harm.
2006-09-14
07 Russ Housley
[Ballot comment]
I would rather not be locked to SHA-1.  Can the following work?

  Input      :=  any bitstring
  Hash_Input :=  Context_ID …
[Ballot comment]
I would rather not be locked to SHA-1.  Can the following work?

  Input      :=  any bitstring
  Hash_Input :=  Context_ID | Hash_Alg_ID | Input
  Hash_Value :=  Hash( Hash_Input )
  ORCHID    :=  Prefix | Encode_n( Hash_Value )

  Where, Hash is the function identified by Hash_Alg_ID, and SHA-1 MUST
  be supported, and other hash functions MAY also be supported.
2006-09-14
07 Russ Housley [Ballot Position Update] New position, No Objection, has been recorded by Russ Housley
2006-09-14
07 Lisa Dusseault [Ballot Position Update] New position, No Objection, has been recorded by Lisa Dusseault
2006-09-14
07 Magnus Westerlund [Ballot Position Update] New position, No Objection, has been recorded by Magnus Westerlund
2006-09-14
07 Ross Callon [Ballot Position Update] New position, No Objection, has been recorded by Ross Callon
2006-09-13
07 David Kessens [Ballot Position Update] New position, No Objection, has been recorded by David Kessens
2006-09-13
07 Yoshiko Fong
IANA Last Call Comment:

IANA is NOT OKAY.

This draft asks for an IPv6 prefix allocation from IANA.
The draft requests an allocation from a …
IANA Last Call Comment:

IANA is NOT OKAY.

This draft asks for an IPv6 prefix allocation from IANA.
The draft requests an allocation from a prefix in 2001:0000::/23.
In a different draft (draft-huston-ipv6-iana-specials-01.txt)
this prefix is referred to as the "Special Purpose IANA Block."
However, the Huston draft has not yet advanced. The current draft, draft-laganier-ipv6-khi, makes use of an allocation policy that
is defined in the Huston draft.

Considering the currently published IPv6 Address Allocation and
Assignment Policy, there is no guidance or published policy
about 2001:0000::/23.

IANA believes that the Huston draft should be published before
we make the allocation requested in the Laganier draft.
2006-09-12
07 Ted Hardie
[Ballot discuss]
The document says:

  These identifiers are expected to be used at the existing IPv6
  Application Programming Interfaces (API) and application protocols …
[Ballot discuss]
The document says:

  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 Host Identity Protocol
  (HIP) [I-D.ietf-hip-base] and Temporary Mobile Identifiers (TMI) for
  Mobile IPv6 Privacy Extension [I-D.dupont-mip6-privacyext].

  As these identifiers are expected to be used alongside 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.

The document does not seem, however, to have adequately considered application
behavior or to explain the extent to which these should be considered as being
equivalent to the layers above.  Would these be used with the existing
v6 literal syntax for URIs, for example?  Would the issues raised in
http://bgp.potaroo.net/ietf/all-ids/draft-fenner-literal-zone-02.txt apply
here as well (that is, could a zone ID be present here, and what would it mean?)
Is it the presumption that these would be stored in AAAA records in the DNS,
or is there an expectation that a new RR would be used?

The "between consenting hosts" arguement is often used to justify changes
to behavior, but using it requires that non-consenting hosts be able to
recognize the offer and reject it appropriately.  Using the allocation
of a range to meet that test while claiming this will be used at the application
layer seems to imply that applications must recognize the special nature
of this prefix (and modify their behavior accordingly) if passed this prefix in
a URI or other application-layer pointer.  That seems like a big bet to make,
and one that this document has not yet justified.
2006-09-12
07 Ted Hardie
[Ballot discuss]
The document says:

  These identifiers are expected to be used at the existing IPv6
  Application Programming Interfaces (API) and application protocols …
[Ballot discuss]
The document says:

  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 Host Identity Protocol
  (HIP) [I-D.ietf-hip-base] and Temporary Mobile Identifiers (TMI) for
  Mobile IPv6 Privacy Extension [I-D.dupont-mip6-privacyext].

  As these identifiers are expected to be used alongside 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.

The document does not seem, however, to have adequately considered application
behavior or to explain the extent to which these should be considered as being
equivalent to the layers above.  Would these be used with the existing
v6 literal syntax for URIs, for example?  Would the issues raised in
http://bgp.potaroo.net/ietf/all-ids/draft-fenner-literal-zone-02.txt apply
here as well (that is, could a zone ID be present here, and what would it mean?)
Is it the presumption that these would be stored in AAAA records in the DNS,
or is there an expectation that a new RR would be used?

The "between consenting hosts" arguement is often used to justify changes
to behavior, but using it requires that non-consenting hosts be able to
recognize that the offer and reject it appropriately.  Using the allocation
of a range to meet that test while claiming this will be used at the application
layer seems to imply that applications must recognize the special nature
of this prefix and modify their behavior accordingly if passed this prefix in
a URI or other application-layer pointer.  That seems like a big bet to make,
and one that this document has not yet justified.
2006-09-12
07 Cullen Jennings
[Ballot discuss]
It seems like 100 bits is far more than is needed for an experiment. If there is some analysis on this is the …
[Ballot discuss]
It seems like 100 bits is far more than is needed for an experiment. If there is some analysis on this is the right size, I am glad to clear.
2006-09-12
07 Ted Hardie [Ballot Position Update] New position, Discuss, has been recorded by Ted Hardie
2006-09-12
07 Sam Hartman
[Ballot comment]
I do not like the dependence on sha-1 without an upgrade path.  Why
can't the hash function be an input along with the …
[Ballot comment]
I do not like the dependence on sha-1 without an upgrade path.  Why
can't the hash function be an input along with the bit string and
context ID?  Each context would be required to choose a hash function.
2006-09-12
07 Sam Hartman [Ballot Position Update] New position, No Objection, has been recorded by Sam Hartman
2006-09-12
07 Cullen Jennings [Ballot Position Update] New position, Discuss, has been recorded by Cullen Jennings
2006-09-12
07 Lars Eggert [Ballot Position Update] New position, No Objection, has been recorded by Lars Eggert
2006-09-11
07 Brian Carpenter [Ballot Position Update] New position, No Objection, has been recorded by Brian Carpenter
2006-09-11
07 Jari Arkko
I looked at the changes between versions 04 and 05. They are shown at:

http://www.arkko.com/publications/intarea/draft-laganier-ipv6-khi-05-from-4.diff.html

The changes are due to the Gen-ART review and are …
I looked at the changes between versions 04 and 05. They are shown at:

http://www.arkko.com/publications/intarea/draft-laganier-ipv6-khi-05-from-4.diff.html

The changes are due to the Gen-ART review and are all editorial.
2006-09-11
07 Jari Arkko State Changes to IESG Evaluation from Waiting for AD Go-Ahead by Jari Arkko
2006-09-10
07 Dan Romascanu [Ballot Position Update] New position, No Objection, has been recorded by Dan Romascanu
2006-09-10
05 (System) New version available: draft-laganier-ipv6-khi-05.txt
2006-09-08
07 (System) State has been changed to Waiting for AD Go-Ahead from In Last Call by system
2006-09-08
07 Jari Arkko [Ballot Position Update] New position, Yes, has been recorded for Jari Arkko
2006-09-08
07 Jari Arkko Ballot has been issued by Jari Arkko
2006-09-08
07 Jari Arkko Created "Approve" ballot
2006-08-22
07 Jari Arkko Placed on agenda for telechat - 2006-09-14 by Jari Arkko
2006-08-11
07 Amy Vezza State Changes to In Last Call from Last Call Requested by Amy Vezza
2006-08-11
07 Jari Arkko Last Call was requested by Jari Arkko
2006-08-11
07 Jari Arkko State Changes to Last Call Requested from IESG Evaluation::AD Followup by Jari Arkko
2006-08-11
07 (System) Ballot writeup text was added
2006-08-11
07 (System) Last call text was added
2006-08-11
07 (System) Ballot approval text was added
2006-08-11
07 (System) Sub state has been changed to AD Follow up from New Id Needed
2006-08-11
04 (System) New version available: draft-laganier-ipv6-khi-04.txt
2006-08-11
07 Jari Arkko
Proto writeup from Julien Laganier:

> (1.a) Has the document had adequate review both from key
>> community members and technical experts? Does the submitting …
Proto writeup from Julien Laganier:

> (1.a) Has the document had adequate review both from key
>> community members and technical experts? Does the submitting author
>> have any concerns about the depth or breadth of the reviews that
>> have been performed?


The document has been reviewed thoroughly. The reviews performed
included one by a key RIR expert, as well as from participants to the
HIP WG.


>>    (1.b) Does the submitting author have concerns that the document
>>          needs more review from a particular or broader
>> perspective, e.g., security, operational complexity, someone
>> familiar with AAA, internationalization or XML?


No, the author does not have such concerns.


>>    (1.c) Has anyone threatened an appeal or otherwise indicated
>> extreme discontent?  If so, please summarise the areas of conflict
>> in separate email messages to the Responsible Area Director. (It
>> should be in a separate email because this questionnaire will be
>> entered into the ID Tracker.)


There have been discussions on the length of the IPv6 prefix to be
allocated for this experiment. The parties involved in the discussion
agreed on the definition of a /28 prefix.


>>    (1.d) Has the submitting author verified that the document
>>          satisfies all ID nits?  (See
>>          http://www.ietf.org/ID-Checklist.html and
>>          http://tools.ietf.org/tools/idnits/).  Boilerplate checks
>> are not enough; this check needs to be thorough.


The document satisfies all ID nits.


>>    (1.e) Has the document split its references into normative and
>>          informative?  Are there normative references to documents
>> that are not ready for advancement or are otherwise in an unclear
>> state?  If such normative references exist, what is the strategy
>> for their completion?  Are there normative references that are
>> downward references, as described in [RFC3967]?  If so, list these
>> downward references to support the Area Director in the Last Call
>> procedure for them [RFC3967].


Yes, the references have been separated and there is a normative
reference to one Internet Draft (draft-huston-ipv6-iana-specials).
This Internet Draft has passed IETF LC and is waiting for an AD
Writeup. This doesn't constitute a risk of publication delay.


>>    (1.f) The IESG approval announcement includes a Document
>>          Announcement Write-Up.  Please provide such a Document
>>          Announcement Write-Up.  Recent examples can be found in
>> the "Action" announcements for approved documents.  The approval
>> announcement contains the following sections:
>>
>>          Technical Summary
>>              Relevant content can frequently be found in the
>> abstract and/or introduction of the document.  If not, this may be
>> an indication that there are deficiencies in the abstract or
>> introduction.


This document introduces Overlay Routable Cryptographic Hash
Identifiers (ORCHID) as a new, experimental class of IPv6-address-
like identifiers. These identifiers are intended to be used as end-
point identifiers at applications and APIs 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 as
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.

This document requests IANA to allocate a temporary prefix out of the
IPv6 addressing space for Overlay Routable Cryptographic Hash
Identifiers.


>>          Working Group Summary
>>              Indicate the community and/or individuals that this
>>              submission comes from. Was this proposal discussed in
>> any public forum, and was there anything in that discussion that is
>> worth noting?  For example, was there controversy about particular
>> points?


This proposal comes from Pekka Nikander and Julien Laganier from the
HIP WG, as well as Francis Dupont which has been proposing the use of
identifiers similar to ORCHIDs in MIP6. This proposal was discussed
both in the HIP WG, the INT area mailing list, and partly during the
ALIEN BOF.


>>          Document Quality
>>              Are there existing implementations of the protocol?
>> Have a significant number of vendors indicated their plan to
>> implement the specification?  Are there any reviewers that merit
>> special mention as having done a thorough review, e.g., one that
>> resulted in important changes or a conclusion that the document had
>> no substantive issues?


AFAIK this proposal is currently implemented in all maintained HIP
implementations projects (i.e. OpenHIP , HIP for
Inter.net  and HIP for Linux


Geoff Huston (APNIC) has done a thorough review that resulted in the
change from an 8-bits prefix to a 28-bits prefix. This change has
permitted to gain consensus amongst both the IPv6 and Internet
community, and the HIP community.
2006-08-11
07 Jari Arkko State Changes to IESG Evaluation::Revised ID Needed from AD Evaluation by Jari Arkko
2006-08-11
07 Jari Arkko
AD review performed, and only two minor editorial issues were uncovered. Asking the authors if they want to do a quick update. Otherwise this will …
AD review performed, and only two minor editorial issues were uncovered. Asking the authors if they want to do a quick update. Otherwise this will go into IETF LC.
2006-08-11
07 Jari Arkko State Change Notice email list have been change to Pekka.Nikander@ericsson.com,julien.ietf@laposte.net,Francis.Dupont@point6.net from Pekka.Nikander@nomadiclab.com,julien.ietf@laposte.net,Francis.Dupont@point6.net
2006-08-11
07 Jari Arkko State Changes to AD Evaluation from Publication Requested by Jari Arkko
2006-08-01
03 (System) New version available: draft-laganier-ipv6-khi-03.txt
2006-07-31
07 Jari Arkko test2
2006-07-31
07 Jari Arkko test
2006-07-31
07 Jari Arkko
Asked the authors and HIP WG chairs for confirmation that no issues remain, and asked for a proto questionnaire to be filled out and returned …
Asked the authors and HIP WG chairs for confirmation that no issues remain, and asked for a proto questionnaire to be filled out and returned to me.
2006-07-31
07 Jari Arkko Main discussion issues have been resolved. Will go ahead as experimental RFC, AD sponsored submission.
2006-07-31
07 Jari Arkko Draft Added by Jari Arkko in state Publication Requested
2006-06-22
02 (System) New version available: draft-laganier-ipv6-khi-02.txt
2006-03-03
01 (System) New version available: draft-laganier-ipv6-khi-01.txt
2005-09-02
00 (System) New version available: draft-laganier-ipv6-khi-00.txt