I hope that IPv6 NAT will be used rarely, but I'm grateful that I will have it in my toolbox for atypical situations where there are no other options.
Originally, I was under the impression that /n subnets have 2^n public IPs at there disposal. Could it be 2^(128-n) instead?
But either way, a /64 should be plenty. However, you suggest here http://news.ycombinator.com/item?id=3261500 that /64 are not so great. I wonder why. Is there something special going on?
1. Topology hiding: the outside world only sees one interface not potentially the rest of your network. Though I doubt this offers and security worth speaking of, some people might want to keep that part of their arrangement when they migrate from IPv4 to IPv6.
2. Selective address forwarding: your router could send packets for a particular IPv6 address to different machines LAN-side depending on various things like where the packets came from WAN-side.
Of course there might be better ways to implement these things in the IPv6 spec already, I'm very behind the times in that respect and really must find time to read up on the subject (I purposely chose an ISP that fully supports IPv6 when I switched a few months ago, so I could try it all out when I have some time to play)
"we're used to the false sense of security from NAT and we like it"
"we feel like NAT protects our privacy ('but we use gmail')"
"its easier to setup than ndp proxying ('because i never heard of ndp before')"
yada yada :-)
http://blog.comcast.com/2011/11/ipv6-deployment-technology.h...
If in some circumstance someone hands you only one address (or, one address too few, perhaps), you can still hang your own network behind it.
No, please don't tell me about socks or other proxy solutions.
== making VoIP deployment hard/impossible depending on your router and phone model. :(
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.
Are you really suggesting that NAT66 be developed and deployed in order to help you violate your contract? Should the IETF find some way to help you get out of paying your bill too, or maybe stealing somebodies WiFi?
This article explains it pretty well (mainly on the second page):
http://arstechnica.com/hardware/news/2007/05/ipv6-firewall-m...
That being said... if firewalls "move" onto computers, it is "easy" to open ports.
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.
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.
