TCPIP MTU settings

philip bridge lists at bridgenet.ch
Mon Jul 26 04:22:34 EDT 1999


The problem with this approach is scalability. If the idea is that IPSec -
or any other kind of VPN technology based on IP packet encapsulation - is
to be used on an 'Internet scale', then you have the problem that
intermediate routers are being asked to fragment and reassemble at
multimegabit speeds.


OS vendors should really fix their broken MTU PD implementations.
Unfortunatly, in todays monopolistic OS environment, the pressure exerted
by competitors on each other to fix things is probably weaker than required
to overcome this problem :-(

Phil

At 23:43 19.07.99 -0500, jason.dowd at us.pwcglobal.com wrote:
>All,
>
>Again some IPSec devices, most notably Network Alchemy CryptoClusters
>(www.network-alchemy.com), will allow you to specify that the don't
>fragment bit, which NT loves to set, not be copied from the inner header
>when encapsulating. The VPN gateway or any other router in the path can
>then happily fragment the overgrown packets until the other end of the
>IPSec tunnel is encountered. The receiving end then reconstructs the
>original datagram from the fragments and sends it on its way.
>
>This is a much better option than manually setting MTU sizes down on all
>servers, and it does not require that the OS handle any returning ICMP
>messages on dropping a packet that has swelled due to encapsulation. The
>discussion in RFC 2401 encourages vendors to support this sort of behavior
>in order to deal with exactly this problem. Evidently not all IPSec vendors
>have heeded their warnings.
>
>Jason Dowd
>Senior Associate
>PricewaterhouseCoopers
>
>
>
>
>Eric Henriksen <eric_h at earthlink.net> on 07/19/99 02:38:17 PM
>
>Please respond to Eric Henriksen <eric_h at earthlink.net>
>To:   guy.raymakers at europe.eds.com, vpn at listserv.secnetgroup.com
>cc:
>Subject:  Re: TCPIP MTU settings
>
>
>
>
>Encapsulation increases full MTU packets beyond the legal packet length,
>thus causing retransmission.  Set the MTU to allow for an additional IP
>header (20 bytes), plus the ESP header (maybe 38 bytes, depending).
>These retransmissions can result in throughput and packet loss problems,
>and are likely to occur in any encapsulation protocol.
>
>-----Original Message-----
>From: guy.raymakers at europe.eds.com <guy.raymakers at europe.eds.com>
>To: vpn at listserv.secnetgroup.com <vpn at listserv.secnetgroup.com>
>Date: Monday, July 19, 1999 7:48 AM
>Subject: TCPIP MTU settings
>
>
>>
>>
>>
>>Hi,
>>
>>We have discovered following problem
>>
>>The remote network (offices) have a NT server and an IPsec enabled router.
>The
>>router encapsulates the TCP/IP packets into IPsec packets.  When using the
>>default tcpip MTU ( = 1500), on the NT server,  we get problems when doing
>file
>>transfers. When we lower the tcpip MTU to 1444 we don't have these
>problems.
>>The remote office ISP is a different one then our ISP.
>>
>>Does anyone had similar experiences ?
>>
>>regards,
>>Guy
>>
>>
>>****************************************************************
>>TO POST A MESSAGE on this list, send it to vpn at listserv.secnetgroup.com
>>
>>The VPN FAQ (under construction) is available at
>>http://kubarb.phsx.ukans.edu/~tbird/FAQ.html
>>
>>We are currently experiencing "unsubscribe" difficulties.  If you
>>wish to unsubscribe, please send a message containing the single line
>>"unsubscribe vpn your-e-mail-address" to
>owner-vpn at listserv.secnetgroup.com
>>
>>****************************************************************
>
>
>****************************************************************
>TO POST A MESSAGE on this list, send it to vpn at listserv.secnetgroup.com
>
>The VPN FAQ (under construction) is available at
>http://kubarb.phsx.ukans.edu/~tbird/FAQ.html
>
>We are currently experiencing "unsubscribe" difficulties.  If you
>wish to unsubscribe, please send a message containing the single line
>"unsubscribe vpn your-e-mail-address" to owner-vpn at listserv.secnetgroup.com
>
>****************************************************************
>
>
>----------------------------------------------------------------
>The information transmitted is intended only for the person or entity to
>which it is addressed and may contain confidential and/or privileged
>material.  Any review, retransmission, dissemination or other use of, or
>taking of any action in reliance upon, this information by persons or
>entities other than the intended recipient is prohibited.   If you received
>this in error, please contact the sender and delete the material from any
>computer.
>
>
>****************************************************************
>TO POST A MESSAGE on this list, send it to vpn at listserv.secnetgroup.com
>
>The VPN FAQ (under construction) is available at
>http://kubarb.phsx.ukans.edu/~tbird/FAQ.html
>
>We are currently experiencing "unsubscribe" difficulties.  If you
>wish to unsubscribe, please send a message containing the single line
>"unsubscribe vpn your-e-mail-address" to owner-vpn at listserv.secnetgroup.com
>
>****************************************************************
>
______________________________________________________________
Philip Bridge	                                www.bridgenet.ch
______________________________________________________________
It might look like I'm doing nothing, but at the cellular 
level I'm really quite busy...

****************************************************************
TO POST A MESSAGE on this list, send it to vpn at listserv.secnetgroup.com

The VPN FAQ (under construction) is available at
http://kubarb.phsx.ukans.edu/~tbird/FAQ.html

We are currently experiencing "unsubscribe" difficulties.  If you
wish to unsubscribe, please send a message containing the single line
"unsubscribe vpn your-e-mail-address" to owner-vpn at listserv.secnetgroup.com

****************************************************************




More information about the VPN mailing list