<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>On 1/6/2022 6:31 PM, Peter Gutmann wrote:<br>
</p>
<blockquote type="cite"
cite="mid:SY4PR01MB6251AB6E06C786C476DD80B7EE4D9@SY4PR01MB6251.ausprd01.prod.outlook.com">
<pre class="moz-quote-pre" wrap="">Phillip Hallam-Baker <a class="moz-txt-link-rfc2396E" href="mailto:phill@hallambaker.com" moz-do-not-send="true"><phill@hallambaker.com></a> writes:
</pre>
<blockquote type="cite" style="color: #007cff;">
<pre class="moz-quote-pre" wrap="">I remember sitting in an IPSEC meeting at the Dallas IETF and hearing the AD
call this 'a feature'.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">Yup, I remember that too (not at the Dallas IETF but elsewhere). The thinking
was "IPsec will be bigger than NAT so if we make sure it breaks NAT, NAT will
go away".
This anti-NAT crusade within the IETF persisted for a long, long time. Look
at RFC 3424 for example, which invented a childish backronym "UNSAF" to refer
to NAT-transversal mechanisms so it can talk about UNSAF clients and UNSAF
servers throughout. Section 4 is particular amusing, describing the various
levels of self-flagellation that any UNSAF mechanism is required by the IAB to
subject itself to.</pre>
</blockquote>
<p>... which is why I had to write something like 19 iterations of
the Teredo draft in order to jump through the UNSAF loops.
Standardizing STUN also took a long time. Yes, that was silly. But
the argument that I heard then was not that "IPsec will be bigger
than NAT". Yes, there was the anti-NAT argument that IPv6 will
make all that complexity go away, but there was also the pro-NAT
argument about NAT providing a firewall service to users, so don't
you dare break through that firewall, even if it is required for
video conferences or video games.</p>
<p>-- Christian Huitema<br>
</p>
</body>
</html>