Subject: RE: draft-ietf-ipngwg-default-addr-select-05.txt

From: "Richard Draves" <[email-masked]>
Date: Fri, 28 Sep 2001 08:51:46 -0700

> 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.

Yes, although it may affect the ICMP error that will be returned. If the
host selects a preferred site-local address or link-local address, then
it will probably get back an scope-exceeded destination-unreachable
error, whereas if it selects one of its deprecated global addresses then
it will probably get a no-route destination-unreachable. I think the
latter is more useful in this situation.

> 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.

The question in B is, why is the host trying to send to a global address
if the administrator is phasing out the use of global addresses? Perhaps
the admin first introduces site-local addressing across the site (if
it's not already in place), then later deprecates global addresses
inside the site, and this causes hosts to remove their global addresses
from the DNS. But there is a window in which DNS caches still return
global addresses for other hosts within the site whereas the host's own
global address is already deprecated. The global addresses should not be
made invalid until the DNS caches are all cleared, so choosing the
global source address should work. In fact, the destination address
ordering will cause the site-local destination to be tried before the
global destination so this case shouldn't happen.

> 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.

Well, I think it's better to maintain communication. :-) An
implementation could log an error when it chooses a deprecated source
address so that admins will notice.

Rich
--------------------------------------------------------------------
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-masked]
--------------------------------------------------------------------