It should be largely similar in v6 land. Generate yourself a random ULA /40 prefix - the randomness is here to prevent collisions should the network of your organisation merge with another.

Assign your sites a /48 each taken out of this /40 prefix. Try to future proof your addressing plan, remember that each /48 contains 65536 /64s, you can afford to “waste” them.

But also note that the “best practice” is to use ULA for intra/inter-site communications only. Since IPv6 hosts can be assigned multiple addresses, it is possible to assign them a GUA for communications with the wider internet, and a ULA for internal communications.

In reality though… Some machines may use their GUA as the source adddress even though the destination is ULA. Firewalling gets hairy. :(

This reminds me of this article about ULA. The TL;DR I got from it was: yeah, use ULA if you are a multi-sited organization, but you can’t afford PI space.

Quote:

In the meantime, we’ll have to use kludges like NAT66 and ULAs in mid-market IPv6 implementations, not because we love them, but because they’re the best tools we have at our disposal.

ULA is problematic with dual-stacked networks just as you have mentioned, although there are drafts trying to fix it. For now, you may have to consider running a NAT64 gateway in your network and go IPv6-only.

I am using it now as I’m commenting.

Been using it daily for years at this point.

And that’s why the MTU is typically 1500 bytes for Ethernet

There are times when the original standard has zero forwards compatibility in it, such that any improvement made to it necessarily creates a new standard.

And then there’s also times when old greybeards simply disregard the improved standard because they are too used to the classic way.

So there you have it, 2630::/16 is currently the largest block allocated by any RIR by far! Honestly, I am most surprised by Egypt and South Africa’s allocation considering how poor the deployment of IPv6 has been over there.

Also… I can’t be the only person to think that assigning an /16 to a financial company is incredibly wasteful, right? Especially considering that we can only ever have 65536 /16s. It sounds like something that is better allocated to an ISP. What was ARIN even thinking?

edit: And the other blocks listed above are indeed all allocated to Internet service providers! (Except 2a08::/19 which was allocated to the UK Ministry of Defence) What the hell, ARIN?

The largest block allocated by APNIC is:

China 240e:2000::/19 on 2018-12-27

The largest blocks allocated by RIPE are:

Germany 2003::/19 on 2005-01-13
France 2a01:c000::/19 on 2005-12-30
United Kingdom 2a08::/19 on 2016-07-01

The largest block allocated by ARIN is:

United States 2630::/16 on 2023-10-20

The largest block allocated by LACNIC is:

Argentina 2800:2000::/20 on 2012-02-28

The largest blocks allocated by AFRINIC are:

Egypt 2c0e::/20 on 2012-11-25
South Africa 2c0e:2000::/20 on 2015-01-19

TOML isn’t elegant at all but damn, it is really simple.

“it just maxes out the ram and then does nothing.” is absolute nonsense. The programs need memory to operate.

If your RAM is maxed out and the programs seem to operate just as fine, the OS is doing something behind the scenes, it’s just a matter of what that something is. And memory swapping / virtual memory is a well-known method of alleviating RAM overuse, at the cost of murdering your SSD/HDD lifespan.

To be honest lack of IPv6 support is a petty reason not to use them

For people like us (IPv6 advocates), moving away from IPv4-only services is just like voting with our wallet. Well, except that the flow we are looking at is not money flow, but internet traffic instead.

Obviously such a movement is not going to make a huge dent in the grand scheme of things – very few people care about the internet protocol they are using. But the idea is that it will eventually end up in someone’s log that, a lack of IPv6 support is driving customers away and/or implementation of IPv6 support is attracting new customers.

Also, it doesn’t hurt anyone else except us when we purposefully move away from IPv4-only services even though the IPv6-capable services are worse ;) Anecdotally speaking though, that’s a rare case.

To be fair: A notebook with a bunch of strong passwords is probably more secure than a human brain memorising a bunch of weak passwords.

deleted by creator

Can’t replicate your results here. I play on Wayland, and deliberately force some games to run natively on Wayland (SDL_VIDEODRIVER=wayland) and so far I haven’t noticed any framerate changes except statistical noise.

Tell me you haven’t seen people adamantly defending IPv4 without telling me so…

Good luck getting a block of IP addresses from your regional internet registry for this community ISP… IP address exhaustion is just that, no more addresses. That’s why we are sharing them.

We do have a solution and it’s called IPv6, but its deployment is still not as widespread as people would like to be. If I self-host my website on IPv6, a lot of people from Europe would still be unable to access it.

That’s pretty much just pushing the centralization from Google, AWS etc to the hosting services.

It’s pretty difficult nowadays to self-host websites when everyone and their nanny shares a single public IP address (IPv4 address exhaustion is real, everyone!) unless you purchase a hosting service.

You are right - although I dislike Google in general, the fact that Android supports only SLAAC is most likely the dominating reason why residential ISPs delegate /64 at all.

Do I hate systemd now?

No, because that’s not specific to systemd.

I can quite clearly remember the long shutdown times back when Ubuntu was still using Upstart.

Generally speaking, long shutdown times are an indication of a system issue (e.g. HDD going bad or slow network) or just scripts being written poorly, and could be worked around by changing the timeout value. Systemd defaults to 90 seconds, but you can change that to 30 secs or lower.

I think someone will still have to route the /96 networks eventually? Aggregation is helpful for routers located in the upper part of the network hierarchy only.

There’s also the problem of service providers “racing to the bottom” if /64 is not standardized, for example some ISPs may choose to delegate /96 instead, or /116, or /120, … you get it. We still have ISPs assigning people /128 in spite of /64 being standardized everywhere.