On 2013-10-25 23:51, Yoav Nir wrote:
On Oct 25, 2013, at 11:23 PM, Yaron Sheffer <[email protected]> wrote:
Section 2.5.1 recommends using 1280-byte max IP datagram size for
IPv6 (based on RFC 2460), and 576 bytes (based on RFC 1122). The big
difference between those two RFCs is not some technical difference
between IPv6 and IPv4, but that the former was written in 1998 while
the latter is from 1989. By 1998 it was reasonable to mandate
infrastructure that could handle 1280-byte datagrams. This has become
more true, not less in the 15 years since RFC 2460. Pretty much all
networks today can carry IPv6, and any network that can carry
1280-byte IPv6 packets, can just as well carry 1280-byte IPv4
packets. I don't think there's any point in still making this
distinction today.
This draft is about broken networks/devices that are unable to handle IPv4
fragments. Can we really assume that they can carry IPv6 traffic?
Yes, RFC 1122 is very old, but if we recommend a larger size I would like to
see better justification.
The original IKEv1 fragments were inspired by broken home routers that wouldn't
keep enough state to NAT fragments. They still worked on Ethernet and 802.11
and had 1500-byte MTU.
The current work was inspired by CGNs doing the same thing. They also deal with
1500-byte Ethernet.
1280 leaves room for various tunnels, encapsulations and what not.
Of course, if your implementation is running in some constrained environment
(like the Internet of Things on 802.15.4) you may need different MTUs. But on
the open Internet? You just don't see PMTUs that small anymore.
Yoav
If we give a recommendation, I think it should be based on measured
data. See for example Sec. 5.5 of
http://nlnetlabs.nl/downloads/publications/pmtu-black-holes-msc-thesis.pdf
Thanks,
Yaron
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
