FYI --
A discussion on v6ops that really ought to be happening here, since it concerns the ND RFC.
Margaret
To: Ronald van der Pol <[EMAIL PROTECTED]> cc: Alain Durand <[EMAIL PROTECTED]>, [EMAIL PROTECTED], [EMAIL PROTECTED] From: Sebastien Roy <[EMAIL PROTECTED]> Subject: Re: dual stack & IPv6 on by default Date: Sat, 08 Mar 2003 12:17:25 -0500
Ronald,
Thanks for reading the draft:
[EMAIL PROTECTED] said: > <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). 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.
> <cite> > 4. Poor IPv6 Network Performance > </cite> > > Is this different from IPv4-only networks? In such networks there can > also be different paths and the path with the lowest cost can have the > highest packet loss.
Right, it's no different from an IPv4 or IPv6 only scenario where the first destination picked for a connection is reachable but has poor connectivity. One general solution to this problem could be to actually connect to all destinations in parallel, somehow determine which one has the best connectivity, and close all of the other ones. I've been told that this kind of approach has been discussed in a few context at the IETF.
> > <cite> > 4.1. Dealing with Poor IPv6 Network Performance > > Not much can be done in this case other than configure each node to > prefer IPv4 destinations over IPv6. > </cite> > > A lot can be done, the network should be fixed :-) I think you mean > the end host can not do much.
Right, we should be more clear.
> Preferring IPv4 over IPv6 could be one > solution. Another could be disabling IPv6. That may be clearer to the > end user. It basically says: don't enable IPv6 unless you are sure you > have good IPv6 connectivity (or know what you are doing).
Thanks for your input, -Seb
-------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED] --------------------------------------------------------------------
