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