Subject: [Int-area] KHIs and SHA-256

From: Pekka Nikander <[email-masked]>
Date: Wed, 9 Nov 2005 10:49:10 -0800

[Cross-posted to HIP WG and IPv6 WG; replies _only_ to INT area please.]

I'd like to direct people's attention to draft-laganier-ipv6- 
khi-00.txt at
http://www.ietf.org/internet-drafts/draft-laganier-ipv6-khi-00.txt

Here is the abstract:

    This document introduces Keyed Hash Identifiers (KHI) as a new,
    experimental class of IPv6-address-lookalike identifiers.  They are
    constructed to be statistically globally unique.  They are intended
    to be used as identifiers only, and not as locators.  They should  
not
    appear in actual IPv6 headers.  Consequently, they are considered as
    non-routable addresses from the IPv6 point of view.

    These identifiers are expected to be used at the existing IPv6 API
    and application protocols between consenting hosts.  They may be
    defined and used in different contexts, suitable for different
    protocols.  Examples of these include Host Identity Tags (HIT) in  
the
    Host Identity Protocol (HIP) and Temporary Mobile Identifiers (TMI)
    for Mobile IPv6 Privacy Extension.

    This document requests IANA to allocate a temporary prefix out of  
the
    IPv6 addressing space for Keyed Hash Identifiers.

The basic question is whether we should go forward with it, and if  
so, where?
Could we last call it at the Internet Area, as the IPv6 chairs  
indicate that they consider it a larger issue and not just IPv6  
specific?

I would also get people's opinion whether SHA-1 is OK for the  
document, as currently the proposed experiment is to end by 2009.   
According to the discussion at security directorate yesterday, SHA-1  
is expected to be at the end of life by 2010.  Consequently, for most  
security protocols there will be two transitions in the foreseeable  
future, first to SHA-256, and then to something that NIST may be  
getting to within the next five years or so.  Hence, are we happy  
with going with (patched) SHA-1 with the expectation that the  
experiment will end by 2009, and will also become unsecure around the  
same time, or should we adopt SHA-256 from the beginning?

See also the previous discussion at the IPv6 WG, starting at
http://www1.ietf.org/mail-archive/web/ipv6/current/msg05627.html

--Pekka Nikander

_______________________________________________
Int-area mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/int-area

---

From: Bob Hinden <[email-masked]>
Date: Thu, 10 Nov 2005 08:42:52 -0800

Pekka,

> indicate that they consider it a larger issue and not just IPv6  

While I do think there are larger issues here, since this proposes an  
allocation of IPv6 addresses I think it is important that the IPv6  
working group review it.  It would be good to talk to the Internet  
ADs to figure out the best way forward (e.g., where to last call it,  
etc.).

Thanks,
Bob

> According to the discussion at security directorate yesterday,  
> SHA-1 is expected to be at the end of life by 2010.  Consequently,  
> for most security protocols there will be two transitions in the  
> foreseeable future, first to SHA-256, and then to something that  
> NIST may be getting to within the next five years or so.  Hence,  
> are we happy with going with (patched) SHA-1 with the expectation  
> that the experiment will end by 2009, and will also become unsecure  
> around the same time, or should we adopt SHA-256 from the beginning?
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Brian Haberman <[email-masked]>
Date: Thu, 10 Nov 2005 16:05:55 -0500

My understanding is that these are not routable addresses.  That is,
they won't appear in routing protocol exchanges or routing tables.
If that is the case, then we are talking about the allocation of 
something
different than IPv6 addresses.

Regards,
Brian

On Nov 10, 2005, at 11:42, Bob Hinden wrote:

> working group review it.  It would be good to talk to the Internet ADs 
> to figure out the best way forward (e.g., where to last call it, 
> etc.).
>
> Thanks,
> Bob
>
>

---

From: Francis Dupont <[email-masked]>
Date: Thu, 10 Nov 2005 23:27:44 +0100

In your previous mail you wrote:

   My understanding is that these are not routable addresses.  That is,
   they won't appear in routing protocol exchanges or routing tables.
   If that is the case, then we are talking about the allocation of 
   something different than IPv6 addresses.
   
=> you are right: not only they are not routable but they should
be easy to be recognized as not routable.

Regards

[email-masked]

---

From: Pekka Nikander <[email-masked]>
Date: Thu, 10 Nov 2005 14:47:01 -0800

