Margaret Wasserman <[EMAIL PROTECTED]> wrote:
|>Please help me to understand something. I have been trying to get people to
|>look at the portable identifier/routing problem for _years_.
|
|Various people _have_ been looking at this problem for years. In fact,
|the IPv6 WG toyed with it for a while in the mid-1990s.
Yes, I've participated in some of the toying. But that's the problem--it is
at best toying. The discussion is always shot down for the same reasons that
are now being used against site-locals, e.g., ``this is just such a complicated
problem that we can't begin to deal with it.'' A good thing that may be coming
from the site-local debate is a loss of credibility for that particular excuse
and/or its users. It's one thing to hand-wave portable identifiers into the
nether-realm of implementation impossibility given the number of steps that
separate them from current practice--this is enough to confuse anyone. Using
that approach to claim that it is impossibly complicated for local addresses
to protect internal connections from global renumbering begins to sound a
little suspect given that people are already doing exactly that particular
impossibly complicated thing. With any luck this may induce folks to reexamine
the assumptions behind other unsubstantiated declarations of impossibility...
|I agree that
|this is _the_ problem that we (the IETF, not necessarily the IPv6 WG)
|need to fix if we want to have an architecturally clean Internet that
|scales.
I suggest that any such solution has to start here for two reasons. First,
even the least intrusive solution is going to involve far-reaching changes
(even if those changes are minor) in many aspects of the stack. No other
forum has the required scope (no pun intended). Second, no solution is
going to be free. There will be implementation costs and probably ongoing
operational/performance costs. Agreement on these costs must come from a
broad base. And this latter is a sticking point. I've asked a number of
times over the years for opinions on what cost we are willing to pay for
a solution. The problem seems to be that some people believe that having
a solution has no (or even negative) value. Thus they are unwilling to
allow for any cost...
|Is there a particular solution (or type of solution) that
|you favor?
Not really; I'd be ok with just about any solution. Realistically, if we
were actually going to do something at this late stage, the least disruptive
solutions would probably be quasi-source-routing using the current addresses
as a fixed-length route in conjunction with a new portable identifier (which
could be the same size as an address) or some version of auto-tunnels. If
I were revamping routing from scratch I would probably favor pure source
routing since it is a totally scalable solution. There are many possible
approaches with various cost/benefit tradeoffs.
|>-When (and how) did site-locals become the main obstacle standing in the
|>way of solving the routing/identifier problem?
|
|I don't see site-locals as an obstacle to solving this problem at
|all. So, if I said something that gave you that impression, I must
|have been unclear.
My comment was directed to Patrick and those others who assert that eliminating
site-locals is a prerequisite. Since we are in agreement that this is not the
case, how about we shelve the site-local deprecation process until a routing
solution can be found? If that problem is in fact solved, the elimination of
site-locals will be far less contentious. On the other hand, if the routing
problem cannot be solved, at least we will have site-locals as a fallback.
|The only obstacle to solving the routing/identifier
|problem (that I know of) is that we haven't found a solution to it (yet).
Hmm, well, I still think that the economic aspects of PA addressing play
a part. But I'll be happy to be proved wrong.
|So, people are currently forced to choose between global-routability
|and provider-independence in a particular address; no address has
|both properties. Some people will choose provider-independence over
|global-routability for (some of) their addresses. So, until we
|can solve the routing/identifier problem, we will be stuck with some
|type of provider-independent, local addressing.
|
|I just happen to think that site-locals (the FECO::/10 prefix, with
|the semantics currently defined in the scoped addressing architecture
|I-D) are a very poor way to provide local, provider-independent
|addressing.
However poor, site-locals are the _only_ currently defined local address.
If we remove them then people will have no choice at all. Also keep
in mind that at least some aspect of the scoped architecture is necessary
to insure that both ends of an internal connection are really using local
addresses. This is independent of the specific form of the local address.
|While local (non-globally-routed) addresses will always, by definition,
|be unreachable from some portions of the network, there is no reason why
|they need to be ambiguous. The ambiguity of site-locals creates a great
|deal of complexity, and imposes unnecessary limitations on their use.
Personally, I have no need for ambiguity. In fact, I would be happier
with completely unique locals because then I can build a layer of routing
on top of them with auto-tunnels. But again, I don't think that unambiguous
addresses actually relieve you of the scoping problem.
|>-When (and how) did all the other reasons that have been advanced to stymie
|>any work on the routing/identifier problem evaporate?
|
|I never once suggested that there is a reason not to work on this
|problem. In fact, I think that it is vitally important to solve
|this problem, and people are working on it (in the IRTF and the
|multi6 WG, among other places). If you have a viable proposal to
|solve this problem, I'd love to see it.
Check the archives.
Dan Lanciani
[EMAIL PROTECTED]
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
