Subject: RE: dual stack & IPv6 on by default

From: "Bound, Jim" <[email-masked]>
Date: Tue, 11 Mar 2003 22:24:27 -0500

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

---

From: Mika Liljeberg <[email-masked]>
Date: 12 Mar 2003 23:17:28 +0200

Hi Jim,

> have to be a default link too or I guess a round robin decision. 

This, I think, is the first time during this discussion that you're
directly addressing the question I am trying to raise.

Default link or round robin? Or try all routerless links at once? That's
my question, and RFC2461 gives no answers at all.

Let's face it, "default interface" is a trivial solution. It might work
in a specific case but not as a general answer. "Round robin" won't work
properly either, since the result is non-deterministic. "Try all
routerless links at once" might work but, hey, that's pretty ugly. There
being no good answer, our current implementationd doesn't try at all.
That, at least, is deterministic.

To take things back in the direction of dual stack hosts and transition,
how does the above fit with the destination address selection algorithm
in RFC3484 and the first rule:

   Rule 1:  Avoid unusable destinations.
   If DB is known to be unreachable or if Source(DB) is undefined, then
   prefer DA.  Similarly, if DA is known to be unreachable or if
   Source(DA) is undefined, then prefer DB.

Is the name resolver implementation supposed to do a route search only,
or is it supposed to try to apply the "no routers -> assume all
destinations are on-link" rule as well?

Of course, RFC3484 doesn't give much guidance either:

      Discussion:  An implementation may know that a particular
      destination is unreachable in several ways.  For example, the
      destination may be reached through a network interface that is
      currently unplugged.  For example, the implementation may retain
      for some period of time information from Neighbor Unreachability
      Detection [14].  In any case, the determination of unreachability
      for the purposes of this rule is implementation-dependent.

An implementation can't really know that a destination address is
unreachable, unless it does a route search and, failing to find one,
proceeds to try to ND all routerless links as well. Is that what we
should do?

	MikaL