[Dropping HIP WG from CC; still including IPv6 though...]

>>  My understanding is that these are not routable addresses.  That  
>> is, they won't appear in routing protocol exchanges or routing  
>> tables.  If that is the case, then we are talking about the  
>> allocation of something different than IPv6 addresses.
>
> you are right: not only they are not routable but they should be  
> easy to be recognized as not routable.

To clarify: if we decide to define this prefix, it will mean that the  
particular prefix will be generally unavailable for routing, as there  
will be hosts that will use the prefix at the API level.   
Consequently, if you want to talk to those hosts, you cannot use the  
prefix in the network.

Hence, even though the prefix is not assumed to appear in the wire,  
defining this does effect on what bits can(not) be used in the wire.

--Pekka Nikander

---

From: Bob Hinden <[email-masked]>
Date: Fri, 11 Nov 2005 11:05:11 -0800

Hi,

> To clarify: if we decide to define this prefix, it will mean that  
> the particular prefix will be generally unavailable for routing, as  
> there will be hosts that will use the prefix at the API level.   
> Consequently, if you want to talk to those hosts, you cannot use  
> the prefix in the network.
>

Right, the draft proposes to get an allocation from IPv6 unicast  
space to allow the addresses to be distinguished from the rest of the  
address space.

I see two issues.  The first is to make sure there are enough  
cautionary words in the draft to insure no one thinks these are  
intended to be put into packets and routed.  The general topic of  
allocating addresses that are not CIDR routable has caused a lot of  
controversy in the past (e.g., ULA discussions).

The second is that while it is may be OK to allocate a block of IPv6  
addresses for this experiment, I don't think we would want to have  
multiple experiments all wanting a separate allocation.  I was  
thinking we could allocate a block of IPv6 non-routable addresses for  
experimental purposes and this proposal could then use that block.   
This would allow other experiments to use the addresses at the same  
time.

Bob

---

From: Geoff Huston <[email-masked]>
Date: Sat, 12 Nov 2005 22:45:08 +1100

>defining this does effect on what bits can(not) be used in the wire.

But _nothing_ in what you have posted so far justifies and _address allocation_

 From HIP's perspective _they are just numbers_ as they are identities, not 
locators.

   Geoff

(The IAB had a draft for a while about identities, and then the IAB decided 
to drop it on the floor. Seems like it could sure come in useful here in 
terms of outlining to some IAB folk the difference between locators and 
identifiers!)

---

From: Geoff Huston <[email-masked]>
Date: Sat, 12 Nov 2005 22:41:07 +1100

>be easy to be recognized as not routable.

+1

Geoff

---

From: Francis Dupont <[email-masked]>
Date: Mon, 14 Nov 2005 12:18:49 +0100

=> the draft is supposed to address both issues. For the first one
we can add more cautionary words if one believes there are not yet
enough. For the second one we already merged two very different
experiments into one request.

Thanks

---

From: Pekka Nikander <[email-masked]>
Date: Mon, 14 Nov 2005 12:53:07 +0100

Geoff,

>>>> My understanding is that these are not routable addresses.
>>>
> From HIP's perspective _they are just numbers_ as they are  
> identities, not locators.

We have tried to address this in the draft.  Succinctly:

If we want legacy IPv6 applications to work without changes with  
protocols that use non-routable identifiers as upper layer  
identifiers, it would be desirable to have identifiers that

a) are syntactically similar to current IPv6 addresses, but

b) are understood to be semantically different.

The draft attempts to address that by allocating a separate prefix  
for such identifiers, and at the same time also provide a secure  
means for associating any identifier in the given identifier space  
with other properties, in a fashion similar to HBA/CGA.

Looking at these identifiers from a HBA/CGA point of view, what we  
propose are similar to HBAs/CGAs with two differences:
- the hash length is much longer and therefore more secure (about 120  
bits vs. about 56 bits)
- they are non-routable

If you feel that argumentation like the above should be in the  
document, I can expand the above and we can add it as an appendix to  
the draft.

> (The IAB had a draft for a while about identities, and then the IAB  
> decided to drop it on the floor. Seems like it could sure come in  
> useful here in terms of outlining to some IAB folk the difference  
> between locators and identifiers!)

I agree a document explaining the various types of identifiers would  
be useful.  OTOH, my own IETF-related work queue is currently more-or- 
less full till March or so.

