An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers (ORCHID)
draft-laganier-ipv6-khi-07

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?

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.

[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.

[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.

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.

[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.

[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.

[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.

[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.

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.

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.

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.

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.