Last Call comments on draft-laganier-ipv6-khi-05 ORCHID

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



All,

I presented these thoughts on the architecture-discuss@xxxxxxxx list
yesterday, and was told it would be useful to send these in as Last Call
comments for draft-laganier-ipv6-khi-05 (ORCHID). I have thought a bit
more about this, so this is a bit more developed than what I wrote
yesterday.

I think ORCHID is asking for too little, and is in no way facilitating
effective lookups, or localizing identities (which I expect to be a
requirement in some jurisdictions). IMO, ORCHID is also plainly wrong:

- 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

 - 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?

- If bit 7 is clear, the whole ID MUST be registered (see below)

- If bit 8 is clear, the bits 9-28 are used for regional/national
  (RIRs/NIRs? and/or DNS top level domain structure?) level
  aggregation for efficient, localized lookups.

  Here is an example what DNS records for an identity could look
  like:

$ORIGIN 5.4.3.2.1.4.0.ip6.arpa

0.1.2.3.4.5.6.7.8.9.a.b.c.d.e.f.e.d.c.b.a.9.8.7.6 IN PTR
example.test.com
                               IN AAAA 3ffe:400:10:100:201:2ff:feb5:3806
                               IN A 153.43.23.1
...

 - the $ORIGIN part has the bits 1-28 (7 nibbles). Nibbles
   "5.4.3.2.1" are the bits 9-28 for regional aggregation.
 - PTR points to a FQDN for the ID (if any), and AAAA and/or A records
   give locators for the identity
 - New RR type would be needed to map from a FQDN or a locator to an
   identity (e.g. "ID")

- If the bit 8 is set, the bits 9-28 are used for experimentation
  and collaborative, independent global lookup provision??

- bits 29-128 would be self assigned identity, as in ORCHID 
  (exept the hash will need to change, see below). See the PTR,
  AAAA, and A RRs in the example above.

- If bit 7 is set, the ID MUST not be registered on any registry.
  In this case the bit 8 would be reserved (set to zero), and use
  bits 9-128 for a 120-bit identifier hashes for better security
  and lower chance for statistical collisions

The hash function will need to be changed to include the prefix
as input. But note that this in NOT network topology dependent 
prefix. If we are lucky this difference will be enough to get
past some of the existing IPR on CGAs.

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.

If what I propose above is too much, please feel free to 
utilized what you find useful (if any).

Regards,

	Jarno Rajahalme


Some context for the above:

Pekka Nikander wrote:
>Rajahalme Jarno wrote:
>
>> Thus it would be beneficial to allocate part of the reserved IPv6 
>> address space (with some of the first couple of bits) for the ID 
>> usage.
>> This way they would be unambiguous. Have sufficient number of bits in
>> an "ID prefix" to enable scalable reverse lookup (might be useful), 
>> and most (e.g. at least 100) bits for the "random" ID part(more bits
>> for higher security).
>
>Do you mean
>
>http://www.ietf.org/internet-drafts/draft-laganier-ipv6-khi-05.txt
>https://datatracker.ietf.org/public/idindex.cgi?command=id_deta
>il&id=13628
>
>Currently in an extended IETF Last Call for 4 weeks, on its last week.
>
>Some apps folks have voiced their concerns, but most people seem to be 
>supportive for such an experiment.
>
>Or do you have something else in your mind?
>

_______________________________________________

Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]