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