Hi, Mark,
On 31/12/2025 22:35, Mark Smith wrote:
NAT traversal is only supposed to be an issue in IPv4.
The underlying flaw here is that, to quite some extent, the "traversal"
problem has more to do with the implicit "diode" firewall that results
from NAT, than with "address translation" itself.
So in IPv6, even in scenarios where NAT is not employed, you'll face
similar challenges.
Allowing NAT on IPv6, by deprecating the only mechanism that can protect
against it, that is, AH, will only encourage its use, because "What you
allow, you encourage." - Michael Josephson.
Maybe it is time to move forward and understand that the vast majority
of organizations simply don't care about IP versions.
If one is in the business of encouraging or fostering IPv6 deployment,
one is probably better of by making it possible in multiple forms
(including NAT for IPv6). Otherwise, you'll probably get a "I don't have
time for this", resulting in no deployment.
If NAT is encouraged in IPv6, what is the point of IPv6?
Nobody "encourages" anything. Folks that may be in a position of
deployiing ipv6, might have a number of challenges on the table. NAT for
IPv6 may address some of them (or at least be perceived as doing so)..
and that's hwat gets NAT for IPv6 deployed.
NAT imposes client/server roles at the network layer. Devices behind the
NAT can't or can't easily act as servers or equal peers to other network
layer devices. They become clients only by default.
Yeah. Similar to default VPC rules in popular public clouds, isn't it?
For example, in a multipath transport protocol, how can a node announce
its own addresses to a peer, to establish further sessions, when it
doesn't know what its outside addresses are, because it's behind a NAT.
Maybe the solution would be for the peer to learn them?
Deprecating AH is effectively saying that any and all IPv6 header fields
are allowed to be mangled in any way by the network, because there would
be no way to protect against it.
Welcome: https://datatracker.ietf.org/group/iesg/appeals/artifact/46
We have never had NAT in E.164 phone numbers of the past 100+ years. We
all expect our phones to be able to equally and as easily send and
receive phone calls.
Why can't we make sure that our computers have that capability too?
Incentives, trade-offs, and what's the best tradeoff for the general case.
I'd ask anybody who thinks NAT is a good idea if they would accept only
being able to make phone calls on their smartphone, but never be able to
receive them, or be able to tell people their phone number.
NAT is a tool. Neither a good or a bad idea. As any tool, depending on
the problem you have at hand, the tool in question might be the best fit
or not.
And "problem you have at hand" need not be exclusively technical. Within
an organization, something that buys "essentially this is the same as
with IPv4... you'll simply get these longer addresses, but otherwise
it's essentially the same" can mean *a lot*. -- and may even make the
difference to get the "go ahead" to deploy IPv6 or not.
Not everyone has the luxury of devoting a lot of time to digging into
protocol details, figuring differences, etc. (*) In fact, i'd argue it's
quite the opposite: in virtually any organization other than an ISP,
CDN, or the like, it's the other way around.
(*) It follows that there probably hasn't been anything more harmful to
IPv6 deployment than the attitude/strategy of "forget about IPv4",
"replace your IPv4 mindset", and the like.
Thanks,
--
Fernando Gont
e-mail: [email protected]
PGP Fingerprint: 7F7F 686D 8AC9 3319 EEAD C1C8 D1D5 4B94 E301 6F01
_______________________________________________
Int-area mailing list -- [email protected]
To unsubscribe send an email to [email protected]
