3 ms·

> As you mention in your other post it really is the "billion dollar mistake", it's obvious to me in hindsight that they should have made IPv6 completely backwa

> As you mention in your other post it really is the "billion dollar mistake", it's obvious to me in hindsight that they should have made IPv6 completely backwards compatible with IPv4, no matter the cost. It's not a matter of cost, it's simply impossible. IPv4 has a 32 bit field for the source address and a 32 bit field for the destination address, and every connection over IP needs to send packets back and forth between the two addresses. As soon as one party has a longer address, the other party has to know how to handle that, otherwise, they cannot possibly communicate. The only point where compatibility would be possible to some degree is the network, but (a) that compatibility is in effect a tunnel, and there are lots of ways to tunnel IPv6 over IPv4 just fine, and (b) most of the global internet supports IPv6 just fine, and has been for a long time. The problem is the migration of the endpoints, not so much the network.

simias 9y ago
I actually started replying to your comment with my master plan to make an "IPv6 in IPv4" but I realized that I was probably going to make an ass of myself since plenty of much more clever people have worked on the subject for a long longer than I did. But I guess my main issue with this is: >(a) that compatibility is in effect a tunnel, and there are lots of ways to tunnel IPv6 over IPv4 just fine I agree that no matter how you slice it, at some point if you want to transition you'll have to tunnel things. But why are there "lots of ways" to do it? Why isn't there one single, "it just works" way to add compatibility? IMO this should have been a core feature of the standard, bullet point #2, just below "add more addresses". Explain in details how the transition will be made, how you convert an IPv4 into IPv6 incrementally while not breaking anything. Sure it's hard to make a one-size-fits all, but all the corners you have to cut and just make it work. Why isn't the IPv6 my ISP provides simply an extension of my IPv4? If my IPv4 is 216.58.213.174, why isn't the IPv6 216.58.213.174.[more stuff]? Why can I just concatenate my IPv4 public and NAT'ed LAN IP to get a valid IPv6? `ifconfig eth0 inet6 216.58.213.174:192.168.0.101/32` and here we go. It looks familiar, I understand what it means. You could even standardize it to make the IPv4 always be the low bytes of the IPv6 address or something like that, this way I don't have to worry about two sets of addresses. Instead it's `ifconfig eth0 inet6 2001:41d0:000a:050d::1 prefixlen 128 accept_rtadv no_radr`. Ah. I'm sure there's a good reason to make those changes but I can't really be bothered to figure them out as long as IPv4 just works. I'll get around to learn it, eventually, maybe in a few months when I read an article on HN telling me that we're at 21% worldwide adoption.
- zAy0LfpBZLC8mAC 9y ago
  > But why are there "lots of ways" to do it? Why isn't there one single, "it just works" way to add compatibility? Well, for the same reason why there are lots of ways to tunnel IPv4 over IPv4? Some work through NAT, some don't, some encrypt, some don't, some allow for transport of packets that exceed the tunnel's transport PMTU, some don't, ... it's some form of tradeoff for different needs: If you are behind CGN of some crappy provider, you probably have to tunnel over UDP using small packets, if you are an ISP, that would be way too much overhead and you want to instead transport over raw IP in jumbo frames. > Why isn't the IPv6 my ISP provides simply an extension of my IPv4? If my IPv4 is 216.58.213.174, why isn't the IPv6 216.58.213.174.[more stuff]? Why can I just concatenate my IPv4 public and NAT'ed LAN IP to get a valid IPv6? Because that would not actually help anything. That would possibly make the user interface look a bit more familiar, but you would still need a completely new protocol underneath with all the same migration problems that we have now. And also, the differences at the user interface level are pretty minor, conceptually IPv6 really works much the same as IPv4, except with longer adresses. That they chose to use hex notation instead of decimal really is probably simply to make the notation shorter, and also the shorthand-notation for a run of zeros makes things a bit less unwieldy. As for actually somehow reusing the existing address space, the existing global IPv4 routing table is massively fragmented with every larger ISP having tons of routes for disparate prefixes that they acquired over the years. That makes IPv4 backbone routers expensive. IPv6 is large enough that providers generally should never have more than one prefix, which makes the routing table a lot smaller.
  - simias 9y ago
    But don't you think UI is extremely important in these situations? If you sold IPv6 as "it works like IPv4 but with 128 bit addresses" I'm sure it wouldn't seem nearly as daunting to make the switch. But when you start looking closely you realize that it's more than that. Regarding the size of the routing table, is it really that much of a big deal? Is it significant in the ISP's expanses? I find that hard to believe. Also, obviously the ISPs might want to use clever tricks to save on bandwidth and processing power but that's not really what I'm talking about. ISPs have the manpower and the knowledge necessary to deal with that difficulty. The case I have in mind is what is, in my experience, 99% of the private networks today: you have a single public address, a NAT/Firewall/Router combo and then a handful of private subnets. This is where the migration should be as simple, seamless, familiar and comfortable as possible. This is where people can't be bothered to spend one week understanding IPv6 and reconfigure everything and still not be certain that they won't break something. This is where having IP addresses that actually look like IP addresses matter.
