Subject: GUSL proposal (very crude)

From: "Michel Py" <[email-masked]>
Date: Wed, 27 Nov 2002 18:57:09 -0800

[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.

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)

--------------------------------------------------------------------
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-masked]
--------------------------------------------------------------------

---

From: Mark Smith <[email-masked]>
Date: 28 Nov 2002 15:10:00 +1100

>        Accepting such routes MUST require specific permit

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.

>    (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.

---

From: "Alan E. Beard" <[email-masked]>
Date: Thu, 28 Nov 2002 00:10:03 -0500 (EST)

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)
> 
Agreed. GUPI is a separate topic which requires a workable solution. 
 
> 3. Clarify the use of site-local addresses for
These seem laudable goals, and fall within what I believe to have been the
bounds of the consensus at Atlanta.

>          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.

>  [...]
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.

>        prefixes within FEC0::/10
This proscription concerning routing of the site-local block seems both
necessary and desirable.  

>        Accepting such routes MUST require specific permit

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"?

>    (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-masked]>
AEBeard Consulting
4109 Chelsea Ln
Lakeland FL 33809
863.815.2529

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 28 Nov 2002 10:00:07 +0100

Michel Py wrote:

...
>        1.2.2 Unregistered, free, unique, sequentially

I suggest considering the "seconds elapsed since a reference date"
proposal, because it would be less work for Charlie. Or use
that method instead for FEC0::/11, because it doesn't need
a seed.
>              other allocation method, TBD.

If you like hexadecimal puns, this should be FEE0::/12

   Brian