A node can know a prefix length associated with its own addresses, but it won't know
the prefix length associated with addresses that it has retrieved from DNS. This makes
it impossible to cap the longest-matching-prefix check with the "right" prefix length.
I don't see that it's harmful to compare all the bits and it simplifies the algorithm
and avoids hard-coding a dependency on 64. (Which will not always be the right number,
even today.) As I wrote earlier, an administrator who cares can use the policy rules
or interface preference to achieve the desired result in Alain's scenario. This will
be a big step forward: today an administrator has no control at all in these
situations.
It's very easy to construct examples where the longest-matching-prefix heuristic does
the wrong thing, both in source address selection and destination address ordering.
However I believe that overall it will produce better node behavior.
I think the algorithm can be helpful without being fully deterministic. After all,
with different implementation choices (most of the provisions are "should"), policy
configuration choices, and application override, a node's behavior would not actually
be deterministic anyway. But if the WG wants to add a final tie-breaker (like numeric
order of the two source addresses) I would not be strongly opposed.
Rich
-----Original Message-----
From: JINMEI Tatuya / 神明達哉 [mailto:[EMAIL PROTECTED]]
Sent: Sun 12/9/2001 12:28 AM
To: Robert Elz
Cc: [EMAIL PROTECTED]
Subject: Re: "Default Address Selection for IPv6"
>>>>> 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]
--------------------------------------------------------------------
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
