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

"Templin (US), Fred L" <Fred.L.Templin@boeing.com> Fri, 06 September 2019 17:43 UTC

Return-Path: <Fred.L.Templin@boeing.com>
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 B4A73120013; Fri, 6 Sep 2019 10:43:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
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 AT4tj8Oh-40c; Fri, 6 Sep 2019 10:43:58 -0700 (PDT)
Received: from clt-mbsout-01.mbs.boeing.net (clt-mbsout-01.mbs.boeing.net [130.76.144.162]) (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 E1F82120018; Fri, 6 Sep 2019 10:43:57 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by clt-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id x86HhsJ1014926; Fri, 6 Sep 2019 13:43:55 -0400
Received: from XCH16-07-07.nos.boeing.com (xch16-07-07.nos.boeing.com [144.115.66.109]) by clt-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id x86HhgHs013793 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Fri, 6 Sep 2019 13:43:42 -0400
Received: from XCH16-07-10.nos.boeing.com (144.115.66.112) by XCH16-07-07.nos.boeing.com (144.115.66.109) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.1713.5; Fri, 6 Sep 2019 10:43:41 -0700
Received: from XCH16-07-10.nos.boeing.com ([fe80::1522:f068:5766:53b5]) by XCH16-07-10.nos.boeing.com ([fe80::1522:f068:5766:53b5%2]) with mapi id 15.01.1713.004; Fri, 6 Sep 2019 10:43:41 -0700
From: "Templin (US), Fred L" <Fred.L.Templin@boeing.com>
To: Ole Troan <otroan@employees.org>, Joe Touch <touch@strayalpha.com>
CC: Ron Bonica <rbonica=40juniper.net@dmarc.ietf.org>, "int-area@ietf.org" <int-area@ietf.org>, IESG <iesg@ietf.org>, Joel Halpern <joel.halpern@ericsson.com>, "draft-ietf-intarea-frag-fragile@ietf.org" <draft-ietf-intarea-frag-fragile@ietf.org>, Suresh Krishnan <suresh@kaloom.com>, "intarea-chairs@ietf.org" <intarea-chairs@ietf.org>
Thread-Topic: [Int-area] Discussion about Section 6.1 in draft-ietf-intarea-frag-fragile
Thread-Index: AQHVZNqfbqH+QOi8RUiYpNu24Aod6w==
Date: Fri, 6 Sep 2019 17:43:41 +0000
Message-ID: <369da680b57e4df4be81a658ebe3d9c3@boeing.com>
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>
In-Reply-To: <5C51DCDC-4031-47D9-A28E-812D0E66EE35@employees.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [137.137.12.6]
x-tm-snts-smtp: FDAD34569C2E9D1631602AB81B5AF89AA56DC83858412FD25E08340045AA9E302000:8
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-TM-AS-GCONF: 00
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-area/tfaz6W9v8SMppA5iYP8gIeFoaFQ>
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: Fri, 06 Sep 2019 17:44:00 -0000

Ole,

> Sure, but that only applies to tunnels that go end to end. And any development of new tunnel mechanisms don't need to depend on
> IP fragmentation.

All existing and future tunneling mechanisms that do not use IP fragmentation work
only due to the good luck that most link sizes in the Internet are on the order of 1500.
But, the only true guarantee is 1280 so the only true way to guarantee that the tunnel
can support 1280 after encapsulation is to apply fragmentation before encapsulation.

> This is essentially link-layer (the tunnel provides a new link layer) fragmentation and reassembly.
> It would anyway have to do that to deal with IPv4 DF=1 and IPv6.

It is RFC8200-standard IPv6 fragmentation.

> This document should not recommend IP in UDP in IP encapsulation to achieve end to end IP fragmentation for new applications.

"Encapsulation" does not necessarily mean IP-in-UDP-in-IP - it could be IP-in-foo-in-IP.
And again, the only true way to ensure that packets will traverse a path is to limit their
size to no more than 1280, and the only true way to achieve that when the original
packet size cannot be reduced is through fragmentation.

> If this paragraph has to be there it would be more accepting to have it in the "Legacy protocols" parapgraph above.

Not for legacy protocols - for the future of the Internet.

Thanks - Fred

>   Legacy protocols that depend upon IP fragmentation SHOULD be updated
>   to break that dependency.  However, in some cases, there may be no
>   viable alternative to IP fragmentation (e.g., IPSEC tunnel mode, IP-
>   in-IP encapsulation).  Applications and protocols cannot necessarily
>   know or control whether they use lower layers or network paths that
>   rely on such fragmentation.  In these cases, the protocol will
>   continue to rely on IP fragmentation but should only be used in
>   environments where IP fragmentation is known to be supported.
>   The risks of IP fragmentation can also be mitigated
>   through the use of encapsulation, e.g., by transmitting IP fragments
>   as payloads.
> 
> Cheers,
> Ole
> _______________________________________________
> Int-area mailing list
> Int-area@ietf.org
> https://www.ietf.org/mailman/listinfo/int-area