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 > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Richard Draves > Sent: Friday, December 07, 2001 8:18 AM > To: Alain Durand; Robert Elz > Cc: [EMAIL PROTECTED] > Subject: RE: "Default Address Selection for IPv6" > > > 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 PROTECTED]] > > Sent: Friday, December 07, 2001 2:12 AM > > To: Alain Durand > > Cc: Richard Draves; [EMAIL PROTECTED] > > Subject: Re: "Default Address Selection for IPv6" > > > > > > Date: Thu, 06 Dec 2001 22:29:36 -0800 > > From: Alain Durand <[EMAIL PROTECTED]> > > Message-ID: > > <[EMAIL PROTECTED]> > > > > | 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 PROTECTED] > -------------------------------------------------------------------- -------------------------------------------------------------------- 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] --------------------------------------------------------------------
