5 ms·

Things also could have been a lot different if IPv6 was just IPv4 with 128 bit addresses.

by oh_sigh 3y ago

ikiris 3y ago
It basically is.
- alfons_foobar 3y ago
  No.
  - ikiris 3y ago
    Yes...
amoss 3y ago
People hate kludges and backward compatibility, but IPv4.1 with 5-byte addresses would have been the dominant standard by now.
- XorNot 3y ago
  No, it wouldn't have been. Where are you going to put that extra byte? How is an intermediate box going to know what to do with it? How is a routing ASIC going to handle it? This is thinking which appeals to people who don't understand the problem because it feels like a compromise, but you can't negotiate with silicon. If it expects a 4 byte address payload, then that's all it will ever handle. Adding more bytes is exactly the same amount of redesign and replacement work as adding more. If the problem was solely software related, it would've been done by now.
  - amoss 3y ago
    Nah, hardware people just don't negotiate hard enough. Add a one-byte option into the header, give it an unassigned value (e.g. 6) and assume that any box that does not understand it will pass it through unchanged. Use it as the most significant byte of the address, and obsolete all routing equipment that doesn't understand it from the backbone so that they can be used to handle routing in one of the new 32-bit super-A class networks. Sure it's ugly as hell, but it is just backward compatible enough to work.
    - XorNot 3y ago
      "just upgrade every backbone router to handle it" - you've just recreated the same problem. Routers don't run packet addresses through software, they run then through silicon ASICs which know the address is 32 bits, that's it. Your solution is literally how Cisco implemented IPv6 on a bunch of it's switches: the IPv6 routing path goes through the firmware and is slow as hell compared to the pure ASIC IPv4 handling. It didn't catch on because it was terrible at any scale (we were building Hadoop clusters, 100+ big data nodes with constrained throughout is money down the drain).
      - amoss 3y ago
        So how many backbone routers are 20 years old? Your claim was that any change to the ASIC was the same design cost. But really? A 40-bit routing table design, where there is a 32-bit fall-back to preserve the top 8-bits vs a 128-bit routing table design. Why would these be the same cost?
        XorNot 3y ago
        How much cost in labor, disruption and time do you think upgrading every backbone router would be? When would you have done it? When the hardware was 5 years old? 10 years old? I've been on change operations where the hardware was over a decade old and our biggest concern was making sure we had replacement PSUs on hand since the thermal shock of a reboot might take them out. This is the problem, you have absolutely no idea what anything costs or how it works - you're simply thinking "lifting those bits sounds heavy, what if we made them lighter?" as though a committee of engineers, designers and industry didn't spend a lot of time considering exactly that problem. If you could add 1 byte in software and be done with it, it would have already happened.
        amoss 3y ago
        Upgrading hardware is an ongoing process. You are proposing a single point of change without any reason for it to be handled that way. You are arguing that all change has the same cost. I don't see your reasoning for this. A smaller change to a system has a lower cost in R&D, and a lower cost in manufacture. Although it is probably true that the cost of updating all equipment dominates the cost of redesign, this is only an issue for a big bang update rather than a rolling upgrade.
- ikiris 3y ago
  If there existed a magic wand to make longer addresses work with existing stuff sure, but since there didn't, you have all the exact same problems as ipv6 which is already basically the same thing as ipv4 anyway with 128 bit addressing, and some minor tweaks to how the "arp" works. If you can articulate how this magic wand would work in practice we're all ears since you solved a worldwide problem, but I'm betting my salary that you can't.
