|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: RFC 1918
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 Attachment:
pgp00040.pgp
|