cronjobber 9y ago
IPv6 could have done three things. First, embed the "legacy" address space. Second, have legacy-to-legacy connections use v4 on the wire. Third, strongly encourage existing user-maintained configuration (config file formats etc.) to remain perfectly valid as long as they don't use v6 addresses (or other v6 features.) You are right, you'd still need a "legacy" address to connect to "true" v4 servers, but that address would be all you need, while most operating systems, routers, client and server software could be, technically, all-v6 all-the-time by now.
- zAy0LfpBZLC8mAC 9y ago
  > First, embed the "legacy" address space. What do you mean by that? > Second, have legacy-to-legacy connections use v4 on the wire. Just as IPv6 does? > Third, strongly encourage existing user-maintained configuration (config file formats etc.) to remain perfectly valid as long as they don't use v6 addresses (or other v6 features.) Just as is the case with IPv6? > You are right, you'd still need a "legacy" address to connect to "true" v4 servers, but that address would be all you need Just as it is now? > while most operating systems, routers, client and server software could be, technically, all-v6 all-the-time by now. If they implemented the extensions ... just as if they implemented IPv6 by now?
- pdkl95 9y ago
  > embed the "legacy" address space They did. Every IPv4 address is in a reserved area of the IPv6 address space. a.b.c.d # v4 ::FFFF:a.b.c.d # v6 http://www.tcpipguide.com/free/t_IPv6IPv4AddressEmbedding-2.htm http://www.tcpipguide.com/free/t_IPv6IPv4AddressEmbedding-2.... > software could be, technically, all-v6 all-the-time by now. I started using v6 in the late 90s. Software developed post-2000(-ish) should already be compatible. Unfortunately, there are a lot of developers that think this is hard/impossible (or they are lazy), and so we have software that is defunct by design. > that address would be all you need Regardless of how the address was represented, software would still need to be updated.
  - cronjobber 9y ago
    I stand corrected, RFC 4038 seems to be what I was looking for. But it seems to be a late addition, and OS support is optional. If developers think moving their apps to IPv6 is too complicated, I can't fault them.

simias 9y ago

I actually started replying to your comment with my master plan to make an "IPv6 in IPv4" but I realized that I was probably going to make an ass of myself since plenty of much more clever people have worked on the subject for a long longer than I did. But I guess my main issue with this is: >(a) that compatibility is in effect a tunnel, and there are lots of ways to tunnel IPv6 over IPv4 just fine I agree that no matter how you slice it, at some point if you want to transition you'll have to tunnel things. But why are there "lots of ways" to do it? Why isn't there one single, "it just works" way to add compatibility? IMO this should have been a core feature of the standard, bullet point #2, just below "add more addresses". Explain in details how the transition will be made, how you convert an IPv4 into IPv6 incrementally while not breaking anything. Sure it's hard to make a one-size-fits all, but all the corners you have to cut and just make it work. Why isn't the IPv6 my ISP provides simply an extension of my IPv4? If my IPv4 is 216.58.213.174, why isn't the IPv6 216.58.213.174.[more stuff]? Why can I just concatenate my IPv4 public and NAT'ed LAN IP to get a valid IPv6? `ifconfig eth0 inet6 216.58.213.174:192.168.0.101/32` and here we go. It looks familiar, I understand what it means. You could even standardize it to make the IPv4 always be the low bytes of the IPv6 address or something like that, this way I don't have to worry about two sets of addresses. Instead it's `ifconfig eth0 inet6 2001:41d0:000a:050d::1 prefixlen 128 accept_rtadv no_radr`. Ah. I'm sure there's a good reason to make those changes but I can't really be bothered to figure them out as long as IPv4 just works. I'll get around to learn it, eventually, maybe in a few months when I read an article on HN telling me that we're at 21% worldwide adoption.