--Pekka

---

From: Geoff Huston <[email-masked]>
Date: Tue, 15 Nov 2005 07:10:30 +1100

But nothing in what you have said is inconsistent with the proposition that 
there is _no_ requirement to allocate IPv6 unicast address space for this 
form of use of 128 numbers.

As you yourself point out "they are non-routeable" and theya re understood 
to be "semantically different".

i.e. what you are going with the number in this context is really 
interesting, and a Good Thing in terms of furthering our understanding of 
the implications of the identifier / locator split. But I have yet to see a 
justification as to why these numbers should also entail a reservation in 
the IPv6 unicast number space. Indeed, I can think of some tolerable 
arguments as to why they should deliberately clash with unicast address values.

regards,

      Geoff

---

From: Thierry Ernst <[email-masked]>
Date: Tue, 15 Nov 2005 09:04:21 +0900

I've heard about people who want to allocate IPv6 address to cars
instead of registration plates (not to a CPU in embedded in a car),
and other to national I-D cards ;-)  

I fear that many other folks who have a very vague understanding of what
an IPv6 address is for gets even more confused that they currently are. 

The fact that a number is 128 bits long doesn't entail it to be called
an IPv6 address when it's not routable.

Thierry

On Tue, 15 Nov 2005 07:10:30 +1100
Geoff Huston <[email-masked]> wrote:

> But nothing in what you have said is inconsistent with the proposition
> that there is _no_ requirement to allocate IPv6 unicast address space
> for this form of use of 128 numbers.
> 
> As you yourself point out "they are non-routeable" and theya re
> understood to be "semantically different".
> 
> interesting, and a Good Thing in terms of furthering our understanding
> of the implications of the identifier / locator split. But I have yet
> to see a justification as to why these numbers should also entail a
> reservation in the IPv6 unicast number space. Indeed, I can think of
> some tolerable arguments as to why they should deliberately clash with
> unicast address values.
>

---

From: Pekka Nikander <[email-masked]>
Date: Tue, 15 Nov 2005 09:46:53 +0100

Geoff,

I fully agree with you that a new identifier name space should not be  
mixed with any existing locator space.  In other words, from an ideal  
architectural point of view, the goals of having non-routable  
identifiers that have different semantics from IPv6 addresses  
definitely do not warrant allocation from the IPv6 address space.   
There we fully agree, and and that is exactly how I would like to see  
the architecture to be in the longer run:  an identifier space fully  
separate from the locator space, the locator space consisting mainly  
of IPv6 addresses.  (The IPv4 story is also there, but it is more  
messy; I'll skip it here for the sake of clarity.)

But we need a transition strategy!

Requiring a change that mandates that you
   1) change your stack,
   2) introduce a new piece of infrastructure, and
   3) change your applications
is a no-starter.  Such changes won't happen, or if they do, it takes  
at least 10 years.  Haven't we learned anything from the pain we are  
feeling with IPv6?

Hence, we need a transition strategy that allows us to move from the  
current situation into full blown identifier / locator split along a  
path where each step is easy enough and brings benefits by itself.

My current view is that we will be progressing along two (or perhaps  
three) parallel paths,  the steps being roughly as follows:

1a. Implement SHIM6
    - changes stack
    - does not change applications
    - implements identifier / locator split, but
      - keeps identifier and locator semantics and syntax identical
    - does not require any additional infrastructure
    - works only with IPv6

1b. Implement "invisible" HIP that uses IP addresses as identifiers
    - changes stack
    - does not change applications
    - implements identifier / locator split, but
      - keeps identifier and locator semantics and syntax identical
    - does not require any additional infrastructure
    - works with both IPv4 and IPv6
    - is more heavyweight than SHIM6

2a. Implement KHIs on the top of SHIM6
    - changes stack but minimally from 1a, perhaps not at all
    - does not change applications
    - continues identifier / locator split by
    - requires additional infrastructure to KHI->locator mapping
    - works only with IPv6

2b. Implement HIP with KHIs in the legacy API
    - does not change stack from 1b
    - does not change applications
    - continues identifier / locator split by
      - making a minimal difference in identifier and locator syntax  
and semantics
    - requires additional infrastructure to KHI->locator mapping
    - works with both IPv4 and IPv6
    - is more heavyweight than SHIM6

