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

From: "Richard Draves" <[email-masked]>
Date: Mon, 24 Sep 2001 16:39:38 -0700

> Questions and comments about the default address selection mechanisms:
> 
> 1- About scope and deprecated addresses in source address selection:
> 
> Considering  the way Rule 2 and rule 3 are specified, is it 
> possible that a deprecated address is selected rather than a  
> non-deprecated with bigger scope? For example suppose that 
> the destination address D has site local scope and the 
> outgoing interface has 2 addresses assigned: a site local 
> address SA which is deprecated and a global address SB which 
> is not deprecated. Applying rule 2 scope(SA)<scope(SB) and 
> scope(SA)=scope(D) then rule 2 chooses SA. Wouldn?t be better 
> to choose SB in this case?

My first comment is that this situation really shouldn't occur often in
practice. Why does the host have a deprecated site-local address SA and
does not have some other non-deprecated site-local address SC? And
getaddrinfo is returning a site-local address to the application?
Possibly the host's site is phasing out usage of site-local addresses
and this is some race-condition in the phase-out, but more likely some
configuration somewhere is broken.

But putting that aside: I would argue that SA is the better choice,
because I think choosing a correctly-scoped source address is more
important than avoiding deprecated addresses. If SB is chosen, then when
D goes to reply to SB, communication might be prevented because of the
scope mismatch. Whereas if SA is chosen, then communication will succeed
until such time as SA expires (if it expires). D, and all the routers in
between, don't know that SA is deprecated. But scope mismatches can
cause problems. (Eg in the past some implementations have refused to
communicate with mismatched scope, or depending on routing vagaries
communication from D to SB could result in a scope-exceeded ICMP error.)

> 2- Final tie-breaker unspecified in source address selection.
> 
> If the 8 proposed rules fail, "some unspecified tie-breaker 
> should be used". In order to obtain  predictable behaviour 
> (specially considering that this is included in standard 
> track), wouldn?t be interesting to specify a final rule that 
> always select an address. (i.e. the smallest address or 
> something like this)

I do not have a strong opinion about this.

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

---

From: Pekka Savola <[email-masked]>
Date: Tue, 25 Sep 2001 09:38:12 +0300 (EEST)

> communication from D to SB could result in a scope-exceeded ICMP error.)

Am I missing something here, or are we changing the definition/expected
use of 'deprecated address' here?  Previously, I think, it was very
clearly not to be used as a source address, to be phased out when
connections using it die off.

If we start re-using 'deprecated address' for new connections under
certain scenarios, we may never actually manage to get rid of it.

After all, deprecated usually _should_ be either refreshed or removed.
If we keep using it anyway, _when_ it is absolutely removed, we're going
to have bigger problems anyway.

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords