Pekka: I am distressed. Please see inline for specifics.
AEB On Fri, 29 Aug 2003, Pekka Savola wrote: > On Thu, 28 Aug 2003, Geoff Huston wrote: > [...] > > The likelihood of conflict exceeds 0.5 after only 1.24 million draws. I'd > > contend that this is definitely not "small" as described in the draft. > > I consider this a bug. Actually, the number of draws should be smaller, > e.g. 1000, to avoid having local addresses misused where they should not. > > That way, prople wouldn't get delusions to e.g. route such addresses in > the Internet. 1.24 million draws until a probable conflict could still > sound attractive. > Hmmm. Was not one of the stated benefits of unique-local the uniqueness (or near-uniqueness) of the address allocations generated by proposed allocation algorithm? A suggestion to _deliberately_ increase the probability of allocation conflict strikes me as a fundamental conceptual change to the proposal. With a change of this magnitude, it seems to me that the resulting draft would be so greatly at variance with the conceptual basis of the Hinden original that a new, wholly independent proposal would be in order, leaving the unique-local draft to stand or fall of its own merit. Additionally, such a suggestion, if implemented, would effectively prohibit one of the chief *legitimate* uses of GUPI address address allocations: routing between private networks on private (or VPN) links under bilateral agreements between the end networks. Private routing arrangements are considered highly desirable to enterprise network operators (in fact, most enterprise network managers will tell you, with quite considerable warmth, that such arrangements are indispensible); decreased probability of uniqueness in allocations would, IMHO, leave the unique-local proposal fatally flawed. If we wish to discourage ubiquity in deployment of NAT6, perhaps we should look to notions other than this. Furthermore, we can discourage global routing of unique-local prefixes by inserting into the unique-local draft more explicit language prohibiting propagation of such prefixes into the global routing tables. Some suggested text (in rough form) is given here: * Manufacturers of routers MUST include in router code a routing black hole for the entire unique-local address block. Router manufacturers MUST ensure that said black hole cannot be deconfigured, turned off, or otherwise overridden in toto; however, manufacturers MAY provide a configuration facility to "punch through" the black hole for user-specified prefixes within the unique-local block. Router manufacturers SHOULD include in user documentation language to the effect that routing of unique-local prefixes beyond site boundaries contravenes IETF recommendations, and that routing of unique-local prefixes may be configured *only* where the user can ensure that such routes will not be propagated into third-party routing tables except by prior agreement between private networks, and that under no circumstances will such routes be propagated into public network routing tables. * Service Providers MUST configure a black hole for the entire unique-local address block on all links which carry public-network traffic. Service Providers SHOULD configure a black hole for the entire unique-local address block at all AS boundary points. I might suggest that similar language be added to the appropriate router-requirements documents when (or if) an RFC on this matter is finally published. The private-link ox is largely property of the enterprise network managers; we are unlikely to greatly endear ourselves to the enterprise network folks if we gore that ox, even inadvertently, in our crusades to extirpate NAT and prevent the public routing of local address spaces. I think it unwise to provoke these folks still further. In summary: 1) the suggestion to make unique-local address allocations considerably less than unique would, if incorporated into the extant draft, fundamentally alter the concepts upon which the original Hinden proposal appears to have been crafted; if such a suggestion is to be considered, a more appropriate means might be a new individual draft 2) an allocation scheme for unique-local prefixes which produces a probability of collision above, say, one in several million, will likely render unique-local addresses of very limited utility for one (perhaps more than one) of the legitimate uses of such address space; specifically, interconnection of private (frequently enterprise) networks over private links 3) increased rate of conflict in allocation of prefixes may tend to encourage, rather than elimiate, use of NAT6 4) we can, IMO, discourage global routing of unique-local prefixes by means other than increasing the probability of address conflicts: one such means (perhaps partial) is suggested above Please disabuse me of any errant notions in the suggestions above. ;-) Regards, AEB -- Alan E. Beard <[EMAIL PROTECTED]> AEBeard Consulting; 4109 Chelsa Ln; Lakeland FL 33809 863.815.2529 -------------------------------------------------------------------- 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] --------------------------------------------------------------------
