[–] BLKNSLVR 15 hours ago
[–] mtoner23 12 hours ago
[–] BLKNSLVR 3 hours ago
Point being that patterns on small scales match patterns on larger scales.
[–] tcfhgj 11 hours ago
[–] BLKNSLVR 3 hours ago
[–] PeterStuer 15 hours ago
Also, that same tech industry has shown remarcable competence in working around IPv4's limitations.
[–] mahboi 11 hours ago
[–] cowlevel 10 hours ago
[–] woah 7 hours ago
[–] throw0101a 2 hours ago
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.
* 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)
[–] Dagger2 6 hours ago
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.
[–] woah 4 hours ago
[–] cowlevel 3 hours ago
[–] mahboi 6 hours ago
[–] throw0101a 2 hours ago
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.
* https://github.com/becarpenter/misc/blob/main/why6why.md[–] mahboi 2 hours ago
[–] cowlevel 4 hours ago
[–] mahboi 3 hours ago
[–] mahboi 9 hours ago
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.
[–] ratorx 9 hours ago
[–] mahboi 9 hours ago
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.
[–] JDups 16 minutes ago
[–] throw0101a 2 hours ago
Pounds vs kg: see above. All the non-American people seem to have "intuitive" grasp of metric measurements.
> 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.
So 'more granularity' is good for temperature but not for speed. Got it.
> 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.
By "foot" do you mean 'regular' foot or survey foot:
* https://www.nist.gov/pml/us-surveyfoot
Because there are two different units in the US customary system, used for basically the same purpose, that use the same name. And the "foot" isn't the only unit like that:
* https://en.wikipedia.org/wiki/Pound_(mass)
* https://en.wikipedia.org/wiki/Pound_(force)
Here's another one: which weighs more, a pound of feathers or a pound of gold? A pound of feathers. Because feathers use one 'pound-system' [1] and is 453g, while gold uses another pound-system [2] and is 373g. But of course an "ounce" of gold (31g) is more than an "ounce" of feathers (28g), because Troy is 1/12 of pound but Avoirdupois is 1/16. In addition to the above "ounces" there is also "fluid ounces".
[–] spauldo 2 hours ago
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!
[–] throw0101a 2 hours ago
US customary is not "thousands" of years; temperature (Fahrenheit) only came out in 1724 for example, and many other units were only standardize much more recently:
* https://en.wikipedia.org/wiki/History_of_measurement#History...
* https://en.wikipedia.org/wiki/System_of_units_of_measurement...
Second, even with-in the system itself there was also sorts of inconsistencies. Until just a few years ago there were two "foot" units; one was recently retired:
* https://www.nist.gov/pml/us-surveyfoot
Here's another one: which weighs more, a pound of feathers or a pound of gold? A pound of feathers. Because feathers use one 'pound-system' [1] and is 453g, while gold uses another pound-system [2] and is 373g. But of course an "ounce" of gold (31g) is more than an "ounce" of feathers (28g), because Troy is 1/12 of pound but Avoirdupois is 1/16. In addition to the above "ounces" there is also "fluid ounces". And let's not forget about the third system [3], which got replaced by… the metric system in 1971.[4]
[1] https://en.wikipedia.org/wiki/Avoirdupois
[2] https://en.wikipedia.org/wiki/Troy_weight
[3] https://en.wikipedia.org/wiki/Apothecaries'_system
[4] https://en.wikipedia.org/wiki/United_States_Pharmacopeia
Also:
* https://en.wikipedia.org/wiki/Pound_(mass)
* https://en.wikipedia.org/wiki/Pound_(force)
> 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?
Millimeters. That single unit gets you down to very small scales (finer than 1/16") and to large lengths: four significant digits (9999mm) gets you to the equivalent of >32' (~11yd).
* https://web.archive.org/web/20200516223819/https://themetric...
As evidence for this Australia/NZ/EU do everything in millimetres in construction.
[–] drnick1 10 hours ago
[–] cowlevel 4 hours ago
[–] mahboi 3 hours ago
[–] Dagger2 2 hours ago
And you already don't have to use all 128 bits in v6. You're forced to use about 48 of them, but the rest is your choice. You can just... not use some of them. It's fine.
[–] nomel 9 hours ago
[–] inglor_cz 15 hours ago
Austria-Hungary adopted the metric system in the 1870s. Back then: no cars, no highways, no speeding laws etc. Oxen-drawn wagons in the countryside were not built to a precise spec.
Only the railway, the architects and the artillery had to really switch. Ordinary people would still ask the grocer for half a pound of ham in the 1930s.
USA in the 1970s would have to remeasure all the land communications etc., or end up with a weird hybrid like the UK.
WHat we have in IPv4 and IPv6 is the weird UK-like hybrid...
[–] throw0101c 12 hours ago
* https://en.wikipedia.org/wiki/Metrication_in_Australia
It's going to take decades, mostly waiting for the non-metric folks to die off probably and the raised-on-metric folks to grow up, but if you don't start you'll never finish.
† Can Aussie HNer confirm?
[–] KnightHawk3 12 hours ago
These are all customary usage so I'd say we are completely switched over, we couldn't tell you generally what these units look like outside of "how big is a baby" or "how tall is that person" or "is my beer large or small" really.
[–] spauldo 1 hour ago
That goes back to the fact that the imperial system replaced the older customary system after the American revolution. The US legislated a somewhat simplified version of the Customary System the English were using at the time, which was a piecemeal system based on several different acts of parliament over hundreds of years. We (much) later made slight changes so that our measurements are based on metric.
The Imperial System was instituted in the UK in 1826 and most of the measurements stayed the same, which is why our foot and pound are the same as your foot and pound. The biggest change was that imperial simplified the various liquid measurements to make them uniform. Before then, different liquids used different measurements. The gallon used in the US was originally based on the wine gallon whose value had been last set by parliament in 1709.
[–] Symbiote 9 hours ago
[–] poncho_romero 8 hours ago
[–] throw0101c 4 hours ago
Construction: "two-bys" are used, with 16/19.2/24" offsets for studs and such (though the building code has millimetre equivalents).
[–] Miaourt 15 hours ago
[–] charlieyu1 15 hours ago
[–] OnlineTux 15 hours ago
[–] xacky 15 hours ago
[–] jon128 12 hours ago
https://en.wikipedia.org/wiki/End-to-end_principle[–] TZubiri 15 hours ago
[–] throw0101c 15 hours ago
Creating an IPng was always going to be complicated:
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.
* https://github.com/becarpenter/misc/blob/main/why6why.md* https://datatracker.ietf.org/doc/html/rfc1671
For anyone curious as to the decision-making process, here are the criteria for what the IETF was looking for in an IPng:
* https://datatracker.ietf.org/doc/html/rfc1726
Here are the candidates that were floating around at the time, and the reason why the winner was chosen:
[–] TZubiri 12 hours ago
I'm not saying that IPv6 is incompetent, or that IPv6 implementations break backward compatibility, or that the problem can be solved without breaking bc.
I'm saying that while IPv6 breaks bc itself, dual stack does not, and even full migrations can maintain bc or gracefully degraded.
In essence, not all implementations IPv6 are good, and not all migrations from IPv4 are responsible, if someone is blindly team IPv6 or blindly team IPv4 in general there's a lack of nuance.
[–] cowlevel 10 hours ago
NAT is the only one that actually does work, and it's terrible.
[–] TZubiri 7 hours ago
[–] cowlevel 4 hours ago
[–] VCFundedGenYer 15 hours ago
IPv6 can be selectively applied to say, NAT addresses, but other than that, IPv4 is just fine and your statement is incorrect.
[–] throw0101c 12 hours ago
Unless there's a merger/acquisition and the two companies both use 10.0.0.0.
Most home networks use 192.168, and so you can't use that in corporate environments, because the WFH people who VPN in could then have routing snags between local and remote locations.
Also, in your VPN software be sure to perhaps not use 172 addresses (like my previous job did), as some of those ranges are used by Docker by default, and so you can cause issues for developers.
But other than that IPv4 RFC 1918 is not complicated at all…
[–] tredre3 6 hours ago
The thing is, asking nicely doesn't always work. Sure, automated tools like docker/incus/wireguard/tailscale will respect it. But admins who don't want to be stuck typing long addresses? Not so much. I've lost count of how often I encounter a network admin that manually set their prefix to some fcXX::, when it's not outright fc00::.
Of course you can (and should) blame this on admins and not on IPv6, but then the same could be said of IPv4 where adding entropy to 10.X.X.0 is the usual recommended way of doing things.
[–] throw0101c 4 hours ago
IPv6 solves this by making it easy for everyone to get their own 200::/3 address so that when two companies get together they have completely different /48s (or whatever).
> […] but then the same could be said of IPv4 where adding entropy to 10.X.X.0 is the usual recommended way of doing things.
There has never been a recommendation to add entropy to 10/8 addresses. At least I have never heard of such a thing. Can you provide a citation for this (alleged) recommendation? Is there an RFC of some kind?
[–] orangeboats 14 hours ago
How would an IPv4 client send a packet to an IPv6 server? The IPv4 packet has only 4 bytes to spare for the destination address.
You can't.
Anything longer, even if it's just 1 bit, would require a new IP version.
[–] freeone3000 14 hours ago
[–] orangeboats 13 hours ago
- If you are managing the 4to6 mappings manually, it's obviously not going to be scalable. Just to give people an idea, websites nowadays can connect to 10+ IPs in a single page due to CDN load balancing and stuff.
- If you are handling the mappings automatically, such as by monitoring DNS queries and creating dynamic mappings based on that, the issues become more insidious: applications with hardcoded IP literals would fail without an obvious reason.
[–] wmf 9 hours ago
[–] favorited 8 hours ago
[–] growse 13 hours ago
[–] jon128 12 hours ago
Anyone who doesn't by default set up IPv6-only networks by default with NAT64 and DNS64, or who present any notion that IPv4 is somehow "okay", shouldn't have a job anywhere, not even an entry-level desktop support job.
:grimace: