[Int-area] Re: Regarding draft-ietf-intarea-tunnels-15

"[email protected]" <[email protected]> Tue, 22 Jul 2025 20:34:25 -0700
Newsgroups gmane.ietf.int,gmane.ietf.mpls
Message-ID <[email protected]>
--===============8714251361451614835==
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_E16EC2EB-3BC3-4CE0-9795-358C5D633B58"


--Apple-Mail=_E16EC2EB-3BC3-4CE0-9795-358C5D633B58
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Hi, Tiger,

> On Jul 22, 2025, at 6:32=E2=80=AFAM, Tiger Xu =
<[email protected]> wrote:
>=20
> Hi all,
>=20
> I
>  find this architectural draft quite valuable. Furthermore, since UDP =
has been widely used as an effective tunneling
>=20
> technology, such as MPLS-over-UDP =
(https://datatracker.ietf.org/doc/rfc7510/), it would be
>=20
> very helpful to include more guidance on how to design elegant UDP =
tunnels.=20

This document is intended to be generic advice about tunneling. E.g., it =
would strongly indicate that packets be fragmented after UDP/IP =
encapsulation (presumably at the IP layer, but could be at any =
intermediate, e.g., above UDP or even within UDP with its pending =
options), and it describes how ICMP is handled at ingress/egress.

There are, however, far too many possibilities to describe them all, and =
this is not a specific proposal to make tunnels using UDP. That is thus =
outside the scope of this doc.

> Let
>  me give a concrete example: GUE variation 1 is just the encapsulation =
of IP within UDP. But to distinguish between variation 1 and variation 0 =
(i.e., complete GUE header), which share the same UDP destination port, =
GUE has to resort to the nibble (i.e., the
>  first 4 bits) after the UDP=20
> header=E2=80=94an=20
> inelegant method that MPLS has to use because its label stack lacks a =
protocol identifier field =
(https://datatracker.ietf.org/doc/draft-xu-mpls-payload-protocol-identifie=
r/).=20
>=20
> The
>  UDP destination port already plays=20
> the role of a protocol=20
> identifier, and therefore it seems straightforward to allocate =
dedicated ports for IP-in-UDP encapsulations, as described in
> https://datatracker.ietf.org/doc/draft-xu-intarea-ip-in-udp/, rather =
than using the inelegant approach as mentioned above.
>=20
>=20
> If
>  the UDP destination port resource were so=20
> scarce, the UDP destination port reserved for=20
> multicast=20
> =
applications=EF=BC=88https://datatracker.ietf.org/doc/draft-ietf-intarea-m=
ulticast-application-port-00=EF=BC=89could be donated for IP-in-UDP =
encapsulation.

That=E2=80=99s a really good example of why this document doesn=E2=80=99t =
address this sort of issue, though. The issue you=E2=80=99re discussing =
is very specific to using UDP and GUE; those who use UDP with other =
layers above would have different concerns. TCP/UDP/etc. transport port =
numbers indicate the *entire* stack of protocols above, not just the =
first layer. It would be nice if each layer included its own =E2=80=9Cnext=
 layer=E2=80=9D protocol identifier, but that=E2=80=99s not the case =
here, as you observe.

This isn=E2=80=99t a tunneling issue at all; it=E2=80=99s an issue with =
protocol layering. This isn=E2=80=99t quite the document to discuss the =
numerous subtleties of that=E2=80=A6

Joe=

--Apple-Mail=_E16EC2EB-3BC3-4CE0-9795-358C5D633B58
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

<html><head><meta http-equiv=3D"content-type" content=3D"text/html; =
charset=3Dutf-8"></head><body style=3D"overflow-wrap: break-word; =
-webkit-nbsp-mode: space; line-break: after-white-space;">Hi, Tiger,<br =
id=3D"lineBreakAtBeginningOfMessage"><div>
<meta charset=3D"UTF-8"><div dir=3D"auto" style=3D"caret-color: rgb(0, =
0, 0); color: rgb(0, 0, 0); letter-spacing: normal; text-align: start; =
text-indent: 0px; text-transform: none; white-space: normal; =
word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: =
none; word-wrap: break-word; -webkit-nbsp-mode: space; line-break: =
after-white-space;"><div dir=3D"auto" style=3D"caret-color: rgb(0, 0, =
0); color: rgb(0, 0, 0); letter-spacing: normal; text-align: start; =
text-indent: 0px; text-transform: none; white-space: normal; =
word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: =
none; word-wrap: break-word; -webkit-nbsp-mode: space; line-break: =
after-white-space;"><br></div></div></div><div><blockquote =
type=3D"cite"><div>On Jul 22, 2025, at 6:32=E2=80=AFAM, Tiger Xu =
&lt;[email protected]&gt; wrote:</div><br =
class=3D"Apple-interchange-newline"><div>

