Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop

"Templin, Fred L" <Fred.L.Templin@boeing.com> Tue, 23 October 2012 16:08 UTC

Return-Path: <Fred.L.Templin@boeing.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7416621F86D2 for <v6ops@ietfa.amsl.com>; Tue, 23 Oct 2012 09:08:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.448
X-Spam-Level:
X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QuKJ8a9Zmh-H for <v6ops@ietfa.amsl.com>; Tue, 23 Oct 2012 09:08:29 -0700 (PDT)
Received: from slb-mbsout-02.boeing.com (slb-mbsout-02.boeing.com [130.76.64.129]) by ietfa.amsl.com (Postfix) with ESMTP id EAD5A21F86E8 for <v6ops@ietf.org>; Tue, 23 Oct 2012 09:08:28 -0700 (PDT)
Received: from slb-mbsout-02.boeing.com (localhost.localdomain [127.0.0.1]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id q9NG8RYS028265 for <v6ops@ietf.org>; Tue, 23 Oct 2012 09:08:28 -0700
Received: from XCH-NWHT-11.nw.nos.boeing.com (xch-nwht-11.nw.nos.boeing.com [130.247.25.114]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id q9NG8QIL028237 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Tue, 23 Oct 2012 09:08:26 -0700
Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.120]) by XCH-NWHT-11.nw.nos.boeing.com ([130.247.25.114]) with mapi; Tue, 23 Oct 2012 09:08:26 -0700
From: "Templin, Fred L" <Fred.L.Templin@boeing.com>
To: "Fred Baker (fred)" <fred@cisco.com>, Fernando Gont <fgont@si6networks.com>
Date: Tue, 23 Oct 2012 09:08:25 -0700
Thread-Topic: [v6ops] new draft: draft-taylor-v6ops-fragdrop
Thread-Index: AQHNsTYUCYKb2mXLAUaEZRxVoFGtdpfHC0hg
Message-ID: <E1829B60731D1740BB7A0626B4FAF0A65E0DFE48D6@XCH-NW-01V.nw.nos.boeing.com>
References: <201210161245.q9GCj0i26478@ftpeng-update.cisco.com> <E1829B60731D1740BB7A0626B4FAF0A65E0DEDF3A2@XCH-NW-01V.nw.nos.boeing.com> <507DA6A3.20807@inex.ie> <E1829B60731D1740BB7A0626B4FAF0A65E0DEDF3C3@XCH-NW-01V.nw.nos.boeing.com> <507DAB13.2010704@inex.ie> <E1829B60731D1740BB7A0626B4FAF0A65E0DEDF3CE@XCH-NW-01V.nw.nos.boeing.com> <508655FA.1080407@si6networks.com> <8C48B86A895913448548E6D15DA7553B184867@xmb-rcd-x09.cisco.com>
In-Reply-To: <8C48B86A895913448548E6D15DA7553B184867@xmb-rcd-x09.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-TM-AS-MML: No
Cc: "v6ops@ietf.org" <v6ops@ietf.org>, "draft-taylor-v6ops-fragdrop@tools.ietf.org" <draft-taylor-v6ops-fragdrop@tools.ietf.org>
Subject: Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/v6ops>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 23 Oct 2012 16:08:29 -0000

> -----Original Message-----
> From: Fred Baker (fred) [mailto:fred@cisco.com]
> Sent: Tuesday, October 23, 2012 8:50 AM
> To: Fernando Gont
> Cc: Templin, Fred L; v6ops@ietf.org; draft-taylor-v6ops-
> fragdrop@tools.ietf.org
> Subject: Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop
> 
> 
> On Oct 23, 2012, at 1:31 AM, Fernando Gont wrote:
> 
> > On 10/16/2012 03:49 PM, Templin, Fred L wrote:
> >> Plus, if we can't rely on ICMP PTB and we can't rely on IPv6
> >> fragmentation/reassembly, then all we are left with is 1280
> >> and IPv6 is the new ATM...
> >
> > ... and that's assuming no translators, and that the IPv6 Internet
> > really complies with the minimum IPv6 MTU (something that some argue
> > that it's not the case).
> 
> One could argue that IPv6 setting a minimum MTU and placing requirements
> on the underlying link layers is ill-considered. The underlying link
> layers are what they are. Some of the more amazing bits of 6lowpan are
> driven by that mismatch between IPv6 and 802.15.4.

Setting the minimum MTU on a tunnel has another problem; for example,
what if that tunnel (tunnel 'A') enters another tunnel (tunnel 'B')
that also sets the minimum MTU? The 1280 packets encapsulated by
'A' show up at 'B' as (1280 + 40) = 1320 packets which are then are
dropped at 'B' because they are too big. Then, if the ICMP PTBs
generated by 'B' are lost on the return path to 'A' -> black hole.

Picking a fixed size 'S' for a tunnel always runs the risk that
that size will be wrong for some paths. Setting the MTU to
infinity and performing subnetwork adaptation when necessary
avoids the black holes.

Thanks - Fred
fred.l.templin@boeing.com