Date: Tue, 18 Jun 2002 09:50:22 -0400
From: Keith Moore <[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
| perhaps, but the "if they're used properly" comes with a cost -
| applications have to know how to deal with them.
Some applications. But those are also the applications that need to
know more about addresses than they currently usually do anyway.
If you remember from some earlier message, I'd only use SL addresses in
those apps that expressly say they want to use them, for others, the
vast majority of apps probably, globals work fine.
| the other thing is that 'proper' handling of of SLs and LLs is different
| enough from proper handling of normal addresses that sane apps will only
| use them as a last resort,
But that makes no sense. If you're able to use them at all, the logic
has to be there in the code, and in that case, it makes sense to use them
whenever they work (SL's anyway, LL's usually only when their use is
specifically requested).
So ...
| and the limitations of those kinds of addresses
| for normal opreations will not be discovered until the global addresses
| fail to work.
I don't think that's true. I'd also never regard a SL address as a fall
back from a global that doesn't work - my model at least requires the
global address to work (in the sense of reach the recipient and get a
reply back) before I'd consider using the SL instead. Rather, SL's are
for those apps that know they will (or are likely to) be using the
address for a long time, and which consequently want an address that
will more probably be stable for longer.
| the bottom line is that renumbering from the outside
| will still affect operations internally - just in ways that are more
| subtle and harder to diagnose.
I disagree - but this seems to largely come down to the theory of when
and how SL's will get used. Certainly external renumbering has the
potential to disrupt internal stuff - anything that is using a global
address will be affected. But if I know that I want to guard against
that possibility (as an app writer of the kind of apps that suffer
most - filesystem, mounts, tunnels, ... probably remote logins) then
if I get to use SLs I can avoid the problems for me - one less issue for
the net people to have to deal with.
| (as if the loss of external connectivity isn't enough of an effect)
External connectivity isn't likely to be lost (or shouldn't be), just
external connections that have lasted longer than the overlap period
of old & new addresses will break when the old finally stop working.
Often, that will be no noticeable effect at all, as there simply tend
not to be that many long term wide area connections (tunnels are probably
the most noticeable kind of application that may be affected).
| so I think SLs are a fairly limited win, and they come at a fairly
| high cost.
I'm still looking for the high cost, I can't really see it. Certainly
not zero cost, but I don't really think that the cost is all that great.
| I also think that external renumbering events are going to have to be
| carefully managed by humans, with plenty of advance notice, for the
| forseeable future.
Depends who is foreseeing ... I certainly agree that it is going to be a
while before things can be less disruptive. But that's no excuse for
deliberately creating the environment where more disruption is required.
Note that for many sites these days (IPv4) renumbering is essentially
an invisible operation - almost nothing is affected at all. That is,
one adjusts the NAT box, and fixes the external DNS, and aside from
any connections that were open and get broken (which a good NAT box,
if such a thing exists, could probably avoid by keeping the old state
even after recreating it becomes invalid) no-one inside the net can
even tell that the renumbering happened.
One of the aims of IPv6 was to be at least as good as IPv4 at everything
(and better wherever it is possible). If SL's get sacrificed, just
how does IPv6 ever return to even par (or better) ? If the answer if
NATv6, then I think we should all just quit and leave all of this to
someone with better judgment.
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]
--------------------------------------------------------------------
