4 ms·

I'm not an expert on HTTP/3, but vehemently disagree about IPv6. It removes tons of overhead and cruft, making it delightful for datacenter work. That, and basi

I'm not an expert on HTTP/3, but vehemently disagree about IPv6. It removes tons of overhead and cruft, making it delightful for datacenter work. That, and basically guaranteeing you don't have to deal with the company you just acquired having deployed their accounts with the same 10/16 subnet your own company uses.

cogman10 2y ago
The problem I keep running into is that IPv6 support in common infrastructure is somewhat lacking. It's always a headache to learn that some container orchestration system doesn't support IPv6. Or an http client. Or a DNS resolver. Or whatever. Not to mention the supreme annoyance I have that, to this day, my ISP still does not have IPv6 addressing available.
- frollogaston 2y ago
  Yep, it's tragic because it all stems from unforced differences vs ipv4. The design was reasonable, but with perfect hindsight, it needed to be different. They needed to keep the existing /32s and just make the address field bigger, despite the disadvantages. "Everywhere but nowhere" is sorta how I'd describe ipv6. Most hardware and lower-level software supports it, so obviously it wasn't impossible to support a new protocol, but it's not being used.
  - JoshTriplett 2y ago
    > Yep, it's tragic because it all stems from unforced differences vs ipv4. The design was reasonable, but with perfect hindsight, it needed to be different. They needed to keep the existing /32s and just make the address field bigger, despite the disadvantages. Exactly. I would love to have seen the world in which that happened, and where all the other parts of IPv6 were independently proposed (and likely many of them rejected as unwanted).
    - frollogaston 2y ago
      The main problem wasn't all the smaller features but one big one in particular that can't be split into smaller pieces, the new addressing scheme. They wanted to replace all the existing addresses, which meant replacing all the routes. Besides the difficulty of that by itself, it automatically meant that the v6 versions of DNS, DHCP, NAT, etc wouldn't support v4, rather it'd be a totally separate stack. There were also some small things. And routers often having bad defaults for v6, which btw, would not even be a concern if they left the big thing alone.
      - JoshTriplett 2y ago
        > Besides the difficulty of that by itself, it automatically meant that the v6 versions of DNS, DHCP, NAT, etc wouldn't support v4, rather it'd be a totally separate stack. Sure, "make the addresses bigger" would have required providing DHCPv6, DNS AAAA records, and various other protocol updates for protocols that embedded IP addresses. And making changes to the protocol header at the same time (e.g. removing the redundant checksum) were also a good idea. It didn't require pushing SLAAC instead of DHCP. It didn't require recommending (though fortunately not requiring) IPsec for all IPv6 stacks. It didn't require changing the address syntax to use colons, causing pain for all protocols that used `IP:port` or similar. It didn't require mandating link-local addresses for every interface. It didn't require adding a mandatory address-collision-detection mechanism. And I'm sure I'm forgetting a few.
        frollogaston 2y ago
        Yeah. I didn't like any of those proposed changes, especially the colons. You also didn't mention how NAT6 isn't a thing by default.
        cyberax 2y ago
        It didn't require removing ARP and inventing Neighbor Discovery that embeds the hardware addresses into the IP address. It didn't require the Ruby Goldberg "on link" network mechanism. It didn't require multicast instead of broadcasts for local network discovery. It didn't require using DNS config (of all things) to specify V4/V6 priority. It didn't require adding a "flow label" that is nobody to this day knows how to use properly. The list of fails is ridiculous.
  - kstrauser 2y ago
    "It's not being used", except for nearly half of Google's traffic: https://www.google.com/intl/en/ipv6/statistics.html https://www.google.com/intl/en/ipv6/statistics.html Disconnect your phone from Wi-Fi and visit https://ifconfig.co/ https://ifconfig.co/ . If you're a Verizon customer, it's probably going to show you an IPv6 address. It's huge, right now, today.
    - frollogaston 2y ago
      "Depended on" is what I should have said. An ISP or website can be v4-only or support both, but it's not going to be v6-only.
      - adgjlsfhk1 2y ago
        this isn't true. I know because at some point XFinity started dropping ipv6 connections for me and I noticed because a number of sites (forget which) were broken
        frollogaston 2y ago
        What do you mean by dropping ipv6 connections, like dropping ipv6 packets? That's only an issue if you're using v6. I disabled ipv6 on my router years ago and have never had a problem just using v4.
      - kstrauser 2y ago
        Fair. I bet that'll change soon though. My prediction is that it'll be a mobile-first game, like the next Pokemon Go sort of thing, that'll be IPv6-only.
        frollogaston 2y ago
        I agree it would probably be something mobile-first that does it, since those carriers all(?) support v6.
        gruez 2y ago
  - p_l 2y ago
    And it would have failed for exactly the same reasons, because just changing the address field size is enough to have everyone who uses BSD Sockets to rewrite all parts of code that create sockets. Especially since getaddrinfo was ported over from more streams/OSI oriented stacks pretty late, precisely because BSD Sockets required separate path for every protocol. On hw side, by mid-1990s even changing one routing-important field would mean possibly a new generation of ASICs needed with more capabilities. Essentially, once you agree to break one field, the costs are so big why not try fixing other parts? Especially given that IETF has rejected an already implemented solution of just going with OSI for layer 3.
    - frollogaston 2y ago
      All that code using BSD sockets is rewritten by now to support v6, right? If so, that can't be the reason, cause v4 is still dominant. And btw, what I suggested would actually work without userspace code changes until you want to start subdividing the /32s. Cause v4 addresses would've still been valid in v6.
      - kstrauser 2y ago
        Where would you store the other 96 bits. In the body?
        frollogaston 2y ago
        Ipv6 packet format was needed either way, but only with the 32-bit address space at first (the other 92 bits set to 0). You simply tell your system to start using v6 instead, and everything else stays the same. No dual-stack. Next step would be upgrading all those parts like DNS, DHCP, etc to accept the 128-bit addrs, which again can be done in isolation. Then finally, ISPs or home routers can start handing out longer addresses like 1.1.1.1.2.
        Dylan16807 2y ago
        There are two ways for me to interpret "simply tell your system to start using v6". If it means upgrading every program, then your plan works but it's the same as how things work today. You're telling people to do a thing, and they aren't bothering. The "simple" step isn't simple at all. If it doesn't mean upgrading every program, then your rollout fails on the last step. You start handing out longer addresses and legacy programs can't access them.
