2000-07-14-20:06:30 Shawn McMahon:

On Fri, Jul 14, 2000 at 07:42:08PM -0400, Greg A. Woods wrote:

...

Unfortunately an increasing number of Internet users, with servers I might add, are now behind DSL lines that have <1500-byte MTUs..... [...] So what are we going to do, folks; are we going to react to people who are in this situation by saying "oh, well; guess I'm walled off from you, too bad, so sad, dump that $50 connection and get a T1 or get off my Internet", or are we going to adapt?

What kind of adaptation is necessary? Traditionally that sort of thing hasn't been a problem; that's what fragmentation is for. If Path MTU Discovery is working it's even less of a problem: if there's a link MTU in the middle of a path that's smaller than the MTUs of the final links at each end, then Path MTU Discovery will find out and adjust the session MTU to fit. 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. And to haul this back to the original thread, I've still heard no claim made that there's an operational problem introduced by using RFC 1918 addrs for endpoints of router-router links where neither router routes traffic over interfaces with different MTUs. If people don't want whiners niggling them about the RFC 1918 addrs showing up in traceroutes, they should just put RFC 1918 filters on their borders, so that the whiners simply won't get returns to their traceroutes. -Bennett

[ 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>