Re: Path-MTU-discovery

[woods () weird com (Greg A. Woods)]

[ On Sunday, July 16, 2000 at 12:29:39 (-0400), Bennett Todd wrote: ]
> Subject: Re: RFC 1918
>
> The only place where this is a problem is where people are trying to
> run Path MTU Discovery, and so have servers that are initiating
> sessions with packets with the Don't Frag bit set, and then have
> firewalls or load balancers or something blocking the ICMP Must Frag
> error returns.

You make it sound as if only a tiny fraction of the servers on the
Internet try to do Path-MTU-discovery!   ;-)

Experience is beginning to suggest that it's the vast majority of them
that use PMTUd now.  Where it doesn't work _at_all_ on the "client" side
you quickly find out that perhaps as many as 2/3's (anecdotally
measured) of the "popular" web servers out there seem to be unusable
(despite the fact that you can make initial contact with them), and
perhaps as many as 50% (again from anecdotal evidence) of the SMTP
servers suffer similar problems (though that latter ratio might actually
be higher since there's a much greater chance that a small e-mail will
get through where even the smallest component on most web pages is too
big).

Indeed direct knowledge of some commonly used server systems reveals
that they come configured by default to do Path-MTU-discovery, and
further analysis shows that at least some such implementations have less
perfect "MTU-discovery black hole detection" algorithms....

I.e. Path-MTU-discovery is frequently used and not all parties on the
path may know it's being used, and since people running servers cannot
predict ahead of time which paths might have lower MTUs and which might
also have problems passing the ICMP replies necessary for successful
PMTUd, problems are inevitable and at the same time difficult to detect,
let alone diagnose.  In other words if you're a network operator and you
think you're smarter than the average bear and you *know* how to use
RFC1918 addresses on your publicly accessible network interfaces then
Path-MTU-discovery is just one more thing you really *MUST* be aware of
and take great care to protect lest you draw the ire of users globally.
So far I haven't had any noticable problems with network providers
actually interfering with PMTUd, though with the vast increase in
numbers of servers doing this by default I'm sure it won't be long
before someone stumbles....

As I mentioned already one of the very real problems with using RFC1918
addresses on server hosts behind load balancers and NAT'ed firewalls is
with protocols such as IDENT.

-- 
                                                        Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods () acm org>      <robohack!woods>
Planix, Inc. <woods () planix com>; Secrets of the Weird <woods () weird com>