- p_l 2y ago
  Major reason for that is BSD Sockets and their leaky abstraction that results in hardcoding protocol details in application code. For a good decade a lot of software had to be slowly patched in every place that made a socket to add v6 support, and sometimes multiple times because getaddrinfo didn't reach everyone early enough.
  - throwaway2037 2y ago
    > results in hardcoding protocol details in application code Are you suggesting that this could have been implemented a different way? Example: IP could be negotiated to upgrade from v4 to v6? I am curious about your ideas.
    - hamandcheese 2y ago
      There isn't much need for many applications to know or care what IP protocol they are speaking, they are all just writing bytes to a TCP stream. I think the parent is saying that existing socket abstractions meant that these applications still had to be "upgraded" to support IPv6 whereas it could/should have been handled entirely by the OS with better socket APIs.
    - tsimionescu 2y ago
      I think in principle, an application didn't need to know the exact format of an IP address, even if connecting directly to an IP. A simple idea that could have made application code much more IP-agnostic would have been for SOCK_ADDR_IN to take the IP in string format, not as a four-byte value. That way, lots of application code would not need to even be recompiled to move from a 4 byte IPv4 address to a 16 byte IPv6 address, whereas today they not only need to be recompiled, they need to be changed at the source level to use a new type that allows for both. Of course, code that operates on packets, in the TCP/IP stack of the OS would have still needed to be rewritten. But that is far less code than "every application that opens a socket". Of course, this only applies to code that uses IPs only to open connections. There's lots of application code that does more things with IPs, such as parsing, displaying, validating etc. All of this code would still need to be rewritten to accept IPv6 addresses (and its much more complex string representations), that part is inevitable.
- afiori 2y ago
  I wonder if something like HTTP connection upgrade would have been possible with ipv6-ipv4, maybe something like imagine Machine 1 with ips 1.1.1.1 and 11::11 and machine 2 with ips 2.2.2.2 and 22::22. When machine 2 receives a packet from 1.1.1.1 at 2.2.2.2 it sends a ipv6 ping-like packet to the ipv4-mapped address ::ffff:1.1.1.1 saying something like "hey you can also contact me at 22::22 and if machine 1 undertands then it can try to use the new address for the following packets. I can see how it would be hard to secure this operation.
