At 02:26 PM 11/3/02, Michel Py wrote:
> Margaret Wasserman wrote:
> [Limiting the Use of Site-Local]
> I have offered to write a document that explains my
> thoughts on the above issues
I don't see how this could reach consensus.
Not all documents that people write do reach consensus. Some do,
and are published. Some explain a viewpoint and are useful as
a means of clear communication, even if they never become RFCs.
There is ample evidence to support the fact that the customer (the
network administrator) wants, if not site-local, at least something that
provides what site-local does; and that they will continue using them
the way they see fit regardless of the fact that the IETF could try to
restrict their use or not. Keep the customer happy.
However, there are significant questions about what site-local
provides, and little enough commercial deployment of IPv6 that
it is hard to say, at this point, what will prevail.
I agree that customers use IPv4 RFC 1918 addresses and NAT, but
I don't think that we have a full understand of _why_ these
things are used -- what the actual motivators are, not a laundry
list of everything they might be useful for... Site-locals
bear a surface resemblance to RFC 1918 addresses behind NAT, but
they actually don't work the same way. For example, site locals
do not really shield the site from the need to renumber the
global prefixes, the way a NAT does. Also, there are no ALGs
defined to allow applications to work properly across site
boundaries in IPv6. Maybe we'll end-up defining IPv6 NAT and
ALGs based on customer demand, but I hope not.
Ideally, we'd like to construct the IPv6 protocol, the IPv6 address
allocations policies, etc. to promote a flatter and more end-to-end
architecture in the IPv6 Internet. Maybe we'll fail, but I'm not
ready to give up trying.
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]
--------------------------------------------------------------------
