Re: [Int-area] Discussion about Section 6.1 in draft-ietf-intarea-frag-fragile

Geoff Huston <gih@apnic.net> Tue, 10 September 2019 22:54 UTC

Return-Path: <gih@apnic.net>
X-Original-To: int-area@ietfa.amsl.com
Delivered-To: int-area@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F3DA12006B; Tue, 10 Sep 2019 15:54:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=apnic.onmicrosoft.com
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 QQfsc4ErgwOD; Tue, 10 Sep 2019 15:54:05 -0700 (PDT)
Received: from APC01-SG2-obe.outbound.protection.outlook.com (mail-eopbgr1310057.outbound.protection.outlook.com [40.107.131.57]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D37F0120074; Tue, 10 Sep 2019 15:54:04 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=UTsWORsUnWD6UiSUrnaE8OdAHYT61K6OtLS1He+Z4AbzjPzLZLuBVM8pRVdLu3cXtLc5VVQHDJTCz8JWGIxf3iVTcw+FHCW9QYUOK+FFOOS2yQYFx5aTr54BDQg+ieueR6mwF0VzoT8odrl8UKSY4gFgSxV5/2gCToR0QXfuJOxB9+V7aR0AXfJgMylGt7RulU0f7uHepCHCveTS0+iFSz7uEcKKkUXl3LLwiAOfkVWmC0ODBHAcNWBJyt/GpXnmmsNJZO+LQm7S4vkn5QFJ+pozUccPLQUWQJrwpom2KRNnFcwG4ULaXGi82bLkPtoPs7QQ8greK/VBT03JgWuaJA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=FSsq2W70KduhAHNWnN+SND5jk+17Z+brQ3FuyjQ6ba8=; b=cp8+dtWiwGbgDqrBZffHMVPBK/Pmo5IEy5139whR7gdVPf/9IHrNgJaf1sjKJlnc8PE2p0kvYZCFbaGXbiyo6wSx5BR4Et9nqcpmiVV3j+Mt2XSy/G/IHRsLctnRuNv+9DpVbgDTgEgz9xPVWmBT865vjj2bdlanM6KXH8x/ahUrvhDYzt0QscnormYoflFjxxAQ04UTk7+BbT5oA1MMyW4v+W9LOgBq4CC0CZPf9oSnkKi0HjNS8tFuZzChrWlAab5ptKptAQjZ5LG9rIzJ9nY2etZsXHNY/9JeUE4xrQOiSdI1oVSP0sBv8ZNvTBdfJwkJ2j33VGFNnR/GE4WavA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=apnic.net; dmarc=pass action=none header.from=apnic.net; dkim=pass header.d=apnic.net; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apnic.onmicrosoft.com; s=selector2-apnic-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=FSsq2W70KduhAHNWnN+SND5jk+17Z+brQ3FuyjQ6ba8=; b=BSGOyraL+5I1Dtm87rmvNr3DUvDqjw9jOw840JesjIyZA+PHXx8armQl5rkcy4txcgDSzctu8DulKgB/1cmFjM2Qk4sljq0rkRg6xhvTVHpOOQol6VvwClqiFP6lhIyByxYKJv2WDUDjAPAdkc7Y5650P9PV5tT5msHhXz1Ws7U=
Received: from PS1PR04MB2839.apcprd04.prod.outlook.com (52.133.231.81) by PS1PR04MB2902.apcprd04.prod.outlook.com (52.133.231.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2241.14; Tue, 10 Sep 2019 22:53:56 +0000
Received: from PS1PR04MB2839.apcprd04.prod.outlook.com ([fe80::9e1:a63e:6ef0:d252]) by PS1PR04MB2839.apcprd04.prod.outlook.com ([fe80::9e1:a63e:6ef0:d252%7]) with mapi id 15.20.2241.018; Tue, 10 Sep 2019 22:53:56 +0000
From: Geoff Huston <gih@apnic.net>
To: "Templin (US), Fred L" <Fred.L.Templin@boeing.com>
CC: Fernando Gont <fgont@si6networks.com>, Joe Touch <touch@strayalpha.com>, Bob Hinden <bob.hinden@gmail.com>, "draft-ietf-intarea-frag-fragile@ietf.org" <draft-ietf-intarea-frag-fragile@ietf.org>, "int-area@ietf.org" <int-area@ietf.org>, IESG <iesg@ietf.org>, Suresh Krishnan <suresh@kaloom.com>
Thread-Topic: [Int-area] Discussion about Section 6.1 in draft-ietf-intarea-frag-fragile
Thread-Index: AQHVZEQhWrTP8m/s+UeOdIBS0MPssKcd2XEAgAAupgCAAClggIAAgMuAgAAKBYCAAAumAIAACLSAgAGpSwCAAALdgIADWf8AgAEYNICAAJ21gA==
Date: Tue, 10 Sep 2019 22:53:56 +0000
Message-ID: <91894E0E-09D3-42E4-B6C4-88AE4493D796@apnic.net>
References: <efabc7c9f72c4cd9a31f56de24669640@boeing.com> <2EB90A57-9BBD-417C-AEDB-AFBFBB906956@gmail.com> <CAHw9_iKozCAC+8TGS0fSxVZ_3pJW7rnhoKy=Y3AxLqWEXvemcA@mail.gmail.com> <4C8FE1C4-0054-4DA1-BC6E-EBBE78695F1B@gmail.com> <BYAPR05MB5463F112A3FFA8CE6378F3D3AEBB0@BYAPR05MB5463.namprd05.prod.outlook.com> <ab0d5600-d71c-9f0b-2955-64074e040bc6@strayalpha.com> <E770BEF0-D901-4CD0-96E6-C626B560DCD6@gmail.com> <163CD364-2975-467A-8925-F114FFD9C422@employees.org> <E00B6159-2771-42D8-B5E8-7750E0B828DE@strayalpha.com> <3764D860-BC6F-441A-86EF-59E1742D7654@employees.org> <939AFA6F-4C75-4532-82DE-77D14ABC41ED@strayalpha.com> <5C51DCDC-4031-47D9-A28E-812D0E66EE35@employees.org> <5DAA16CC-791E-4042-95F6-65DA58D23EB8@gmail.com> <EA3B45A1-FFD2-49A5-B577-602065632F41@strayalpha.com> <5d22dd34-3972-060e-ddc1-b7f27a110a69@si6networks.com> <14f06217149d40ba8a41865ebb08ee08@boeing.com>
In-Reply-To: <14f06217149d40ba8a41865ebb08ee08@boeing.com>
Accept-Language: en-AU, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-clientproxiedby: SG2PR06CA0205.apcprd06.prod.outlook.com (2603:1096:4:68::13) To PS1PR04MB2839.apcprd04.prod.outlook.com (2603:1096:803:40::17)
x-originating-ip: [58.137.176.10]
authentication-results: spf=none (sender IP is ) smtp.mailfrom=gih@apnic.net;
x-ms-exchange-messagesentrepresentingtype: 1
x-mailer: Apple Mail (2.3445.104.11)
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 4d30c719-5fb5-4df6-b559-08d73641c288
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600166)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:PS1PR04MB2902;
x-ms-traffictypediagnostic: PS1PR04MB2902:
x-ms-exchange-purlcount: 1
x-microsoft-antispam-prvs: <PS1PR04MB2902F522FC84AC0F6E1D6746B8B60@PS1PR04MB2902.apcprd04.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 01565FED4C
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(366004)(136003)(376002)(346002)(396003)(39840400004)(199004)(189003)(66446008)(64756008)(66946007)(66556008)(66476007)(11346002)(186003)(50226002)(6506007)(81166006)(81156014)(8676002)(102836004)(36756003)(33656002)(229853002)(386003)(305945005)(7736002)(76176011)(8936002)(6486002)(446003)(6116002)(2616005)(3846002)(53936002)(86362001)(478600001)(966005)(5660300002)(14444005)(6916009)(26005)(256004)(486006)(2906002)(14454004)(71190400001)(6512007)(6436002)(476003)(54906003)(71200400001)(316002)(6246003)(25786009)(4326008)(66066001)(99286004)(6306002)(52116002); DIR:OUT; SFP:1101; SCL:1; SRVR:PS1PR04MB2902; H:PS1PR04MB2839.apcprd04.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: apnic.net does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: Tucrp19WAV0PTxQ2JBhA7TvEK6LQh2/OoaOHEvF01VWfQJIWIsbbxC0w8UAh6mpW5jTM969ch69i9zXsUs9Cn/kwm26b5rA0x/RlD6FQGLfurI9U5ZO7w0073z3J8B5p6xY9DnlVYFZbO8MtnN9+x7L1/1icY6WTqlHGzrL6eCL3Rk6WWezU6XyDPLa8x/bzZuYuBRAbnYJ1+0rtGoEQQxOivfI/GmFOoyNS6JU3w6Yvmn67yRQFPXZA+0aXUgPucUyfxxK3kCvbICvvdPJXaeDGXRj5qhYrKTmTbn/NJleXF33yz+q7t4uVywA15YdAyvOijC6DswZXTMld02G5XgBIUPMuudXdR162s191DjtVMxe4V0+N0s3sB6oh4KHBzXVtwpElTx6nOrMr51VxUVinwl4/Y2C0mWLHxCsv+bQ=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-ID: <DE81EC40C83C4840821EE153F6D57851@apcprd04.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: apnic.net
X-MS-Exchange-CrossTenant-Network-Message-Id: 4d30c719-5fb5-4df6-b559-08d73641c288
X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Sep 2019 22:53:56.3006 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 127d8d0d-7ccf-473d-ab09-6e44ad752ded
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: b8QZwdyzA4zfhmaYt4f1KUHAug/iQY83dN0VLzhrwIbROCZt5ZbabcZf/vvClJaM
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PS1PR04MB2902
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-area/Wpv1jT6UQt6KlzrdIoZSSLF-7XA>
Subject: Re: [Int-area] Discussion about Section 6.1 in draft-ietf-intarea-frag-fragile
X-BeenThere: int-area@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF Internet Area Mailing List <int-area.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/int-area>, <mailto:int-area-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/int-area/>
List-Post: <mailto:int-area@ietf.org>
List-Help: <mailto:int-area-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/int-area>, <mailto:int-area-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Sep 2019 22:54:08 -0000

>> 
>> This would seem to be incorrect. IP has a minimum MTU of 68 bytes, and
>> IPv6 has a minimum MTU of 1280. Hence if you send packets smaller than
>> or equal to the minimum MTU, the packets should go through.
> 
> Even if the original source uses the IPv6 minimum MTU of 1280, a tunnel somewhere
> further down the path could add encapsulations that would cause the (encapsulated)
> packet to exceed 1280 bytes. The tunnel therefore has to apply fragmentation.

I hesitate to venture into this thread but I did a bit of digging around in the mail archives some time ago to figure out “why 1280?” as the IPv6 MTU. The desire was to lift the minimum unfragmented packet from 64 bytes (IPv4) to something that would reflect what was possible that would all but eliminate the need for fragmentation in IPv6. But at the same time there was the awareness of various forms of encapsulation and the possibility of multiple levels. 1500 octets was taken as the stating point and in the end 1280 was proposed. Why 1280? Because its the number you get when you add 1024 and 256. However, it expressed a basic idea that 1480 (IPv6 in IPv4), 1460 (IPv6 in IPv6), or any other number ‘close’ to 1500 could not. It allowed for almost any form of encapsulation of an IPv6 packet that we would be likely to see and the result would still  be within the 1500 ethernet framing limit and hence avoid a path MTU mismatch. From this starting point it is odd odd to see an argument about packet size that _starts_ with 1280 as some lower level media-related packet limit (it isn’t) and then applies encapsulation models on this. If we really are going to go through such an exercise then it would be more realistic to start with the number 1500 and apply encapsulation to that number. 

Secondly, it is interesting to look at what IPv6 stacks actually do with local MTU values. Do they all use 1280? nope! The most common value is 1430. (see http://www.potaroo.net/ispcol/2019-07/mss.html) 

So I personally don't see any practical value in this line of logic that says: "start with a source using a MTU of 1280 and apply encapsulation”

But I’ve said enough - I’m heading back back to lurking in this rather protracted and messy thread.

g