jandrese 3y ago
I see this sentiment from time to time, but it doesn't make sense to me. Any way you do it you need to deploy new hardware, new firewall rules, new end user applications, etc... What parts of IPv6 are harder now than they would be with just a fat IPv4? Is it really so complicated now that you can't fragment packets on path? Is Neighbor Discovery Protocol really so much more difficult to understand than Address Resolution Protocol? Do you yearn for DHCP and NAT?
- kortilla 3y ago
  Administrators memorized IPs a lot. This is hard to under estimate and is frequently the disconnect I see when a SWE doesn’t understand why people could possibly complain about ipv6. This is likely the #1 issue I hear from people in the field. #2, for better or worse, NAT became peoples’ comfort blanket. It’s a boneheaded stateful firewall regardless of how long people can scream “NAT isn’t security”. By forcing people to take both changes at the same time, adoption was setup for failure. So many places in the US turned it off “because nothing I use is v6 only” and they weren’t quite sure if they were exposing their end hosts accidentally. #3, link local addresses, guids, etc all assigned at the same time is a steep learning curve. Which will be used for which flows in the network? If my ISP changes my prefixes, do I know have to reconfigure all of my local network firewalls? #4, prefix delegation, should each client behind my router get its own /64? My ISP only gives me 128 of them to hand out which is a problem for IOT. Guidance here is weak. Burning all of the early adopters with the slaac vs dhcpv6 vs privacy extensions didn’t help either. Nobody gives a shit about fragmentation. The upgrade UX was a disaster.
  - iainmerrick 3y ago
    Administrators memorized IPs a lot. Right - I’m not a network admin, but back a few decades when I was hanging around the CS lab and setting up home networks, I sure had to type in IP addresses by hand a lot. If they were more than four bytes long that would have been painful!
  - jandrese 3y ago
    #1 seems pretty unavoidable. Yes, bigger numbers are harder to remember, but we're in this mess in the first place because we made the numbers too small. It's kind of like complaining that phone numbers are too hard to memorize after we switched to 10 digit dialing. That may be true, but since we all have address books built into the phones now it's really not an issue. #2 is people being nervous, but seriously the "DENY incoming on $WANIF if not in state table" rule is all you need. This always struck me as "I refuse to learn anything new, no matter how little I need to learn". #3 Again, people worried about the firewalls when they really don't need to be. #4 A /64 is a subnet. Normally all of your devices would be on the same subnet, although with IPv6 you get a whole bunch which is nice. You can put the IoT devices on a different subnet that is partitioned from the rest of your network because they are IoT devices which means they are adorable little security vulnerabilities. I think your last point is a good one. DHCP6 was poorly named. People thought it would work like DHCP did in IPv4 but it's really not intended for that. It's really only meant for routers, not for end hosts. You missed a couple of points where I think IPv6 did have some flaws. SLAAC originally lacked a lot of the extensions that DHCP offered, like DNS server advertisement. In theory you could anycast your DNS queries, but DNS is a dodgy enough protocol already and this was really not a great idea. It's one of those things that works great in the lab, but is kind of a nightmare in the real world. It also offers no way to communicate back to a DNS server what IP address you have chosen, so if two hosts want to communicate with each other, especially if they are not in the same subnet, it becomes difficult to determine what their partner's address is. All in all the IPv6 committee considered DNS to be an application protocol and outside of their scope, but application developers consider it part of the network and so it got left out in the cold. Using the MAC address to create the IPv6 address was also a bad idea from a big data standpoint. Luckily that was one of many options so it was easy to switch without breaking anything.

Things also could have been a lot different if IPv6 was just IPv4 with 128 bit addresses.

ikiris 3y ago

It basically is.

alfons_foobar 3y ago
No.
- ikiris 3y ago
  Yes...

amoss 3y ago

People hate kludges and backward compatibility, but IPv4.1 with 5-byte addresses would have been the dominant standard by now.

XorNot 3y ago
No, it wouldn't have been. Where are you going to put that extra byte? How is an intermediate box going to know what to do with it? How is a routing ASIC going to handle it? This is thinking which appeals to people who don't understand the problem because it feels like a compromise, but you can't negotiate with silicon. If it expects a 4 byte address payload, then that's all it will ever handle. Adding more bytes is exactly the same amount of redesign and replacement work as adding more. If the problem was solely software related, it would've been done by now.
- amoss 3y ago
  Nah, hardware people just don't negotiate hard enough. Add a one-byte option into the header, give it an unassigned value (e.g. 6) and assume that any box that does not understand it will pass it through unchanged. Use it as the most significant byte of the address, and obsolete all routing equipment that doesn't understand it from the backbone so that they can be used to handle routing in one of the new 32-bit super-A class networks. Sure it's ugly as hell, but it is just backward compatible enough to work.
  - XorNot 3y ago
    "just upgrade every backbone router to handle it" - you've just recreated the same problem. Routers don't run packet addresses through software, they run then through silicon ASICs which know the address is 32 bits, that's it. Your solution is literally how Cisco implemented IPv6 on a bunch of it's switches: the IPv6 routing path goes through the firmware and is slow as hell compared to the pure ASIC IPv4 handling. It didn't catch on because it was terrible at any scale (we were building Hadoop clusters, 100+ big data nodes with constrained throughout is money down the drain).
    - amoss 3y ago
      So how many backbone routers are 20 years old? Your claim was that any change to the ASIC was the same design cost. But really? A 40-bit routing table design, where there is a 32-bit fall-back to preserve the top 8-bits vs a 128-bit routing table design. Why would these be the same cost?
      - XorNot 3y ago
        How much cost in labor, disruption and time do you think upgrading every backbone router would be? When would you have done it? When the hardware was 5 years old? 10 years old? I've been on change operations where the hardware was over a decade old and our biggest concern was making sure we had replacement PSUs on hand since the thermal shock of a reboot might take them out. This is the problem, you have absolutely no idea what anything costs or how it works - you're simply thinking "lifting those bits sounds heavy, what if we made them lighter?" as though a committee of engineers, designers and industry didn't spend a lot of time considering exactly that problem. If you could add 1 byte in software and be done with it, it would have already happened.
        amoss 3y ago
        Upgrading hardware is an ongoing process. You are proposing a single point of change without any reason for it to be handled that way. You are arguing that all change has the same cost. I don't see your reasoning for this. A smaller change to a system has a lower cost in R&D, and a lower cost in manufacture. Although it is probably true that the cost of updating all equipment dominates the cost of redesign, this is only an issue for a big bang update rather than a rolling upgrade.
