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