Hi Dan, > The engineering effort to improve this situation is closely tied > to how severe the problem really is, and how often we hit the > small MTU layer 2 links (that draft-generic-6man-tunfrag is > trying to fix) and how often we hit IPv6/IPv4 translators (that > the last paragraph of Section 5 of RFC2460 is trying to fix, but > doesn't quite handle well with stateless IPv6/IPv4 translators). > > Myself, I am frustrated with layer 2 networks that have smaller > than 1500 byte MTUs, because we know anything that looks like > Ethernet succeeds (even if it isn't Ethernet, e.g., WiFi), and > technologies that don't look like Ethernet have enjoyed less > success. Can we expect those networks to fail in the market, > or to look enough like Ethernet that IP works well on top of > them, making draft-generic-6man-tunfrag unnecessary? There > is a similar question for IPv6/IPv4 translators -- will they > persist long enough to make the engineering effort to improve > that last paragraph in Section 5 of RFC2460 worth while, and > will we see deployment in IPv6 hosts while there are still > IPv6/IPv4 translators?
One other thing to note is that, while IPv6/IPv4 translators may not be around long enough to matter, IPv6-over-IP tunnels will be around for the long term. And, encapsulation always reduces the size of the available MTU (to (1500-HLEN) in the case of Ethernet). Since even ICMPv6 PMTUD messages may be lost, and since Ethernet MTUs prevail, we really need to find a way to get tunnels to configure an MTU of 1500 or larger. That is the problem space that draft-generic-6man-tunfrag is addressing. Thanks - Fred fred.l.temp...@boeing.com -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
