Art of the State: NAT in IPv6

Back in October, Daniel Ouellet asked about NAT in IPv6 on the OpenBSD misc@ mailing list. It was thus destined to become a legendary thread. I’m going to post a few interesting responses here, since there is much confusion and doubt associated with the topic. Enjoy!

Jussi Peltola wrote:

> NAT will not go away, there are plenty of corner
> cases where it is useful (like managment networks
> where you cannot put each management interface in
> a vrf.) Companies will also very likely want to
> keep private addresses internally; NAT is easier
> for many cases than having a separate routable
> address on every host.
> NAT is a necessary evil, and it really is not that
> bad when operated voluntarily by the same party as
> the end-hosts behind it. The real problem is CGN;
> I doubt any ISP is going to NAT when it is not
> absolutely necessary because it is expensive and
> painful.

Claudio Jeker wrote:

> But less PI space. Since some evangelists believe
> in the superiority of IPv6 and try everything to
> make it impossible to get routable PI space. At
> the moment IPv6 is a step backwards in all regards.
> If the idea would be to get everybody to use v6
> then the RIR should give out IPv6 ranges like
> candy -- if you have a PI IPv4 space you should
> get a PI IPv6 space. But instead people still
> dream of the 10k routing table...
> I know one thing for sure. In the next few years
> the internet will suck.

Theo de Raadt (charming as ever) wrote:

>> End hosts need to get smarter, instead of the
>> network adapting to their stupidity. But I'm
>> not holding my breath.
> No, what you are really saying is that
> non-transient network traffic (long lived TCP
> sessions) need to have the applications talking
> them -- and obviously the protocols also -- modified,
> adding great additional complexity, to sure that
> they can keep traffic moving when the routing part
> of the protocol fails to do, uhm, ROUTING.
> So, to make this clear with an example.
> Basically to make IPv6 pseudo-"multihoming" work
> like IPv4 multihoming, ssh and sshd need to be
> modified that they can handle a network break,
> and re-connect using another address.
> (Yes, I know there are a few places where this
> can be solved, using various tools now being
> discussed, which means the BIG GUYS can avoid
> this problems, but the LITTLE PEOPLE can't).
> Awesome.  Totally awesome.
> Pushing additional complexity into applications
> is retarded.
> The IETF is run by a bunch of idiots.

Joel Wirämu Pauling wrote:

> As someone working for a 'Carrier' vendor - I
> can tell you straight up that LSN(Large Scale)
> or CGN(Carrier Grad) NAT are big sell points
> (i.e customers are asking for them).
> Personally out of the various RFC's and schemes
> i've had the displeasure of perusing for V6 to
> V4 access NAT64 to me seems to the be the least
> evil.
> It is the ONLY solution which can easily remove
> the need for upstream fiddling if the CPE
> implements it, i.e the bad stuff at least stays
> on the edge of YOUR network. You effectively
> need the NAT64 module and a DNS proxy sitting
> on the CPE - all the various other RFC's require
> some level of ISP/Carrier interaction upstream
> to make things work; or break in interesting
> strange ways for the user (not that I am saying
> NAT64 is perfect).
> I know which I would prefer to see widely adopted.
> Also under the general guise of WHY you need NAT
> at all in IPV6 stacks... the ONE good argument
> is for easily setup Load Balancing.

Stuart Henderson wrote:

> Another important thing to note here is that
> with NAT64 the natting _no longer needs to be
> in the normal network path_, the translation
> gateways can be off to one side without any
> special tricks, just normal routing.
> (Horizontal scaling can even be done by having
> the DNS64 push out different prefixes). And as
> more traffic goes to native v6, the load on
> the NAT64 gateways decreases.
> VOIP of various kinds over v6 is still a big
> problem, though I am sure some of the larger
> networks interested in protocol transition
> would not see that as a disadvantage ;)

Constantine A. Murenin wrote:

> I think you're confused between NAT66 and
> NAT64. [0]
> T-Mobile USA optionally supports IPv6
> connectivity in some limited number of new
> phones (Galaxy Nexus etc) [1], and when the
> IPv6 option is manually activated by the
> user^w beta-tester on their phone, then
> no IPv4 support is provided, and access to
> IPv4-only resources is available through
> NAT64 [2] and DNS64 [3]. No dual-stacking is
> provided; in their slides from [0], T-Mobile
> USA claims that IPv6-only with NAT64/DNS64 is
> cheaper than dual-stack with NAT44.
> Frankly, dual-stacking (with the plain old
> NAT44) would seem like a better approach for
> an end-user; I would guesstimate that less
> than 1% of Galaxy Nexus users on T-Mobile USA
> have actually enabled IPv6 (and left it enabled
> after simply testing it), precisely because
> dual-stacking is not an option, and T-Mo's
> NAT64/DNS64 must be consumed (instead of NAT44),
> breaking all those crappy apps that hardcode IPv4
> addresses outside of the DNS and such.

Henning Brauer wrote:

> we're talking about the industry that has
> gazillions of gsm access points installed
> with baseband controllers that crash more
> than once a minute. and instead of fixing
> their broken software they apply workaround
> hacks, and since these are of the same
> quality they apply another layer of
> workaround hacks, and ...
> to the internet, and we're supposed to
> implement their workaround hacks so that
> they can continue to deploy shit? brilliant
> approach.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.