At 12:17 PM 10/24/02, Margaret Wasserman wrote:
I think that we should keep site-local addresses in the
addressing architecture, but limit their use to non-globally-
connected IPv6 networks.
Some folks have pointed out that it might have been helpful if
I had explained my reasoning...
The addressing architecture currently defines a set of addresses
that are allocated for use as "site-local unicast addresses", but
it does not discuss the details of when or how those addresses can
or should be used.
The scoped addressing architecture document defines how site-local
unicast addresses (and other scoped addresses) will be used, and
defines node behaviour related to these addresses. I am suggesting
that we should consider placing some restrictions on the _use_
of site-local addresses in the scoped addressing architecture
document.
However, it is imperative that the site-local address allocation
remain in the addressing architecture, even if we do decide that
the use of these addresses should be restricted (or even forbidden).
The allocation has been there for several years, and there are some
implementations that recognize these addresses.
I also believe that it is apporpriate for the node requirements
document to indicate the minimal acceptable support that a node
should have for site-local unicast addressing.
In my opinion, we should limit the use of unicast site-local
addresses to non-globally connected sites, and have the following
requirements for IPv6 nodes:
- Hosts do not have to be aware of site-local addresses
at all (treat them just like globals).
- Routers do not have to be aware of site-local
addresses at all (treat them just like globals).
I do understand that, even if we do make this restriction, there may
be some people in the world who will later insist on using site-local
addresses (or other allocated private addresses) to build
a private address space within a globally connected IPv6 network.
I also understand that those people may build a kludge tower to
support this, similar to the IPv4 kludge tower needed to support
NAT, but with the added twist that a single node may have both
private and global addresses (yum!). However, I don't think that
the IPv6 WG should go down the rat-hole of documenting that kludge
tower...
Instead, I think that we should advocate a position where all
nodes on globally attached networks have global addresses, and
site-local addresses are only used on non-globally connected
networks. This would work with the currently documented IPv6
routing protocols, would provide the easiest IPv4->IPv6 transition
for applications, and would not require changes to DNS. This also
has the advantage of limiting the problem that the IPv6 WG is trying
to solve, which should allow us to finish up the base IPv6 documents
and confidently deploy IPv6.
In my opinion, IPv6 does not require support for private
site-local unicast address spaces to be successful. The major
benefits of IPv6 are a larger address space (which should eliminate
some motivations for using private address spaces) and host
autoconfiguration, and I think that the world is already preparing
to deploy IPv6 based on those current advantages.
I _would_ support an effort to start a separate IRTF or IETF WG
to explore whether we can build an architecturally sound model for
private and global addresses to co-exist on the same network
and in the same nodes, but I would prefer not to invent that
model in the IPv6 WG and build it into the core of IPv6.
This is my personal opinion, not a directive from the chairs or
anything like that.
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]
--------------------------------------------------------------------
