Interconnecting entities would involve these steps (pretty much
repeating what you have said above) :
1) play GUPI prefix lotto - if you loose, one of the entities will have
to renumber their network
This assumes some sort of locally-generated GUPI addresses. There is
also the possibility of externally allocated GUPI addresses. I don't
think that we've made a decision one way or the other yet, and I don't
think we can/should make a decision between different GUPI address
allocation methods until we have documented what problems we are
trying to solve.
>
> - You may have different "levels" of GUPI addresses within
> a single network... Some devices may use addresses
> that are filtered at the department level, some
> may be filtered at the corporate level, and
> some may be filtered at the extranet level, for
> example.
>
When you use "levels", am I right in assuming you mean creating
different packet forwarding boundaries via packet filtering ACLs etc,
Yes.
within the same instance of a GUPI address space ?
What does this mean?
Let's take two steps back, stop discussing possible solutions for a
moment and discuss the problem statement. I'd like it to be possible for
an enterprise to:
- Have resources (i.e nodes or services) that are accessible
only to sub-groups within the enterprise (i.e.
departments). Example: a printer that only marketing
is allowed to use.
- Have resources that are available to the whole enterprise,
but that are not accessible outside the enterprise.
Example: An HR benefits website.
- Have resources that are available on an extranet (between a
selected group of enterprises) that are not accessible
to all other enterprises. Example: A supplier/customer
network.
- Have resources that are globally available, and be able to
send global traffic. Example: Google.
All of these things can be achieved without site-locals, using
provider-allocated global addresses and appropriate configurations of
firewalls, ACLs, route filtering and split DNS.
The key here is to control access/reachability. IPv6 site-local
addresses (as currently defined) don't significantly help with this
problem, because they only provide one level of "local" addressing
(Would I use them at the department level? At the enterprise level?),
and their ambiguity prevents them from being nested. Their ambiguity
also causes numerous other architectural problems and does not,
inherent offer any benefits related to this problem statement.
However, some people have argued that network administrators will
choose to use site-locals at one of these boundaries (probably the
enterprise-wide boundary) in order to achieve ISP independence. In
other words, they want to make sure that they don't have to renumber
their internal firewalls, ACLs, etc. if they change ISPs and/or
their ISP renumbers.
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.
Sounds good, but it opens some basic (and related questions):
- How will these addresses be allocated and/or generated?
- Will enterprises end up paying their ISPs to route these
addresses globally?
- 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.
- If not, then we can probably just allocate these
addresses sequentially and/or randomly.
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.
Now, I have a second type of problem statement:
For the home environment, it would be nice to be able to ship
nodes that are configured, by default, only to be accessible
locally -- i.e. storage devices or home security systems (I'm
actually not that worried that hackers will use my printer :-)).
Since these devices will be installed and used by fairly
unsophisticated users (like me :-)) who do not want to set-up
firewalls, ACLs and split DNS to protect their resources, it would
be good if there were a way for these addresses to recognize
certain prefixes as inherently "local", and only accept traffic
from nodes with addresses within those prefixes.
Steve Bellovin has proposed a new RA mechanism that would allow some
prefixes to be tagged at "local" (and would even provide multiple
levels of "local"), so that we could get the access control benefits
of local addressing without the need to use overlapping private
addresses.
It might be useful to have a home gateway generate some sort of
addresses (current site-locals, site-locals with random numbers to
make them unique, other types of addresses?) for use on the
local network, and tag those addresses as "local" in RAs.
Would home users want to (or ever be allowed to) pay their ISPs
to globally route their provider-independent addresses? If so,
we would need a way to assign aggregable addresses. If not, it
might be sufficient to assign them sequentially and/or randomly.
Are there other problems that NATs solve for the home environment
that we need to find an architecturally sound way to solve in IPv6?
I don't really know.
And, are there any needs for local addressing within ISPs or other
types of provider networks? If so, what are the needs in those
environments?
It isn't even clear that a single solution will serve for all of
these environments.
But, until we understand what problem we are trying to solve, I think
it is quite premature to argue over the details of what random
number generator it would be best to use...
Margaret
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
