Re: dual stack & IPv6 on by default

[Mika Liljeberg <mika.liljeberg@welho.com>]

On Sat, 2003-03-08 at 22:02, Sebastien Roy wrote:
> > 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.

No, I wasn't paying enough attention to the scenario - sorry. I think
the text in the draft says this clearly enough.

> > 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)?

This is a practise adopted by some current implementations because there
is a sigificant usability impact, e.g., in web browsing.  I don't recall
that this is documented in any RFC, though.

For IPv4, RFC1122 defines the ICMP errors that are to be treated as soft
errors, but does not state any special conditions for the connect phase.
It does say the following:

            An attempt to open a TCP connection could fail with
            excessive retransmissions of the SYN segment or by receipt
            of a RST segment or an ICMP Port Unreachable.  SYN
            retransmissions MUST be handled in the general way just
            described for data retransmissions, including notification
            of the application layer.

However, port unreachable is classified as a hard error. Treating the
other unreachable errors as hard errors during connect bends the rules a
little bit (in a nice way IMO).

> Should it be explicitly stated in the nodes requirements?

Probably yes. RFC1122 still has a lot of good stuff for an implementor
even though it is partially out-of-date. Certainly a lot of deployment
experience has been gained since it was written. It would be good to
write some of those things down in an updated document.

>   In practice, I don't think many TCP
> implementations do this correctly (or as you've described), and they
> should be fixed.

I'm not able to test other boxes right now, but at least Linux seems to
do it this way.

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

Agreed. RFC3484 helps, of course, but the "assume on-link" rule is still
likely to cause trouble.

	MikaL