cowsandmilk 2y ago
For those building on AWS with VPC per service and using PrivateLink for connections between services, the whole IP conflict problem just evaporates. Admittedly, you’re paying some premiums to Amazon for that convenience.
einpoklum 2y ago
> It removes tons of overhead and cruft Can you elaborate? Here, or with links? What kinds of overhead and cruft?
- kstrauser 2y ago
  * The header is a fixed length. * You can't fragment packets. * The redundant checksum header was removed. * No more private addressing (unless you're a glutton for punishment). * No more NAT (see above). * Simpler routing. * Doesn't require DHCP. It benefits hugely from the lessons learned with IPv4.
  - tsimionescu 2y ago
    IPv6 packets can still be fragmented, but only at the source. IPv4 fragmentation has only worked this way in practice for a long time. Private addressing is still needed with IPv6, it's a crucial part of how address allocation works, and it's the only way to reliably connect to a client-like IPv6 device on the local network, since its public IP address will change all the time for privacy reasons, assuming it respects best practices. Routing is only simpler if the ISPs actually hand out the large prefixes they are supposed to. Not all of them do. DHCP is still required for many use cases. So now you have two solutions for handing out addresses, and you need to figure out when to use SLAAC and when to use DHCP. This is strictly more complex than IPv4, not simpler. SLAAC is mostly just unnecessary cruft, a cute little simple path for limited use cases, but it can never replace DHCPv6 for all use cases (e.g. for subnets smaller than a /64, for communicating additional information like a local DNS server or NTP server, for complex network topologies, for server machines etc).
  - cyberax 2y ago
    > * No more private addressing (unless you're a glutton for punishment). OK. So what happens if your ISP connection goes down? Your router will detect this and withdraw the ISP's prefix. So now you can't print because your printer doesn't have an address. Good luck. > * Doesn't require DHCP. This turns out to be a problem, as you can't easily see what's going on in the network.
  - 2y ago
yyyk 2y ago
>That, and basically guaranteeing you don't have to deal with the company you just acquired having deployed their accounts with the same 10/16 subnet your own company uses. I always found that to be a desperate talking point. 'Prepare your network for the incredibly rare event where you intend to integrate directly' (didn't anyone hear of network segmentation?). It makes a lot more sense to worry about the ISP unilaterally changing your prefix - something that can only happen in IPv6.
- bigstrat2003 2y ago
  > It makes a lot more sense to worry about the ISP unilaterally changing your prefix - something that can only happen in IPv6. ISPs unilaterally change your DHCP address on IPv4 all the time. And in any situation where you would have a static address for IPv4, your ISP should have no problem giving you a static v6 prefix. This argument makes no sense at all.
  - shawabawa3 2y ago
    Your ISP provided ipv4 has no relation to your internal private network space My understanding is that for some bizarre reason this is not usually the case with IPv6

cogman10 2y ago

The problem I keep running into is that IPv6 support in common infrastructure is somewhat lacking. It's always a headache to learn that some container orchestration system doesn't support IPv6. Or an http client. Or a DNS resolver. Or whatever. Not to mention the supreme annoyance I have that, to this day, my ISP still does not have IPv6 addressing available.

frollogaston 2y ago
Yep, it's tragic because it all stems from unforced differences vs ipv4. The design was reasonable, but with perfect hindsight, it needed to be different. They needed to keep the existing /32s and just make the address field bigger, despite the disadvantages. "Everywhere but nowhere" is sorta how I'd describe ipv6. Most hardware and lower-level software supports it, so obviously it wasn't impossible to support a new protocol, but it's not being used.
- JoshTriplett 2y ago
  > Yep, it's tragic because it all stems from unforced differences vs ipv4. The design was reasonable, but with perfect hindsight, it needed to be different. They needed to keep the existing /32s and just make the address field bigger, despite the disadvantages. Exactly. I would love to have seen the world in which that happened, and where all the other parts of IPv6 were independently proposed (and likely many of them rejected as unwanted).
  - frollogaston 2y ago
    The main problem wasn't all the smaller features but one big one in particular that can't be split into smaller pieces, the new addressing scheme. They wanted to replace all the existing addresses, which meant replacing all the routes. Besides the difficulty of that by itself, it automatically meant that the v6 versions of DNS, DHCP, NAT, etc wouldn't support v4, rather it'd be a totally separate stack. There were also some small things. And routers often having bad defaults for v6, which btw, would not even be a concern if they left the big thing alone.
    - JoshTriplett 2y ago
      > Besides the difficulty of that by itself, it automatically meant that the v6 versions of DNS, DHCP, NAT, etc wouldn't support v4, rather it'd be a totally separate stack. Sure, "make the addresses bigger" would have required providing DHCPv6, DNS AAAA records, and various other protocol updates for protocols that embedded IP addresses. And making changes to the protocol header at the same time (e.g. removing the redundant checksum) were also a good idea. It didn't require pushing SLAAC instead of DHCP. It didn't require recommending (though fortunately not requiring) IPsec for all IPv6 stacks. It didn't require changing the address syntax to use colons, causing pain for all protocols that used `IP:port` or similar. It didn't require mandating link-local addresses for every interface. It didn't require adding a mandatory address-collision-detection mechanism. And I'm sure I'm forgetting a few.
      - frollogaston 2y ago
        Yeah. I didn't like any of those proposed changes, especially the colons. You also didn't mention how NAT6 isn't a thing by default.
      - cyberax 2y ago
        It didn't require removing ARP and inventing Neighbor Discovery that embeds the hardware addresses into the IP address. It didn't require the Ruby Goldberg "on link" network mechanism. It didn't require multicast instead of broadcasts for local network discovery. It didn't require using DNS config (of all things) to specify V4/V6 priority. It didn't require adding a "flow label" that is nobody to this day knows how to use properly. The list of fails is ridiculous.
