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

From: Kurt Erik Lindqvist <[email-masked]>
Date: Mon, 2 Dec 2002 08:54:37 +0100

> This is a real issue, and a real benefit of site-local addressing.
> However, the ambiguity of site-local addresses causes a lot of
> problems in this sort of situation.  Wouldn't it be better, instead,
> if people had a way to get provider-independent addresses that were
> globally unique?  Enter GUPI addresses...  Addresses that are _just_
> like ISP-provided global addresses, except that they belong to the
> enterprise and don't need to be changed when you switch ISPs and/or
> the ISP renumbers.

Well, said!

> Sounds good, but it opens some basic (and related questions):
>
>         - How will these addresses be allocated and/or generated?

Why can't we take them out of the global address blocks just like 
today? And have them allocated by the RIRs? Yes, this does create a 
routing problem, but that is why we have multi6, right? (ok, not 
entirely true as that deals with multihoming these addresses, but they 
are more or less related).

Somehow I think that this WG and multi6 are discussing more or less the 
same.

>         - Will enterprises end up paying their ISPs to route these
>                 addresses globally?

Enterprises will end up paying their ISP anyway. Nothing is for free. 
Additional routes and the cost of longer prefixes of IPv6 will come at 
a price.

>                 - If so, we need an aggregable way to allocate/generate
>                         these addresses, so that they won't cause
>                         explosive growth of the IPv6 core routing 
> tables.

See above.

>                 - If not, then we can probably just allocate these
>                         addresses sequentially and/or randomly.

Except that then we have a problem when this enterprise want this node 
to be visible globally and would have to renumber - which was the 
problem we where trying to solve anyway.

> Also, we need to consider whether there are other addressing-related
> problems in enterprise environment.  Are there other needs for
> local and/or provider-independent addressing? I don't really know.
>

PI addressing, I would say yes. Site-local, no.

Best regards,

- kurtis -

--------------------------------------------------------------------
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: David Borman <[email-masked]>
Date: Mon, 2 Dec 2002 13:19:56 -0600 (CST)

> From: Keith Moore <[email-masked]>
> Subject: Re: Taking two steps back (Was: Re: one question...) 
> Date: Mon, 02 Dec 2002 10:48:43 -0500
>
> > 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.
>
> 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?

Sure, why not?  I don't think we can stop it from happening.  And
I don't see anything inherently wrong with it.  The problem with
trying to globally route PI addresses is the routing table explosion
it causes to the global internet.  If a site wants to route SLs or
GUPI addresses with another site over a private link, then they are
just bloating their own routing tables (but probably not enough bloat
to cause serious problems).

I see 3 options:
	1) State that PI addresses (SL, GUSL/GUPI, GRUPI) are not
	   routeable between sites, even over private links.
	2) State that PI addresses (SL, GUSL/GUPI, GRUPI) are only
	   routeable between sites over private links.
	3) State the PI addresses are not routeable over the global internet.
I don't think that stating #1 is going to prevent #2, so I'd vote for #3.
As long as people don't impact the global internet, how they choose to
configure private links is up to them.

> > 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.
>
> or they can just start routing GUPIs.

Yes, but as others have pointed out, if there are filters everywhere
to block them it might be easier to create a new block for GRUPI
addresses than trying to "upgrade" the GUPI addresses.

		-David Borman

---

From: [email-masked]
Date: Mon, 2 Dec 2002 11:43:40 -0800 (PST)

> From: David Borman <[email-masked]>
> 
> 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.
> 
> 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.
> 

This is the most sensible posting I've seen on this issue in the past
month and a half.                                  -- George Mitchell

---

From: David Borman <[email-masked]>
Date: Mon, 2 Dec 2002 13:19:56 -0600 (CST)

I see 3 options:

		-David Borman