Re: RFC3484 destination address selection rule 2 is buggy

[Sebastien Roy <[e-mail]>]

Fred Baker wrote:
> Speaking for myself, there is a simpler rule in that special case  
> that imght be instructive in the ULA case.
> 
> There is no sense in using a link-local address as a source address  
> unless one is sending to someone on the same LAN. Hence, there is no  
> sense in suing a link-local address as the source if one cannot also  
> use one in the destination.
> 
> Similarly, there is no sense using a ULA source address unless the  
> destination is in the same ULA. If the destination is a global  
> address it might or might not be able to reply, but the sender can't  
> tell.
> 
> Hence, in sender address choice:
>    - use a link-local source address if and only if the destination  
> is a link-local address

In RFC3484-speak, do you mean that if the destination is global, then the 
candidate set must not contain link-local?  That makes sense to me.

Otherwise, if you're referring to a new selection rule for either source 
address selection or destination address ordering, there is no way to 
express "use a ... if and only if ...", as the language of a rule is, 
"prefer x over y".

>    - use a ULA source address if and only if the destination is a ULA  
> in the same prefix
>    - otherwise, use a global address
> 

So far, there are at least three ways to address this problem:

1. destination address ordering rule 2.5 that prefers destinations with 
non-link-local source addresses.

2. treat rfc1918 as global scope.

3. in source address selection, the candidate set should be comprised of 
addresses of equal or greater scope than the destination. (this isn't 
exactly how it has been expressed, but that's how I'm interpreting what's 
been said at the moment.)

IMO, #2 seems like the simplest approach, and #3 is also not a bad idea. 
  #1 is probably overkill.  I'd consider implementing both #2 and #3.

-Seb
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[e-mail]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------