throw0101c
Joined 4 years ago
Karma
10,252
Submissions
3,046
Member since
Jan 1
Recent submissions
Comment · 1 day ago
Comment · 1 day ago
> Today, the imperial system holds on in a few places, like heights and weights of people (although not at the hospital) and cooking temperatures.
Construction: "two-bys" are used, with 16/19.2/24" offsets for studs and such (though the building code has millimetre equivalents).
Comment · 1 day ago
> In theory IPv6 solves the problem by putting all of this under a single prefix (fc00::/8) and asking nicely that implementation/admins add 40 random bits to form their prefix. Which is plenty to prevent (almost all) eventual conflicts.
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?
Comment · 1 day ago
> You mean it's fixed by NAT and CGNAT. Because it's works just fine for me.
CGNAT works for you? Do you play video games at all? Because there are all sorts of people for which it doesn't.
The fact that you may be fortunate enough to get a publicly-accessible IPv4 address on your WAN interface does not mean everyone else is. This type of attitude seems to be akin to "I gots mine."
Comment · 1 day ago
> It's slightly unrealic idea though, as most of internet users are consumers, and that's the role they really prefer.
Because just about all applications are currently architected in such a manner.
When Skype first came out many moons ago it allowed peer-to-peer connections with clients, but a lot of clients were behind NAT (especially ones that could not do PCP or UPnP), so Skype had to come up with the notion of "super nodes" that could do relaying.
Protocols like STUN/TURN/ICE/etc had to be developed to deal with all of this blocking of traffic.
If clients could know their 'real' addresses and allow things like PCP (which is often needed for (e.g.) video games), then perhaps there could me less strictly consuming and more collaborating.
Comment · 2 days ago
> IMO, IPv6 solved the address pool size part of the issue, but it made managing the v4 to v6 transition very painful.
There is no easy way to transition from IPv4 to any kind of IPng; see my other comment:
Comment · 2 days ago
> IPv4 is perfectly and objectively fine on internal networks. IPv6 is overkill and way too complicated for most.
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…
Comment · 2 days ago
Australia managed to do a complete† change over starting in the 1970s:
* 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?
Comment · 2 days ago
> I can read one at a glance and the other makes me fill in the blanks myself after having to count how many invisible blanks I need to fill in.
The protocol chosen for IPng, SIPP, did actually have "only" 64 bits, but this was deemed not enough as folks did not want to have to worry about running out again (amongst other reasons), and so tweaked it to have a fixed 128 bits:
* https://datatracker.ietf.org/doc/html/rfc1752
SIPP originally was variable-length capable, but it was decided fixed-length was better (e.g., for hardware like ASICs).
> Wouldn't have been a problem if they hadn't given every square millimeter of the planet 100 billion addresses.
For the record: IPv6 gives 10¹⁷ addresses per mm²; in terms of volume, 10⁸ IPv6 addresses per mm³ throughout the Earth.
Comment · 2 days ago
> From around 10% adoption up to 50%.
Google sees 70-80% from some countries:
* https://www.google.com/intl/en/ipv6/statistics.html#tab=per-...
Comment · 2 days ago
> And vice-versa for decimal on ipv6 if desired, I guess?
Or octal:
* https://networkingtoolbox.net/ip-address-convertor/represent...
Comment · 2 days ago
Ran across a comment a while ago on some fun "IPv6 math":
On the surface of the Earth [land+water], there are 8.4 IPv4 addresses per km². Not counting the oceans, that would be 28 IPv4 addresses per km² land.
IPv6 gives 10¹⁷ addresses per mm² (yes, square millimetre).
In terms of volume, 10⁸ IPv6 addresses per mm³ throughout the Earth.
A second way of thinking about it:
* Stars in the Milky Way: 400 Billion
* Galaxies in the universe: 2 Trillion
* So (4x10¹¹)x(2x10¹²) = 8x10²³ stars in the universe.
* Size of IPv6 address space: 3.4x10³⁸
* Find the ratio between addresses and stars: 3.4x10³⁸ / 8x10²³
IPv6 offers about 430 trillion times more addresses than estimated stars in the universe. From Tom Coffee's presentation "An Enterprise IPv6 Address Planning Case-Study":
Comment · 2 days ago
> Absolutely not. Existing IPv4 hardware and software expects addresses to be 4 bytes long.
As does DNS.
"A" records are fixed at 32 bits, so you have to add a new record type and update all DNS software, plus user-space API/library code and data structures to ask for and store the new record type.
Just like IPv6.
There is no "just" adding more addresses: whatever scheme anyone comes up with is the same amount of work as IPv6.
Comment · 2 days ago
> I still think we should just extend the length of IPv4. In my proposed system, existing addresses would become a subnet of the new set.
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://datatracker.ietf.org/doc/html/rfc1671
> Keeps all the nice parts of IPv4, doesn’t require everyone to switch to an entirely new system, backwards compatible with existing hardware/software. Problem solved.
You have to ship new code to every 'network element' to support your "IPv4+" plan. Just like with IPv6.
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.)
You need to update socket APIs to hold new data structures for longer addresses so your app can tell the kernel to send packets to the new addresses. Just like with IPv6. 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 IPv4+-only destination (like IPv6 with DNS64/NAT64, CLAT, etc)
You're updating the exact same code paths in both the "IPv4+" and IPv6 scenarios: dual-stack, DNS, socket address structures, dealing with legacy-only code that is never touched to deal with the larger address space.
"Just adding more bits" means updating a whole bunch of code (routers, firewalls, DNS, APIs, userland, etc) to handle the new data structures. There is no "just": it's the same work for IPv6 as with any other idea.
Comment · 2 days ago
> No, backwards compatibility is competence.
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://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:
It's not about "what 'normal' humans want", it's about what can even be built.
It's currently hard to build decentralized anything now, and it'd be nice to open things up to see what creative things (if any) people could come up with if the network allowed for more peer-to-peer connections.