Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: =?utf-8?Q?Ole_Tr=C3=B8an?= <otroan@employees.org>
Mime-Version: 1.0 (1.0)
Date: Fri, 8 Aug 2025 17:39:30 +0200
Message-Id: <ABFD390A-386C-4E8D-84BC-B9EF752E1835@employees.org>
References: <83EC3EBE-17D3-4545-BE6B-40A15D27869D@strayalpha.com>
In-Reply-To: <83EC3EBE-17D3-4545-BE6B-40A15D27869D@strayalpha.com>
To: touch@strayalpha.com
Message-ID-Hash: DV7XXHOGL3HTM2XOY2TWRZSMI6W5Q2ZR
CC: Fred L Templin <Fred.L.Templin=40boeing.com@dmarc.ietf.org>,
 Ron Bonica <rbonica=40juniper.net@dmarc.ietf.org>,
 Internet Area <Int-area@ietf.org>
Precedence: list
Subject: =?utf-8?q?=5BInt-area=5D_Re=3A_WGLC_for_=22IP_Tunnels_in_the_Internet_Archit?=
	=?utf-8?q?ecture=22_draft-ietf-intarea-tunnels?=
Archived-At: 
 <https://mailarchive.ietf.org/arch/msg/int-area/l6Vlj1bnBVUBqUcDd19TCA8JyOQ>

Thanks Joe!
Ah, I misread =C2=ABOuter fragmentation=C2=BB to imply =C2=ABOuter IP fragme=
ntation=C2=BB.

Thanks for the clarification.=20

Ole


> On 8 Aug 2025, at 16:07, touch@strayalpha.com wrote:
>=20
> =EF=BB=BFHi, Ole,
>=20
>>> On Aug 8, 2025, at 12:26=E2=80=AFAM, Ole Troan <otroan@employees.org> wr=
ote:
>>>=20
>>> Additionally:
>>>=20
>>>> On Aug 7, 2025, at 1:15=E2=80=AFPM, Templin (US), Fred L <Fred.L.Templi=
n=3D40boeing.com@dmarc.ietf.org> wrote:
>>>>=20
>>>> Many tunneling protocols live by =E2=80=9Cgrace=E2=80=9D and assume 150=
0 everywhere. But, robust
>>>> tunneling protocols need to live by the =E2=80=9Claw=E2=80=9D, and the l=
aw says 1280.
>>>=20
>>> And its subtle - for IPv4, they assume 1500 everywhere but it=E2=80=99s r=
eally 576 after reassembly at the receiver.
>>>=20
>>> For IPv6, it=E2=80=99s 1280 over each hop BUT up to 1500 after reassembl=
y at each receiver.
>>>=20
>>> These and other aspects are why this isn=E2=80=99t just an op-ed.
>>=20
>> I think the current text is fine from a historical perspective.
>> For future recommendations I would prefer a recommendation that tunnels m=
ust support link-layer segmentation and reassembly.
>> That could be UDP options FRAG or something else.
>>=20
>> Outer IP fragmentation is undesirable for multiple reasons.
>> E.g. a tunnel tail-end has to reassemble _before_ it can check if the fra=
gment chain belongs to a tunnel. Last I looked, a lot of IP fragments are pa=
rt of attacks, and they are costly to process.
>>=20
>> Ole
>=20
> Tunnel fragments must be reassembled by the receiver - that=E2=80=99s a fu=
ndamental point of the document. The mechanism used for fragmentation and re=
assembly happens on the packet being tunneled, not within that packet. That i=
s what outer fragmentation refers to - not necessarily fragmentation at the o=
utermost IP layer.
>=20
> I.e., yes, we can avoid use of IP fragmentation IF there are other protoco=
l layers available as part of tunnel encapsulation. But regardless of method=
 used, the tunnel endpoint MUST do the reassembly.
>=20
> That clarification can be added.
>=20
> Joe
>=20
>=20