Subject: "Default Address Selection for IPv6"

From: Alain Durand <[email-masked]>
Date: Thu, 06 Dec 2001 22:29:36 -0800

In preparation for SLC meeting, I'm revisiting this issue.

At 03:27 PM 10/5/2001 -0700, Richard Draves wrote:
> > >2. The current draft does longest prefix match on 128 bits.
> > >     In the case of a dual-rail network where each hosts has
> > >     2 interfaces
> > >
> > >     prefix P1/64
> > >     ------------------------------------------------------
> > >           | h1                  | h2               |h3
> > >     ------------------------------------------------------
> > >     prefix P2/64
> > >
> > >     In this case, the choice of network 1 or network 2 depend
> > >     on the actual MAC address of the hosts.
> > >     This is a situation that is very difficult to understand/debug
> > >     by network administrator.
> > >
> > >     I would like to suggest to do longest prefix match only
> > on the 64
> > > most significant bits.
>
>
>If there is some reason to prefer the P1 network over the P2 network
>(maybe one is faster/better than the other?), then I think rule 7 is the
>way to accomplish it. The administrator should give interfaces on the
>two networks different preferences or metrics.
>
>I'm a bit reluctant to build in the constant 64. Admittedly it's already
>a magic number for IPv6, but I'm not excited about embedding knowledge
>of it in yet another place.
>
>If we do change the draft to cut-off longest-prefix matching at 64 bits,
>then it would not necessarily lead to predictable behavior in your
>scenario. The choice of P1 vs P2 would then come down to the order in
>which destination addresses are returned from DNS, which may or may not
>be predictable depending on the DNS servers and how the addresses are
>put into the DNS.
>
>This is why I think rule 7 is the better solution for the administrator
>in your scenario.

In Destination selection rule 7:
 > Rule 7: Prefer native transport. If DA is reached via an encapsulating 
transition mechanism
 > (eg, IPv6 in IPv4) and DB is not, then sort DB before DA. Similarly, if 
DB is reached via
 > encapsulation and DA is not, then sort DA before DB. Discussion: 
6-over-4 [14],
 > ISATAP [15], and configured tunnels [16] are examples of encapsulating 
transition
 > mechanisms for which the destination address does not have a specific 
prefix and
 > hence can not be assigned a lower precedence in the policy table. An 
implementation
 > MAY generalize this rule by using a concept of interface preference,
 > and giving virtual interfaces (like the IPv6-in-IPv4 encapsulating 
interfaces)
 > a lower preference than native interfaces (like ethernet interfaces).

This idea of interface preference is only mentioned as a MAY.
It means that some implementation will do it right and some don't.
In the case they don't, the system will rely on longest prefix match
with the problematic behavior I exposed earlier.

Doing a longest prefix match on something longer than the actual
prefix length is always meaningless.
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 first
interface or address the system has configured.
The alternative you mention, that is to use the order returned by the DNS
is in my opinion more suitable than sorting interfaces on the particular brand
of NIC card they are using.

         - Alain.

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

Date:        Thu, 06 Dec 2001 22:29:36 -0800
    From:        Alain Durand <[email-masked]>
    Message-ID:  <[email-masked]>

  | 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

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Sun, 09 Dec 2001 17:28:28 +0900

>>>>> On Fri, 07 Dec 2001 17:12:17 +0700, 
>>>>> Robert Elz <[email-masked]> said:

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

---

From: Dianna Adair <[email-masked]>
Date: Sun, 09 Dec 2001 17:10:49 -0800

Any thoughts about the >64 address or a "variable length" longer address as
regards this point?