[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
- RE: [RAM] Tunneling overheads and fragmentation Templin, Fred L
- [RAM] Tunneling overheads and fragmentation Robin Whittle
- [RAM] Re: Tunneling overheads and fragmentation Stephane Bortzmeyer
- Re: [RAM] Re: Tunneling overheads and fragmentati… Iljitsch van Beijnum
- Re: [RAM] Re: Tunneling overheads and fragmentati… David Meyer
- Re: [RAM] Tunneling overheads and fragmentation Wassim Haddad
- Re: [RAM] Tunneling overheads and fragmentation Robin Whittle
- Re: [RAM] Tunneling overheads and fragmentation Gert Doering
- Re: [RAM] Tunneling overheads and fragmentation Robin Whittle
- Re: [RAM] Tunneling overheads and fragmentation Marshall Eubanks
- Re: [RAM] Tunneling overheads and fragmentation Robin Whittle
- Re: [RAM] Tunneling overheads and fragmentation Iljitsch van Beijnum
- Re: [RRG] Re: [RAM] Tunneling overheads and fragm… Iljitsch van Beijnum
- Re: [RRG] Re: [RAM] Tunneling overheads and fragm… Dino Farinacci
- Re: [RRG] Re: [RAM] Tunneling overheads and fragm… Iljitsch van Beijnum
- Re: [RRG] Re: [RAM] Tunneling overheads and fragm… Dino Farinacci
- Re: [RRG] Re: [RAM] Tunneling overheads and fragm… Dino Farinacci
- Re: [RRG] Re: [RAM] Tunneling overheads and fragm… Pekka Savola
- Re: [RRG] Re: [RAM] Tunneling overheads and fragm… Gert Doering
- Re: [RRG] Re: [RAM] Tunneling overheads and fragm… Gert Doering
- Re: [RRG] Re: [RAM] Tunneling overheads and fragm… Dino Farinacci