Michel: In response to your later request for feedback on this proposal, here are my initial reactions:
On Wed, 27 Nov 2002, Michel Py wrote: > Subject: GUSL proposal (very crude) > > [Note: this is independent of "GUPI"] > Agreed. GUPI is a separate topic which requires a workable solution. > > GUSL > > Globally Unique Site Local > > > Goals: > 1. Provide an allocation method of site-local addresses > within FEC0::/10 in order to avoid ambiguity of such > addresses. > 2. Enforce the non-routability of site-local addresses > on the public Internet. > 3. Clarify the use of site-local addresses for > inter-site traffic. > These seem laudable goals, and fall within what I believe to have been the bounds of the consensus at Atlanta. > > 1. Allocation method: > > 1.1 Rationale. > There is a need for three types of allocation: > - Free, automated configuration, no registration, > no external connection, almost unique. > - Free, manual or semi-automatic configuration, > no registration, Internet connection necessary > for semi-automatic configuration, unique. > - Fee-based, manual registration, unique. > Additonal properties TBD. > The three allocation types may be broader in scope that the _minimum_ requirements, but, to quote Mae West: "too much of a good thing can be wonderful." ;-) I see no objection to the allocation types as enumerated above. > 1.2 The site-local address space (FEC0::/10) will be > divided in 3 parts: > > 1.2.1 Free, random/hash allocation, for unattended/ > automated setups. > See Paul Francis / Pekka Savola > FEC0::/11 > > 1.2.2 Unregistered, free, unique, sequentially > allocated. > See Charlie Perkins. > FEE0::/12 > > 1.2.3 Registered, probably not free, geographical or > other allocation method, TBD. > FEF0::/12 > > 1.3 Choice of allocation method: > [...] This section seems entirely reasonable to me, at least in concept. The details can be settled as the work progresses. In the later note, a specification was included which seems to require that each allocation bear a prefix length of /48. Since we are already dealing with a /10 block for the entire SL space, this yields a maximum of 2**38 allocatable prefixes. I am impelled to wonder aloud: is this a sufficient count of possible allocations to meet the anticipated demand over the expected life of the IPv6 protocol? We thought, at least in the days of our innocence, that the IPv4 address space would be amply sufficient to the need; and we have for the past ten years or so reaped the bitter harvest of our myopia. Would it perhaps be wiser to make the allocations on a longer default prefix length, or, alternatively, to allocate on varying prefix lengths as the end-user's network requirements indicate? I suspect, based on the experience gained in working with clients, that a great many end-user networks will rush to acquire GUSL space, and very few of those networks are likely to _require_ an 80-bit address block to satisfy their operational requirements. Having stood ten years in a corner of the IPv4 implementation space while waiting for paint to dry, I would be greatly distressed to see like conditions arise pertaining to IPv6 within my lifetime. > > 2. Enforcement of global non-routability: > > 2.1 Rationale. > Ambiguity provided some fail-safe for route leaks. > By removing ambiguity, we must provide additional > Enforcement of non-routability. > > 2.2 Routers MUST have a default blackhole for FEC0::/10. > See Bob Hinden. > This blackhole MUST NOT be easily removable, as it > does not prevent the site from using more specific > prefixes within FEC0::/10 > This proscription concerning routing of the site-local block seems both necessary and desirable. > 2.3 Routers MUST discard by default any BGP routes > matching FECO::/10 ge 10. See Michel Py. > Accepting such routes MUST require specific permit > statements. Here again, the requirement seems necessary and desirable. Should we consider making the routing protocol requirement more general by substituting the specfication "any exterior gateway protocol" for the very specific "BGP"? > > 3. Multiple sites: > > GUSL addresses SHOULD NOT be used for communication with > other sites. > (I am open to a MUST NOT, whatever the WG consensus is) > It seems to me that item 3 above may be interpreted variously to mean, among other things: a) GUSL addressing may not be assigned to links (private or otherwise) connecting two or more sites, even if the GUSL addresses are not routable over the public network; or b) traffic bearing GUSL source or destination addresses may not be carried over links (private or otherwise) interconnecting two or more sites, even if the links themselves bear global addresses Based on previous traffic in the mailing list, I would expect that your intent would have been closer to the latter. I see potential implementation inconveniences with either interpretation above, but nothing that is insurmountable if a reasonable PI address allocation scheme for private network facilities is worked out before IPv6 begins to see widespread service in end-user networks. That's my $.02 worth. AEB -- Alan E. Beard <[EMAIL PROTECTED]> AEBeard Consulting 4109 Chelsea 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] --------------------------------------------------------------------
