Hot Diggety! On a dark and stormy night, Phil Howard was rumored to have said...
I agree MTU needs to be flexible. But in a protocol where MTU discovery is based on ICMP, and where filters are often implemented for ICMP without detailing, then I think DF is just as uncivilized as other bad behaviour.
It is? It would seem to me the problem here is idiots-for-network-admins, not the protocol per se. Although, yes, it would be optimal if it could work in an environment without regard to misconfigurations.
And is its MTU discovery poorly designed like in IPv4 (which looks to me like it's an afterthought). Of course MTU discovery is something that
Them be fighting words. :) Allow me to quickly educate/introduce a different viewpoint where years ago the Internet landscape was *very* different (1989), and the problems of the time basically was itty bitty pipes, and setting IP options or other schemes that would have been 'nicer' design-wise just ended up eating valuable, limited bandwidth. Below is a post from one of the RFC 1191 authors, the chair of the IETF WG who came up with PMTUD. He says it much better than I ever could regarding the context in which they operated in. Aside from that, no other comments. -Dan Foster From: mogul@actitis.pa.dec.com (Jeffrey Mogul) Newsgroups: comp.protocols.tcp-ip Subject: Re: Lost http from sites - Will PAY for Help! Date: 3 Feb 1998 01:30:51 GMT Organization: DEC Western Research Message-ID: <6b5s0b$bvk@usenet.pa.dec.com> In article <6atrrf$m6p$2@ocean.cup.hp.com>, foo@bar.baz (Rick Jones) writes: |> had the ietf gone the route for path mtu discovery based on an IP |> option, people could have filtered all the ICMP they wanted, *and* |> detecting a smaller mtu would not have required a packet |> loss...instead, what was probably seen as a quicker, cheaper solution |> (by the router vendors?) was selected, and not surprisingly, there are |> a couple problems with it As the chair of the IETF working group that came up with Path MTU Discovery, and the co-author of RFC1191, I suppose I should respond. Some of us originally proposed using an IP option. However, at the time, most members of the working group (eventually including me) believed that it would be nearly impossible to get the installed base of routers, and the vendors of new routers, to upgrade in any reasonable time. My recollection of the process was that the router vendors were not in any way dominating the decision. Also, some people objected to the IP-option mechanism on the grounds that this would inject extra packets into the Internet backbone on every connection, whereas RFC1191 doesn't inject any extra packets unless the initial MTU is too high. Remember that we started this in 1989, when "backbone" bandwidth was scarce (DS0? Certainly no higher than T1) and Van Jacobson's congestion-avoidance mechanisms had only been published the previous year. Finally, the options-based mechanism could not detect changes in the path MTU (because of a routing topology change) without explicit polling. This seemed like a drawback. In retrospect, we were probably too optimistic that vendors would not do silly things (like engineering FDDI-Ethernet bridges that obeyed the DF bit without sending an ICMP message), but generally I think we made the right decision. By the way, one could presumably set up an ICMP filter so that it allows "destination unreachable" messages (as are sent as a result of RFC1191) without allowing other ICMP messages. I know that screend-based firewalls make this easy, but I'm not sure whether other firewalls are so flexible. I'm also willing to concede that this might leave people open to denial-of-service attacks; in 1989, we weren't quite as experienced with the scum of the Internet as we are today. -Jeff P.S.: If anyone is really interested in reading the mail exchanged during the design of RFC1191, I still have the archive of the working group's mailing list ... only 600Kbytes. [Dan: He made a second post 20 minutes later saying this archive is accessible at: http://gatekeeper.dec.com/~mogul/ietf-mtudwg-archive.txt.Z ]