-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, all,
The solution has a bug: if TCP traffic uses TCP MD5 or TCP-AO, then it needs to be handled like non-TCP traffic, since MSS revision would destroy the packet's integrity. IMO, this should be handled the simple way - remove the TCP case, and handle all traffic the non-TCP way. Finally, if a NAT ever refuses to reassemble anything, it MUST issue an ICMP too-big IMO. The whole idea of creating a problem (encapsulating, decreasing the effective MSS on a path) then not cleaning it up yourself, or deciding when to clean it up based on *current* assumptions of network traffic is a bad idea and shouldn't be supported. Joe Magnus Westerlund wrote: > Hi, > > There is a proposal to use TCP MSS clamping to deal with MTU issues that > comes from Dual-stack lite's tunnel encapsulation. > > I think it would be good if TCPM could provide some feedback on this > proposal. > > The relevant document and section: > http://tools.ietf.org/html/draft-ietf-softwire-dual-stack-lite-00 > > 7.4. MTU > > > Using an encapsulation (IP in IP or L2TP) to carry IPv4 traffic over > IPv6 will reduce the effective MTU of the datagrams. Unfortunately, > path MTU discovery is not a reliable method to deal with this. As > such a combination of solutions is suggested: > > o For TCP traffic, let the carrier-grade NAT rewrite the MSS in the > first SYN packet to a lower value. > > o For non-TCP traffic, perform fragmentation and reassembly over the > tunnel between the home gateway and the carrier grade NAT. In > practice, this means put the IPv4 packet into a large IPv6 packet > and fragment/reassemble the IPv6 packet at each endpoint of the > tunnel. There is a performance price to pay for this. > Fragmentation is not very expensive, but reassembly can be, > especially on the carrier-grade NAT that would have to keep track > of a lot of flows. However, such a carrier-grade NAT would only > have to perform reassembly for large UDP packets sourced by > customers, not for large UDP packets received by customers. In > other words, streaming video to a customer would not have a > significant impact on the performance of the carrier-grade NAT, > but will require more work on the home gateway side. > > Cheers > > Magnus Westerlund > > IETF Transport Area Director & TSVWG Chair > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > Färögatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: [email protected] > ---------------------------------------------------------------------- > _______________________________________________ > tcpm mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/tcpm -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAknb2a8ACgkQE5f5cImnZrs0ewCg7ScElkpLrz20zSpTMnXuRApa CPsAoIyhk9N9K2fPpEJTyShMKeZNLxD/ =9ob2 -----END PGP SIGNATURE----- _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
