
Linux gets IPv6 NAT - KonradKlause
http://marc.info/?l=linux-netdev&m=132185445023922&w=2
======
adestefan
This makes me sad. People claiming that NAT provides some sort of privacy are
misguided. There's also the option of the privacy extensions described in RFC
4941. This is even easier to enable in Linux, just add
"net.ipv6.conf.<if>.use_tempaddr = 2" to /etc/sysctl.conf.

~~~
forgotusername
As for uses, how about: I live in a crappy country with a crappy monopolistic
ISP that provides a crappy /128. No amount of purist theoretical pontification
can fix this reality, which is guaranteed to happen for someone, regardless of
the size of address space (say, because a business guy at $ISP thinks that
will somehow force users to pay for extra subscriptions for their devices).

I for one am glad to see that if the time should arrive for me, Linux will
support this out of the box, and that the greater madness by far, is to ignore
a problem simply because you'd prefer that it not exist.

Besides all that, there is simple hacker value in having this kind of
translation available. Great ideas are often borne of insanity.

~~~
wmf
And now every protocol needs to add NAT66 traversal to work around you. The
lack of NAT66 is not ignoring a problem, it's trying to prevent a massive
externality.

~~~
forgotusername
Omitting support for something that's technically possible is a dumb approach
to fighting this (actually it's exactly equivalent to ignoring the problem).
Instead the focus should be on making it less economical for protocol
developers to violate layering and embed layer 3 addresses at layer 5, which
is the reason "every protocol" needs special casing in the first place.

Accomplishing that could happen in various ways, e.g. promoting SCTP (which
allows establishing new channels over the same initial connection), or
introduction of an abstract naming service that would preserve layering (I'd
be very surprised if something like this didn't already exist).

------
kenny_r
I'd be interested to hear some of these legitimate use cases for IPv6 NAT.

~~~
guan
I don't know if this qualifies as legitimate, but Comcast has already decided
to allocate /128 to customers with "directly connected CPE", which sounds like
people who have just a cable modem and didn't pay for a "home gateway device".
NAT could be useful if you plug that cable modem into a Linux box.

[http://blog.comcast.com/2011/11/ipv6-deployment-
technology.h...](http://blog.comcast.com/2011/11/ipv6-deployment-
technology.html)

~~~
wmf
You're interpreting it wrong; Comcast is going to provide at least /64 to each
customer but they just haven't turned on prefix delegation yet.

~~~
agwa
/64 is almost as bad and will lead to IPv6 NATing. What if you want multiple
subnets (for example, a separate guest network, which some high-end consumer
access points already tout as a selling point)? You don't want to sub-divide
your /64 because then stateless auto configuration won't work. You could
bridge multiple subnets with the same /64 prefix and use a layer 2 firewall
(ebtables in Linux), but that's ugly. NAT is the only other option.

That said, Comcast did leave open the possibility for shorter prefixes,
possibly as early as 2012, and they have already received quite a thrashing on
their IPv6 beta tester forums for using /64 prefixes. So they might eventually
do the right thing. I'm optimistic :-).

------
alexchamberlain
Will it ever be safe to design a protocol which isn't "NAT Safe"?

~~~
agwa
Well, even if NAT went away, you would still have to contend with stateful
firewalls (i.e. those that only allow inbound packets from established
connections).

This article explains it pretty well (mainly on the second page):

[http://arstechnica.com/hardware/news/2007/05/ipv6-firewall-m...](http://arstechnica.com/hardware/news/2007/05/ipv6-firewall-
mixed-blessing.ars)

~~~
alexchamberlain
It depends where firewalls are implemented in x years time. (In the context of
the home) At the moment, people rely on their routers to provide a decent
firewall rather than configuring their computers properly.

That being said... if firewalls "move" onto computers, it is "easy" to open
ports.

~~~
agwa
Yeah, good point. Personally, I'm torn on whether I would ever want to give up
my whole-network firewall, especially when there's a wireless network in the
mix. My servers' ssh logs are choke full of brute force attempts. I would hate
to waste my wireless bandwidth and battery life on such attack attempts. On
the other hand, IPv6 address space will be so sparse that maybe such attacks
won't be practical...

~~~
alexchamberlain
Have you got password logins turned off?

------
mindslight
The more I hear about IPv6 (these comments in particular), the more it seems
like it contains many solutions to non-problems. Yes, IPv4's 32 bit address
space is basically full, and upgrading that is a good thing.

But honestly, burning 64 bits of address space for a redundant global
identifier just so "nat+dhcp" are only half as complicated? And then needing
privacy extensions to keep the uuid from leaking out? All while doing nothing
to solve the problem that caused NAT to spring up in the first place.

On the surface, "no NAT" sounds like a reasonable goal, but ignores the
realities of what NAT is actually used for - keeping your network your
business. How long until consumer providers offer different tiers of plans
based on number of devices that can be connected, and smart users are back to
NAT anyway? The proper solution to NAT problems is at layer 4 - a standard way
of making connections from the outside to a device inside based on some kind
of onion address, where the upstream can only see the outer part.

------
WalterGR
How does this relate to / compare with Teredo?

<http://en.wikipedia.org/wiki/Teredo_tunneling>

~~~
wmf
Teredo is a way of getting IPv6 if your ISP doesn't provide it. IPv6 NAT
translates between outside IPv6 addresses and inside IPv6 addresses.

~~~
WalterGR
Thanks. (I had it in my head that Teredo was an IPv6 NAT, despite the
Wikipedia link.)

------
1010010111
What makes solutions like NAT* and IPv6 necessary is the concept of the
"backbone". In spite of all its benefits, it also has tradeoffs too.

When everything has to pass through centralised "core" routers for enormous
segments of the network, it limits how we can work with addresses.

It forces us to allocate addresses in blocks (the larger ones within which
most of the individual addresses remain unused). And it creates
problematically large routing tables for those "core' routers.

As with everything, there are both costs and benefits to doing things this
way. There are always tradeoffs with any approach, whether it is centralised
or decentralised. So arguments can go on to infinity about the "best" way.
There is no such thing. There are just different alternatives, each with their
own costs and benefits. And there's human consensus.

And there are the inevitable workarounds, some of them pure "hacks".

NAT* and IPv6 are a natural result of having a "backbone", "core routers",
gigantic ever-growing routing tables and large address allocation minimums.

------
seanlinmt
Without looking at the code to see what's going on, I'm wondering if this
patch is actually about IPv6 NAPT, ie. protocol translation between IPv4 and
IPv6. If it's really NAT, like IPv4 NAT, then has there been an RFC on this? I
can't seem to find it.

~~~
wmf
There wasn't an RFC for NAT44 either, because the IETF didn't want to
encourage it. Realizing how that worked out last time, the debate is raging
about NAT66 specification.

