Subject: Re: dual stack & IPv6 on by default

From: Ronald van der Pol <[email-masked]>
Date: Sat, 8 Mar 2003 16:32:19 +0100

On Thu, Feb 27, 2003 at 16:10:49 -0800, Alain Durand wrote:

> My colleagues (Sebastien Roy & Jim Paugh) from Sun & I wrote a draft
> on dual stack implementations and turning IPv6 on by default on them.
> 
> http://www.ietf.org/internet-drafts/draft-roy-v6ops-v6onbydefault-00.txt
> 
> We would like to offer it as a contribution to v6ops
> and would like to receive feedback from the wg.

Thanks. I think you raise some important issues.

At this moment, I think IPv6 is not yet ready for the general public.
There still are too many connectivity problems (early adoptors however
_should_ use IPv6 to sort out these problems).

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

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

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

	rvdp

---

From: Sebastien Roy <[email-masked]>
Date: Sat, 08 Mar 2003 12:17:25 -0500

Ronald,

Thanks for reading the draft:

[email-masked] said:
> <cite> 2.  No IPv6 Router

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.

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

> 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

---

From: Mika Liljeberg <[email-masked]>
Date: 08 Mar 2003 21:05:24 +0200

On Sat, 2003-03-08 at 19:17, Sebastien Roy wrote:
> 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

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

---

From: Sebastien Roy <[email-masked]>
Date: Sat, 08 Mar 2003 15:02:05 -0500

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

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

> that caches the routing decision will have problems with this.

Indeed, all good points.
Thank you,
-Seb

---

From: Mika Liljeberg <[email-masked]>
Date: 08 Mar 2003 23:06:59 +0200

> need to more explicitly specify in the draft what types of networks

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

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

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

	MikaL

---

From: Alain Durand <[email-masked]>
Date: Sat, 08 Mar 2003 14:00:03 -0800

> little bit (in a nice way IMO).

RFC1122, section 4.2.3.5 says more just bellow what you quote:

             However, the values of R1 and R2 may be different for SYN
             and data segments.  In particular, R2 for a SYN segment MUST
             be set large enough to provide retransmission of the segment
             for at least 3 minutes.  The application can close the
             connection (i.e., give up on the open attempt) sooner, of
             course.

             DISCUSSION:
                  Some Internet paths have significant setup times, and
                  the number of such paths is likely to increase in the
                  future.

==> I understand from that section that a TCP implementation should
         wait 3 minutes on a SYN-sent before timing out.
        Do I miss something? Is this recommendation widely ignored?

	- Alain.

---

From: Mika Liljeberg <[email-masked]>
Date: 09 Mar 2003 00:33:05 +0200

>          wait 3 minutes on a SYN-sent before timing out.

This bit applies to the case when there is no feedback (no RST or ICMP
error received by the sender).

>         Do I miss something? Is this recommendation widely ignored?

I don't think it's ignored but, as I said, some implementations take a
bit more liberal view to which ICMP errors can abort the connect phase.

There is some variation to the initial retransmit timeouts and retry
counts in different implementations, though. Linux defaults to 5 SYN
retransmissions, which comes pretty close to 3 minutes with the standard
3 second initial RTO. I recall some versions of Solaris starting with a
1 second RTO and timing out roughly after one minute.

	MikaL

---

From: Alain Durand <[email-masked]>
Date: Sat, 08 Mar 2003 14:45:18 -0800

> error received by the sender).

Thanks for the explanation, that was not clear to me by reading 1122.

This 3 mins timeout is relevant to a variation of case 'no Ipv6 
routers' where we
actually have a route but v6 packets are black holed somewhere
in the network. This case is not theoretical, it happens to
me at home on my dual stack network when I connect to SUN
via our v4 only VPN.

	- Alain.