Pekka, Jarno, Thank you Jarno for the comments. A few observations: 1) You are right Jarno that the document is inconsistent with its claim of RFC 3513 compliance. The document needs to change in some manner to resolve this. 2) Nevertheless, as we discussed this draft in the IESG, it was felt that while there are issues in the choice of the location of the prefix in the address space, it is more important to first look at the higher level issue that Ted Hardie raised. For discussion, see these e-mails: http://www1.ietf.org/mail-archive/web/ietf/current/msg44187.html http://www1.ietf.org/mail-archive/web/ietf/current/msg44183.html and please state your opinion! If we can't agree that this type of use of addresses is a good idea to begin with, arguing about the details make little difference. My personal opinion is that the benefits from this type of an allocation far outweigh the risks of referral leakage etc (and the type of leakage is already occurring from RFC 1918 address space). 3) Does the move to a different starting bits remove the above concern? Personally, I don't think it makes a lot of difference. Applications do not look at the bits. It is definately easier from a debugging point of view, however. 4) When I looked at the issue of prefix size I did not find any evidence that you would actually need more bits than the 100-or-so that the current draft states. But I'm not an expert in key lengths. Perhaps you have some specific arguments that we could look at? But lets still stay focused on the idea that this is an experiment and targeted for IP layer operations. This isn't your banking records archival system. And I don't think its a good idea to keep the same IP layer identifiers for decades; the required safety margins need to be designed accordingly. And its a temporary experiment. I do not think we should allocate more address space for this than is really necessary. And yes, it is a good idea to not to set a precedent that we can allocate more address space than needed. But if there's an argument that we actually DO need more bits, this can certainly be considered. 5) The suggested localized, DNS-based lookup scheme: none of this has ever been in the draft. I think we should experiment with ideas like the one that you have Jarno. And there are many ways to do it. But isn't the right approach for you to write a draft about it? I understand that there are many needs beyond the one that the khi draft is addressing. But it is not clear to me that we should hold up HIP experiments until we've decided how to do identifier lookups. And there are many ways to do it. I would also recommend experimenting and testing these techniques before we standardize them. Experimental allocations, experimental protocols in this space would be very welcome. Once we have some evidence that they actually work and are useful, we can start discussing moving them to real use and standards track. --Jari Pekka Nikander kirjoitti: > 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@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf