Re: dual stack & IPv6 on by default

[Sebastien Roy <Sebastien.Roy@sun.com>]

mika.liljeberg@welho.com said:
> > 
> > I don't think I see how this would be reasonable even in an IPv6-only
> > environment.  Let's assume there are billions of IPv6 devices out there.
> > If you have no route (and I do think that at the very least the ND spec
> > should say route instead of default route in this case) to one of those
> > billions of devices, what are the odds that it happens to reside on your
> > link?  This bit of ND is an optimization for a very rare case at the
> > expense of very a common case (you actually can't reach the
> > destination).
> 
> The common case is that the host has a default router, in which case
> this rule isn't invoked at all.

Ok, I agree that this would be the common case in an IPv6 only network.
If a random dual stack box that has IPv6 enabled is placed in a random
network out there, the common case today is that it has no IPv6 default
router, and this ND rule would be problematic for it.  That's what we
were trying to get across in this section of the draft.  I suppose we
need to more explicitly specify in the draft what types of networks
we're concerned with.

> >   Quickly notifying the application that there's no route
> > to the destination so that the user can correctly configure routes
> > (on-link or off) seems better than sitting there for minutes while TCP
> > times out the larval connection.
> 
> A TCP connection in SYN-SENT or SYN-RECEIVED states should abort
> immediately when ND determines that the destination is unreachable, so
> TCP does not incur any additional delay here.

Is that stated somewhere (it should be)?  Should it be explicitly stated
in the nodes requirements?  In practice, I don't think many TCP
implementations do this correctly (or as you've described), and they
should be fixed.  Even if TCP is fixed to abort connections, there is
still a 3 second delay in IP while NUD is being performed, which may or
may not be acceptable depending on how many IPv6 destinations the
application will try before trying IPv4.  I can't see this as being
acceptable when a destination resolves to a few dozen IPv6 addresses,
for example.  An immediate ICMP destination unreachable/network
unreachable from IP would be generated if it didn't assume destinations
were on-link.

> 
> However, this rule *is* somewhat problematic with multihomed hosts as
> well as in cases where network interfaces are set up on-demand. In the
> former case, the packets apparently have to be replicated to all links
> that have no default routers. In the latter case, an application might
> trigger an on-demand network interface setup. However, the packets from
> the application would still be directed on-link, since it takes a little
> while to receive and process a router advertisement. An implementation
> that caches the routing decision will have problems with this.

Indeed, all good points.
Thank you,
-Seb