Subject: RE: (ngtrans) Re: 6to4/isatap MTU

From: "Christian Huitema" <[email-masked]>
Date: Wed, 21 Aug 2002 09:34:59 -0700

> Rather, allowing some implementations to pick 1280, and others bigger
> numbers (up to the 4554, assuming everyone else accepts that one) will
> allow the different (ipv4) fragmentation strategies that people have
been
> discussing here to be tested - with implementations making use of
whatever
> happens to be available to them.

There are a couple of obvious requirements that all nodes should follow.
One, for example, is to NOT set the DF bit: even if we restricted 6to4
to the IPv6 minimum MTU of 1280 octets, there would still be a risk of
IPv4 fragmentation on some links. Another is to take into account the
causes of loss in fragmented packets.

A point in our favor is that we don't have to consider one of the major
causes of fragment losses in IPv4, i.e. poorly configured firewalls that
drop packets when they cannot recognize port numbers in the first bytes
of the payload. This means that some fragmentation is OK, as long as we
can cope with the next most prominent cause of fragment losses, which
are random losses due to congestion and systematic losses due to
mis-configured link buffers. The latter tend to occur with long trains
of packets, are very hard to debug when they occur, and pretty much rule
out any value much larger than 4K.

The theory of random losses is easy enough: the probability of receiving
N segments correctly is (1-x)^N, where x is the random loss rate. Any
large value of N runs afoul of the architecture law that Erik quoted,
that "the unit of control should be the unit of transmission". It all
depends then on how badly we break the law. This depends on two
variables, the dominant MTU in the IPv4 Internet, and the dominant
packet loss rate. Let's consider two classic MTU value, 512 bytes and
1500 bytes, and two classic loss rates, 1% and 3% -- the latter for
heavy congestion. We get the following:

IPv4 MTU	IPv4 loss	6to4 MTU	N	6to4 loss
     512        1%       < 1500     3        3%
                3%       < 1500     3        9%
                1%       < 4500     9        9%
                3%       < 4500     9       24%
    1500        1%       < 1500     1        1%
                3%       < 1500     1        3%
                1%       < 4500     3        3%
                3%       < 4500     3        9%

To me, the answer is clear: whatever we do, we must be conservative and
avoid ever being locked in a situation where a combination of congestion
and fragmentation results in very high loss rates, as in the 4rth line
of our table. I see two solutions. One is to try to be smart and combine
PMTU discovery with packet reassembly: a 6to4 receiver that encounters a
reassembly error would issue an "MTU exceeded" error -- assuming indeed
that it has received the first fragment that contains the IPv6 header.
If it can be implemented, it will result in actually discovering the
adequate PMTU for each pair of source and destination. However, the
implementation requires linking two independent modules in the stack,
IPv4 reassembly and 6to4 processing.

Another approach is to just keep it simple and pick a low MTU, lower
than 1500 bytes; this will be sub-optimal in some cases, but the design
point for 6to4 is universality, not optimality. Indeed, that can also be
enforced by the receiver: if the receiver does not implement the "smart
reassembly" listed above, it could simply issue an "MTU exceeded" error
when it receives a dangerously long packet.

-- Christian Huitema