Wondering about 6to4 and MTU issues

[kasperd]

I started wondering about how 6to4 deals with certain MTU issues. In particular I am wondering about this scenario:

• 1500 bytes packet is sent from 2001:db8::1 to 2002:c000:22a::1
• Packet arrives at 6to4 relay, which sends too-big error message back to 2001:db8::1
• 2001:db8::1 receives error message and retransmits packet in two fragments of 1480 and 76 bytes
• Both packets arrive at some 6to4 relay, likely the same as before.
• 6to4 relay encapsulates both packets in IPv4 packets from 192.88.99.1 to 192.0.2.42 of 1500 and 86 bytes
• Both IPv4 packets makes it most of the way, but link from 192.0.2.1 to 192.0.2.42 has an MTU of only 1492 bytes.
• 192.0.2.1 sends fragmentation-needed error to 192.88.99.1 for the first packet.
• ICMP error arrives at a different 6to4 relay, which never saw the first packet to 192.0.2.42
• This 6to4 relay remembers that packets to 192.0.2.42 must not be larger than 1492
• 2002:c000:22a::1 receives second fragment and discards it after timeout. (No error message is sent because first fragment is missing.)
• 2001:db8::1 retries after a retransmission timeout.
• Packet is received by 6to4 relay, but this relay did not see the ICMP error and sends a 1500 bytes packet again.

Can somebody explain to me, which of the parties involved in above communication is supposed to do something differently? And what exactly can they do to find the proper MTU?

[plugwash]

I started wondering about how 6to4 deals with certain MTU issues. In particular I am wondering about this scenario:

• 1500 bytes packet is sent from 2001:db8::1 to 2002:c000:22a::1
• Packet arrives at 6to4 relay, which sends too-big error message back to 2001:db8::1
• 2001:db8::1 receives error message and retransmits packet in two fragments of 1480 and 76 bytes
• Both packets arrive at some 6to4 relay, likely the same as before.
• 6to4 relay encapsulates both packets in IPv4 packets from 192.88.99.1 to 192.0.2.42 of 1500 and 86 bytes

6to4 relays SHOULD NOT set the don't fragment bit in their IPv4 packets.

• Both IPv4 packets makes it most of the way, but link from 192.0.2.1 to 192.0.2.42 has an MTU of only 1492 bytes.

Assuming the first relay did the recommended thing the don't fragment bit should not be set and hence the router should fragment the IPv4 packet t this point. The two fragments should then be delivered to the destination 6to4 router which should reassemble them and dencapsulate the IPv6 packet inside.

• 192.0.2.1 sends fragmentation-needed error to 192.88.99.1 for the first packet.
• ICMP error arrives at a different 6to4 relay, which never saw the first packet to 192.0.2.42
• This 6to4 relay remembers that packets to 192.0.2.42 must not be larger than 1492
• 2002:c000:22a::1 receives second fragment and discards it after timeout. (No error message is sent because first fragment is missing.)
• 2001:db8::1 retries after a retransmission timeout.
• Packet is received by 6to4 relay, but this relay did not see the ICMP error and sends a 1500 bytes packet again.

Assuming the first relay did the recommended thing none of this should happen.

[kasperd]

6to4 relays SHOULD NOT set the don't fragment bit in their IPv4 packets.

You may be right. RFC 3056 seems a bit unclear on the matter. First it references RFC 2893 which implies the packets should be send with DF set in order to perform PMTU discovery. But in the very next paragraph RFC 3056 states DF should not be set.

Clearing DF introduces a new problem if the receiving end is using anycast. And it is also suboptimal because you can no longer do proper PMTU discovery at the IPv6 layer as the real MTU of the tunnel is hidden. Both of those can of course be solved by having the receiving end of the tunnel skip the reassembly of the IPv4 packet and instead produce an ICMPv6 too big error based on the first fragment. It could even find the PMTU using fewer packets than would have been needed using ICMP errors.

I do however find it ironical that 6to4 relies on fragmentation performed by intermediate IPv4 routers, as that feature was considered to have been a mistake in the IPv4 design and was deliberately eliminated from IPv6.