On Thu, 26 Jul 2007, Iljitsch van Beijnum wrote: > However, for this to work reliably, it's necessary that a host only > sends large packets if it actually supports RFC 4821. What could > happen if that host A1 on subnet A where RFC 4821 in combination with > a variable MTU is used by systems supporting jumboframes communicates > with host B2 on subnet B where RFC 4821 isn't used, but the > administrator has set a larger than 1500 byte MTU on all nodes on the > subnet (the way jumboframes are done traditionally). If host B2 then > sends a packet that is too large for the switch that host A1 connects > to, the router on subnet A keeps sending packets that are too large > into the layer 2 network and host B2 never recovers from the lack of > reachability.
This is the same failure that John mentions. In short: a jumbo enabled non-RFC4821 host trying to connect via a jumbo path to a standard MTU host on a mixed MTU subnet. Fixing this case requires the router at the mixed MTU subnet to know the MTU of the host and send the proper PTB message back to the non-RFC 4821 host. Years ago there was a lot of work in this space, including the use of jumbo arp to deduce the MTU of the router's peer devices. I think this failed because it was deemed to be too hard to deploy sufficiently to enable the global deployment of jumbograms. However, in conjunction with 4821, it is only needed to solve the above corner case. RFC 4821, 1191 and 1981 should be sufficient for all other reasonable deployment scenarios. And as John Heffner noted, the community can decide to evade this problem. All we have to do is declare it to be a bug to be trying to do jumbo from a non-4821 host. Then RFC 4821, 1191 and 1981 are definitely sufficient. Jumbo ARP would actually be pretty efficient, since the first packet of a connection is (nearly) always small. The router does a regular ARP for the SYN (or whatever), and then has lots of time: a full end-to-end RTT before the first data packet arrives after the SYN-ACK. During this time it can test the largest MTU and possibly even do RFC 4821 style MTU searching before the first data packet arrives. I could not find any of the old documents..... pointers anyone? (BTW: 4821 unilaterally solves a lot of other problems with tunnels and the like, so I expect it to be deployed even without a solution to the router part of the global MTU problem). Thanks, --MM-- _______________________________________________ Int-area mailing list [email protected] https://www1.ietf.org/mailman/listinfo/int-area
