Just wondering what this community thinks of NIST in general and their SP800-119 ( http://csrc.nist.gov/publications/nistpubs/800-119/sp800-119.pdf ) writeup about IPv6 in particular.
Well, according to this document IPv4 path MTU discovery is,
"optional, not widely used."
-Bill
Optional seems right. Have there been any recent studies on how widely pMTUd is actually used in v4?
More contentious is that Path MTU discovery is "strongly recommended" in IPv6. Surely it's mandatory whenever you're exchanging datagrams larger than 1280 octets? Otherwise the sender can't fragment.
Joe
Hi Joe,
Are you aware of a TCP implementation in an OS that shipped within the
last decade but doesn't enable IPv4 pMTUd by default? Each version of
Windows and all the major unixes use it on every TCP connection unless
you explicitly turn it off.
Regards,
Bill
I am not, but I'd still be vaguely interested in an actual study 
The last time I tangled with v4 pMTUd it actually was a decade or more ago. At that time wholesale ICMP blocking caused all kinds of problems for clients with a sub-ethernet MTU in their path. If the world has moved on, that seems good
Joe
All modern TCPs support it; many firewalls are configured to block the necessary ICMPs.
--Steve Bellovin, http://www.cs.columbia.edu/~smb
Then probably blackholing themselves the firewall operators....
Best Regards,
Janos Mohacsi
I've spent some time reading through it over the past couple of days and it
seems to be very good so far (have read up to end of section 3).
IOS does not support it unless explicitly turned on. It will result in decreased network performance for some things (eg: BGP Updates) as the negotiated mss will be really small.
They likely don't want to change some sacred default either as it would break other things. If you run larger than ~500 mtus internally, you may want to enable 'ip tcp path-mtu-discovery' and watch your BGP convergence improve significantly.
Router#sh ip bgp neighbors | inc max data segment
Broken setups will show something like this:
Datagrams (max data segment is 1240 bytes):
Datagrams (max data segment is 516 bytes):
Datagrams (max data segment is 536 bytes):
Others may show something much larger depending on your infrastructure.
IMHO, path-mtu-discovery is REQUIRED, not optional. Anyone saying otherwise has a broken network and you should not give them your money.
- Jared
>All modern TCPs support it; many firewalls are configured to block the necessary ICMPs.
Then probably blackholing themselves the firewall operators....
And the replies when you try to fix it simmer with contempt for those
so unresponsible as to even contemplate allowing any ICMP at all.
Routers indicate local MTUs, but minimum MTUs are not assured to have 1280 octets when IPv4 translation is involved. See Section 5 in rfc2460. (1280 minus 40 for the IPv6 header and 8 for the Fragment header.) Bill suggested this could even be smaller. This also ignores likely limited resources to resolve addresses within a /64. Public facing servers might be placed into much smaller ranges to avoid supporting 16M multicast. Also there might be a need to limit ICMPv6 functions as well, depending upon the features found in layer-2 switches.
-Doug
I've heard that interpretation of 2460 before from Bill Manning, but I still don't see it myself. The text seems fairly clear that 1280 is the minimum MTU for any interface, regardless of the type of interface (tunnel, PPP, whatever). In particular,
Links that have a configurable MTU (for example, PPP links [RFC-
1661]) must be configured to have an MTU of at least 1280 octets; it
is recommended that they be configured with an MTU of 1500 octets or
greater, to accommodate possible encapsulations (i.e., tunneling)
without incurring IPv6-layer fragmentation.
That same section indicates that pMTUd is strongly recommended in IPv6 rather than mandatory, but in the context of embedded devices that can avoid implementing pMTUd by never sending a packet larger than the minimum MTU. Such devices would break if there was an interface (of any kind) in the path with a sub-1280 MTU.
Joe
Bill makes a good point. Ensuring a minimum MTU of 1280 octets over v6 connections carrying protocol 41 will not allow subsequent v4 routers to fragment based upon discovered PMTUs. This could influence maximum UDP packets from a DNS server for example, where path MTU discovery is impractical. To be assured of continued operation for critical infrastructure, minimum MTUs of 1280 for v6 connections that might handle protocol 41 packets, becomes 1280 - 40 - 8 = 1232 or less as indicated in RFC2460. As suggested, there might be another 18 octet header, like L2TP, where the maximum MTU safely assumed becomes 1214.
Perhaps IPv6 should have specified a required minimum of 1346 octets, where 1280 octets could be safely assumed available. A SHOULD is not a MUST, but critical operations MUST be based upon the MUSTs. How much longer will native v4 be carried over the Internet anyway? :^)
-Doug