Date: Tue, 25 Sep 2001 14:41:36 -0700
From: "Richard Draves" <[EMAIL PROTECTED]>
Message-ID:
<[EMAIL PROTECTED]>
| Does anyone else think that the order of these two rules should be
| reversed, so that choosing a non-deprecated source address is more
| important than choosing a source address of the appropriate scope?
For the case where the deprecated address is of smaller scope than
the preferred one, yes, I think that would be the right way. On the
other hand, I see the chances of deprecated link local or site local
addresses ever being seen as almost too remote to worry about. I
suppose the one possibility is for internal site subnet renumbering
(so old site local addresses are deprecated) or a desire to phase
out use of site local (or an admin screwp or something.) In that instance
using a global address instead of the deprecated site local seems
like a clear win.
It is the case where the preferred address is of smaller scope than
the deprecated one which is of real interest .. to analyse that I think
we need to enumerate the ways we can see where we might get into that
state, and then see which of those, if any, is actually a state where
the order actually matters much, and then just how important that is.
The ones I can imagine (please, contribute more) are...
(I will use "global" just to avoid having to say "the address with the
wider scope - the same would apply to a deprecated site local with a
"preferred" link local, which is really a pretty silly concept)
A The admin screwup - eg: a global address is deprecated when it
wasn't meant to be.
B global addresses are being phased out on a link (nodes to be
restricted to intra site communications only), so all the global
addresses are deprecated before being removed
C Address adverts based upon availability of connectivity to the
relevant provider, and no links are currently functioning, so
all ISP based addresses (globals) are deprecated, until a new ISP
link starts working (or restarts working). (Yes, this assumes
functionality that doesn't currently exist that I know of).
more??
The third case (C) is not very interesting, which address is used probably
doesn't matter - only on-site communications are possible, and either
address would do for that.
For B, using the site local (the preferred) address over the deprecated
address seems like the clear winner - that is going to have to happen soon
anyway, the only question is just when the line in the sand is drawn
(when the addresses went deprecated, or when they're finally withdrawn).
Here, the original idea of deprecated addresses being only to permit
existing connections time to gracefully close (or somehow switch to new
addresses), seems to fit. Prefer the preferred address, whatever scope.
For A, it is harder - to keep things functioning, using the deprecated
address is the obvious answer, that way the error can be corrected, and
the address returned to being preferred, and no-one really even notices,
everything just keeps working. So, preferring the address of the appropriate
scope seems like the winner there. But if that's what's done, will the
error actually be noticed? Or would it be better to provoke investigation
by causing some new communications to fail (outgoing ones, all the incoming
stuff will just keep on working, as would anything where site local addresses
would work)? If that would be a better outcome, then preferring the
preferred address (whatever scope) seems like a better choice.
Are there other ways that we might get into the situation where the order
of those rules might make a difference?
Given the above, I'm tempted to switch the order, though my gut feeling
is that the current order is better. Weird...
kre
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