<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dbig5">

<div>
<div dir=3D"ltr">
<div dir=3D"ltr"><span style=3D"text-decoration: none; font-family: =
Inter, -apple-system, system-ui, &quot;Segoe UI&quot;, &quot;SF Pro =
SC&quot;, &quot;SF Pro Display&quot;, &quot;SF Pro Icons&quot;, =
&quot;PingFang SC&quot;, &quot;Hiragino Sans GB&quot;, &quot;Microsoft =
YaHei&quot;, &quot;Helvetica Neue&quot;, Helvetica, Arial, sans-serif; =
orphans: 2; widows: 2; background-color: rgb(255, 255, 255); display: =
inline !important;">Hi
 all,</span></div>
<div dir=3D"ltr"><span style=3D"text-decoration: none; font-family: =
Inter, -apple-system, system-ui, &quot;Segoe UI&quot;, &quot;SF Pro =
SC&quot;, &quot;SF Pro Display&quot;, &quot;SF Pro Icons&quot;, =
&quot;PingFang SC&quot;, &quot;Hiragino Sans GB&quot;, &quot;Microsoft =
YaHei&quot;, &quot;Helvetica Neue&quot;, Helvetica, Arial, sans-serif; =
orphans: 2; widows: 2; background-color: rgb(255, 255, 255); display: =
inline !important;"><br>
</span></div>
<div dir=3D"ltr"><span style=3D"text-decoration: none; font-family: =
Inter, -apple-system, system-ui, &quot;Segoe UI&quot;, &quot;SF Pro =
SC&quot;, &quot;SF Pro Display&quot;, &quot;SF Pro Icons&quot;, =
&quot;PingFang SC&quot;, &quot;Hiragino Sans GB&quot;, &quot;Microsoft =
YaHei&quot;, &quot;Helvetica Neue&quot;, Helvetica, Arial, sans-serif; =
orphans: 2; widows: 2; background-color: rgb(255, 255, 255); display: =
inline !important;"><span style=3D"text-decoration: none; white-space: =
pre-wrap; display: inline !important; background-color: rgba(0, 0, 0, =
0.04);">I
 find this architectural draft quite valuable. Furthermore, since UDP =
has been widely used as an effective tunneling
<span style=3D"text-decoration: none; display: inline !important; =
background-color: rgba(0, 0, 0, 0.04);">
technology,</span> such as MPLS-over-UDP (<a =
href=3D"https://datatracker.ietf.org/doc/rfc7510/">https://datatracker.iet=
f.org/doc/rfc7510/</a>), it would be
<span style=3D"text-decoration: none; display: inline !important; =
background-color: rgba(0, 0, 0, 0.04);">
very</span> helpful to include more guidance on how to design elegant =
UDP =
tunnels.&nbsp;</span></span></div></div></div></div></blockquote><div><br>=
</div><div>This document is intended to be generic advice about =
tunneling. E.g., it would strongly indicate that packets be fragmented =
after UDP/IP encapsulation (presumably at the IP layer, but could be at =
any intermediate, e.g., above UDP or even within UDP with its pending =
options), and it describes how ICMP is handled at =
ingress/egress.</div><div><br></div><div>There are, however, far too =
many possibilities to describe them all, and this is not a specific =
proposal to make tunnels using UDP. That is thus outside the scope of =
this doc.</div><div><br></div><blockquote type=3D"cite"><div><div><div =
dir=3D"ltr">
<div dir=3D"ltr"><span style=3D"text-decoration: none; font-family: =
Inter, -apple-system, system-ui, &quot;Segoe UI&quot;, &quot;SF Pro =
SC&quot;, &quot;SF Pro Display&quot;, &quot;SF Pro Icons&quot;, =
&quot;PingFang SC&quot;, &quot;Hiragino Sans GB&quot;, &quot;Microsoft =
YaHei&quot;, &quot;Helvetica Neue&quot;, Helvetica, Arial, sans-serif; =
orphans: 2; widows: 2; background-color: rgb(255, 255, 255); display: =
inline !important;"><span style=3D"text-decoration: none; white-space: =
pre-wrap; display: inline !important; background-color: rgba(0, 0, 0, =
0.04);"></span></span></div>
<div dir=3D"ltr"><span style=3D"text-decoration: none; font-family: =
Inter, -apple-system, system-ui, &quot;Segoe UI&quot;, &quot;SF Pro =
SC&quot;, &quot;SF Pro Display&quot;, &quot;SF Pro Icons&quot;, =
&quot;PingFang SC&quot;, &quot;Hiragino Sans GB&quot;, &quot;Microsoft =
YaHei&quot;, &quot;Helvetica Neue&quot;, Helvetica, Arial, sans-serif; =
orphans: 2; widows: 2; background-color: rgb(255, 255, 255); display: =
inline !important;"><span style=3D"text-decoration: none; white-space: =
pre-wrap; display: inline !important; background-color: rgba(0, 0, 0, =
0.04);">Let
 me give a concrete example: GUE variation 1 is just the encapsulation =
