This is *not* recommended because it will require the v4 host to know about ds-lite. This won¹t work for home router model where the hosts behind the ds-lite home router won¹t know about ds-lite. Besides, the v4 packet isn¹t over-sized, it is the v6 encapsulation caused the oversized issue. So the tunnel points are responsible to handle the fragmentation.
In the hosted model, the host is aware of ds-lite. The host can in fact reduce the v4 packet size to avoid fragmentation. This optimization is up to the implementation rather than mandated in the draft. On 8/16/09 9:42 PM, "Zhen Cao" <[email protected]> wrote: > Hi Yiu, > > Thanks for your clarification. > > Do you consider another method that let the IPv4 packet inside the > tunnel do fragmentation at a lower MTU (link-MTU - 40), so that the > packet won't exceed the MTU after IPv6 header encapsulation. Then > there is no need of IPv6 encapsulation and assembly. I believe this > is more cost efficient than IPv6 fragmentation and assembly. > > Thanks and regards, > Zhen > > On Mon, Aug 17, 2009 at 12:34 AM, Lee, Yiu<[email protected]> wrote: >> > Hi Zhen, >> > >> > In general, the Tunnel-Entry Point and Tunnel-Exist Point should fragment >> > and reassemble the oversize datagram. This mechanism is transport protocol >> > agnostic and work for both UDP and TCP. >> > >> > For TCP, we ³could² potentially avoid fragmentation by modify MSS option. >> > However, we were required by the Chairs to remove this optimization from >> the >> > draft in next update. >> > >> > Thanks, >> > Yiu >> > >> > >> > On 8/16/09 3:56 AM, "Zhen Cao" <[email protected]> wrote: >> > >> > Hi Alain and All, >> > >> > I have a question on MTU issue in ipv4-in-ipv6 softwire. I notice >> > Sec.10.2 of DS-Lite draft has discussed the MTU problem. The draft >> > introduces one possible way of using TCP MSS option to avoid IP layer >> > fragmentation and reassembly. It is a good idea but how about the case >> > for UDP sockets? I suppose there should be a general way to handle the >> > MTU issue? Thanks for any explanation. >> > >> > Thanks and regards, >> > Zhen >> > _______________________________________________ >> > Softwires mailing list >> > [email protected] >> > https://www.ietf.org/mailman/listinfo/softwires >> > >> > >
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
