hi, On Mon, May 9, 2011 at 4:08 PM, Matthias van der Heide < [email protected]> wrote:
> 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. > Jacni>: It just says "Fragmentation MUST happen after the encapsulation on the IPv6 packet" , seems to be not in conflict with RFC2473? Cheers, Jacni > 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 > >
_______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