of IP within UDP. But to distinguish between variation 1 and variation 0 =
(i.e., complete GUE header), which share the same UDP destination port, =
GUE has to resort to the nibble (i.e., the
 first 4 bits) after the UDP <span style=3D"text-decoration: none; =
display: inline !important; background-color: rgba(0, 0, 0, 0.04);">
header=E2=80=94an</span> <span style=3D"text-decoration: none; display: =
inline !important; background-color: rgba(0, 0, 0, 0.04);">
inelegant</span> method that MPLS has to use because its label stack =
lacks a protocol identifier field (<a =
href=3D"https://datatracker.ietf.org/doc/draft-xu-mpls-payload-protocol-id=
entifier/">https://datatracker.ietf.org/doc/draft-xu-mpls-payload-protocol=
-identifier/</a>).&nbsp;</span></span></div></div></div></div></blockquote=
><blockquote type=3D"cite"><div><div><div dir=3D"ltr">
<div dir=3D"ltr"><span style=3D"text-decoration: none; font-family: =
Inter, -apple-system, system-ui, &quot;Segoe UI&quot;, &quot;SF Pro =
SC&quot;, &quot;SF Pro Display&quot;, &quot;SF Pro Icons&quot;, =
&quot;PingFang SC&quot;, &quot;Hiragino Sans GB&quot;, &quot;Microsoft =
YaHei&quot;, &quot;Helvetica Neue&quot;, Helvetica, Arial, sans-serif; =
orphans: 2; widows: 2; background-color: rgb(255, 255, 255); display: =
inline !important;"><span style=3D"text-decoration: none; white-space: =
pre-wrap; display: inline !important; background-color: rgba(0, 0, 0, =
0.04);">
</span></span></div>
<div dir=3D"ltr"><span style=3D"text-decoration: none; font-family: =
Inter, -apple-system, system-ui, &quot;Segoe UI&quot;, &quot;SF Pro =
SC&quot;, &quot;SF Pro Display&quot;, &quot;SF Pro Icons&quot;, =
&quot;PingFang SC&quot;, &quot;Hiragino Sans GB&quot;, &quot;Microsoft =
YaHei&quot;, &quot;Helvetica Neue&quot;, Helvetica, Arial, sans-serif; =
orphans: 2; widows: 2; background-color: rgb(255, 255, 255); display: =
inline !important;"><span style=3D"text-decoration: none; white-space: =
pre-wrap; display: inline !important; background-color: rgba(0, 0, 0, =
0.04);">The
 UDP destination port already plays <span style=3D"text-decoration: =