3. Implement full HIP, with a new HIP-aware API
    - does not change stack from 2b
    - does change applications
    - continues identifier / locator split by
      - making identifiers and locators fully separate
    - does not work any additional infrastructure compared to 2
    - works with both IPv4 and IPv6
    - is more heavyweight than SHIM6

Note that "HIP" above does not necessarily mean HIP as currently  
defined, but something that combines host-layer mobility, multi- 
homing, and security in a HIP-like way.  It may grow from the current  
HIP, it may grow from SHIM6, it may grow from IPsec+IKEv2+MOBIKE 
+BTNS, or it may grow from MIP+MONAMI6, or from some combination of  
those.  Or we may end up having three or four different ways of  
implementing it.  What is important here is the semantics; if we end  
up with multiple protocols to implement the semantics, well then we do.

To summarise my idea of the transition path, we progress step-by-step:

   1. Change the stack
   2. Introduce KHIs and supporting infrastructure
   3. Change the API and applications

Trying to do any combination of the steps at once would decrease the  
chances of success proportionally.  Trying to do all three at once is  
bound to fail.

So, the one and only reason why KHIs need to be *temporarily*  
allocated from the IPv6 address space is to allow smooth transition  
without requiring any changes to existing applications.  In theory we  
could live without such allocation, creating syntactically similar  
overlapping spaces, but that would not be prudent engineering.   
During the transition some identifiers are bound to leak to the  
locator space, as Alan pointed out.  It is just prudent engineering  
to minimise the effects of such leaks, both in the implementation  
(within the stack) and in the operational environment (in live  
networks).  Even if there was no implementation errors, some upper  
layer protocols would still send these identifiers to non-consenting  
hosts, causing indirect leaks.

Finally, note that we have very carefully proposed to use KHIs as an  
*experiment* until 2009.  By that time we will know much better if  
the transition strategy is working, and if it is, how long longer we  
will need the allocation.  If the transition is not taking place at  
all, which is of course possible, the allocation will be defaulted  
back to IANA.

--Pekka

---

From: Pekka Nikander <[email-masked]>
Date: Tue, 15 Nov 2005 09:59:22 +0100

Thierry,

> an IPv6 address when it's not routable.

While I agree with you, I think KHIs are a valuable means as a  
transition mechanism; see my other message on the list.

--Pekka

---

From: Thierry Ernst <[email-masked]>
Date: Tue, 15 Nov 2005 19:48:35 +0900

> > The fact that a number is 128 bits long doesn't entail it to be
> > called an IPv6 address when it's not routable.
> 

May be, but let's be careful about the terminology. You and
peolple on this list definitely know what an IPv6 address is but  I can
tell you that many people really don't, so whatever we do we must
clarify the boundaries of the "IPv6 address" term.  I don't know where
this confusion started in people's mind, but it's here. 

The people who wants to use the IPv6 address as an
identifier (they still call it an IP address even when to identify a
person) are generally unaware of the locator/id split discussion, so I
think it might be helpful to educate people about longer-term plans of
the IETF.

Thierry

---

From: Geoff Huston <[email-masked]>
Date: Wed, 16 Nov 2005 04:07:28 +1100

>think it might be helpful to educate people about longer-term plans of

s/the longer term plans of the IETF/the aspirations of some folk  as to the 
IETF's direction/

There is a critical distinction here, of course.

     Geoff

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 15 Nov 2005 14:42:02 -0800

Pekka Nikander wrote:

>    - does not change applications

I don't understand the last point. A KHI couldn't be used in referrals 
unless we have a ubiquitous and scalable KHI->locator lookup system, and 
I don't think we know how to build such a thing (yet).

>      - making a minimal difference in identifier and locator syntax  and 
> semantics

I think there is also a 2c to explore, which hasn't been talked about much.
Instead of doing KHI, define Hierarchically allocated 128-bit 
identifiers (hereby named HAI). If we have those we can use existing 
scalable infrastructure for lookups (defining some new DNS RR, or 
perhaps just use PTR and AAAA).
This would still be more heavyweight than SHIM6, since the lookup of the 
locators is needed before communication can start.
But it would run on top shim6 for the locator agility part.

    Erik

---

From: Julien Laganier <[email-masked]>
Date: Wed, 16 Nov 2005 15:04:52 +0100

> Pekka Nikander wrote:
 
