7 ms·

This is a little self contradictory. Saying that it's "not that different", then going on to mention "the strategy of having two internets". Having two interne

by johnea 2y ago

This is a little self contradictory. Saying that it's "not that different", then going on to mention "the strategy of having two internets". Having two internets suggests that it's totally different, in the sense that there is no address space overlap between IPv4 and IPv6, an inherent design flaw of the IPv6 protocol. Just to provide the architypical links: This was documented about 25 years ago by DJB: https://cr.yp.to/djbdns/ipv6mess.html https://cr.yp.to/djbdns/ipv6mess.html And has been repeatedly discussed on HN: https://news.ycombinator.com/item?id=10854570 https://news.ycombinator.com/item?id=10854570 As you mention, IPv6 has exsited for the majority of the commercial internet's history, now 25 years later, it's still not the default transport protocol. It _was_ possible to create an address space extension that was IPv4 backwards compatible, this option was just not chosen, and now we're still dealing with the dual stack mess.

ninkendo 2y ago
> Having two internets suggests that it's totally different, in the sense that there is no address space overlap between IPv4 and IPv6 That's not at all what I'm suggesting, I'm saying "two internets" because there are two internets: IPv4 and IPv6. You need two internet stacks on every host to deal with this, hence two internets. If everything in the IPv6 protocol suite was literally identical to IPv4, but just with some extra bytes in every address, there would still be two internets, because they are not mutually compatible. Saying "two internets" is not a judgement call on whether IPv6 changed too much or is too different. It's just the literal truth. There are two internets, because one can't communicate with the other.
- Dagger2 2y ago
  Well, that's just not true: $ ip -4 addr 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever $ ping -6 ipv4.google.com PING ipv4.google.com(sof04s06-in-f14.1e100.net (64:ff9b::142.251.140.78)) 56 data bytes 64 bytes from 64:ff9b::8efb:8c4e: icmp_seq=1 ttl=55 time=27.9 ms This is a v6-only machine (no v4 address other than lo), talking to a v4-only hostname. If it was truly not possible to communicate, this wouldn't work. > If everything in the IPv6 protocol suite was literally identical to IPv4, but just with some extra bytes in every address, because they are not mutually compatible. This part is true though. v6 is backwards compatible in rather a lot of ways, but v4 isn't forwards compatible, and it's important to note that this comes entirely from the larger address size -- no amount of making v6 more identical to v4 than it already is would make v4 any more compatible with it, unless you undermined the entire point and made the addresses 32 bits.
  - ninkendo 2y ago
    Now try that on an ipv4-only host trying to talk to an IPv6-only address. You can’t, hence, 2 internets. (Yes, I understand there is no other way for a larger address space to exist that doesn’t have this problem. We are in violent agreement here. But that doesn’t mean there aren’t 2 internets. Let’s call a spade a spade.)
    - Dagger2 2y ago
      I can do it with a moral equivalent of a port forward. This situation was inevitable, but it's not like they just gave up and said "welp, guess they're separate then". We've developed basically every single method of communicating between v4 and v6 that are possible to develop. There's two address spaces, but they're linked into one Internet. (Or really, with NAT in the picture, it's millions of overlapping address spaces, but we still consider that to be one Internet.)
hypeatei 2y ago
> no address space overlap between IPv4 and IPv6, an inherent design flaw of the IPv6 This is not an inherent design flaw and is often brought up in IPv6 threads commonly referred to as the "just add more octets, bro" argument. This comment[0] sums it up well, but I'll leave it here for convenience: > Fact is you'd run into exactly the same problems as with IPv6. Sure, network-enabled software might be easier to rewrite to support 40-bit IPv4+, but any hardware-accelerated products (routers, switches, network cards, etc.) would still need replacement (just as with IPv6), and you'd still need everyone to be assigned unique IPv4+ addresses in order to communicate with each other (just as with IPv6). [0]: https://news.ycombinator.com/item?id=37120422 https://news.ycombinator.com/item?id=37120422
growse 2y ago
> It _was_ possible to create an address space extension that was IPv4 backwards compatible How? People keep claiming this, but I've yet to see a coherent design (either back then or today). Do you think they broke backwards-compatibility _on purpose_? What's the motivation here?
- aboardRat4 2y ago
  By promoting cgnat46
Hikikomori 2y ago
It's not that different, it's separate. >It _was_ possible to create an address space extension that was IPv4 backwards compatible, this option was just not chosen, and now we're still dealing with the dual stack mess. This was never possible.
- aboardRat4 2y ago
  cgnat46 is totally possible
