7 ms·

We had two choices back then.. 1) make everything the same, the good and the bad, just extend the address space, and replace all the networking stacks in all t

We had two choices back then.. 1) make everything the same, the good and the bad, just extend the address space, and replace all the networking stacks in all the gear everywhere. 2) if we're already replacing everything, make stuff better We chose #2, with varying degrees of what is "better".

quectophoton 2y ago
And for the record, a backwards-compatible-ish way was proposed in 1993 (https://datatracker.ietf.org/doc/html/rfc1475 https://datatracker.ietf.org/doc/html/rfc1475), by using an option in the IPv4 packet header. AFAIU it was "just" defining an option type; the IPv4 packet header itself didn't even need to be changed. 1993 was more than 30 years ago. So people who wanted to keep it backwards-compatible with IPv4 already had a chance.
- throw0101b 2y ago
  From §8.3: Each TCP/IP v7 system, whether host or router, must be able to recognize adjacent systems in the topology that are (only) v4, and call the appropriate conversion routine just before sending the datagram. […] On networks where ARP is not normally used, the method is to assume that a remote system is v7. If an IPv7 datagram is received from it, the assumption is confirmed. If, after a short time, no IPv7 datagram is received, a v7 ICMP echo is sent. If a reply is received (in either version) the assumption is confirmed. If no reply is recieved, the remote system is assumed not to understand IPv7, and datagrams are converted to IPv4 just before transmitting them. So basically very close to what's done now in the IPv4-IPv6 world with Happy Eyeballs (do a DNS lookup, and try both A and AAAA responses, and see who answers first): * https://en.wikipedia.org/wiki/Happy_Eyeballs https://en.wikipedia.org/wiki/Happy_Eyeballs And let's not forget about all the function and system calls that need to be updated (§2.4) because various structs are of a fixed sized: There is a non-trivial amount of software that assumes that an "int" is the same size and shape as an IP address, and does things like "ipaddr = *(int *)ptr". This usage has always been incorrect, but does occur with disturbing frequency. As IPv7 8 byte addresses appear in the application layers, this software will find those addresses unreachable; this is preferable to interacting with a random host. Just like with IPv6, the IPv7 described in RFC 1475 would have needed libraries and data structures to be created. Also DNS A records were fixed sizes, and so a new record type would have needed to be created for IPv7 (like AAAA was for IPv6). IPv7 would have had the exact same issues that IPv6 had with rollout. There is no "just" when trying to expand a fixed-size data structure across the entire planet.
  - theamk 2y ago
    No they would not. Linux is IPv6 compatible since 1996. Apache since 2002. Python since 2004. The C programs and network protocols have been implemented for 20+ years.. so why isn't everyone switched yet? Because IPv6 refused to be IPv4-with-extensions and instead decided to be completely incompatible - so all the admin scripts, all the best practices, all the configuration needs to be rewritten. Instead of fixing a single apache codebase, one needs to fix millions of adhoc network configurations. IPv7 on the other side, had absolutely different philosophy: The objective of conversion is to be able to upgrade systems, both hosts and routers, in whatever order desired by their owners. Organizations must be able to upgrade any given system without reconfiguration or modification of any other; and IPv4 hosts must be able to interoperate essentially forever. (IPv4 routers will probably be effectively eliminated at some point, except where they exist in their own remote or isolated corners.) this would get things converted much faster.
    - throw0101b 2y ago
      > No they would not. Linux is IPv6 compatible since 1996. Apache since 2002. Python since 2004. Okay: so given that gethostbyname(3) only dealt with struct hostent with type of AF_INET: * https://pubs.opengroup.org/onlinepubs/000095399/functions/gethostbyname.html https://pubs.opengroup.org/onlinepubs/000095399/functions/ge... * https://www.akkadia.org/drepper/userapi-ipv6.html https://www.akkadia.org/drepper/userapi-ipv6.html Those had to be rewritten to support AF_INET6 and use use that new address type. See also changing all socket(2) calls. * https://datatracker.ietf.org/doc/html/rfc3493 https://datatracker.ietf.org/doc/html/rfc3493 * https://datatracker.ietf.org/doc/html/rfc4038 https://datatracker.ietf.org/doc/html/rfc4038 Regardless of what was chosen to be IPng, there would have been a whole bunch of rewriting necessary. If "IPv7" (TP/IX) was chosen as IPng (instead of SIPP(-16) becoming "IPv6") then we would have to add "AF_INET7" everywhere. And the supporting infrastructure (e.g., new DNS record types) would also have needed to be done for AF_INET7, just like it had to be done for AF_INET6. > The C programs and network protocols have been implemented for 20+ years.. so why isn't everyone switched yet? Because most programs are written in Western, industrialized countries. And those countries have plenty of IPv4 address to go around since they got to the Internet first. And so there is no (perceived) shortage for the people writing and and running the largest Internet services they feel no pressing need to. ("Address shortage? What address shortage?") IPv6 has not taken off not because it's "bad" or "worse" than IPv4, or because IPv4 is "better" than IPv6: it has not taken off because of inertia: IPv4 works well enough and its short-coming (e.g., NAT) are known quantities with known workarounds. Meanwhile those folks that weren't fortunate enough to around for the early IPv4 address land grab are struggling with shortages: * https://community.roku.com/t5/Features-settings-updates/It-s-2022-and-still-no-IPv6/m-p/854673/highlight/true#M35732 https://community.roku.com/t5/Features-settings-updates/It-s... * https://news.ycombinator.com/item?id=35047624 https://news.ycombinator.com/item?id=35047624 > IPv7 on the other side, had absolutely different philosophy: All IPng had the same criteria, including gradual upgrades ("Technical Criteria for Choosing IP The Next Generation (IPng)" § 5.5 Transition): We believe that it is not possible to have a "flag-day" form of transition in which all hosts and routers must change over at once. The size, complexity, and distributed administration of the Internet make such a cutover impossible. Rather, IPng will need to co-exist with IPv4 for some period of time. There are a number of ways to achieve this co-existence such as requiring hosts to support two stacks, converting between protocols, or using backward compatible extensions to IPv4. Each scheme has its strengths and weaknesses, which have to be weighed. Furthermore, we note that, in all probability, there will be IPv4 hosts on the Internet effectively forever. IPng must provide mechanisms to allow these hosts to communicate, even after IPng has become the dominant network layer protocol in the Internet. * https://datatracker.ietf.org/doc/html/rfc1726#section-5.5 https://datatracker.ietf.org/doc/html/rfc1726#section-5.5 The authors of RFC 1475 themselves 'abandoned' / changed TP/IX and put forward CATNIP: * https://datatracker.ietf.org/doc/html/rfc1707 https://datatracker.ietf.org/doc/html/rfc1707 You are putting forward an idea (RFC 1475: TP/IX) which the authors themselves did not put forward for evaluation.
ninkendo 2y ago
It’s interesting because much of the “better” has eroded away in the current IPv6 landscape: - “You don’t need NAT”: well, you still need a stable address space for your LAN that survives your ISP randomly changing your prefix (which has happened to me at least a half dozen times over the past year), and the best option for that is ULA, which erodes many of the benefits of “no NAT” because my IP’s are not routable. - “No DHCP”, well you can’t reliably know the IP address of anything on your network without it: SLAAC with EUI-64 was supposed to make addresses stable and derived from your MAC address, but oops, that’s a privacy nightmare, so we end up randomly generating them (and rotating them!) IMO this is more complicated than DHCP, not less. Oh and DHCP lets you assign dynamic DNS names to every lease you hand out, and you lose that too with SLAAC. You can do mDNS but that doesn’t help with public hosts that you want to access from the internet, you’re left with static IPs there, and god help you if you get re-prefixed (see point #1) because now your static IP won’t route because your ISP changed the prefix. I’m really rooting for ipv6, trust me, but it feels like all the greenfield rearchitecting they did ultimately doesn’t seem much better than the IPv4 equivalent standards. NAT is here to stay, unfortunately, and so is DHCP.
- simoncion 2y ago
  > ...the best option for that is ULA... I have both globally-routable and ULA addresses assigned to the hosts on my LAN. The ULA addresses are in my local DNS, and I update global DNS whenever the site's global prefix changes. Aside from the fact that the global prefix changes way too frequently (like once a quarter) it works great for me. > ...so we end up randomly generating them (and rotating them!)... Yeah, I turn this shit off whenever I have the power to. This was a fucking stupid-ass thing to have on by default. Hella buncha ways you can be tracked that give zero shits about what your IP address is. (This is one time when I wish the Net Heads would have consulted with the Web Heads and learned about how trackers actually work.) > NAT is here to stay, unfortunately, and so is DHCP. Nothing wrong with doing DHCPv6 and SLAAC, or just DHCPv6. My network just uses SLAAC, but folks who need more features than that provides have another tool they can deploy. This is a good thing. And you __can__ use NAT if you choose to, but if you're being assigned a publicly-routable prefix, there's no real reason to. Set up your border firewall to deny inbound unsolicited traffic, and set up uPNP (or similar) to hole-punch and you end up with the same security guarantees.
Control8894 2y ago
I think there's an extra, important, oft-missed part implicit in your scenarios: 1) make everything the same, the good and the bad, just extend the address space, and replace all the networking stacks in all the gear everywhere. ... but don't make anyone learn anything new 2) if we're already replacing everything, make stuff better ... and make everyone learn everything all over again
sidewndr46 2y ago
I'd argue they chose a 3rd option: make it 'better' but be sure that the transition can never actually happen.

quectophoton 2y ago

And for the record, a backwards-compatible-ish way was proposed in 1993 (https://datatracker.ietf.org/doc/html/rfc1475 https://datatracker.ietf.org/doc/html/rfc1475), by using an option in the IPv4 packet header. AFAIU it was "just" defining an option type; the IPv4 packet header itself didn't even need to be changed. 1993 was more than 30 years ago. So people who wanted to keep it backwards-compatible with IPv4 already had a chance.

throw0101b 2y ago
From §8.3: Each TCP/IP v7 system, whether host or router, must be able to recognize adjacent systems in the topology that are (only) v4, and call the appropriate conversion routine just before sending the datagram. […] On networks where ARP is not normally used, the method is to assume that a remote system is v7. If an IPv7 datagram is received from it, the assumption is confirmed. If, after a short time, no IPv7 datagram is received, a v7 ICMP echo is sent. If a reply is received (in either version) the assumption is confirmed. If no reply is recieved, the remote system is assumed not to understand IPv7, and datagrams are converted to IPv4 just before transmitting them. So basically very close to what's done now in the IPv4-IPv6 world with Happy Eyeballs (do a DNS lookup, and try both A and AAAA responses, and see who answers first): * https://en.wikipedia.org/wiki/Happy_Eyeballs https://en.wikipedia.org/wiki/Happy_Eyeballs And let's not forget about all the function and system calls that need to be updated (§2.4) because various structs are of a fixed sized: There is a non-trivial amount of software that assumes that an "int" is the same size and shape as an IP address, and does things like "ipaddr = *(int *)ptr". This usage has always been incorrect, but does occur with disturbing frequency. As IPv7 8 byte addresses appear in the application layers, this software will find those addresses unreachable; this is preferable to interacting with a random host. Just like with IPv6, the IPv7 described in RFC 1475 would have needed libraries and data structures to be created. Also DNS A records were fixed sizes, and so a new record type would have needed to be created for IPv7 (like AAAA was for IPv6). IPv7 would have had the exact same issues that IPv6 had with rollout. There is no "just" when trying to expand a fixed-size data structure across the entire planet.
- theamk 2y ago
  No they would not. Linux is IPv6 compatible since 1996. Apache since 2002. Python since 2004. The C programs and network protocols have been implemented for 20+ years.. so why isn't everyone switched yet? Because IPv6 refused to be IPv4-with-extensions and instead decided to be completely incompatible - so all the admin scripts, all the best practices, all the configuration needs to be rewritten. Instead of fixing a single apache codebase, one needs to fix millions of adhoc network configurations. IPv7 on the other side, had absolutely different philosophy: The objective of conversion is to be able to upgrade systems, both hosts and routers, in whatever order desired by their owners. Organizations must be able to upgrade any given system without reconfiguration or modification of any other; and IPv4 hosts must be able to interoperate essentially forever. (IPv4 routers will probably be effectively eliminated at some point, except where they exist in their own remote or isolated corners.) this would get things converted much faster.
  - throw0101b 2y ago
    > No they would not. Linux is IPv6 compatible since 1996. Apache since 2002. Python since 2004. Okay: so given that gethostbyname(3) only dealt with struct hostent with type of AF_INET: * https://pubs.opengroup.org/onlinepubs/000095399/functions/gethostbyname.html https://pubs.opengroup.org/onlinepubs/000095399/functions/ge... * https://www.akkadia.org/drepper/userapi-ipv6.html https://www.akkadia.org/drepper/userapi-ipv6.html Those had to be rewritten to support AF_INET6 and use use that new address type. See also changing all socket(2) calls. * https://datatracker.ietf.org/doc/html/rfc3493 https://datatracker.ietf.org/doc/html/rfc3493 * https://datatracker.ietf.org/doc/html/rfc4038 https://datatracker.ietf.org/doc/html/rfc4038 Regardless of what was chosen to be IPng, there would have been a whole bunch of rewriting necessary. If "IPv7" (TP/IX) was chosen as IPng (instead of SIPP(-16) becoming "IPv6") then we would have to add "AF_INET7" everywhere. And the supporting infrastructure (e.g., new DNS record types) would also have needed to be done for AF_INET7, just like it had to be done for AF_INET6. > The C programs and network protocols have been implemented for 20+ years.. so why isn't everyone switched yet? Because most programs are written in Western, industrialized countries. And those countries have plenty of IPv4 address to go around since they got to the Internet first. And so there is no (perceived) shortage for the people writing and and running the largest Internet services they feel no pressing need to. ("Address shortage? What address shortage?") IPv6 has not taken off not because it's "bad" or "worse" than IPv4, or because IPv4 is "better" than IPv6: it has not taken off because of inertia: IPv4 works well enough and its short-coming (e.g., NAT) are known quantities with known workarounds. Meanwhile those folks that weren't fortunate enough to around for the early IPv4 address land grab are struggling with shortages: * https://community.roku.com/t5/Features-settings-updates/It-s-2022-and-still-no-IPv6/m-p/854673/highlight/true#M35732 https://community.roku.com/t5/Features-settings-updates/It-s... * https://news.ycombinator.com/item?id=35047624 https://news.ycombinator.com/item?id=35047624 > IPv7 on the other side, had absolutely different philosophy: All IPng had the same criteria, including gradual upgrades ("Technical Criteria for Choosing IP The Next Generation (IPng)" § 5.5 Transition): We believe that it is not possible to have a "flag-day" form of transition in which all hosts and routers must change over at once. The size, complexity, and distributed administration of the Internet make such a cutover impossible. Rather, IPng will need to co-exist with IPv4 for some period of time. There are a number of ways to achieve this co-existence such as requiring hosts to support two stacks, converting between protocols, or using backward compatible extensions to IPv4. Each scheme has its strengths and weaknesses, which have to be weighed. Furthermore, we note that, in all probability, there will be IPv4 hosts on the Internet effectively forever. IPng must provide mechanisms to allow these hosts to communicate, even after IPng has become the dominant network layer protocol in the Internet. * https://datatracker.ietf.org/doc/html/rfc1726#section-5.5 https://datatracker.ietf.org/doc/html/rfc1726#section-5.5 The authors of RFC 1475 themselves 'abandoned' / changed TP/IX and put forward CATNIP: * https://datatracker.ietf.org/doc/html/rfc1707 https://datatracker.ietf.org/doc/html/rfc1707 You are putting forward an idea (RFC 1475: TP/IX) which the authors themselves did not put forward for evaluation.

ninkendo 2y ago

It’s interesting because much of the “better” has eroded away in the current IPv6 landscape: - “You don’t need NAT”: well, you still need a stable address space for your LAN that survives your ISP randomly changing your prefix (which has happened to me at least a half dozen times over the past year), and the best option for that is ULA, which erodes many of the benefits of “no NAT” because my IP’s are not routable. - “No DHCP”, well you can’t reliably know the IP address of anything on your network without it: SLAAC with EUI-64 was supposed to make addresses stable and derived from your MAC address, but oops, that’s a privacy nightmare, so we end up randomly generating them (and rotating them!) IMO this is more complicated than DHCP, not less. Oh and DHCP lets you assign dynamic DNS names to every lease you hand out, and you lose that too with SLAAC. You can do mDNS but that doesn’t help with public hosts that you want to access from the internet, you’re left with static IPs there, and god help you if you get re-prefixed (see point #1) because now your static IP won’t route because your ISP changed the prefix. I’m really rooting for ipv6, trust me, but it feels like all the greenfield rearchitecting they did ultimately doesn’t seem much better than the IPv4 equivalent standards. NAT is here to stay, unfortunately, and so is DHCP.

simoncion 2y ago
> ...the best option for that is ULA... I have both globally-routable and ULA addresses assigned to the hosts on my LAN. The ULA addresses are in my local DNS, and I update global DNS whenever the site's global prefix changes. Aside from the fact that the global prefix changes way too frequently (like once a quarter) it works great for me. > ...so we end up randomly generating them (and rotating them!)... Yeah, I turn this shit off whenever I have the power to. This was a fucking stupid-ass thing to have on by default. Hella buncha ways you can be tracked that give zero shits about what your IP address is. (This is one time when I wish the Net Heads would have consulted with the Web Heads and learned about how trackers actually work.) > NAT is here to stay, unfortunately, and so is DHCP. Nothing wrong with doing DHCPv6 and SLAAC, or just DHCPv6. My network just uses SLAAC, but folks who need more features than that provides have another tool they can deploy. This is a good thing. And you __can__ use NAT if you choose to, but if you're being assigned a publicly-routable prefix, there's no real reason to. Set up your border firewall to deny inbound unsolicited traffic, and set up uPNP (or similar) to hole-punch and you end up with the same security guarantees.

Control8894 2y ago

I think there's an extra, important, oft-missed part implicit in your scenarios: 1) make everything the same, the good and the bad, just extend the address space, and replace all the networking stacks in all the gear everywhere. ... but don't make anyone learn anything new 2) if we're already replacing everything, make stuff better ... and make everyone learn everything all over again

sidewndr46 2y ago

I'd argue they chose a 3rd option: make it 'better' but be sure that the transition can never actually happen.