North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: MTU of the Internet?

  • From: Dan Foster
  • Date: Thu Feb 05 20:26:04 1998

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: [email protected] (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: <[email protected]>

In article <[email protected]>, [email protected] (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

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

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.


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: ]