4 ms·

There are a whole host of standards to support interoperability between v4-only->v6, v4/v6->v4, v6-only->v4 addressing. I know it doesn't answer your complaint,

• geofft 9y ago
  > we all know how much the tech community loves to hate on NAT This, I think, is the unpopular but true reason the IPv6 transition has been slow. It ties together two changes, "get rid of IPv4" and "get rid of NAT", and making a business case for doing both of those simultaneously is very hard. Lots of people understand NAT. Lots of vendors understand NAT. Lots of managers understand NAT. ("NAT", of course, means "PAT with implicit firewall," but "NAT" is the term people use.) You can get the same security and privacy benefits and an equally good or even better design without NAT, but that's not what people are used to. If IPv6 had been a straightforward extension of IPv4 to 128 bits instead of a bunch of cool and reasonable and backwards-incompatible ideas, the transition would probably be done already. The tradeoff, of course, is we'd still be on the same quality of architecture we have on IPv4.
  • welterde 9y ago
    How exactly would this straightforward extension of IPv4 to 128 bits look like? How would it differ from how IPv6 today looks like? Frankly I can't see any way (that has at least some degree of sanity), to make a backwards-compatible replacement for IPv4 with significantly more address space than IPv4.
    • geofft 9y ago
      No implication that NAT is bad. 6to4 space (and RFC 4193 space, if needed) would be explicitly okay for use with NAT, like RFC 1918 space. Allow NAT from IPv6 on the inside to IPv4 on the outside, as well as IPv6-to-IPv6 NAT. Extend ARP to support IPv6 addresses instead of designing NDP. Use DHCPv6 like DHCPv4. Don't have SLAAC; encourage the use of existing techniques (static addressing or DHCP). Don't have RAs. Don't have privacy addresses, because they're not needed, because NAT is expected. Don't have Teredo, because again, you're expected to get IPv6 addressing from some NAT technology. Note that I'm not super advocating for extending the IPv4 space to IPv6, except via 6to4 if you want to. IPv6 continues to be its own space. But the advantage here is that you don't have compatibility problems from clients that support RDNSS and not DHCPv6 (looking at you, Android) or vice versa, because the way you do things in IPv6 is just like the way you do them in IPv4 and you can use the existing software stack with just a different typedef. You don't have problems with IPv6's infatuation with multicast and aging network architectures that only begrudgingly support it and fall back to broadcast quickly (cf. https://blog.bimajority.org/2014/09/05/the-network-nightmare-that-ate-my-week/ https://blog.bimajority.org/2014/09/05/the-network-nightmare... ); you're only using network features that IPv4 already requires your hardware to support. And so forth. No implicit 64/64-bit split in addresses, where if you want to build an equivalent architecture to IPv4 NAT, you must have at least a /64 (there are plenty of service providers that give you a /128, and your only option becomes NAT66). With IPv4, if you get so much as a /31, you can usefully put two computers behind it. With IPv6, there's no way to implement, say, SLAAC with a /127; you have to use static addressing or DHCPv6. And you lose privacy addresses, which means you have less effective privacy than IPv4 NAT. That's the sort of thing I mean by "backwards compatible." Once we're on IPv6, by all means, convince everyone that you have better ways of doing everything. But if you tie the IPv6 transition to "NAT is bad and if you need it you suck", "multicast is great and if you don't support it you suck", etc., the only thing you'll succeed in doing is delaying the IPv6 transition.
  • mike-cardwell 9y ago
    You can still do NAT with IPv6. At least the Linux kernel supports it.