Re: [6bed4-devel] Tunnel MTU fixed at 1280
zeroconfig IPv6 tunnel
Status: Beta
Brought to you by:
vanrein
From: Timothy B. <tim...@fa...> - 2011-12-10 22:09:42
|
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. |