[RAM] Tunneling overheads and fragmentation

Robin Whittle <rw@firstpr.com.au> Thu, 19 July 2007 14:34 UTC

Return-path: <ram-bounces@iab.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBX5b-0007ze-0H; Thu, 19 Jul 2007 10:34:47 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBX5Z-0007zU-N8 for ram@iab.org; Thu, 19 Jul 2007 10:34:45 -0400
Received: from gair.firstpr.com.au ([150.101.162.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBX5V-0008Oc-MK for ram@iab.org; Thu, 19 Jul 2007 10:34:45 -0400
Received: from [10.0.0.8] (zita.firstpr.com.au [10.0.0.8]) by gair.firstpr.com.au (Postfix) with ESMTP id CC52E59E3D; Fri, 20 Jul 2007 00:34:39 +1000 (EST)
Message-ID: <469F7673.6070702@firstpr.com.au>
Date: Fri, 20 Jul 2007 00:34:27 +1000
From: Robin Whittle <rw@firstpr.com.au>
Organization: First Principles
User-Agent: Thunderbird 2.0.0.4 (Windows/20070604)
MIME-Version: 1.0
To: ram@iab.org
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002
Subject: [RAM] Tunneling overheads and fragmentation
X-BeenThere: ram@iab.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Routing and Addressing Mailing List <ram.iab.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ram>, <mailto:ram-request@iab.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ram>
List-Post: <mailto:ram@iab.org>
List-Help: <mailto:ram-request@iab.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ram>, <mailto:ram-request@iab.org?subject=subscribe>
Errors-To: ram-bounces@iab.org

Can anyone help me understand the likely problems with tunneling
packets and what MTU limits might be exceeded if LISP, eFIT-APT or
Ivip is used with IPv4?

I understand that fragmentation in IPv4 is very much to be
avoided.  I understand that in IPv6, each host is supposed to
explore how long it can make the packets without getting error
messages from some router en-route whose length limit is exceeded.


eFIT-APT tunnel endpoints are always within provider networks.
With LISP the ETRs and ITRs are also probably in provider
networks.  With Ivip, ITRs could be in the end-user network,
including an ITFH function in the sending host.

What sort of limits are there likely to be with the maximum length
of IP packets on any of these routes.

For instance, if all provider and transit routers happily handle
packets significantly longer than whatever hosts normally produce
(say 1500 bytes) then adding the encapsulation won't lead to any
fragmentation.  Is this a reasonable assumption?

What about routers in end-user networks, or CE routers of providers?

I could imagine some trouble if the main TCP/IP stack of a host
produced a packet which was at the maximum length which could be
handled by its DSL modem (and the NAT function of that
modem/router) but that if an additional item of software in the
host added an Ivip header to it, then there would be problems.

Likewise if the NAT function in the host had an ITFH function
which caused packets to get longer before they actually traversed
the "modem" link and went to whatever router was at the other end
of it, which might have an MTU limit which then gets exceeded.
Perhaps a NAT device with such a function would send out different
DHCP responses with smaller MTU and MSS so the hosts would
generally be making packets which were suitable for being
encapsulated.

In Mobile IP, how do mobile nodes handle the extra length of the
packets they tunnel to their home agent?  Does the additional
mobile IP software in the host operating system somehow change the
MTU and MSS of the layer above it which is preparing packets, not
knowing they are to be further encapsulated?


 - Robin


_______________________________________________
RAM mailing list
RAM@iab.org
https://www1.ietf.org/mailman/listinfo/ram