[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