(...)

> I don't understand the last point. A KHI couldn't be used in
> referrals unless we have a ubiquitous and scalable KHI->locator
> lookup system, and I don't think we know how to build such a thing
> (yet).

Yes and no. We do not know yet how to build a scalable KHI->locator 
lookup system.

But OTOH, a KHI can be used in FTP referrals, we had it working. Then, 
for the rest of applications using referrals that break with KHIs, 
one can argue that they probably break in presence of NATs too.

But nobody's perfect ;) Perhaps it's acceptable for a _transition_ and 
_experimental_ tool.

I used to run HIP on the laptop with which I am writing this message. 
It had vanilla IP and IPsec stacks plus a HIP userland  daemon, and 
still I was able to use both HIP and IP at the same time. 

That was possible because we could make the distinction between an 
IPv6 address (starting with binary 00 or 11) and a HIT (starting with 
binary 10 or 01.) When this distinction was lost I was not any longer 
able to use the _vanilla_ IPsec SPD to specify that packets send from 
any HIT to any HIT should be encrypted and integrity protected by ESP 
(hence causing HIP exchange). Yes that was hacky and overloaded, but 
again it was just working (as a transition and experimental tool.)

> >      - making a minimal difference in identifier and locator
> > syntax  and semantics
> I think there is also a 2c to explore, which hasn't been talked
> about much. Instead of doing KHI, define Hierarchically allocated
> 128-bit identifiers (hereby named HAI). If we have those we can use
> existing scalable infrastructure for lookups (defining some new DNS
> RR, or perhaps just use PTR and AAAA).
> This would still be more heavyweight than SHIM6, since the lookup
> of the locators is needed before communication can start.

The 2c you are referring to used to exist as 'Type 2' HITs (64 bits 
hierarchical prefix for lookup + 64 bits of public key hash). They 
were removed lately by the working group because the HIT diversity 
was problematic and there was no consensus to keep them alive.

--julien

-- 
julien

---

From: Francis Dupont <[email-masked]>
Date: Wed, 16 Nov 2005 15:14:34 +0100

Please note KHIs have other usages than HIP...

Regards

PS: one of the strong points of the KHI drafts is it should cover
more than one usage (if possible all usages) for crypto generated
identifiers which look like addresses (so called "not routable
addresses") for the API.

---

From: Julien Laganier <[email-masked]>
Date: Wed, 16 Nov 2005 15:30:02 +0100

> Please note KHIs have other usages than HIP...

Off course! That was just an usefulness example of having identifiers 
allocated out of the locator space as a transition tool: it makes 
possible to use at the same time identifiers and locators in an 
unmodified protocol layer (IPsec, TCP/UDP and APIs in my case).

--julien

---

From: Julien Laganier <[email-masked]>
Date: Wed, 16 Nov 2005 15:30:02 +0100

--julien

---

From: Julien Laganier <[email-masked]>
Date: Wed, 16 Nov 2005 15:30:02 +0100

--julien

---

From: Jari Arkko <[email-masked]>
Date: Wed, 16 Nov 2005 21:38:11 +0200

> different than IPv6 addresses.

Well, "not appear in routing table" != "is not an address". Link
local addresses, for instance, do not appear in routing protocols
or tables but we still consider them IPv6 addresses. Anyway,
the point is moot because these folks ARE requesting an allocation
from the IPv6 address space, no matter what we call the values.

Also, it would appear to me that application-layer referrals
would probably cause some of these numbers to leak outside
host processing and onto packets during the experiment.

--Jari

---

From: Jari Arkko <[email-masked]>
Date: Wed, 16 Nov 2005 21:43:10 +0200

> But we need a transition strategy!

FWIW, I agree with the above.

--Jari

---

From: Pekka Nikander <[email-masked]>
Date: Thu, 17 Nov 2005 15:40:31 +0100

Erik,

> lookup system, and I don't think we know how to build such a thing  

I think we know, at least for some value of "know".  We can use  
DHTs.  What we don't apparently know are how to secure them against  
freeloading in the case of multi-operator DHTs and how fast/slow they  
will be in widespread use.  But there are experiments and lots of  
research going on in those areas.

http://www.opendht.org/
http://www.cs.cornell.edu/people/egs/beehive/codons.php

Some of the existing HIP implementations already support HIT->IP  
address lookups from OpenDHT.

> about much.
> identifiers (hereby named HAI). If we have those we can use  

Yes, that would be an interesting area to explore.  But that would  
also create yet another hierarchy, and in my current "slash all  
hierarchies from the Internet" attitude I would rather not go  
there.  :-)

