Re: A question of small MTUs
William Ivancic <[email protected]> Wed, 13 Nov 2002 20:48:24 -0500
| Newsgroups | gmane.ietf.pilc |
|---|---|
| Message-ID | <[email protected]> |
I'm not sure about the largest or smallest MTU size, but I thought it may be appropriate to note some behaviors and problems we were having with MTU discovery over mobile networks using mobile-IPv4 double tunnels and encryption. The mobile-IPv4 mobile networking we are using applies double tunnels from the home agent to the foreign agent when foreign agent service is used. Adding encryption on top of that hides MTU discovery. To add to the problem, somewhere the don't fragment bit is being set - perhaps in some applications or at some Web servers. Thus, we manually have to set the Max MTU in the hosts on the mobile LAN or set the minimum acceptable MTU size at the last visible interface to the mobile LAN. We haven't had much time to really track this problem down and analyze it. But we have experienced it. I think this is a problem that needs to be recognized by the NEMO groups. Were is the best place to address it is yet to be determined. I think the problems are noted in various RFCs, but the implementations are not always followed. In our particular case, I suspect the encryption units are not following the appropriate advice for IPSec or IP-in-IP. Also, there may be ICMP filtering to some locations. At 05:09 PM 11/13/02 -0500, Matt Mathis wrote: >Kevin Lehey, John Heffner and I are working on a replacement for RFC1191 style >path MTU discovery (See RFC2923 for some of the reasons...). > >In our current design there is an open question about what is the smallest >MTU >that is cost effective to discover dynamically. ........ >Asked another way, what is the smallest MTU that is (more than occasionally) >used as an intermediate link between general purpose systems You may want to contact some military folks regarding this. They have some very small bandwidths and long delays. They may be using small MTU's to get small messages through the network quicker. The aeronautics group may also have similar problems, but they expected to eventually. Will _______________________________________________ pilc mailing list [email protected] https://www1.ietf.org/mailman/listinfo/pilc http://www.ietf.org/html.charters/pilc-charter.html http://pilc.grc.nasa.gov/