- kstrauser 2y ago
  "It's not being used", except for nearly half of Google's traffic: https://www.google.com/intl/en/ipv6/statistics.html https://www.google.com/intl/en/ipv6/statistics.html Disconnect your phone from Wi-Fi and visit https://ifconfig.co/ https://ifconfig.co/ . If you're a Verizon customer, it's probably going to show you an IPv6 address. It's huge, right now, today.
  - frollogaston 2y ago
    "Depended on" is what I should have said. An ISP or website can be v4-only or support both, but it's not going to be v6-only.
    - adgjlsfhk1 2y ago
      this isn't true. I know because at some point XFinity started dropping ipv6 connections for me and I noticed because a number of sites (forget which) were broken
      - frollogaston 2y ago
        What do you mean by dropping ipv6 connections, like dropping ipv6 packets? That's only an issue if you're using v6. I disabled ipv6 on my router years ago and have never had a problem just using v4.
    - kstrauser 2y ago
      Fair. I bet that'll change soon though. My prediction is that it'll be a mobile-first game, like the next Pokemon Go sort of thing, that'll be IPv6-only.
      - frollogaston 2y ago
        I agree it would probably be something mobile-first that does it, since those carriers all(?) support v6.
      - gruez 2y ago
- p_l 2y ago
  And it would have failed for exactly the same reasons, because just changing the address field size is enough to have everyone who uses BSD Sockets to rewrite all parts of code that create sockets. Especially since getaddrinfo was ported over from more streams/OSI oriented stacks pretty late, precisely because BSD Sockets required separate path for every protocol. On hw side, by mid-1990s even changing one routing-important field would mean possibly a new generation of ASICs needed with more capabilities. Essentially, once you agree to break one field, the costs are so big why not try fixing other parts? Especially given that IETF has rejected an already implemented solution of just going with OSI for layer 3.
  - frollogaston 2y ago
    All that code using BSD sockets is rewritten by now to support v6, right? If so, that can't be the reason, cause v4 is still dominant. And btw, what I suggested would actually work without userspace code changes until you want to start subdividing the /32s. Cause v4 addresses would've still been valid in v6.
    - kstrauser 2y ago
      Where would you store the other 96 bits. In the body?
      - frollogaston 2y ago
        Ipv6 packet format was needed either way, but only with the 32-bit address space at first (the other 92 bits set to 0). You simply tell your system to start using v6 instead, and everything else stays the same. No dual-stack. Next step would be upgrading all those parts like DNS, DHCP, etc to accept the 128-bit addrs, which again can be done in isolation. Then finally, ISPs or home routers can start handing out longer addresses like 1.1.1.1.2.
        Dylan16807 2y ago
        There are two ways for me to interpret "simply tell your system to start using v6". If it means upgrading every program, then your plan works but it's the same as how things work today. You're telling people to do a thing, and they aren't bothering. The "simple" step isn't simple at all. If it doesn't mean upgrading every program, then your rollout fails on the last step. You start handing out longer addresses and legacy programs can't access them.
