Subject: RE: "Default Address Selection for IPv6"

From: "Richard Draves" <[email-masked]>
Date: Sun, 9 Dec 2001 16:17:25 -0800

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-masked]] 
	Sent: Sun 12/9/2001 12:28 AM 
	To: Robert Elz 
	Cc: [email-masked] 
	Subject: Re: "Default Address Selection for IPv6" 

	>>>>> On Fri, 07 Dec 2001 17:12:17 +0700,
	>>>>> Robert Elz <[email-masked]> 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-masked]
	--------------------------------------------------------------------
	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-masked]
	--------------------------------------------------------------------

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

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Mon, 10 Dec 2001 09:36:03 +0900

>>>>> On Sun, 9 Dec 2001 16:17:25 -0800, 
>>>>> "Richard Draves" <[email-masked]> said:
 
> 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.

I basically agree with you.  Perhaps I was not very clear in the
previous message, but my point was:

- If we cared about the prefix length in the longest matching, we
  should use a generic length, not hardcoded 64.
- The longest matching algorithm is not so meaningful in the
  destination address ordering.
- In any case (about the longest matching), the current algorithm is
  not deterministic.  If we wanted the deterministic behavior, we'd
  need another rule.

And, my preference is (in the appeared order)

1. remove the longest matching rule in the destination address
   ordering, or
2. leave the document as is

I don't care about the deterministic behavior (so I don't see the need
to introduce additional rule).  Even if we made the algorithm
deterministic, it would not be so meaningful.

					JINMEI, Tatuya

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 10 Dec 2001 19:34:52 +0100

JINMEI Tatuya / 神明達哉 wrote:
...
> 2. leave the document as is

I am against choice 1. The longest match rule originally came in via
an early 6to4 draft - it is still useful in the case where both
6to4 and native addresses are present, I think.

I think the document isn't broken and doesn't need fixing.

  Brian