upvote
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.
reply
> 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.
* 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)

reply
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.

reply
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.
reply
Ah yes exotic locations like San Francisco, New York, London, Prague, Sydney, and Tokyo. Totally not major business hubs or anything.
reply
Some of those locations probably did feel more exotic back in the early 90s than they do today... but they're also sensible places to hold international conferences. Where are you supposed to do them, if not there?
reply
That's what they did and you're here complaining about it
reply
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.
reply
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.
reply
> […] 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.
* https://github.com/becarpenter/misc/blob/main/why6why.md

* https://datatracker.ietf.org/doc/html/rfc1671

reply
Yes it's 3A. They didn't need to make the new protocol have separate state from the old one. Let me keep my old address on the new protocol.
reply
> Yes it's 3A. They didn't need to make the new protocol have separate state from the old one.

Except there will be a period of time when many 'network elements' (routers, firewalls, servers (web, SMTP, DNS, etc), clients) will not be updated for the new protocol so you may also need 3B.

And this will be true for any IPng, and not just the one that just happened to be chosen to be for "IPv6" (which was SIPP, over CATNIP and TUBA; see RFC 1752).

> Let me keep my old address on the new protocol.

You can/could. You can encourage people who have addresses in the older protocol to use the new one with "free" "automatic" address assignments in the new one to encourage translation and tunnelling:

> For any 32-bit global IPv4 address that is assigned to a host, a 48-bit 6to4 IPv6 prefix can be constructed for use by that host (and if applicable the network behind it) by appending the IPv4 address to 2002::/16.

> For example, the global IPv4 address 192.0.2.4 has the corresponding 6to4 prefix 2002:c000:0204::/48. This gives a prefix length of 48 bits, which leaves room for a 16-bit subnet field and 64 bit host addresses within the subnets.

* https://en.wikipedia.org/wiki/6to4

And the 'old' IPv4 addresses are available in the new IPv6 world:

> Addresses in this group consist of an 80-bit prefix of zeros, the next 16 bits are ones, and the remaining, least-significant 32 bits contain the IPv4 address. For example, ::ffff:192.0.2.128 represents the IPv4 address 192.0.2.128. A previous format, called "IPv4-compatible IPv6 address", was ::192.0.2.128; however, this method is deprecated.[5]

* https://en.wikipedia.org/wiki/IPv6#IPv4-mapped_IPv6_addresse...

There is no way around this limitation: you must have a separate network space because of physical limitations.

Your supposed solution, and many others, have been thought of already. Have been tried. You are not thinking of anything new in your proposal.

reply
6to4 and NAT64 are not what I'm saying. Those involve a relay server and v4 translation, and there's an entire memo on why that's unreliable and abandoned. I want to switch to fully native IPv6 without changing any of my addresses. There's no reason this should be impossible.
reply
> I want to switch to fully native IPv6 without changing any of my addresses. There's no reason this should be impossible.

… except for the fact that you have to have completely new data structures and packet format to fit more address bits, and once you change the structures you need a new version field so any gear that sees a packet knows where to use the old code paths or new ones.

Then you're at the point where you have to push new code everywhere to handle these changes, and some nodes will have only the old code and some the new code, so now you're into translation and/or tunnelling to make sure the old addresses can talk to new addresses. Depending on their risk tolerance, some operators will enable the new code and some will not.

You also have to update DNS with new records, as A records are hard-coded to 32 bits. So now you're updating DNS libraries and user land.

There is no way to expand address space without going through all the same issues as what we call "IPv6" (originally SIPP) has gone through.

* https://github.com/becarpenter/misc/blob/main/why6why.md

reply
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.

reply
Can you give some examples of where Imperial works better from first principles and why you think so?
reply
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.

reply
I'm not sure common urban/highway speed limits like 30mph/70-75mph line up better than the 50kmh/100-110kmh you see in Canada.
reply
As a Canadian I have no idea what 72˚F means or feels like: is it warm or cold? I do know what 22˚C feels like and how to dress for it. How "intuitive" a temperature number is completely learned behaviour and cultural acclimation.

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".

[1] https://en.wikipedia.org/wiki/Avoirdupois

[2] https://en.wikipedia.org/wiki/Troy_weight

reply
I didn't say it's about being used to one. It can be "in the 20s" C for multiple months, kinda silly. 22.0˚C also feels different from 22.5˚C. There's a right amount of granularity for temperature and for speed.

