Subject: RE: "Default Address Selection for IPv6"

From: "Richard Draves" <[email-masked]>
Date: Fri, 7 Dec 2001 08:18:14 -0800

There are clearly some strong opinions both ways on this issue. I plan
to raise the issue during the discussion of this draft at IETF and I
hope we can discern WG consensus then.

Thanks,
Rich

> -----Original Message-----
> From: Robert Elz [mailto:[email-masked]] 
> Sent: Friday, December 07, 2001 2:12 AM
> To: Alain Durand
> Cc: Richard Draves; [email-masked]
> Subject: Re: "Default Address Selection for IPv6" 
> 
> 
>     Date:        Thu, 06 Dec 2001 22:29:36 -0800
>     From:        Alain Durand <[email-masked]>
>     Message-ID:  
> <[email-masked]>
> 
>   | In the case they don't, the system will rely on longest 
> prefix match
>   | with the problematic behavior I exposed earlier.
> 
> As I recall it, it wasn't really problematic, just strange.
> 
>   | Doing a longest prefix match on something longer than the actual
>   | prefix length is always meaningless.
> 
> Yes, but at least, deterministic meaningless, rather than random.
> 
>   | I would rather have longest prefix match limited to the 
> prefix length
>   | (that is /64 in the normal case) and, in the end, all 
> things being equal,
>   | suggest to use a deterministic tie breaker,
> 
> like using the following bits in the address...
> 
>   | like using the first
>   | interface or address the system has configured.
> 
> Neither of those is deterministic.   Especially the address, which can
> determine upon the order in which RAs are received (and how 
> long since an address there was last deprecated).
> 
>   | The alternative you mention, that is to use the order 
> returned by the DNS
> 
> which is also not deterministic.
> 
>   | is in my opinion more suitable than sorting interfaces on 
> the particular
>   | brand of NIC card they are using.
> 
> There's certainly nothing to commend using the MAC addresses, 
> other than that they simplify the algorithm (no special 
> cases), and most particularly avoid building in any knowledge 
> of 64 in places where it does not belong.
> 
> If you can specify this such that it actually uses the 
> currently configured prefix lengths (no mention of the number 
> 64 anywhere) and actually find a way to make the outcome 
> predictable, then I'd be more inclined to accept it
> as a reasonable change.   Otherwise not.
> 
> 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-masked]
--------------------------------------------------------------------

---

From: "Tony Hain" <[email-masked]>
Date: Fri, 7 Dec 2001 09:47:47 -0800

While it is appropriate to raise the issue for resolution, there is
nothing wrong with  the text as written. The minor niche case of
automating predictability when multiple machines connect to parallel
networks is covered by:
   IPv6 implementations SHOULD support configurable address selection
   via a mechanism at least as powerful as the policy tables defined
   here. If an implementation is not configurable or has not been
   configured, then it SHOULD operate according to the algorithms
   specified here in conjunction with the following default policy
   table:
If there is a local policy to prefer one wire over the other then the
implementation SHOULD have made that configurable. There is no reason to
change the default rule set simply to avoid configuration in a case that
is MOST LIKELY TO BE CONFIGURED anyway. The people that build networks
like the example are the same ones that will refuse to use the automated
features of configuration, so making the rules more complex doesn't do
anything except delay publication.

Tony

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Richard Draves
> Sent: Friday, December 07, 2001 8:18 AM
> To: Alain Durand; Robert Elz
> Cc: [email-masked]
> Subject: RE: "Default Address Selection for IPv6"
>
>