Re: [arch-d] Last Call comments on draft-laganier-ipv6-khi-05 ORCHID

Jarno,

Thanks for your valuable comments.  While I largely agree with you,  
I'm afraid that what you ask below, and what we originally asked for  
in the first versions of the ORCHID draft, are just too much for the  
wider IETF community to swallow at this point of time.  In other  
words, the original version of the ORCHID draft asked for more than  
the current one; not exactly in the way you did in your message, but  
still.  The current draft represents a consensus that was achieved at  
the Internet Area mailing list.  A watered down consensus if you  
will, but, hey, this is the IETF.  :-)
A few details:
> - 1st of all, the ORCHID proposal is contradicting itself. It calls
>   for conformity with RFC 3513 section 2.5.4, but breaks this:
>
> "All global unicast addresses other than those that start with binary
>    000 have a 64-bit interface ID field (i.e., n + m = 64), "
>
> - Therefore it is wrong to ask for allocation under IANA Special
>   Purpose Address Block (which starts with binary 001).
>
> - ORCHID should ask for something like 0400::/6 (binary 0000 01),
>   claiming 1/8 of the address space starting with binary 000
We originally asked for 1000::/8 (binary 0001 0000), which falls  
within the binary 000.  Then there would have been 120 bits of the  
hash, instead of the kind-of regional structure that you propose.   
Personally, I still think that the 100 bits of hash is problematic.   
It won't take that long before it will be vulnerable to brute force  
attacks.  By Moore's law, 120 bits would give us some 20-30 years more.
But that was deemed unsuitable by some old-time IETFers, including a  
former member of the IAB.  Basically, if I understood correctly, the  
original proposal was felt to overstep the RIR policies.  Secondly,  
apparently, some people feared that it would open up the floodgates  
to the 0000::/3 space, which was considered politically very bad.   
There were corridor rumours of fears that if this experiment was  
given something, then other SDOs would come and ask for similar  
pieces of space for non-addressing purposes.  Personally, I don't  
understand what would be so bad there.  But hey, apparently I don't  
understand the IETF power politics in any case; that I have bitterly  
felt enough of times.
Hence, as I stated above, the current proposal is the compromise we  
were able to reach.
Personally, I still think that allocation from 0000::/3 would be  
better than what we ask for in the current draft.  As you indicated  
later, it would to make a distinction between ORCHIDs/Identifiers and  
"mere" addresses.  However, at least one of the IESG members seems to  
think that there is no difference on where the prefix is allocated,  
from the apps point of view, and apparently not worth doing due to  
the reasons stated above.  But I may be misreading people's words.   
On the other hand, personally, I think RFC 3513 makes a potential  
difference.
>  - Maybe should be asked for limited time experimentation (e.g. 5
>    years), and all systems could be mandated to cease using these
>    addresses after the dead line. Unless the status is changed
>    before expiration?
That is exactly what we asked for originally: a time-limited  
experiment, with by-default cease of use.  Again, that was removed as  
a part of the drafting process.
> The hash function will need to be changed to include the prefix
> as input.
I think that change was already done as per security review, but my  
memory may fail here.  Julien took care of that change.
> If I recall right, one of the expressed concerns against ORCHID has
> been semantical overloading. By using address space starting with
> binary 000 this overloading is avoided.
I completely agree with you here, but some other people seem to  
bitterly disagree.
--Pekka Nikander

PS.  I don't read ietf-discuss.  If you want your replies to reach  
me, please include my personal address in the CC/To field.

_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf