After reading the latest version of the Dual-Stack Lite draft, the issue of Tunnel MTU and fragmentation got me confused.
Tunneling according to RFC2473 dictates that IPv4 packets exceeding the Tunnel MTU (Link MTU - size of Tunnel Headers) with the Don't Fragment bit set should be dropped and answered with an ICMP that carries the Tunnel MTU. Packets with the Don't Fragment bit cleared that exceed the Tunnel MTU must be encapsulated and then fragmented. However, this distinction isn't mentioned in the Dual-Stack Lite draft. Instead it says (section 5.3): > However, as not all service providers will be able to increase their > link MTU, the B4 element MUST perform fragmentation and reassembly if > the outgoing link MTU cannot accommodate for the extra IPv6 header. > The original IPv4 packet is not oversized. The packet is oversized > after the IPv6 encapsulation. The inner IPv4 packet MUST not be > fragmented. Fragmentation MUST happen after the encapsulation on the > IPv6 packet. Reassembly MUST happen before the decapsulation of the > IPv6 header. Detailed procedure has been specified in [RFC2473] > Section 7.2. So although it refers to RFC2473 for the detailed procedures, it modifies these procedures by removing the distinction between packets with and without the Don't Fragment bit set. Is it true that tunneling in Dual-Stack Lite differs from tunneling described in RFC2473? If so, what should be used as the MTU value for the link on which a DS-Lite interface is enabled? Should it be the Link MTU (for instance 1500 in Ethernet), or the Tunnel MTU (Link MTU - 40 or more bytes)? Perhaps the draft could be extended with an example of a fragmented flow. If not, I think the text should be clarified. In both cases, I hope this helps the draft to become a robust, stable standard, and I'm willing to contribute. - Matthias van der Heide
_______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
