Subject: Re: Taking two steps back (Was: Re: one question...)

From: David Borman <[email-masked]>
Date: Mon, 2 Dec 2002 09:30:58 -0600 (CST)

> From: Keith Moore <[email-masked]>
> Subject: Re: Taking two steps back (Was: Re: one question...) 
> Date: Tue, 26 Nov 2002 15:29:52 -0500
>
> > The lack of global routability of site-local addresses is a
> > feature, not a bug.
>
> I don't think we have concensus on that.  there seem to be at least
> a few  people who want PI addresses that *are* routable, or at least,
> for which such restrictions are not imposed.

IPv4 has globally routable GUPI (GRUPI) addresses.  That's all it had
in the early days.  The explosion in the size of the routing tables is
was forced changes such as CIDR and new addresses being allocated from
ISP blocks.  The only reason we still have GRUPI addresses in IPv4
is because they were grandfathered in.

With the current routing structure, trying to define IPv6 GRUPI addresses
is doomed to failure because it will not scale.  We learned that with IPv4.
Until there is a new routing structure that will support scaling of GRUPI
addresses, we should not define GRUPI addresses.

We are talking about 3 different classes of addresses, they should
each have their own block of address space:

1) Leave FEC0::/10 as Site Local addresses.  They are not globally
   unique, but several proposals have been proposed for picking
   them in a somewhat random method to make them mostly unique.
   Site Locals should be free and not require any registration.

2) There seems to be a need for a globally unique version of Site Local
   addresses (GUSL), so we should just define a new block for them.
   These would require registration, and perhaps a fee, just like when
   you get a domain name.

3) If anyone ever comes up with a method for handling the problem of
   scaling GRUPI addresses in the routing protocols, then at that time
   we can define a third block for GRUPI addresses.

At the Atlanta IETF meeting I voted for limited use of Site Local
addresses.  That is because we have several issues for dealing with
SLs, DNS support being one of the top items.  It seems to me that the
pros and cons of SL vs. GUSL vs. GRUPI have been discussed in great
detail, and we now just seem to be rehashing the same things.

1) We seem to have a better handle on dealing with GUSL addresses (or
   at least we've identified issues that SLs have that can be mitigated
   by having GUSL addresses), so we should get a block of address space
   reserved for GUSL addresses, and those who want them can work on
   getting the registration rules set up.

2) Many of the issues that GUSL addresses mitigate can be mitigated for
   SLs by having random generation of SL prefixes.  So we should select
   the method(s) of generating pseud-random SLs and document it (them).

3) We should list the specific problems that will occur with wide-spread
   deployment of SLs and GUSLs, and start to work on them one at a time.

4) The people who really want GRUPI addresses should work on the scaling
   issues with routing, and if that is ever solved then a new block of
   addresses can be allocated for GRUPI.

		-David Borman
--------------------------------------------------------------------
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: Keith Moore <[email-masked]>
Date: Mon, 02 Dec 2002 10:48:43 -0500

>    These would require registration, and perhaps a fee, just like when

I think it's still up in the air as to whether these are really local
to a site in the sense that site-locals were assumed to be.  In other 
words, can they be routed between sites by private agreement?

>   addresses can be allocated for GRUPI.

or they can just start routing GUPIs.

Keith