layer8 2y ago
> there is no address space overlap between IPv4 and IPv6 Yes there is: https://www.rfc-editor.org/rfc/rfc4291.html#section-2.5.5.2 https://www.rfc-editor.org/rfc/rfc4291.html#section-2.5.5.2
throw0101c 2y ago
> Having two internets suggests that it's totally different, in the sense that there is no address space overlap between IPv4 and IPv6, an inherent design flaw of the IPv6 protocol. It is not a design flaw of IPv6, it is a limitation of the laws of physics: how can you fit >32 bits of data (IPv6) into 32 bit data structures (IPv4: struct s_addr)? Even if the IPng protocol could recognize IPv4 address and send out data, how can a host which only understands 32-bit addresses send back a reply back to the IPng host? If a packet with a >32b address comes in, how would a 32b-only hosts be able to handle it? From Bernstein: > In other words: The current IPv6 specifications don't allow public IPv6 addresses to send packets to public IPv4 addresses. They also don't allow public IPv4 addresses to send packets to public IPv6 addresses. How would a non-updated IPv4 system know about the IPng protocol? If a non-updated router had a IPng packet arrive on an interface, how would it know how to handle the packet and routing? All the folks criticizing IPv6 don't ever describe how this mythical system would work: how do you get 32-bit-only system to understand more-32-bits of addressing? Translation boxes? Congratulations, you've just invented 6rd BR or NAT64, making it no different that IPv6. The primary purpose of IPng was a bigger address space, but how would that work without updating every single IPv4 device? You know, like had to be done for the eventual IPng, SIPP (aka IPv6). * https://datatracker.ietf.org/doc/html/rfc1752 https://datatracker.ietf.org/doc/html/rfc1752
- aboardRat4 2y ago
  >how can you fit >32 bits of data (IPv6) into 32 bit data structures (IPv4: struct s_addr)? By using nat46 on ISP's routers.
  - throw0101c 2y ago
    >> how can you fit >32 bits of data (IPv6) into 32 bit data structures (IPv4: struct s_addr)? > By using nat46 on ISP's routers. I do not understand. In Ye Olde Times a system would call gethostbyname() and this send out a DNS packet asking for the IP address. Of course DNS record returned would be an A record, which is where your first problem is: A records are fixed at 32-bits (RFC 1035 § 3.4.1). So your first task is to create a new record type and update every DNS server and client to support the longer addresses. Of course the longer address has to fit into the data structures of the OS you called gethostbyname() from, but gethostbyname() is set to use particular data structures. So now you have to update all the client DNS code to support the new, longer addresses. Further, gethostbyname() had no way to specify an address type (like if you wanted the IPv4 address(es) or the IPng one(s)): * https://man.freebsd.org/cgi/man.cgi?query=gethostbyname&manpath=FreeBSD+1.0-RELEASE https://man.freebsd.org/cgi/man.cgi?query=gethostbyname&manp... The the returned data structures only allowed for one type of address type, so you either got IPv4 or IPng. So if you wanted to be able to specify the record/address type to query, a new API had to be created. Luckily the next step, setting up a socket() and connect()ing is less of a burden, because that API already supported different protocols: * https://man.freebsd.org/cgi/man.cgi?query=socket&manpath=FreeBSD+1.0-RELEASE https://man.freebsd.org/cgi/man.cgi?query=socket&manpath=Fre... But if you have a host that support IPng, but its upstream router does not, how does it support a packet with a longer source address a shorter destination address get through? Do you send IPv4 packets with embedded IPng packets with-in them to translation relays perhaps? How is this any different IPv6 transition mechanisms like Teredo?

by johnea 2y ago

ninkendo 2y ago

> Having two internets suggests that it's totally different, in the sense that there is no address space overlap between IPv4 and IPv6 That's not at all what I'm suggesting, I'm saying "two internets" because there are two internets: IPv4 and IPv6. You need two internet stacks on every host to deal with this, hence two internets. If everything in the IPv6 protocol suite was literally identical to IPv4, but just with some extra bytes in every address, there would still be two internets, because they are not mutually compatible. Saying "two internets" is not a judgement call on whether IPv6 changed too much or is too different. It's just the literal truth. There are two internets, because one can't communicate with the other.

Dagger2 2y ago
Well, that's just not true: $ ip -4 addr 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever $ ping -6 ipv4.google.com PING ipv4.google.com(sof04s06-in-f14.1e100.net (64:ff9b::142.251.140.78)) 56 data bytes 64 bytes from 64:ff9b::8efb:8c4e: icmp_seq=1 ttl=55 time=27.9 ms This is a v6-only machine (no v4 address other than lo), talking to a v4-only hostname. If it was truly not possible to communicate, this wouldn't work. > If everything in the IPv6 protocol suite was literally identical to IPv4, but just with some extra bytes in every address, because they are not mutually compatible. This part is true though. v6 is backwards compatible in rather a lot of ways, but v4 isn't forwards compatible, and it's important to note that this comes entirely from the larger address size -- no amount of making v6 more identical to v4 than it already is would make v4 any more compatible with it, unless you undermined the entire point and made the addresses 32 bits.
- ninkendo 2y ago
  Now try that on an ipv4-only host trying to talk to an IPv6-only address. You can’t, hence, 2 internets. (Yes, I understand there is no other way for a larger address space to exist that doesn’t have this problem. We are in violent agreement here. But that doesn’t mean there aren’t 2 internets. Let’s call a spade a spade.)
  - Dagger2 2y ago
    I can do it with a moral equivalent of a port forward. This situation was inevitable, but it's not like they just gave up and said "welp, guess they're separate then". We've developed basically every single method of communicating between v4 and v6 that are possible to develop. There's two address spaces, but they're linked into one Internet. (Or really, with NAT in the picture, it's millions of overlapping address spaces, but we still consider that to be one Internet.)

