Hi Tony,
At 05:44 PM 12/6/2002 -0800, Tony Hain wrote:
Margaret Wasserman wrote:
> It is my personal opinion that we should leave site-local
> addresses as-is and strictly limit their use to completely
> disconnected, isolated networks.
1) It is not possible for the IETF to restrict their use to completely
isolated networks.
I realize that the IETF cannot enforce such a restriction. But, we
can write a standard that says "these addresses are intended for use
on isolated networks and must not be used on non-isolated networks"
(or equivalent). We can also document the problems that are likely
to occur (presumably in a companion Info or BCP document) if
site-local addresses are used on connected networks. I am working
on a document that outlines the problems and recommends placing
limits on the IETF-advocated/supported use of site-locals, and I
believe that others are working on alternative proposals.
2) It is not a requirement that a connected network not use them.
I'm not sure what you mean...
The only reasonable argument here is that the IETF may choose to leave
the details of such use undocumented, and not spend time addressing the
DNS issues.
Actually, I think it would be quite reasonable for the IETF to
provide a strong recommendation against using site-locals on
connected networks, and to document the problems that they cause.
We might provide an informational document that provides guidance to
sites to randomize the upper 38 bits to avoid potential problems with
mergers later. We don't need to specify a standard mechansim, but might
suggest a couple of reasonable stratigies.
I wouldn't try to stop this sort of approach if others think it is
valuable. I just don't think that it solves the larger problems
caused by site-local addresses, and I'm not sure that its benefits
are worth the effort. Real PI independent addresses are the only real
solution to this problem, IMO. So, I'd like to see if we can find
a way to provide PI addresses in IPv6.
I have been thinking about this topic a lot lately, and I have
been refining my thinking...
In order to provide real PI addresses, we have both a policy issue
and a technical issue, both of which need to be solved.
The policy issues is that registries are currently set-up to provide
addresses to service providers for further delegation to customers
(enterprises, homes, etc.). In order to supply PI addresses, this
would have to change. I don't know what type of difficulties would
arise in making this change -- address allocaton policy isn't
something I know very much about, but I guess I'll have to learn.
The technical issue is that we don't want to allocate non-aggregable
addresses that will show up in the global routing table. Tony, you
seem to have a good start on one approach to solving this problem.
Are there other well-developed proposals? What are the current
issues/weaknesses to your approach that will need to be resolved
before it is workable, if any?
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]
--------------------------------------------------------------------
