On Thu, 2002-11-28 at 13:57, Michel Py wrote: > [Note: this is independent of "GUPI"] > > > 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. > > > 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. > > 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: > > 1.3.1 If the router autoconfigures itself, use 1.2.1, > then save the prefix obtained in the config. > > 1.3.2 If there is interaction with the user, offer > the choice: > a) Manual, then save in config. > b) Contact Charlie's server, then save in config. > c) Same as 1.3.1. > > 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 > > 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. >
The above is all really good (and I'm not being typically Australianly sarcastic), but isn't "Multiple sites" below the whole purpose of above ? I thought the scenario we were aiming to provide a solution for was : Michel and Mark come to some agreement that they don't want to use the global Internet to communicate with each other any more. The reasons for this agreement could be trust, cost, organisational merger, or just because it is Thursday. Both have near-unique / unique GUSLs, so they order a layer 2 circuit between (or create a private VPN between) each other's sites, connect networks together, and push the other's GUSL aggregate /48 or more specific prefixes into their IGP, possibly even using BGP between IGPs. Or is it that the wording below stating that GUSL addresses SHOULD NOT be used between sites if traffic will transit links _that are part of the public Internet_ (excluding a private VPN tunnel over the public Internet) ? If so, I agree with the text, though it probably needs to be a bit more explicit about what it is SHOULD NOTting. > 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) > > ps, if the above scenario _not_ is what GUPIs were trying to solve, a problem statement and how they go about solving it would also be good at this point. I've always thought we were trying to solve this same single problem, and GUPIs and GUSLs were basically the same thing. Regards, Mark. -------------------------------------------------------------------- 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] --------------------------------------------------------------------
