Article does not address the elephant: there is no ability to NAT with IPv6. Sure, absolutely, you shouldn't have to NAT, but in my datacenter, NAT is a feature, not a bug. The article specifically asks "did the ipv6 designers go mad" and then they list features I've never heard of or use to prove they didn't. Those features are not why I think they went mad. The inability to create a NAT is. For this reason, at ever…
No ability to NAT in V4 either - it was hacked on top. And you can run hacky NAT in V6 too. If you really, really, really want to.
This is the only topic that tempts me to create a throwaway account. (I have not given in) None of the IPv6 proponents are willing to acknowledge that IPv6 is a pain. All of them seem to have gone to some secret seminar somewhere where they receive their talking points: - Everyone who dislikes IPv6 doesn't know how NAT works and thinks it's the same as a firewall. - There's absolutely no downside whatsoever to being…
In troubleshooting, "It's always DNS" has become "If it's not DNS, it's IPv6".
I don't even try to fix it. If I disable IPv6 and everything starts working, I move on.
Article does not address the elephant: there is no ability to NAT with IPv6. Sure, absolutely, you shouldn't have to NAT, but in my datacenter, NAT is a feature, not a bug. The article specifically asks "did the ipv6 designers go mad" and then they list features I've never heard of or use to prove they didn't. Those features are not why I think they went mad. The inability to create a NAT is. For this reason, at ever…
I am reading about ipv6 nat. I guess it's possible but discouraged? This contention point confuses me. I consistently get downvoted for this opinion, and I've seen contrarian voices online, but I have yet to meet an actual datacenter network admin who disagrees with me.
It's totally possible and it's totally discouraged. We are not the internet police on HN, and neither is the IETF. If you want to do weird stuff on your own network, you can and you get to keep both pieces.
I think we've been shunted into an alternate universe by NAT - one which reinforces the power of large companies because we essentially cannot communicate computer to computer without going through some service. As for security.........are we really that secure running code in our browsers that we downloaded from who knows where? Is nat really saving us? And now here we are with IPv6 and the real age of the network c…
Odd that all these pro ipv6 top level comments are greyed out.
I think if they just double the address length the people would still cry about how 111.211.234.231.189.243.253.100 too hard to write and remember... There is no helping with people.
yeah and the global migration to add bits is already so expensive, if you're adding bits you shouls add a lot of bits so it only has to be done once. Wish they'd made it 256 bits actually, it could fit cryptographic hashes for secure routing protocols of the future.
You are right that a 32 bit ipv4 stack can not understand a 64 bit packet format. The thing I am trying to get at is not native compatibility, it is operational compatibility via translation. I know, I know, you will probably say that is what ipv6 bridges do. But in an ipv42 type setup, you would have determnistic embedding so that every ipv4 address is represented inside the larger address space. This would allow tr…
We have that, it's called ipv6. A section of the v6 address space is sectioned off to hold all v4 addresses
The embedding I believe you are referring to is not a part of the global routing model. (maybe I am wrong?) What I am describing is making that kind of declaration central to the system in a deterministic, network wide mapping of ipv4 to the larger ipv6 space. The translation in ipv6 ended up being handled by a mix of mechanisms after the fact, rather than a single, uniform mapping model that tied directly to the address structure. I think part of the problem is they did not put that front and center, at the beginning, when doing the initial specification.
We have that, it's called ipv6. A section of the v6 address space is sectioned off to hold all v4 addresses
The embedding I believe you are referring to is not a part of the global routing model. (maybe I am wrong?) What I am describing is making that kind of declaration central to the system in a deterministic, network wide mapping of ipv4 to the larger ipv6 space. The translation in ipv6 ended up being handled by a mix of mechanisms after the fact, rather than a single, uniform mapping model that tied directly to the add…
How would an embedding handle the other 99.999999999999% of addresses not embedded?
This is a fake argument. Noone is arguing for backwards compatibility. But there was also no necessity to demand reshaping networks and changing address assignment in a way that made migration extremely work intensive and hard to deploy in parallel.
How would you do it?
I wouldn't try to reinvent DHCP, kept NAT and generally attempted to keep the overall shape of a v6 network the same as v4 networks to ease transition of large deployments.
Ipv6 now has most of that - after years of resistance - which results in a mixed mess of "several ways to do it" approaches spiced with clients and equipment supporting a random set of them.