Hi Cao, Thanks for pointing out this draft. I don¹t think this is a draft produced by Softwire WG.
I read it and it recommended that the tunnel endpoint not to fragment the oversized datagrams after encapsulation . The author¹s concerns are valid. We discussed their same concerns in the Software meeting and possible ways to handle fragment. In the conclusion section of 4459, the author recommend to fragment the IPv4 datagram before entering the tunnel. I believe that this is less desire due to the fact that the oversizing happens only after the encapsulation. If the tunnel endpoint fragmented the IPv4 datagram into two datagrams and encapsulate them into two individual IPv6 datagams, the fragmentation information would be lost at the IPv6 layer. The receiver would not know the two IPv6 datagrams in fact carry the same IPv4 datagam until after de-capsulation. This would require the receiver to look one layer deeper to discover the fragmentation. Thanks, Yiu On 9/29/09 2:17 AM, "Zhen Cao" <[email protected]> wrote: > Thanks for your information. > > I would like to bring back this discussion once again. It is a good > idea to have an individual document for the MTU and fragmentation > issues. But I noticed there is RFC 4459 discussing MTU and > Fragmentation Issues with In-the-Network Tunneling. Is this RFC 4459 a > product of softwire wg? > > Thanks, > -Zhen > > On Mon, Aug 17, 2009 at 9:52 PM, Lee, Yiu <[email protected]> wrote: >> > We have many discussions in the IETF-75 meeting about optimizing >> > fragmentation. In the end, the group agreed that this draft isn¹t the best >> > place to discuss the optimization. For fragmentation problem shares among >> > all the tunneling protocols, this is not unique to ds-lite technology. The >> > chairs suggested we should produce another draft which only discusses >> > fragmentation strategy for tunnel protocols. >> > >> > >> > On 8/17/09 9:48 AM, "Zhen Cao" <[email protected]> wrote: >> > >> > Hi Yiu, >> > >> > Thanks for your message. In this sense, any methods except >> > fragmentation and assembly are optimization and up to implementation. >> > But it is not a bad idea to introduce some suggestion for >> > implementation in the draft, so keeping the text for TSS option and >> > others is also reasonable. >> > >> > Best regards, >> > Zhen >> > >> > On Mon, Aug 17, 2009 at 10:29 AM, Lee, Yiu<[email protected]> >> wrote: >>> >> 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
