RE: dual stack & IPv6 on by default

["Bound, Jim" <Jim.Bound@hp.com>]

Hi Mika,

 
> On Tue, 2003-03-11 at 02:17, Bound, Jim wrote:
> > >If one takes the ND spec strictly, case a) might or might not 
> > >trigger dialup, depending on which default route we hit first. Case

> > >b) would never trigger the dialup [although an implementation might

> > >choose to do so after NUD].
> > 
> > OK. But NUD would mean it tells some function to configure the
> > interface in this case of dial up?  Right? Even dialers do 
> this now.
> > But ND is working above you do not say it does not from
> what I can see
> > as question?
> 
> So far so good. ND itself is fine, I'm just exploring the rule:
> 
> "If the Default Router List is empty, the sender assumes that
> the destination is on-link."
> 
> The above rule makes option a) unfeasible in multi-homed
> hosts, so implementors have to go for option b). Not 
> necessarily a big problem but reduces the options available 
> to the implementor.

Hmmm.  See below assumption on my part.

> 
> > >On the other hand, as soon as the host receives the first RA from 
> > >the dialup interface and configures a default router, the other 
> > >interface stops working for ad-hoc.
> > 
> > Why?
> 
> Because now the default router list (combined from all
> interfaces) is not empty, so we can no longer assume that all 
> destinations are on-link. Applications rely on the default 
> route to get them to the routed network, so it does not make 
> sense to have a default router in one interface and an 
> on-link default route in another. Applications can't cope with it.

This is where I believe I disconnect.  To me applications are
transparent to defult routes totally.  This is done by the transport in
combination with the IP routing table lookups, to determine the
interface the packet will leave on, and in that process use a route for
that interface and link.  Those are per link with per link default
routes. Given that it is not a problem?

> 
> >   From your example it sounds like two separate links and that is a
> > non-issue as I interpret ND.
> 
> Yes, I'm talking about separate links, but I'm sure its a non-issue.

I agree per my comment above.

> 
> > >All this just goes to show that the default on-link route implied 
> > >by the ND specification perhaps isn't fully thought out, at least 
> > >with multihoming.
> > 
> > The default route is for a link.  And multiple routers are
> permitted
> > to announce routes.  So two routers can be supported on a
> link, with
> > one being the default.  Multipe interfaces can exist on one
> link.  So
> > in that sense ND is transparent to multihome node.
> 
> I understand and agree with all this. The point is:
> applications can't cope with multiple default routes, unless 
> those routes offer equivalent connectivity. Default routers 
> and on-link default routes just don't mix. Normal 
> applications can't be expected to choose which network 
> interface they want to use.

Agreed, but applications do not choose this normally or the link.
For a multilink node the search cannot just be for first left most bits
match but an exhaustive search for the route till no match is found.
That is the key.  I agree if that is not done there is a problem.

So if link 1 is 3FFE:3::24  and link2 is 3FFE:4::25 a match on 3FFE is
not enough for a multilink node.  The search must look past 3FFE and to
the next bit (assume bit position search).  Then one of them will be
successful.  This will point to an interface and link.  At that point a
default route will be looked for if no ND cache entry, if route exists
that will be used, else sent over the link. 

The packet goes over the correct link and the application should not be
involved.

Now I agree an implementation that is not as robust as I suggest above
will have a problem if the search is only on 3FFE and then a default
interface will be selected too.

But that is not a flaw in ND which is what I am saying but in the
robustness of an implementation.  The standard does nothing to prevent
multihome nodes using ND.
> 
> So what I'm trying to say is that the rule "If the Default
> Router List is empty, the sender assumes that the destination 
> is on-link" doesn't seem to make sense in a multi-homed host. 

If the node has received no prefix or address knowledge it is a means to
still try to send the packet.  But in that case as I said above it would
have to be a default link too or I guess a round robin decision. 

But this is not a problem with ND.  Other than in many places in general
in the IETF we always try to send the packet.  One of my favorites is
sending to a Global Address if all you have is a link-local address.  I
find this silly but it is permitted :--)  But that is not a flaw in ND
either.  Though in most cases source address selection will fix this but
not all.


> To my mind, it doesn't make much sense in a single-homed host 
> either. The intent would seem to be to allow link-local 
> communication using configured addresses in the absence of a 
> router. What's the point? Why not just use link-local 
> addresses? I suspect the answer to that is ideological rather 
> than practical.

Errr.  Yep.

> 
> If the idea is to allow ad-hoc communication using configured
> addresses, then logically a multi-homed host, which currently 
> doesn't know any default routers, would have to try to do ND 
> on *all* its interfaces (rather than just picking an 
> arbitrary one), in order to resolve a given destination 
> address. Unfortunately this is not normal routing anymore.

True, it is the ND protocol and it is required for IPv6.

> 
> > I may have missed your point in my parser?
> 
> Maybe at least partially. I hope I was more lucid this time.

Well I believe it's a worthwhile discussion but this has been the case
for awhile and ND if used will populate the ND cache and Route List,
which I believe makes the problem go away.  With the correct search
algorithm for sending packets.  ND works fine.  Now if someone doesn't
run ND then they are not IPv6 compliant.

/jim
> 
> 	MikaL
> 
>