ikiris 3y ago
If there existed a magic wand to make longer addresses work with existing stuff sure, but since there didn't, you have all the exact same problems as ipv6 which is already basically the same thing as ipv4 anyway with 128 bit addressing, and some minor tweaks to how the "arp" works. If you can articulate how this magic wand would work in practice we're all ears since you solved a worldwide problem, but I'm betting my salary that you can't.

jandrese 3y ago

I see this sentiment from time to time, but it doesn't make sense to me. Any way you do it you need to deploy new hardware, new firewall rules, new end user applications, etc... What parts of IPv6 are harder now than they would be with just a fat IPv4? Is it really so complicated now that you can't fragment packets on path? Is Neighbor Discovery Protocol really so much more difficult to understand than Address Resolution Protocol? Do you yearn for DHCP and NAT?

kortilla 3y ago
Administrators memorized IPs a lot. This is hard to under estimate and is frequently the disconnect I see when a SWE doesn’t understand why people could possibly complain about ipv6. This is likely the #1 issue I hear from people in the field. #2, for better or worse, NAT became peoples’ comfort blanket. It’s a boneheaded stateful firewall regardless of how long people can scream “NAT isn’t security”. By forcing people to take both changes at the same time, adoption was setup for failure. So many places in the US turned it off “because nothing I use is v6 only” and they weren’t quite sure if they were exposing their end hosts accidentally. #3, link local addresses, guids, etc all assigned at the same time is a steep learning curve. Which will be used for which flows in the network? If my ISP changes my prefixes, do I know have to reconfigure all of my local network firewalls? #4, prefix delegation, should each client behind my router get its own /64? My ISP only gives me 128 of them to hand out which is a problem for IOT. Guidance here is weak. Burning all of the early adopters with the slaac vs dhcpv6 vs privacy extensions didn’t help either. Nobody gives a shit about fragmentation. The upgrade UX was a disaster.
- iainmerrick 3y ago
  Administrators memorized IPs a lot. Right - I’m not a network admin, but back a few decades when I was hanging around the CS lab and setting up home networks, I sure had to type in IP addresses by hand a lot. If they were more than four bytes long that would have been painful!
- jandrese 3y ago
  #1 seems pretty unavoidable. Yes, bigger numbers are harder to remember, but we're in this mess in the first place because we made the numbers too small. It's kind of like complaining that phone numbers are too hard to memorize after we switched to 10 digit dialing. That may be true, but since we all have address books built into the phones now it's really not an issue. #2 is people being nervous, but seriously the "DENY incoming on $WANIF if not in state table" rule is all you need. This always struck me as "I refuse to learn anything new, no matter how little I need to learn". #3 Again, people worried about the firewalls when they really don't need to be. #4 A /64 is a subnet. Normally all of your devices would be on the same subnet, although with IPv6 you get a whole bunch which is nice. You can put the IoT devices on a different subnet that is partitioned from the rest of your network because they are IoT devices which means they are adorable little security vulnerabilities. I think your last point is a good one. DHCP6 was poorly named. People thought it would work like DHCP did in IPv4 but it's really not intended for that. It's really only meant for routers, not for end hosts. You missed a couple of points where I think IPv6 did have some flaws. SLAAC originally lacked a lot of the extensions that DHCP offered, like DNS server advertisement. In theory you could anycast your DNS queries, but DNS is a dodgy enough protocol already and this was really not a great idea. It's one of those things that works great in the lab, but is kind of a nightmare in the real world. It also offers no way to communicate back to a DNS server what IP address you have chosen, so if two hosts want to communicate with each other, especially if they are not in the same subnet, it becomes difficult to determine what their partner's address is. All in all the IPv6 committee considered DNS to be an application protocol and outside of their scope, but application developers consider it part of the network and so it got left out in the cold. Using the MAC address to create the IPv6 address was also a bad idea from a big data standpoint. Luckily that was one of many options so it was easy to switch without breaking anything.