More seriously, I would rather see the Internet to develop towards  
fewer contention points (like the current DNS and IP address  
assignments) rather than towards more of them.

--Pekka

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 17 Nov 2005 14:54:14 -0800

Pekka Nikander wrote:

> I think we know, at least for some value of "know".  We can use  DHTs.  
> What we don't apparently know are how to secure them against  

Yes, but IMHO the hardest problem is scale.

If we want the architecture to move towards a flat identifier space 
(whether fixed length or crammed into 128 bits) we need a way to do 
lookups that scale to when every host on the planet has such an 
identifier. RFC 1726 talks about at least 10^12 hosts.
I don't know of any DHT research that is pushing towards such scale, but 
I'd would be interested in finding out if there is.

> assignments) rather than towards more of them.

But if we don't have any indication that we can scale flat spaces, then 
we need hierarchy. Hierarchy doesn't necessarily imply administratively 
controlled root of the name/number space; one can in theory construct a 
hierarchy based on multiple hashes that give statistical uniqueness at 
the top level.

I think it would be wise to expand the KHI draft to allow for 
hierarchical identifiers, so that we have flexibility as we learn more 
about a 128-bit identifier space.

For instance, allocating binary 0001/4 for IP identifiers, and then 
000100/6 for flat  Keyed Hash Identifiers might make sense, leaving room 
for other work in 0001/4.

    Erik

---

From: Tim Shepard <[email-masked]>
Date: Thu, 17 Nov 2005 18:12:47 -0500

> identifier. 

We do not necessarily need such "a way to do lookups" that scales.

Indeed for some architectures for how these identifiers might be used,
we would need such a mechanism.

But other architectures might have other ways of doing things (like
referals might carry something other than just one of these flat
identifiers).

I think it might be helpful to understand all the different ways
referals might be passed, and then in each case, what lookupability
properties the various names, and locators would need to have.

			-Tim Shepard
			 [email-masked]

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 17 Nov 2005 16:12:57 -0800

> properties the various names, and locators would need to have.

Yes, one can contemplate such an approach. What is hard to determine is 
how large set of the applications would need to be modified to handle 
this. (Referrals, callbacks, and  long-lived application associations 
are all problematic - see draft-ietf-shim6-app-refer.)

Note that it isn't just the applications; in some cases the application 
*protocols* would need to be modified (to be able to carry the new 
"referral handle" in addition to a 128-bit IPv6 referral handle).
This means that the application needs to negotiate with the peer to 
determine whether or not it supports the new type of referral handles 
(whatever they might be).

These are all reasons why I'm personally trying to figure out what we 
can do under the existing 128-bit API where the 128-bit quantities 
passed over that API can be used as referral handles.

    Erik 'don't break the app' Nordmark

---

From: "James Kempf" <[email-masked]>
Date: Thu, 17 Nov 2005 20:25:13 -0800

The other alternative to hierarchy for scalability is separate addressing 
domains. But let's not go there.

            jak

----- Original Message ----- 
From: "Erik Nordmark" <[email-masked]>
To: "Pekka Nikander" <[email-masked]>
Cc: "Internet Area" <[email-masked]>; <[email-masked]>
Sent: Thursday, November 17, 2005 2:54 PM
Subject: Re: [Int-area] Re: KHIs and SHA-256

>> What we don't apparently know are how to secure them against  freeloading 
>> in the case of multi-operator DHTs and how fast/slow they  will be in 
>> widespread use.  But there are experiments and lots of  research going on 
>> in those areas.
>
>> More seriously, I would rather see the Internet to develop towards  fewer 
>> contention points (like the current DNS and IP address  assignments) 
>> rather than towards more of them.
>
> But if we don't have any indication that we can scale flat spaces, then we 
> need hierarchy. Hierarchy doesn't necessarily imply administratively 
> hierarchy based on multiple hashes that give statistical uniqueness at the 
> top level.
>
> I think it would be wise to expand the KHI draft to allow for hierarchical 
> identifiers, so that we have flexibility as we learn more about a 128-bit 
> identifier space.
>