[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: dual stack & IPv6 on by default



On Sat, 2003-03-08 at 19:17, Sebastien Roy wrote:
> > <cite> 2.  No IPv6 Router
> > 
> >    Neighbor Discovery's [1] conceptual sending algorithm dictates that
> >    when sending a packet to a destination, if a host's default router
> >    list is empty, then the host assumes that the destination is on-link.
> > </cite>
> > 
> > Hmm, that sounds reasonable in an IPv6-only environment, but not in a
> > dual stack environment. A good example why this document is useful.
> 
> 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.

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

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.

	MikaL