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 ... > > and now THESE PEOPLE apply THEIR APPROACH > to the internet, and we're supposed to > implement their workaround hacks so that > they can continue to deploy shit? brilliant > approach.