Foot and pound have unambiguous meanings in the US. There's a reason the whole survey foot and gold-pound thing is trivia that nobody knows, they're niche or abandoned systems that you only use if you're being clear that it's not regular feet or pounds. I also know that the US system is technically not "imperial," but nobody cares.

reply
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!

reply
> Reservoir volume in the US is measured in acre-inches.

Never heard of an acre-inch before, and I'd have to get out a calculator to work out how much water that actually is in pints or gallons, or how much it weighs.

The metric equivalent would be a hectare-meter or a hectare-mm. I know a hectare is 100 m x 100 m, so 10,000 m². So I instantly know that a hectare-meter is 10,000 m³ (10 ML, or 10,000 tonnes of fresh water). A hectare-mm is 10 m³ (10 kL). If my 1 ha block gets 1 mm of rain, then that's 10 kL or 10 tonnes of water. So easy i can do it in my head.

> And of course an inch is 2.4cm

2.54 cm.

reply
A couple more to add to your list: an inch is about as long as your thumb joint (with some variation between individuals obviously). It's an easy way to gauge the size of everyday objects without needing to carry around a tape measure.

The recommendation for emergency supplies is about a gallon of water per person per day - or 3.7 liters if you're using metric.

I've also heard it claimed that the 0-100 Fahrenheit scale is more functionally useful because the endpoints of 0 and 100 represent the tipping point of serious danger for humans from hot or cold weather. The closer you get to 100 degrees the more care you need to take about heat stroke and keeping hydrated, and similarly the closer you get to 0 degrees the more care you need to take about retaining heat and staying out of the elements - the freezing and boiling point of water isn't a necessary marker for survival. And people like nice round numbers to serve as markers for such things, divisibility be damned.

Metric is sterile and functional for calculation and consistency, which is fine and necessary for many things, but that's not a reason to completely ditch Imperial.

reply
> 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.

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.

reply
> US customary is not "thousands" of years

You misunderstood me. It's based on measurements that people have been using for thousands of years. The Romans had feet and miles, for example - not exactly the same lengths, but for the same purposes. The Japanese shaku is almost exactly the same as a US foot. A Japanese Shō is about half a gallon. A Chinese jīn is just slightly larger than a pound. There's a reason for this.

> there was also sorts of inconsistencies

I never claimed otherwise. But do notice that the survey foot and standard foot weren't used for the same purposes, and the difference between them wasn't likely to confuse anyone except maybe people new to the field.

> Here's another one: which weighs more, a pound of feathers or a pound of gold?

Yep, Troy weights. And no one's sure where the Troy system came from. The main reason for its use is because of international trade. Also not something regular people (i.e. people that didn't work directly with precious metals) would have had contact with.

> Millimeters

Hah! Yeah right. Look at all the various non-metric systems that have existed throughout history. Did any of them use something like millimeters to measure wooden planks? Why not?

> As evidence for this Australia/NZ/EU do everything in millimetres in construction.

They do it because the metric system is mandated there and it doesn't give you reasonably sized unit for that scale of work.

Try this: go to a home center (or whatever it's called there - the place you buy building supplies) and measure some drywall. Do the measurements you made agree to the advertised ones within half a millimeter? Compare the dimensions of drywall sheets from different pallets and manufacturers. Do their dimensions agree to within half a millimeter? If not, that's a sure sign you're using units poorly adapted for purpose.

reply
They are better for human consumption/understanding. Have you ever had to type an IPv6? It's awful.
reply
How could you ever have really long addresses without having that problem?
reply
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.
reply
1 trillion addresses isn't anywhere near enough[1]. Remember that we're not talking about L2 here. (...I don't think 1 trillion MACs would even be enough if we want to ensure they're unique, and it seems the IEEE agree with me since they expanded MACs to 64 bits, but that's a different conversation.)

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.

[1] https://www.rfc-editor.org/info/rfc1715/

reply
The world is already managing with 32 bits of addresses plus NAT, and NAT most likely gives you less than 256 concurrent users per address. But sure, if some cheap ISP only owns a few /32s and needs to use more octets, let them do that, doesn't mean my 4-octet address needs to be super long too.

You're kinda forced to use 128 bits in v6 if you're an end user, cause that's the lowest common denominator. SLAAC is default, DHCP6 is widely unsupported. Most ISPs also only give out a /64 per spec minimum.

reply
deleted
reply