p_l 2y ago
Major reason for that is BSD Sockets and their leaky abstraction that results in hardcoding protocol details in application code. For a good decade a lot of software had to be slowly patched in every place that made a socket to add v6 support, and sometimes multiple times because getaddrinfo didn't reach everyone early enough.
- throwaway2037 2y ago
  > results in hardcoding protocol details in application code Are you suggesting that this could have been implemented a different way? Example: IP could be negotiated to upgrade from v4 to v6? I am curious about your ideas.
  - hamandcheese 2y ago
    There isn't much need for many applications to know or care what IP protocol they are speaking, they are all just writing bytes to a TCP stream. I think the parent is saying that existing socket abstractions meant that these applications still had to be "upgraded" to support IPv6 whereas it could/should have been handled entirely by the OS with better socket APIs.
  - tsimionescu 2y ago
    I think in principle, an application didn't need to know the exact format of an IP address, even if connecting directly to an IP. A simple idea that could have made application code much more IP-agnostic would have been for SOCK_ADDR_IN to take the IP in string format, not as a four-byte value. That way, lots of application code would not need to even be recompiled to move from a 4 byte IPv4 address to a 16 byte IPv6 address, whereas today they not only need to be recompiled, they need to be changed at the source level to use a new type that allows for both. Of course, code that operates on packets, in the TCP/IP stack of the OS would have still needed to be rewritten. But that is far less code than "every application that opens a socket". Of course, this only applies to code that uses IPs only to open connections. There's lots of application code that does more things with IPs, such as parsing, displaying, validating etc. All of this code would still need to be rewritten to accept IPv6 addresses (and its much more complex string representations), that part is inevitable.
afiori 2y ago
I wonder if something like HTTP connection upgrade would have been possible with ipv6-ipv4, maybe something like imagine Machine 1 with ips 1.1.1.1 and 11::11 and machine 2 with ips 2.2.2.2 and 22::22. When machine 2 receives a packet from 1.1.1.1 at 2.2.2.2 it sends a ipv6 ping-like packet to the ipv4-mapped address ::ffff:1.1.1.1 saying something like "hey you can also contact me at 22::22 and if machine 1 undertands then it can try to use the new address for the following packets. I can see how it would be hard to secure this operation.

cowsandmilk 2y ago

For those building on AWS with VPC per service and using PrivateLink for connections between services, the whole IP conflict problem just evaporates. Admittedly, you’re paying some premiums to Amazon for that convenience.

einpoklum 2y ago

> It removes tons of overhead and cruft Can you elaborate? Here, or with links? What kinds of overhead and cruft?

kstrauser 2y ago
* The header is a fixed length. * You can't fragment packets. * The redundant checksum header was removed. * No more private addressing (unless you're a glutton for punishment). * No more NAT (see above). * Simpler routing. * Doesn't require DHCP. It benefits hugely from the lessons learned with IPv4.
- tsimionescu 2y ago
  IPv6 packets can still be fragmented, but only at the source. IPv4 fragmentation has only worked this way in practice for a long time. Private addressing is still needed with IPv6, it's a crucial part of how address allocation works, and it's the only way to reliably connect to a client-like IPv6 device on the local network, since its public IP address will change all the time for privacy reasons, assuming it respects best practices. Routing is only simpler if the ISPs actually hand out the large prefixes they are supposed to. Not all of them do. DHCP is still required for many use cases. So now you have two solutions for handing out addresses, and you need to figure out when to use SLAAC and when to use DHCP. This is strictly more complex than IPv4, not simpler. SLAAC is mostly just unnecessary cruft, a cute little simple path for limited use cases, but it can never replace DHCPv6 for all use cases (e.g. for subnets smaller than a /64, for communicating additional information like a local DNS server or NTP server, for complex network topologies, for server machines etc).
- cyberax 2y ago
  > * No more private addressing (unless you're a glutton for punishment). OK. So what happens if your ISP connection goes down? Your router will detect this and withdraw the ISP's prefix. So now you can't print because your printer doesn't have an address. Good luck. > * Doesn't require DHCP. This turns out to be a problem, as you can't easily see what's going on in the network.
- 2y ago

yyyk 2y ago

>That, and basically guaranteeing you don't have to deal with the company you just acquired having deployed their accounts with the same 10/16 subnet your own company uses. I always found that to be a desperate talking point. 'Prepare your network for the incredibly rare event where you intend to integrate directly' (didn't anyone hear of network segmentation?). It makes a lot more sense to worry about the ISP unilaterally changing your prefix - something that can only happen in IPv6.

bigstrat2003 2y ago
> It makes a lot more sense to worry about the ISP unilaterally changing your prefix - something that can only happen in IPv6. ISPs unilaterally change your DHCP address on IPv4 all the time. And in any situation where you would have a static address for IPv4, your ISP should have no problem giving you a static v6 prefix. This argument makes no sense at all.
- shawabawa3 2y ago
  Your ISP provided ipv4 has no relation to your internal private network space My understanding is that for some bizarre reason this is not usually the case with IPv6