RE: [RAM] Tunneling overheads and fragmentation
"Templin, Fred L" <Fred.L.Templin@boeing.com> Thu, 19 July 2007 15:52 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 1IBYIY-0001L7-Kx; Thu, 19 Jul 2007 11:52:14 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBYIX-0001Ih-5t for ram@iab.org; Thu, 19 Jul 2007 11:52:13 -0400
Received: from slb-smtpout-01.boeing.com ([130.76.64.48]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBYIV-0002Gt-UB for ram@iab.org; Thu, 19 Jul 2007 11:52:13 -0400
Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [192.42.227.216]) by slb-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id l6JFq1Rx007967 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 19 Jul 2007 08:52:09 -0700 (PDT)
Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id l6JFq1r3024992; Thu, 19 Jul 2007 08:52:01 -0700 (PDT)
Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by blv-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id l6JFppAX024535; Thu, 19 Jul 2007 08:51:53 -0700 (PDT)
Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Jul 2007 08:51:52 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [RAM] Tunneling overheads and fragmentation
Date: Thu, 19 Jul 2007 08:51:51 -0700
Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1029ED923@XCH-NW-7V2.nw.nos.boeing.com>
In-Reply-To: <469F7673.6070702@firstpr.com.au>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [RAM] Tunneling overheads and fragmentation
Thread-Index: AcfKEfkUQzGoWhzSTP6njcVAkts22gAChTxw
References: <469F7673.6070702@firstpr.com.au>
From: "Templin, Fred L" <Fred.L.Templin@boeing.com>
To: Robin Whittle <rw@firstpr.com.au>, ram@iab.org
X-OriginalArrivalTime: 19 Jul 2007 15:51:52.0155 (UTC) FILETIME=[B96382B0:01C7CA1C]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81
Cc:
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
Robin, This may not address all of your questions, but here is something that may help with IPv6-in-IPv4 tunnel MTUs: http://www.ietf.org/internet-drafts/draft-templin-linkadapt-06.txt See also RFCs 4459 and 4821. Fred fred.l.templin@boeing.com > -----Original Message----- > From: Robin Whittle [mailto:rw@firstpr.com.au] > Sent: Thursday, July 19, 2007 7:34 AM > To: ram@iab.org > Subject: [RAM] Tunneling overheads and fragmentation > > 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 > _______________________________________________ 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