|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: MTU of the Internet?
Marc Slemko writes... > On Thu, 5 Feb 1998, Phil Howard wrote: > > > IMHO setting DF should not be allowed where the MTU is greater than 576, > > or whatever number today constitutes the "minimum reasonable requirement" > > which I would say isn't larger than 1006. Maybe in a few years we can > > kiss SLIP bye-bye and make sure everything is 1500. > > Erm... no. The whole point of setting the DF bit is to avoid > fragmentation. Read up on path MTU discovery to see why it is a good > thing. Just because braindead filters cause problems is no reason to > suggest that PMTU discovery is bad. It becomes even more critical in IPv6 > where routers don't fragment period, so people had better get used to it. > > Trying to force everyone to have the same MTU simply is not practical. > You will always have systems with higher path MTUs that can get a gain > from knowing it and you will always have systems with lower MTUs for > whatever reason. 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. What's the mechanism for negotiating packet size in IPv6 and how to does it deal with minimal routers in between? Does it have an MTU discovery? 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 needs to take place across TCP, UDP, and whatever else is just above IP, but putting that over in ICMP is, IMHO, part of the problem. It would not violate the statelessness principle to allow a transit router to send back something entirely outside of the concept of ICMP to do MTU discovery since that doesn't involve storing any state of any connections in transit routers. -- Phil Howard | [email protected] [email protected] [email protected] phil | [email protected] [email protected] [email protected] at | [email protected] [email protected] [email protected] milepost | [email protected] [email protected] [email protected] dot | [email protected] [email protected] [email protected] com | [email protected] [email protected] [email protected]
|