>>>>> On Fri, 07 Dec 2001 17:12:17 +0700,
>>>>> Robert Elz <[EMAIL PROTECTED]> said:
> | 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.
I agree with kre as for hardcoding 64; it's better to use the
configured prefix length (which may or may not be equal to 64).
However, I'd rather think longest matching is meaningless in the
destination address ordering, especially with this generalization.
For example consider the following configuration:
A host has two prefix P::/32 and Q::/64 (P:: != Q::), both of which
can be used to autoconfigure addresses and are regarded as on-link.
The host thus configures P::a and Q::b as its addresses accordingly.
Then the host tries to send a packet to a remote node, and the host
name resolves to P::c and Q'::d, where Q' matches Q:: in 48 bits.
Then the longest matching rule will choose the set of (src=Q::b,
dst=Q'::d). But this may not be the best combination, because the
source and the destination is not on-link and may need many hops in
terms of routing, while P::a and P::c is on-link and can be accessed
within the same single link.
I know this is quite an artificial example, but I still think the
longest matching in the destination address ordering does not buy much.
For the source address selection, however, the longest matching is
sometimes useful, because for a given destination address we can
choose a source address in the same ISPs prefix block, which may have
advantage wrt the routing.
BTW, as for the deterministic behavior, the longest matching still
cannot be the final tie-breaker, as described in the addr-select
draft. If we need full deterministic algorithm, we'll need another
(almost meaningless) rule like "choose a smaller address" which I
recall someone mentioned before in this list.
JINMEI, Tatuya
Communication Platform Lab.
Corporate R&D Center, Toshiba Corp.
[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]
--------------------------------------------------------------------
