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 [EMAIL PROTECTED] > -------------------------------------------------------------------- -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM NEW ADDRESS <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] --------------------------------------------------------------------
