> I think that the -06 document still does not address the 
> comment I sent to 
> the mailing list
> right after London IETF.

I did not see that comment, but I remember that you raised this issue at
the Redmond interim meeting, along with the related issue of
ISATAP/6over4 subnets being preferred over native subnets. I followed
Erik's suggestion and added rule 7 in section 5 (destination address
ordering) to fix these issues.

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

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

Reply via email to