IETF Logo Mail Archive

RE: Responding to Ron's comment about removing fragmentation

Ronald Bonica <rbonica@juniper.net> Fri, 14 November 2014 20:44 UTC

Return-Path: <rbonica@juniper.net>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 427C11A90C0 for <ipv6@ietfa.amsl.com>; Fri, 14 Nov 2014 12:44:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.902
X-Spam-Level:
X-Spam-Status: No, score=-101.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nsegqcniVoBd for <ipv6@ietfa.amsl.com>; Fri, 14 Nov 2014 12:44:35 -0800 (PST)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0746.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:746]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A3031A90AA for <ipv6@ietf.org>; Fri, 14 Nov 2014 12:44:34 -0800 (PST)
Received: from CO1PR05MB442.namprd05.prod.outlook.com (10.141.73.146) by CO1PR05MB441.namprd05.prod.outlook.com (10.141.73.147) with Microsoft SMTP Server (TLS) id 15.1.16.15; Fri, 14 Nov 2014 20:44:11 +0000
Received: from CO1PR05MB442.namprd05.prod.outlook.com ([169.254.13.170]) by CO1PR05MB442.namprd05.prod.outlook.com ([169.254.13.170]) with mapi id 15.01.0016.006; Fri, 14 Nov 2014 20:44:12 +0000
From: Ronald Bonica <rbonica@juniper.net>
To: Erik Nordmark <nordmark@acm.org>, IETF IPv6 <ipv6@ietf.org>
Subject: RE: Responding to Ron's comment about removing fragmentation
Thread-Topic: Responding to Ron's comment about removing fragmentation
Thread-Index: AQHQAEm799KQrv3ciUuGEEY7xCNJG5xglUuQ
Date: Fri, 14 Nov 2014 20:44:11 +0000
Message-ID: <4ee7bd6bbd61425a8720dcd6ac402854@CO1PR05MB442.namprd05.prod.outlook.com>
References: <5466662F.6080400@acm.org>
In-Reply-To: <5466662F.6080400@acm.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [66.129.241.11]
x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB441;
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB441;
x-forefront-prvs: 03950F25EC
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(189002)(377454003)(51704005)(13464003)(76176999)(74316001)(92566001)(66066001)(97736003)(122556002)(20776003)(108616004)(64706001)(4396001)(50986999)(54356999)(33646002)(87936001)(99396003)(101416001)(120916001)(19580395003)(105586002)(76576001)(95666004)(107046002)(19580405001)(31966008)(107886001)(46102003)(2656002)(99286002)(62966003)(40100003)(77156002)(86362001)(77096003)(106356001)(106116001)(21056001)(24736002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB441; H:CO1PR05MB442.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/Ysbs1ROqrE1rxcf7dhpVeQakGwc
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
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: Fri, 14 Nov 2014 20:44:39 -0000

Erik,

In one sense, I agree with you. Encapsulation is the best argument for fragmentation.

However, I think the designers of IPv6 anticipated the problem. Knowing that most interfaces support a 1500 byte MTU, the designers specified a required MTU of 1280. This leaves 220 bytes for encapsulation.

BTW, I don't intend to resurrect draft-bonica-6man-frag-deprecate. There doesn't appear to be WG support for that.

                                                                                    Ron



> -----Original Message-----
> From: Erik Nordmark [mailto:nordmark@acm.org]
> Sent: Friday, November 14, 2014 3:30 PM
> To: IETF IPv6; Ron Bonica
> Subject: Responding to Ron's comment about removing fragmentation
> 
> [Ran out of mike line]
> 
> I don't know of a way to handle encapsulation (such as router doing GRE, IP-
> IP, IPsec tunnels) if we
>   - allow hosts to send 1280 byte packets with doing path MTU discovery
>   - don't allow the encapsulating node to fragment the packet (which is at
> least 1320 bytes after adding the outer headers)
> 
> Thus removing all support for fragmentation from IPv6 has the implication of
> removing all forms of IPv6 packet encapsulation from the
> IPv6 architecture.
> 
> Such a radical change doesn't make any sense to me.
> 
>     Erik
> 
> 
>

v2.23.0 | Report a Bug | By Email