I'd be interested to hear some of these legitimate use cases for IPv6 NAT.
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?
2^(128-n) is the way it works for HOST addresses (no '-1', as in ipv4, as there is no broadcast address in ipv6, and 128-128=0, so 2^0=1, a single host address). 2^n is the way it works for networks/subnets, so a /128 leaves 2^128 possible networks, each with 2^0 hosts on them, while a /127 leaves 2^127 networks, each with 2^1 hosts on them.
A /64 is equal to the square of the entire existent ipv4 space (/32), and should be more than enough for any subnet anywhere, ever (it's roughly 18,446,744,073,709,551,615 IPs).
The issue is that many of the 'fundamental' protocols are built on assumptions that the smallest network will be a /64, and if your ISP gives you 1 /64, you can't have more than one 'network' on your end of the connection - even if you can have 18 quintillion addresses, they all have to be on the same subnet, so no fire-walling/etc. within your network.
This is really cool because it means your computer will always have the same lower 64 bits no matter where you take it, and it can auto-discover the prefix without the complexities of DHCP. (Note that there were some concerns about tracking computers using the lower 64 bits, which led to the optional privacy extensions, under which the interface ID is randomly generated.)
However, the standard requires that the interface ID be 64 bits, so if you only have a /64 from your ISP you are, practically speaking, limited to 1 subnet. For this reason, I like to measure prefix lengths in terms of subnets rather than IPv6 addresses.
What a horrible assumption to tack on though - it should have been codified in the v6 RFC if that's how it's going to work.
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)
You could use some sort of proxy services the the machines make the requests through (and the passes incoming requests back - you can avoid NAT in both directions that way) of course, but NAT seems (to me) to be a lighter solution for that use case.
"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...
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 :-).
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.
And yes, NAT is bad, ugly and from hell.
== making VoIP deployment hard/impossible depending on your router and phone model. :(
If the singalling protocols would allow for something like 'hi - my client $foo wants to talk to your client $bar. Please direct your response to me' and the other end would then send the packets with 'this is a packet from my client $bar to your client $foo - as you told me, I'm sending it to you', then there wouldn't be an issue - aside of a very small bit of additional latency and higher complexity of the gateway software.
If these client IDs are opaque, then the network topology stays hidden, but NAT would be completely irrelevant in between.
Now, personally, I'm really looking forward to having a /64 at the end of my cable modem. I will make splendid use of it and I will highly enjoy the additional uses I get from having my machines freely accessible to the internet.
On the other hand, people got good at understanding the feature set NAT provides and, thus, at configuring NAT gateways which also don't allow incoming connections per default.
That way, if I'm just a "normal user" and I buy myself a WiFi printer, I don't have to concern myself with configuring a firewall in order to ensure that it doesn't turn into an involuntary fax machine for example.
This could of course be solved by correctly configured firewalls on these crappy blue box routers, but how many years will it take them to reach "correctly"? Will they actually be configurable enough? Or would they just drop anything with a SYN bit set? How would these crappy firewalls deal with incoming UDP? Block it unconditionally (thus breaking VoIP even more)? Add "connection" tracking? In that case, why not just NAT?
I believe it's a good thing to have NAT back. Will I use it at home? Probably not. Will my parents use it at home? Likely. Would they be affected? Likely not as we already are used to deal with NATed clients.
That's called routing, and routers are perfectly able to do that already, much better than some possibly whacky custom application level implementation. By your reasoning, there's no reason not to have HTTP proxies everywhere.
> I don't have to concern myself with configuring a firewall in order to ensure that it doesn't turn into an involuntary fax machine for example
This has to be the most ludicrous example I keep hearing again and again. I don't see what's different from the end-user point of view between "my gateway does NAT" vs "my gateway refuses unrelated incoming packets". Seriously, take your random Airport Extreme and it's one freaking checkbox in the IPv6 tab (which should and will, in the forecoming wide availability case, be on by default, just like current NAT).
Can we stop conflating NAT with the no-incoming filtering rule already, please? Let's look at the "hello, world" of Linux NATs example:
/sbin/iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
/sbin/iptables -A FORWARD -i eth0 -o eth1 -m state --state RELATED,ESTABLISHED -j ACCEPT
/sbin/iptables -A FORWARD -i eth1 -o eth0 -j ACCEPT
Also it works with asterisk only, so it's not that useful in practice.