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

[Kurt Erik Lindqvist]

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