I had proposed limiting the use of site-locals to completely isolated
networks (i.e. test networks and/or networks that will never be
connected to other networks). This would give administrators of
those networks an address space to use (FECO::/10) for those networks
The first question that comes to mind here then is - why would we need a
/10 for this? That more than the currently totally allocated address space....
The /10 has been allocated for the purpose of "site-local" addressing
in the addressing architecture for years -- at least since 1995. There
are already lots of implementations that know something special about these
addresses -- they are ambiguous and need a zone ID to fully qualify them,
and they are not to be forwarded outside "site" boundaries).
The use of these addresses, however, has not been fully defined in any
IPv6 specification, and the definition of a "site" is unclear. The
scoped addressing architecture I-D is attempting to define the use of
these addresses, and we are currently trying to figure out what it should
say... We have consensus to limit the use of these addresses in some
way, and we are working to determine a complete plan.
Regardless of what administrative or technical restrictions we place on
the use of these addresses, though, we are pretty much stuck with the /10
allocation of "site-local" addresses. We can't reasonably reuse that
space for global-unique PI addresses (or any other global addresses),
because of the treatment that these addresses will receive from existing
implementations.
that wouldn't conflict with anyone else's and could be filtered by ISPs,
etc. (in case anyone ever makes a mistake and connects an "isolated"
network to the Internet). This is actually what site-local addresses
(and RFC 1918 addresses) were originally invented for...
Yes, but that didn't really stop anyone....
I know. And, it will probably be very tempting for people to use these
addresses behind IPv6 NAT boxes, like in IPv4.
In my opinion, the only way that we will stop people from using NAT
(with or without IPv6 site-local addresses) will be to provider better
(architecturally cleaner, more convenient, more functional) mechanisms
for people to get the same benefits that they get from NATs today.
Although NATs may have started as a response to address space shortage,
today their use is driven by the needs for provider-independent addressing
and convenient access control. So, we need to work on better ways to
provide those things in IPv6.
We also need to understand and document how a network operator could
reasonably run an operationally sound and secure network using global
IPv6 addresses and IPv4 NAT side-by-side. There are a number of subtle
problems caused by this configuration, and we need to understand those
issues and educate network operators, enterprise operators, in particular,
about how to properly set-up a shared IPv4/IPv6 network. That is one
of the major roles of the v6ops WG, BTW.
If we limit site-locals to this case, they can be treated _exactly_ like
globals in all implementations (since they will be global to any network
where they should be used), and all BGP routers could ship with a default
filter to block propagation of these routes (which the administrator
would have modify in the unlikely event that he wanted to use BGP in
his completely isolated network).
The problem I see (and have been beaten to death here) is that people WILL
connect them to the Internet. We have applications that can't
handle this and that will break, and we will have really hard times
implementing them.
Yes, you are probably right, but I think that the only way that we can
fight this is by providing _better_ solutions to the problems, and by
trying to educate people about how to deploy those solutions into
existing networks.
I'm working on a draft that explains why I believe that site-locals
need to be limited to this extreme, and that draft will provider further
The above said - I will agree with you.
Good, because I agree with you, too.
Anyway, although I don't like what you suggest above - I think it is the
only think that we can get some sort of consensus for and move on. But I
think that we need to learn from the RFC1918 mistake and make sure we
include a enforcement method.
What sort of enforcement method would you suggest?
The WG had consensus to limit the use of site-locals to one of these
two proposals, but we were pretty much split down the middle between
Wait - to ONE of them?
We had three largish groups -- the folks who wanted to eliminate site-local
addresses from the architecture altogether, the folks who wanted to limit
site-locals to disconnected networks (the "limited usage" case) and the
folks who wanted to limit site-locals to sites that don't touch other
sites (the "moderate usage" case). We were able to get consensus in the
room that we should limit the use of site-locals in some way, and that we
should further document both the "limited usage" case and the "moderate
usage" case, and try to figure out the right choice -- which may be one
of those cases, or something in between, I suppose.
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]
--------------------------------------------------------------------
