RE: New draft: "IPv6 Source Fragmentation for Link Adaptation Avoidance"

["Templin, Fred L" <[e-mail]>]

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
[e-mail]