none; display: inline !important; background-color: rgba(0, 0, 0, =
0.04);">
the</span> role of a protocol <span style=3D"text-decoration: none; =
display: inline !important; background-color: rgba(0, 0, 0, 0.04);">
<span style=3D"text-decoration: none; display: inline !important; =
background-color: rgba(0, 0, 0, 0.04);">identifier,</span> and =
therefore</span> it seems straightforward to allocate dedicated ports =
for IP-in-UDP encapsulations, as described in
<a =
href=3D"https://datatracker.ietf.org/doc/draft-xu-intarea-ip-in-udp/">http=
s://datatracker.ietf.org/doc/draft-xu-intarea-ip-in-udp/</a>, rather =
than using the inelegant approach as mentioned above.</span></span><br>
</div>
<div dir=3D"ltr"><span style=3D"text-decoration: none; font-family: =
Inter, -apple-system, system-ui, &quot;Segoe UI&quot;, &quot;SF Pro =
SC&quot;, &quot;SF Pro Display&quot;, &quot;SF Pro Icons&quot;, =
&quot;PingFang SC&quot;, &quot;Hiragino Sans GB&quot;, &quot;Microsoft =
YaHei&quot;, &quot;Helvetica Neue&quot;, Helvetica, Arial, sans-serif; =
orphans: 2; widows: 2; background-color: rgb(255, 255, 255); display: =
inline !important;"><span style=3D"text-decoration: none; white-space: =
pre-wrap; display: inline !important; background-color: rgba(0, 0, 0, =
0.04);"><br>
</span></span></div>
<div dir=3D"ltr"><span style=3D"text-decoration: none; font-family: =
Inter, -apple-system, system-ui, &quot;Segoe UI&quot;, &quot;SF Pro =
SC&quot;, &quot;SF Pro Display&quot;, &quot;SF Pro Icons&quot;, =
&quot;PingFang SC&quot;, &quot;Hiragino Sans GB&quot;, &quot;Microsoft =
YaHei&quot;, &quot;Helvetica Neue&quot;, Helvetica, Arial, sans-serif; =
orphans: 2; widows: 2; background-color: rgb(255, 255, 255); display: =
inline !important;"><span style=3D"text-decoration: none; white-space: =
pre-wrap; display: inline !important; background-color: rgba(0, 0, 0, =
0.04);">If
 the UDP destination port resource were so <span style=3D"text-decoration:=
 none; display: inline !important; background-color: rgba(0, 0, 0, =
0.04);">
scarce,</span> the UDP destination port reserved for <span =
style=3D"text-decoration: none; display: inline !important; =
background-color: rgba(0, 0, 0, 0.04);">
multicast</span> <span style=3D"text-decoration: none; display: inline =
!important; background-color: rgba(0, 0, 0, 0.04);">
applications</span>=EF=BC=88<a =
href=3D"https://datatracker.ietf.org/doc/draft-ietf-intarea-multicast-appl=
ication-port-00">https://datatracker.ietf.org/doc/draft-ietf-intarea-multi=
cast-application-port-00</a>=EF=BC=89could be donated for IP-in-UDP =
encapsulation.</span></span></div></div></div></div></blockquote><br></div=
><div>That=E2=80=99s a really good example of why this document =
doesn=E2=80=99t address this sort of issue, though. The issue you=E2=80=99=
re discussing is very specific to using UDP and GUE; those who use UDP =
with other layers above would have different concerns. TCP/UDP/etc. =
transport port numbers indicate the *entire* stack of protocols above, =
not just the first layer. It would be nice if each layer included its =
own =E2=80=9Cnext layer=E2=80=9D protocol identifier, but that=E2=80=99s =
not the case here, as you observe.</div><div><br></div><div>This isn=E2=80=
=99t a tunneling issue at all; it=E2=80=99s an issue with protocol =
layering. This isn=E2=80=99t quite the document to discuss the numerous =
subtleties of that=E2=80=A6</div><div><br></div><div>Joe</div></body></htm=
l>=

--Apple-Mail=_E16EC2EB-3BC3-4CE0-9795-358C5D633B58--


--===============8714251361451614835==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Disposition: inline

X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KSW50LWFyZWEg
bWFpbGluZyBsaXN0IC0tIGludC1hcmVhQGlldGYub3JnClRvIHVuc3Vic2NyaWJlIHNlbmQgYW4g
ZW1haWwgdG8gaW50LWFyZWEtbGVhdmVAaWV0Zi5vcmcK

--===============8714251361451614835==--