Date: Mon, 09 Jun 2003 11:16:04 -0700
From: Alain Durand <[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
| >Agreed. There could be a long timeout on connection if we use an invalid
| >address (local or global) as our first choice, and an out-of-scope local is
| >theoretically guaranteed to be invalid.
| >
| Operational experience on a production network:
| We have seen the results of those timers with different implementations.
| They can be up to 3 minutes and 30 seconds per invalid address.
| Multiply that by the number of 'published/leaked' addresses (v6 nodes with
| multiple interfaces can have many) and you end up with an unusable system.
This general problem has nothing much to do with address forms, and it
is more likely that a host will have lots of global addresses than
lots of local ones (that is, the number of global addresses will normally
be a multiple of the number of local ones - sometimes that multiple will
be 1, sometimes bigger). It would be rare for a host to have more
local addresses than global (unless the number of global is 0, in which
case this whole discussion is moot).
But I'd hate to think that we were allowing stupid software design to
influence choices, rather than simply striving to improve the software.
I do "local first" (actually a variation of that, but the effects for this
purpose are the same) - the implementation waits up to about 100ms for
a response. If it gets an answer, it goes on with the local address. If
it gets an ICMP it switches to global, if the 100ms passes with no
response, it switches to global.
This relies on several assumptions about the nature of local addresses.
First, they tend to be local - the RTT to a local address should be
fairly small (100ms allows for spans of a continent). Sometimes
for a diverse organisation, this might result in a global address being
used where a local one could have been (either because 100ms isn't long
enough, or because of packet loss - congested local nets) but that's
no different than "prefer global first" would achieve. (Work is
currently being done which should lower the effects of this without
delaying applications).
Second, if one local address doesn't work, then it is very likely that
none will (the way we do this, it actually becomes a side effect,
rather than a deliberate act, but anyway). That is, if one local address
fails, then we don't try others, we switch to global (of course, if
there are no global addresses things are different). We're going to
need to revisit this if we end up switching from site local addresses
to Hinden addresses, as there the reachability of one local address
really says nothing about that of any other, but for current SLs it does.
The overall effect of this is that the difference to the application
when preferring local first is almost invisible (but we're doing more
to make this even smaller).
There doesn't need to be a huge delay before finally trying a global
address and having it work.
On the other hand, if you try global first, and you're really trying to
reach a local node, for which the global addresses don't work (have been
arranged to be dropped by routers intervening, to force the use of
local addressing) then you really must suffer a long delay - the delay
waiting for a response has to allow for worst case internet RTTs (or
you might fail to find the only address that actually works) along
with retransmits (as while dropped packets locally are usually quite rare,
across the internet they're normal) - and you cannot draw any conclusions
about one global address's reachability from that of another, they all
need to be tried.
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]
--------------------------------------------------------------------