hypeatei 2y ago

> no address space overlap between IPv4 and IPv6, an inherent design flaw of the IPv6 This is not an inherent design flaw and is often brought up in IPv6 threads commonly referred to as the "just add more octets, bro" argument. This comment[0] sums it up well, but I'll leave it here for convenience: > Fact is you'd run into exactly the same problems as with IPv6. Sure, network-enabled software might be easier to rewrite to support 40-bit IPv4+, but any hardware-accelerated products (routers, switches, network cards, etc.) would still need replacement (just as with IPv6), and you'd still need everyone to be assigned unique IPv4+ addresses in order to communicate with each other (just as with IPv6). [0]: https://news.ycombinator.com/item?id=37120422 https://news.ycombinator.com/item?id=37120422

growse 2y ago

> It _was_ possible to create an address space extension that was IPv4 backwards compatible How? People keep claiming this, but I've yet to see a coherent design (either back then or today). Do you think they broke backwards-compatibility _on purpose_? What's the motivation here?

aboardRat4 2y ago
By promoting cgnat46

Hikikomori 2y ago

It's not that different, it's separate. >It _was_ possible to create an address space extension that was IPv4 backwards compatible, this option was just not chosen, and now we're still dealing with the dual stack mess. This was never possible.

aboardRat4 2y ago
cgnat46 is totally possible

layer8 2y ago

> there is no address space overlap between IPv4 and IPv6 Yes there is: https://www.rfc-editor.org/rfc/rfc4291.html#section-2.5.5.2 https://www.rfc-editor.org/rfc/rfc4291.html#section-2.5.5.2

throw0101c 2y ago

> Having two internets suggests that it's totally different, in the sense that there is no address space overlap between IPv4 and IPv6, an inherent design flaw of the IPv6 protocol. It is not a design flaw of IPv6, it is a limitation of the laws of physics: how can you fit >32 bits of data (IPv6) into 32 bit data structures (IPv4: struct s_addr)? Even if the IPng protocol could recognize IPv4 address and send out data, how can a host which only understands 32-bit addresses send back a reply back to the IPng host? If a packet with a >32b address comes in, how would a 32b-only hosts be able to handle it? From Bernstein: > In other words: The current IPv6 specifications don't allow public IPv6 addresses to send packets to public IPv4 addresses. They also don't allow public IPv4 addresses to send packets to public IPv6 addresses. How would a non-updated IPv4 system know about the IPng protocol? If a non-updated router had a IPng packet arrive on an interface, how would it know how to handle the packet and routing? All the folks criticizing IPv6 don't ever describe how this mythical system would work: how do you get 32-bit-only system to understand more-32-bits of addressing? Translation boxes? Congratulations, you've just invented 6rd BR or NAT64, making it no different that IPv6. The primary purpose of IPng was a bigger address space, but how would that work without updating every single IPv4 device? You know, like had to be done for the eventual IPng, SIPP (aka IPv6). * https://datatracker.ietf.org/doc/html/rfc1752 https://datatracker.ietf.org/doc/html/rfc1752

aboardRat4 2y ago
>how can you fit >32 bits of data (IPv6) into 32 bit data structures (IPv4: struct s_addr)? By using nat46 on ISP's routers.
- throw0101c 2y ago
  >> how can you fit >32 bits of data (IPv6) into 32 bit data structures (IPv4: struct s_addr)? > By using nat46 on ISP's routers. I do not understand. In Ye Olde Times a system would call gethostbyname() and this send out a DNS packet asking for the IP address. Of course DNS record returned would be an A record, which is where your first problem is: A records are fixed at 32-bits (RFC 1035 § 3.4.1). So your first task is to create a new record type and update every DNS server and client to support the longer addresses. Of course the longer address has to fit into the data structures of the OS you called gethostbyname() from, but gethostbyname() is set to use particular data structures. So now you have to update all the client DNS code to support the new, longer addresses. Further, gethostbyname() had no way to specify an address type (like if you wanted the IPv4 address(es) or the IPng one(s)): * https://man.freebsd.org/cgi/man.cgi?query=gethostbyname&manpath=FreeBSD+1.0-RELEASE https://man.freebsd.org/cgi/man.cgi?query=gethostbyname&manp... The the returned data structures only allowed for one type of address type, so you either got IPv4 or IPng. So if you wanted to be able to specify the record/address type to query, a new API had to be created. Luckily the next step, setting up a socket() and connect()ing is less of a burden, because that API already supported different protocols: * https://man.freebsd.org/cgi/man.cgi?query=socket&manpath=FreeBSD+1.0-RELEASE https://man.freebsd.org/cgi/man.cgi?query=socket&manpath=Fre... But if you have a host that support IPng, but its upstream router does not, how does it support a packet with a longer source address a shorter destination address get through? Do you send IPv4 packets with embedded IPng packets with-in them to translation relays perhaps? How is this any different IPv6 transition mechanisms like Teredo?