IPv6 has a huge amount of bloat created by guys in cargo shorts and pony tails being flown out to exotic locales 3x a year for IETF conferences to argue about minutia and try to get their name on some IPv6 spec document. All they needed to do was add a couple more dots onto IPv4 and maybe switch to hex.
> All they needed to do was add a couple more dots onto IPv4 and maybe switch to hex.
There is no 'just' extending the address length:
So it's a matter of mathematical and physical fact that to expand
the address size, you must change the protocol, and that means
[three] things immediately:
You have to change the version number.
You have to add new code to handle the new version.
[…]
You need a coexistence technique so that updated systems,
with the new protocol, can connect to old systems that know
nothing of the new protocol.
Two minutes of thought show that this third requirement has only
two solutions:
(3A) Dual stack, in which the new machines speak both
the old (IPv4) and new (IPng) protocol.
(3B) Translation, in which something translates addresses
between the old and new protocols.
You also have to update DNS to create new resource record types ("A" is hard-coded to 32-bits) to support the new longer addresses, and have all user-land code start asking for, using, and understanding the new record replies. Just like with IPv6. (A lot of legacy code did not have room in data structures for multiple reply types: sure you'd get the "A" but unless you updated the code to get the "A+" address (for "IPv4+" addresses) you could never get to the longer with address… just like IPv6 needed code updates to recognize AAAA, otherwise you were A-only.)
In any 'address extension' plan the legacy code cannot use the new address space; you have to:
* update the IP stack (like with IPv6)
* tell applications about new DNS records (like IPv6)
* set up translation layers for legacy-only code that cannot be update to reach extended-address-only destination (like IPv6 with DNS64/NAT64, CLAT, etc)
Wasn't it from academics in their ivory towers? That's kind of the opposite of flying out to exotic locales.
Of course, back here in the real world you can look at the RFCs yourself and see that they're credited to places like Ipsilon Networks, Xerox and Sun Microsystems. Boring corporate network companies.
No literally, the IETF meets 3x a year in a different location each time and all the guys from with cargo shorts from the companies you named argue about IPv6 minutia all day and spend their per diem by night. It's actually a lot of fun.
IPv6 invalidated the existing IPv4 addresses, changed the addressing scheme, and de facto got rid of DHCP and NAT in favor of SLAAC and global routing. It doesn't share any state with v4. This was a very different set of choices from just adding more bits to v4.
Nah, the details in the spec all have good reasons, but it's based on the original mistake of making it an entirely separate network from v4 with new address blocks.
> […] but it's based on the original mistake of making it an entirely separate network from v4 with new address blocks.
This was not a "mistake":
So it's a matter of mathematical and physical fact that to expand
the address size, you must change the protocol, and that means
[three] things immediately:
You have to change the version number.
You have to add new code to handle the new version.
[…]
You need a coexistence technique so that updated systems,
with the new protocol, can connect to old systems that know
nothing of the new protocol.
Two minutes of thought show that this third requirement has only
two solutions:
(3A) Dual stack, in which the new machines speak both
the old (IPv4) and new (IPng) protocol.
(3B) Translation, in which something translates addresses
between the old and new protocols.
IPv4 is inherently more user-friendly. IPv6 was designed for a world, in the 1990s, where it was expected that every host wanted to be routable. SLAAC etc were all natural consequences of that. For today's use cases, the v4 NAT public/private thing actually turned out to be nicer than v6 global routing. There's still confusion today about whether devices are exposed on a v6 network because the spec itself says default-deny firewall is optional. They had to recently add privacy addresses. The other kinds of v6 addrs like link-local and ULA add more complexity. V4 addresses are easy to remember, which v6 advocates keep saying doesn't matter but it does. There are all these little network management details that are messier in v6, as you will find on online help forums for v6 advocates who you cannot write off as just being too used to v4.
The v6 spec also has all these alternative ways to use it more like v4, commonly brought up as a cop-out against the above criticisms, but that's actually part of the problem. The spec is too big, and things only implement a subset of it, see Android not supporting DHCP6. Realistically you'll have 99% of people using anything like this the default way, and the spec does define SLAAC, no-NAT, etc as default.
But you could say v6 is better just cause it has more addresses, and that's fair.
...Imperial is better than metric because it lines up with everyday usage better unless you're specifically concerned about the physical properties of water. Especially ˚F vs ˚C. Not a big deal though.
0-100˚F lines up well with weather ranges, and 1˚F is about the smallest diff someone can feel. Many digital thermostats use integer ˚F and introduce 0.5 steps if you switch to ˚C, even in countries where ˚C is default, so they kinda admit it.
Pounds vs kg, similar story as F vs C. Pound is pretty much the human-discernible granularity. Otherwise doesn't matter.
0-100 MPH lines up well with car speeds, which is usually the thing you're measuring with that. KPH is excessively granular for that. Probably not by design, but yeah.
The feet/inches vs meters/cm thing matters less. It's base-12 vs base-10. You can do decimal feet or fractional meters of course, but it's less common, so apparently both ways are fine.
I'm not the person you were replying to, but I can answer this one. And yeah, I can see all the metric fanboys (a very small subset of metric users, mind you) hovering over that downvote button, but I don't get paid in Internet points so here goes:
The nice thing about imperial (as well as the customary system used in the US) is that it's based on measurements that people have found useful over thousands of years. They're human units, adapted to what people need to do with them, not the other way around.
It's difficult to explain to metric folks because it's really something you have to experience. But here's an example:
Reservoir volume in the US is measured in acre-inches. An acre is a unit of area used for measuring property, usually farmland. It's a bit less than half of a hectare. And of course an inch is 2.4cm. Acre-inches sounds totally bizarre when you first hear about it. But for the people that need to work with this value, it's an extremely useful way to measure reservoirs and gives you an intuition that you just don't get from cubic meters.
It's true that you can't just convert that to other units of volume without doing some math or looking up the conversion rate, but that rarely matters. If you're trying to figure out how fast the lake will rise or fall with a given inflow and outflow, you're going to have to have some way to account for the fact that the lake is a) an irregular shape and b) takes up more area the higher the water gets. You already need to know the area of the lake at any particular height to work out the evaporation rate anyway, so that's a number you're going to have. The units are designed to make that calculation easier, which was really important back in the days when slide rules were the state of the art.
All the customary units are like this in one way or another. They're units designed for a particular domain, and when used in their domain they work very well and calculations can be done in your head. They use fractions because that's what people have historically used (seriously - my grandfather could work fractions in his head faster than I could type them into a calculator, and he made asphalt for a living. Imagine what a carpenter could do.).
Think about it. Imagine you were never taught a measurement system. You find yourself needing to come up with a unit to make measurements for wooden planks you're going to use to build a house. Would you choose a unit as long as a meter? Or one as short as a centimeter or even a decimeter?
Bonus challenge to the fine folks clicking that downvote button: give me a real practical reason to prefer Celsius to Fahrenheit, besides the fact that Celsius is part of the metric system. No, the freezing and boiling points of water don't cut it - I work with hydrocarbon fuels, I salt my driveway and patio, I don't live at sea level, and quite honestly every American 8-year-old can spout off 32° and 212°. There's a Fahrenheit equivalent to Kelvin (Rankine) so the Kelvin to Celsius equivalence doesn't count either. My claim is that both scales are completely arbitrary, and only advantage one has over the other is that you're used to one of them. Go ahead, prove me wrong!
They don't need to be really long. Adding one more octet to v4 makes it 1 trillion addresses. Sure the header should support longer than that, but it doesn't mean everyone needs to use all of it.
IPv6 has a huge amount of bloat created by guys in cargo shorts and pony tails being flown out to exotic locales 3x a year for IETF conferences to argue about minutia and try to get their name on some IPv6 spec document. All they needed to do was add a couple more dots onto IPv4 and maybe switch to hex.
> All they needed to do was add a couple more dots onto IPv4 and maybe switch to hex.
There is no 'just' extending the address length:
* https://github.com/becarpenter/misc/blob/main/why6why.md
* https://datatracker.ietf.org/doc/html/rfc1671
You also have to update DNS to create new resource record types ("A" is hard-coded to 32-bits) to support the new longer addresses, and have all user-land code start asking for, using, and understanding the new record replies. Just like with IPv6. (A lot of legacy code did not have room in data structures for multiple reply types: sure you'd get the "A" but unless you updated the code to get the "A+" address (for "IPv4+" addresses) you could never get to the longer with address… just like IPv6 needed code updates to recognize AAAA, otherwise you were A-only.)
In any 'address extension' plan the legacy code cannot use the new address space; you have to:
* update the IP stack (like with IPv6)
* tell applications about new DNS records (like IPv6)
* set up translation layers for legacy-only code that cannot be update to reach extended-address-only destination (like IPv6 with DNS64/NAT64, CLAT, etc)
Wasn't it from academics in their ivory towers? That's kind of the opposite of flying out to exotic locales.
Of course, back here in the real world you can look at the RFCs yourself and see that they're credited to places like Ipsilon Networks, Xerox and Sun Microsystems. Boring corporate network companies.
No literally, the IETF meets 3x a year in a different location each time and all the guys from with cargo shorts from the companies you named argue about IPv6 minutia all day and spend their per diem by night. It's actually a lot of fun.
2 replies →
That's what they did and you're here complaining about it
IPv6 invalidated the existing IPv4 addresses, changed the addressing scheme, and de facto got rid of DHCP and NAT in favor of SLAAC and global routing. It doesn't share any state with v4. This was a very different set of choices from just adding more bits to v4.
Nah, the details in the spec all have good reasons, but it's based on the original mistake of making it an entirely separate network from v4 with new address blocks.
> […] but it's based on the original mistake of making it an entirely separate network from v4 with new address blocks.
This was not a "mistake":
* https://github.com/becarpenter/misc/blob/main/why6why.md
* https://datatracker.ietf.org/doc/html/rfc1671
4 replies →
IPv4 is inherently more user-friendly. IPv6 was designed for a world, in the 1990s, where it was expected that every host wanted to be routable. SLAAC etc were all natural consequences of that. For today's use cases, the v4 NAT public/private thing actually turned out to be nicer than v6 global routing. There's still confusion today about whether devices are exposed on a v6 network because the spec itself says default-deny firewall is optional. They had to recently add privacy addresses. The other kinds of v6 addrs like link-local and ULA add more complexity. V4 addresses are easy to remember, which v6 advocates keep saying doesn't matter but it does. There are all these little network management details that are messier in v6, as you will find on online help forums for v6 advocates who you cannot write off as just being too used to v4.
The v6 spec also has all these alternative ways to use it more like v4, commonly brought up as a cop-out against the above criticisms, but that's actually part of the problem. The spec is too big, and things only implement a subset of it, see Android not supporting DHCP6. Realistically you'll have 99% of people using anything like this the default way, and the spec does define SLAAC, no-NAT, etc as default.
But you could say v6 is better just cause it has more addresses, and that's fair.
...Imperial is better than metric because it lines up with everyday usage better unless you're specifically concerned about the physical properties of water. Especially ˚F vs ˚C. Not a big deal though.
Can you give some examples of where Imperial works better from first principles and why you think so?
0-100˚F lines up well with weather ranges, and 1˚F is about the smallest diff someone can feel. Many digital thermostats use integer ˚F and introduce 0.5 steps if you switch to ˚C, even in countries where ˚C is default, so they kinda admit it.
Pounds vs kg, similar story as F vs C. Pound is pretty much the human-discernible granularity. Otherwise doesn't matter.
0-100 MPH lines up well with car speeds, which is usually the thing you're measuring with that. KPH is excessively granular for that. Probably not by design, but yeah.
The feet/inches vs meters/cm thing matters less. It's base-12 vs base-10. You can do decimal feet or fractional meters of course, but it's less common, so apparently both ways are fine.
3 replies →
I'm not the person you were replying to, but I can answer this one. And yeah, I can see all the metric fanboys (a very small subset of metric users, mind you) hovering over that downvote button, but I don't get paid in Internet points so here goes:
The nice thing about imperial (as well as the customary system used in the US) is that it's based on measurements that people have found useful over thousands of years. They're human units, adapted to what people need to do with them, not the other way around.
It's difficult to explain to metric folks because it's really something you have to experience. But here's an example:
Reservoir volume in the US is measured in acre-inches. An acre is a unit of area used for measuring property, usually farmland. It's a bit less than half of a hectare. And of course an inch is 2.4cm. Acre-inches sounds totally bizarre when you first hear about it. But for the people that need to work with this value, it's an extremely useful way to measure reservoirs and gives you an intuition that you just don't get from cubic meters.
It's true that you can't just convert that to other units of volume without doing some math or looking up the conversion rate, but that rarely matters. If you're trying to figure out how fast the lake will rise or fall with a given inflow and outflow, you're going to have to have some way to account for the fact that the lake is a) an irregular shape and b) takes up more area the higher the water gets. You already need to know the area of the lake at any particular height to work out the evaporation rate anyway, so that's a number you're going to have. The units are designed to make that calculation easier, which was really important back in the days when slide rules were the state of the art.
All the customary units are like this in one way or another. They're units designed for a particular domain, and when used in their domain they work very well and calculations can be done in your head. They use fractions because that's what people have historically used (seriously - my grandfather could work fractions in his head faster than I could type them into a calculator, and he made asphalt for a living. Imagine what a carpenter could do.).
Think about it. Imagine you were never taught a measurement system. You find yourself needing to come up with a unit to make measurements for wooden planks you're going to use to build a house. Would you choose a unit as long as a meter? Or one as short as a centimeter or even a decimeter?
Bonus challenge to the fine folks clicking that downvote button: give me a real practical reason to prefer Celsius to Fahrenheit, besides the fact that Celsius is part of the metric system. No, the freezing and boiling points of water don't cut it - I work with hydrocarbon fuels, I salt my driveway and patio, I don't live at sea level, and quite honestly every American 8-year-old can spout off 32° and 212°. There's a Fahrenheit equivalent to Kelvin (Rankine) so the Kelvin to Celsius equivalence doesn't count either. My claim is that both scales are completely arbitrary, and only advantage one has over the other is that you're used to one of them. Go ahead, prove me wrong!
4 replies →
They are better for human consumption/understanding. Have you ever had to type an IPv6? It's awful.
How could you ever have really long addresses without having that problem?
They don't need to be really long. Adding one more octet to v4 makes it 1 trillion addresses. Sure the header should support longer than that, but it doesn't mean everyone needs to use all of it.
3 replies →