RE: Meta-issues: On the deprecation of the fragmentation function

"Manfredi, Albert E" <albert.e.manfredi@boeing.com> Tue, 09 July 2013 21:21 UTC

Return-Path: <albert.e.manfredi@boeing.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0747311E8169 for <ipv6@ietfa.amsl.com>; Tue, 9 Jul 2013 14:21:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NoVHJ9yVYAtG for <ipv6@ietfa.amsl.com>; Tue, 9 Jul 2013 14:21:17 -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 CF9B821F9D3A for <ipv6@ietf.org>; Tue, 9 Jul 2013 14:21:11 -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 r69LL2XB016437 for <ipv6@ietf.org>; Tue, 9 Jul 2013 14:21:02 -0700
Received: from XCH-PHX-408.sw.nos.boeing.com (xch-phx-408.sw.nos.boeing.com [137.136.239.50]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id r69LL1Dq016421 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Tue, 9 Jul 2013 14:21:01 -0700
Received: from XCH-BLV-213.nw.nos.boeing.com (137.136.239.117) by XCH-PHX-408.sw.nos.boeing.com (137.136.239.50) with Microsoft SMTP Server (TLS) id 14.2.328.11; Tue, 9 Jul 2013 14:21:01 -0700
Received: from XCH-PHX-503.sw.nos.boeing.com ([169.254.3.45]) by XCH-BLV-213.nw.nos.boeing.com ([169.254.13.32]) with mapi id 14.02.0328.011; Tue, 9 Jul 2013 14:21:01 -0700
From: "Manfredi, Albert E" <albert.e.manfredi@boeing.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
Subject: RE: Meta-issues: On the deprecation of the fragmentation function
Thread-Topic: Meta-issues: On the deprecation of the fragmentation function
Thread-Index: AQHOfLVaZnTlKlB4FkOxCA1WCzV5ipldAU2AgAAN9ACAADiygP//kGpg
Date: Tue, 09 Jul 2013 21:21:00 +0000
Message-ID: <021E64FECA7E5A4699562F4E667164810B4641B0@XCH-PHX-503.sw.nos.boeing.com>
References: <FAD482FE-4583-472A-8B57-E789A942686E@gmail.com> <1DF7BDE3-1490-41FE-A959-EC8EC54B0A5F@tzi.org> <8B84E185-36AC-4F22-A88E-5A2F1200AE8B@gmail.com> <51DC77B1.9020206@gmail.com>
In-Reply-To: <51DC77B1.9020206@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [137.136.248.6]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-TM-AS-MML: disable
Cc: "ipv6@ietf.org" <ipv6@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 09 Jul 2013 21:21:25 -0000

> From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of Brian
> E Carpenter

> On 10/07/2013 05:28, RJ Atkinson wrote:
> ...
> >> But for one problem: adaptation layer fragmentation is
> >> *transparent*, so there is no way for an application
> >> to do the equivalent of PMTUD to avoid/minimize adaptation
> >> layer fragmentation.
> >
> > Good point.
> 
> And you can't get round it. The decision to raise the minimum link
> MTU from 576 to 1280 was not a change in principle; it was just
> raising the level at which transparent adaptation layers were
> presumed to be acceptable. The big change in principle was the
> abolition of on-path fragmentation.

I'm not sure I follow this.

First is, the change of MTU was not one of 576 to 1280. It was one of 64 to 1280. That 576 figure is the smallest maximum RECONSTITUTED packet size that IPv4 is supposed to support. Individual fragments need not be larger than 64 bytes. If that same principle had been applied to IPv6, maybe we wouldn't be having these discussions at all.

The other point is, I don't see how transparent adaptation layers are an issue at all? I don't think anyone is saying that it's impossible to transmit IPv6 over ATM cells? Or are they?

Bert