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