zAy0LfpBZLC8mAC 9y ago
> But why are there "lots of ways" to do it? Why isn't there one single, "it just works" way to add compatibility? Well, for the same reason why there are lots of ways to tunnel IPv4 over IPv4? Some work through NAT, some don't, some encrypt, some don't, some allow for transport of packets that exceed the tunnel's transport PMTU, some don't, ... it's some form of tradeoff for different needs: If you are behind CGN of some crappy provider, you probably have to tunnel over UDP using small packets, if you are an ISP, that would be way too much overhead and you want to instead transport over raw IP in jumbo frames. > Why isn't the IPv6 my ISP provides simply an extension of my IPv4? If my IPv4 is 216.58.213.174, why isn't the IPv6 216.58.213.174.[more stuff]? Why can I just concatenate my IPv4 public and NAT'ed LAN IP to get a valid IPv6? Because that would not actually help anything. That would possibly make the user interface look a bit more familiar, but you would still need a completely new protocol underneath with all the same migration problems that we have now. And also, the differences at the user interface level are pretty minor, conceptually IPv6 really works much the same as IPv4, except with longer adresses. That they chose to use hex notation instead of decimal really is probably simply to make the notation shorter, and also the shorthand-notation for a run of zeros makes things a bit less unwieldy. As for actually somehow reusing the existing address space, the existing global IPv4 routing table is massively fragmented with every larger ISP having tons of routes for disparate prefixes that they acquired over the years. That makes IPv4 backbone routers expensive. IPv6 is large enough that providers generally should never have more than one prefix, which makes the routing table a lot smaller.
- simias 9y ago
  But don't you think UI is extremely important in these situations? If you sold IPv6 as "it works like IPv4 but with 128 bit addresses" I'm sure it wouldn't seem nearly as daunting to make the switch. But when you start looking closely you realize that it's more than that. Regarding the size of the routing table, is it really that much of a big deal? Is it significant in the ISP's expanses? I find that hard to believe. Also, obviously the ISPs might want to use clever tricks to save on bandwidth and processing power but that's not really what I'm talking about. ISPs have the manpower and the knowledge necessary to deal with that difficulty. The case I have in mind is what is, in my experience, 99% of the private networks today: you have a single public address, a NAT/Firewall/Router combo and then a handful of private subnets. This is where the migration should be as simple, seamless, familiar and comfortable as possible. This is where people can't be bothered to spend one week understanding IPv6 and reconfigure everything and still not be certain that they won't break something. This is where having IP addresses that actually look like IP addresses matter.

cronjobber 9y ago

IPv6 could have done three things. First, embed the "legacy" address space. Second, have legacy-to-legacy connections use v4 on the wire. Third, strongly encourage existing user-maintained configuration (config file formats etc.) to remain perfectly valid as long as they don't use v6 addresses (or other v6 features.) You are right, you'd still need a "legacy" address to connect to "true" v4 servers, but that address would be all you need, while most operating systems, routers, client and server software could be, technically, all-v6 all-the-time by now.

zAy0LfpBZLC8mAC 9y ago
> First, embed the "legacy" address space. What do you mean by that? > Second, have legacy-to-legacy connections use v4 on the wire. Just as IPv6 does? > Third, strongly encourage existing user-maintained configuration (config file formats etc.) to remain perfectly valid as long as they don't use v6 addresses (or other v6 features.) Just as is the case with IPv6? > You are right, you'd still need a "legacy" address to connect to "true" v4 servers, but that address would be all you need Just as it is now? > while most operating systems, routers, client and server software could be, technically, all-v6 all-the-time by now. If they implemented the extensions ... just as if they implemented IPv6 by now?
pdkl95 9y ago
> embed the "legacy" address space They did. Every IPv4 address is in a reserved area of the IPv6 address space. a.b.c.d # v4 ::FFFF:a.b.c.d # v6 http://www.tcpipguide.com/free/t_IPv6IPv4AddressEmbedding-2.htm http://www.tcpipguide.com/free/t_IPv6IPv4AddressEmbedding-2.... > software could be, technically, all-v6 all-the-time by now. I started using v6 in the late 90s. Software developed post-2000(-ish) should already be compatible. Unfortunately, there are a lot of developers that think this is hard/impossible (or they are lazy), and so we have software that is defunct by design. > that address would be all you need Regardless of how the address was represented, software would still need to be updated.
- cronjobber 9y ago
  I stand corrected, RFC 4038 seems to be what I was looking for. But it seems to be a late addition, and OS support is optional. If developers think moving their apps to IPv6 is too complicated, I can't fault them.