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

Geoff Huston's draft and the intended use of the hinden/templin addressspace




If the sole purpose of these addresses is for layer 3 connectivity as 
envisioned for LOCAL USE, then I would agree with Nir Arad that we do 
not have a problem.  Stop reading here if that's your position.

If on the other hand, as Geoff states in his draft, and some people seem 
to be implying, that these addresses could be used as some sort of end 
point identifier outside of the routing system, then we do have a problem.

The reason this is an interesting problem is because these addresses 
have properties that would seem to align well with many people's idea of 
conceptually separate end point identifiers.  In particular:

  o  Statistical v. Administrative uniqueness
     -- see the NSRG draft

  o  Easy processing as a fixed size and at a (mostly) fixed point in
     the packet.

  o  Below the transport that could be used to maintain connections.

  o  non-aggregatability
     -- some would believe that since only a forward mapping is
     necessary there is no need for aggregatability, and that indeed
     one shouldn't allow these things to have properties of addresses
     in order to avoid overloading of functions.

A word of caution is in order.  It is just that overloading, however, 
that we are doing in the context of local connectivity.  And so for 
those who are considering this approach, you would be wise to consider a 
bit further as to the implications of that overloading.  In particular, 
ipv6.arpa issues should be considered as well as any *forward* mapping 
from this address to globally routable IPv6 addresses.

The problems with doing this, however, are well stated in Geoff's draft. 
    All of a sudden you are not simply interacting locally but more 
globally, and that means that for statistically "unique" values one 
should assume some collisions *will* occur (albeit rarely).

So in a peculiar sort of way, various efforts are converging towards 
very similar architectural properties but for somewhat different purposes.

Eliot


--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------