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
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
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
Precedence: list

Ole,

> Sure, but that only applies to tunnels that go end to end. And any develo=
pment of new tunnel mechanisms don't need to depend on
> IP fragmentation.

All existing and future tunneling mechanisms that do not use IP fragmentati=
on work
only due to the good luck that most link sizes in the Internet are on the o=
rder 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 encap=
sulation.

> This is essentially link-layer (the tunnel provides a new link layer) fra=
gmentation and reassembly.
> It would anyway have to do that to deal with IPv4 DF=3D1 and IPv6.

It is RFC8200-standard IPv6 fragmentation.

> This document should not recommend IP in UDP in IP encapsulation to achie=
ve 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 o=
riginal
packet size cannot be reduced is through fragmentation.

> If this paragraph has to be there it would be more accepting to have it i=
n 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.
>=20
> Cheers,
> Ole
> _______________________________________________
> Int-area mailing list
> Int-area@ietf.org
> https://www.ietf.org/mailman/listinfo/int-area