On Fri, 27 Jul 2007, Iljitsch van Beijnum wrote: > On 27-jul-2007, at 14:10, Matt Mathis wrote:
> I don't think that's a workable approach. For ethernet, using packets > larger than 1500 bytes is illegal, strictly speaking, but there are > no limits on other link technologies. So if I get some FDDI equipment > in a garage sale or connect to the internet over ATM, SONET or even > PPP, I will / can have an MTU larger than 1500 bytes without breaking > any specification. Retroactively making this illegal would be a > curious move to say the least. Most highend Ethernet gear supports jumbo (or "superjumbo" as the IEEE calls it). See http://darkwing.uoregon.edu/~joe/jumbo-clean-gear.html for a list. The IEEE refuses to standardize it in part because it breaks the zero configuration "plug and play" usage model for ethernet. > A better approach is to exchange MTU information at the neighbor > discovery / ARP stage. That way, you're not breaking anything that > your correspondent may be depending on. The problem with an explicit protocol solution is that you have to get both parties to deploy it before anybody gets any gain. Why should the router vendors implement it if no hosts support it and vice versa? This is why it is important that RFC 4821 unilaterally solves some other problems. Although jumbo ARP is a hack^H^H^H^H workaround, it has the advantage that any vendor can unilaterally implement and market a product that solves the router part of mixed MTU subnet problem (or so I think). Furthermore they can do so even in advance of a standard! (In the style of 4821 you send ARP padded out to the MTU that you want to test.) Which is why I think it is so awesome that the first hit I see when googling "jumbo arp" is online documentation for one of the more popular switch/routers out in the field today. You could consider adding a padding option to neighbor discovery, in the style of RFC4820. Thanks, --MM-- _______________________________________________ Int-area mailing list [email protected] https://www1.ietf.org/mailman/listinfo/int-area
