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