> From: Keith Moore <[EMAIL PROTECTED]>
> 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 PROTECTED]
--------------------------------------------------------------------
