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

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



Eliot,

I kept reading, because if these things are created they *will*
certainly end up being used as end point identifiers. We have to invent
some multi6 solution quickly to prevent them also being NATted.

Unfortunately, this applies even if they are not created. Before RFC 1918,
lots of sites were configured with Net 1, because at least one vendor shipped
boxes configured for that by default. Similarly, IPv6 sites that can't get 
stable PA prefixes will configure *something* as a stable prefix, 
even if the IETF does nothing.

As for the locally-assigned pseudo-random variant of Hinden/Templin,
it carries a low risk of collision, which is why the centrally-assigned
option is there. I would advise my own employer to go for the
central solution, to avoid the minute risk of a collision. But the central
solution will take a while to set up, for reasons that Geoff has
documented. The local solution could be there in a hurry, by IANA action.
If I needed a limited-range prefix this week, I'd prefer that to nothing.

As I think I already said, if you want cryptographic assurance of identity,
an IPv6 prefix isn't the solution. They are too easily forged. That's
the real risk, not a random number collision.

   Brian

Eliot Lear wrote:
> 
> 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
> --------------------------------------------------------------------

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter 
Distinguished Engineer, Internet Standards & Technology, IBM 

NEW ADDRESS <brc@zurich.ibm.com> PLEASE UPDATE ADDRESS BOOK
--------------------------------------------------------------------
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
--------------------------------------------------------------------