Re: [6bed4-devel] Tunnel MTU fixed at 1280

[Timothy B. <tim...@fa...>]

On 05/12/11 23:26, Rick van Rein wrote:
> Hello Tim,
>
> Thanks for getting into this!  Fragmentation is something that
> I don't excell at, so this is really useful input.  I'm trying
> to summerise the situation, and conclude in A to E below what
> seems to be the best approach.  Do you agree?
>
> As I understand from IPv4:
>   1. IPv4 permits silently dropping packets>576 bytes during fragment reassembly
Yes, but one will not be using an IPv6 tunnel on such nodes, all major 
operating systems support larger packets.
>   2. IPv4 path MTU discovery uses the DF-bit to avoid fragmentation
Yes
>   3. If the MTU of a leg along the path is exceeded, an ICMPv4 error is sent back
> 	(type 3, code 4)
It should happen, the standard says "MUST", but it often does not. How 
often?
>   4. Routing is dynamic, so this can principally occur at any time
Yes, however it is common for the small MTU to occur over statically 
routed links to single-homed customers.
> Furthermore, for IPv6:
>   5. IPv6 packets can only be fragmented and reassembled in end-points
Yes
>   6. An IPv6 packet that won't fit an MTU results in ICMPv6 (type 2, code 0)
Yes
>   7. Routing is dynamic, so this can principally occur at any time
>
>  From this, I'm tempted to conclude:
>
> A. Due to 1. tunnel packets could silently but consistently disappear
> _unless_ DF is set.  Since that is unacceptable, the IPv4 level MUST
> set the DF bit.
No, unfortunately the opposite is the case.
> B. With DF set, an ICMPv4 message informs the sender if an MTU along the path
> is being exceeded.  This ICMPv4 message (type 3, code 4) could be translated
> to the corresponding ICMPv6 message (type 2, code 0) to inform the
> IPv6 layer about fragmentation requirements.  (I hope there will be enough
> data available in the ICMPv4 message to make that possible, by the way.)
It's usually not translatable, RFC792 states that 64 bits of the IP 
payload MUST be included, that is just the UDP header. Whilst RFC1812 
states that as much as possible SHOULD be included, the reality is that 
just 8 bytes is common.

> C. This means that the IPv4 layer never does any packet reassembly at all,
No.
> which is rather desirable for the packets to flow through quickly and
> statelessly.
It's also desirable as IPv4 fragment reassembly is unreliable with 
multiple anycast sources, the beginning of packet A could be attached to 
the end of packet B.
> In addition, 6bed4 can process fragmentation issues in
> a stateless manner, namely by direct translation of ICMP messages.
No, see above.
> D. From this, it would follow that an MTU in excess of 1280 is possible,
> as long as the IPv6 client is aware of the risks involved, of needing to
> fragment the packet.
Backwards, setting a small IPv6 MTU increases the risk of IPv6 
fragmentation being needed, but reduces IPv4 fragmentation. Reducing the 
MTU at endpoints avoids the risk of mis-configured firewalls dropping 
ICMPv6 Too Big as TCP will never attempt to send a packet larger than 
the MTU at either end, reducing the MTU at a router increases the risk 
of problems. A typical TCP implementation never sends fragmented packets.

Did you mean the risk of having to retransmit?
> In other words, 1280 is not a "MUST" for the MTU of
> 6bed4, but rather a "SHOULD" with an explanation/warning against higher
> MTU values.
>
> E. A remaining problem is that the minimum MTU for IPv6 is 1280 and IPv4
> does not guarantee that, let alone in a tunnel, so packets of 1280 or
> even less might lead to ICMPv6 type 2, code 0 messages.  That is a
> nuisance, except that it won't happen in practice as the Internet has
> support for near-1500 packet sizes.
In that case we just let IPv4 fragmentation happen.
> F. An alternative would be to set DF only on packets with an IPv6 MTU
> in excess of 1280, and to rely on packet fragmentation to help a few
> more IPv6 packets through IPv4 than would be possible with DF set.
> I'd rather not: it adds complexity; it is ugly; it is not a complete
> solution; an IPv6 application may well be able to scale down its
> packets to an MTU below 1280 and achieve a much greater chance of
> success.
A ICMPv6 Too Big packet will not reliably result in smaller than 1280 
byte packets, it certainly will not cause IPv6 layer fragmentation to 
smaller packets, it only results in a fragment header being perpended so 
that the packet can be fragmented after a IPv6 to IPv4 translator.

RFC 1918 states:

    A node MUST NOT reduce its estimate of the Path MTU below the IPv6
    minimum link MTU.

RFC 2460 states:

    IPv6 requires that every link in the internet have an MTU of 1280
    octets or greater.  On any link that cannot convey a 1280-octet
    packet in one piece, link-specific fragmentation and reassembly must
    be provided at a layer below IPv6.

I suggest that the client MUST either honor the MTU specified in the 
router advertisement, which SHOULD be low enough to avoid excessive IPv4 
fragmentation, or use IPv4 path MTU discovery, it SHOULD take 
precautions against IPv4 PMTU black-holes. The Relay MAY respond to IPv4 
fragmentation by sending ICMPv6 Too Big or a router advertisement with a 
lower MTU.

Relays SHOULD have a IPv6 MTU of 1280 for sending encapsulated packets 
unless either they perform IPv4 path MTU discovery (which will 
often/usually be impossible). Otherwise using larger packets will 
increase the risk of packet fragmentation and mis-reassembly due 
identification field collision.

I do not think more complicated schemes are worthwhile to decrease the 
overhead from 7.91% to 7.13% (on Ethernet), compared to 5.32% for native 
IPv6 and 4.02% for IPv4.