You know, I'm not sure I can explain how I feel about this properly without waving the shotgun around.
On the shotgun, or adjacent, I do tend to prefer ammo classes for my nets... 10.22.x.y, where x may be 1, 38, 45, etc. Allows for site to site vpn with friends/family a bit easier to remember.
Also, just in case this comment isn't pedantic enough, 10.22 would be a firearm range, not an ammo range. And AFAIK they only ever chambered that for .22 rimfire cartridges. ;)
Google's DNS worked fine, but Cloudflare's didn't. No idea if they ever fixed it... I'm using it as a backup for my main connection, eventually I'll setup autofailover on my router (OpnSense). For now, I just swap the cables.
https://medium.com/@mrtcve/atts-misuse-of-cloudflare-dns-ip-...
Also, I had a DSL modem back in the day with its own terrible NAT built-in. I managed to log in (I may have been given the admin password from a friend who worked at the ISP, allegedly) and once I put it into bridge mode, I was able to acquire multiple public IPv4 addresses via DHCP.
Sounds like they blocked Cloudflare but couldn't block Google
If you're gonna do that, though, it's better if you use fd00:... or one of the other assigned ranges so it's still in the standard range. OSes use this as a heuristic for source address selection.
It's a much better compromise and ergonomics to migrate from IPv4 to an IPv4 respecting successor, where IPv6 is just the academic snobbery and utterly alien mental model for not-enough benefits.
For the same reason Unix stuck around and beat up its own successor Plan 9/inferno. That inertia even decades later is the same reason IPv4 still beats IPv6.
IPv8 is more of a linux to unix than a plan 9.
192.168.1.0/24 -> fd00:1::/64
192.168.2.0/24 -> fd00:2::/64
192.168.240.0/24 -> fd00:240::/64
It's not a great idea, but its no harder.
No need to mess around with setting up DHCP, remembering if your router is top or bottom of the subnet, and if you want 500 devices on a single subnet that's no problem.
Now if you still need ipv4 then yes, ipv6 is stupid as you have double the pain for none of the gain, but if you are ip6 only then its far easier.
I know you can just block inbound non-established connections, but it feels like an extra step and complexity. Not to mention, that I really don't understand how IPs are supposed to be provisioned to devices on IPv6. Is there like a 50-100 page book you can recommend "for dummies" on IPv6, that hopefully contains at least a tiny amount of how to configure a common router and/or linux host.
SLAAC is the only way that works across all IPV6 devices. In that mode, the router advertises the prefix and the device assigns its own address (prefix + its mac address).
DHCPv6 exists but is poorly supported. It sucks for people who like assigning IPs individually from an authoritative place (through static dhcp entries on the router). But people like us are "doing it wrong", you see? We must accept that in this brave new worlds an IP means nothing.
Again, I don't know any of IPv6 enough to use it really right or wrong.
So it seems like it helps ISPs and large networks router… but they never had problems with address space running out at the high levels and almost all likely need to support v4 anyhow.
I think it’s been long enough to be honest that ipv6 was a spectacular failure by complicating an already complicated system into something no one actually asked for.
No human said “hey, networking sucks. Please make it much harder at my level!!”.
Lte and 5G can be v6 only, usually they also have NAT64 and DNS64 so you can get everywhere, but the less stuff that needs v4, the smaller their nat boxes are.
like 1.1.1.1/192.168.45.4 ... for a router that understands IPv6, that's the direct route to the sub-network, otherwise it will have to use IPv4, and the subnet route is treated as NAT and otherwise isolated.
To me, that would make more sense... then internal IPv6 might be practically limited to 10. and 102.168. in the nearer term, but adoption would be MUCH simpler in practice, and distribution would mostly already be established, however unfairly, but can then be broken into single addresses and vNext adoption could be that much quicker as a result of piggybacking.
I'm not familiar with IPv6's details, could you elaborate on this? To me, this reads like you're saying that IPv6 solves the problem by having low adoption rates rather than an actual function of the protocol.
The point of IPv6 was to make the addresses so long they are easy to manage.
lol, there is no doubt that had a massive opposite effect. To the point of nearly killing it in terms of willingness to adopt.
Not to mention, at home, most of the ads I do see (PiHole) are IPv6 addresses.
So yeah, having to relearn a bunch of basic network knowledge that worked just fine for decades is a PITA, and I’m 100% positive a design process that focused more on the people that need to configure networks could have yielded a much friendlier, and therefore a much easier to adopt standard.
its really extremely simple, just dont NAT, is that really so hard? just because you dont NAT, doesnt mean you have to let the traffic pass through, that is also an extremely simple concept, no?
Split subnets at four bit chunks.
Allocated networks, like to a home or small office, should be /56 or /60.
Then you have to think about link-local addresses and privacy addresses, and how to hand out IPv6 and configure DNS: SLAAC vs. DHCPv6 or some combination.
I have a rough draft of a beginner document but it's not ready. :)
Going smaller than /64 is against best practice and unnecessary. People coming from IPv4 need to understand that trying to be careful with subnet sizing for purposes of preserving space is not a thing in IPv6 below /64. Maybe if a residential user has a /64 from their crappy ISP settings they'd need to do it, but not in a properly configured scenario and certainly not in enterprise.
So I have 1.2 million million million million IPv6 addresses available.
That ought to be enough, eh?
There fixed that for you.
64 bits would be enough to avoid run out, but hierarchical allocation would still be a problem. 128 bits is long enough for many levels of hierarchy. (And yes, you can subnet all the bits, not just the first 64)
It's not about low adoption, it's that there are unimaginably many IPv6 addresses.
...which is a major reason for why it has low adoption
fc00::/7 is for "Unique Local Addresses". Basically, private, non-globally-routable addresses from which you can freely pick space. Kind of like RFC1918. It's deliberately huge and you should only use as much from it as you need. The idea being that if you merge with another organization or connect to them via VPN, it's unlikely your addresses will collide like with RFC 1918.
There's even a website (sites?) to register your ULA space on a volunteer basis to reduce collision chances.
Anyone in IT who allocates 1.1.1.0/24 because 192.168.0.0/24 is hard, should be allocated to trash pickup.
IPs having a global distinction between public/private is a convention, but local routing can widely differ.
Same with the "China Cyberattacks" - the guys sitting on top of my outgoing fiber can simulate any IP address they want to me.
192.0.0.0/24, 10/8, 172.16/12, and various other subslices of 192/8 are reserved for local use and are not publicly routable.
22.0.0.0/8 - it's basically free real estate!
Just to chime in agreeing with sibling comments, the issue is when it's not about just your house and you're deep into self-hosted stuff with a lot of different properties and businesses other people's houses all sharing resources. Without a lot of coordination and consideration, which in practice doesn't really happen easily given the adhoc nature such things tend to organically develop out of, and all the random stuff that wants specific addresses at least for setup, it actually gets pretty easy to run into collisions. Allocations typically are definitely inefficient in many respects but also made sense in the context they were first done and of course can be a certain amount of effort to change.
In an ideal world I sorta feel like "IPv6" should have been more along the lines of <12 octet prefix>:<IPv4>, everyone gets a prefix or set of prefixes that they actually own and are consistent worldwide, or at least only change when geographic location changes, and then can just have the entire 32-bit IPv4 space for LAN however they want. Then you only have to care about prefix between LANs and it could all be extremely automated, internally you only need to use something that looks like IPv4 with the network hardware transparently able to handle prefixes for WAN. Backwards compatibility story would be a lot more straight forward too. Oh well.
@kotaKat: that's a great idea and I don't know why I forgot I played with that like 15 years ago. Really handy as a backup space that almost certainly won't collide with any commercial hardware at least.
But one of our vendor networks uses 10.32.x.x/32 for various radio gateways, and the radios themselves all locally expose (this is where I give away too big a clue as to what I do) 10.0.0.101 as a management address that emits important link status data.
So you can imagine what a godawful bùrach everyone's routing tables are.
Crucially, we set aside the common 10.1 and 10.10 ranges as nonroutable, so any devices that default into those have to be dealt with before they can live on the wider network.
Newcomers get handed a block and have to renumber, or NAT into it, or whatever, but they cannot emit bogons. At a small scale (first-name basis), this works.
The Canadian Navy very recently made a major choice and agreed with you
https://www.google.com/search?client=firefox-b-d&q=hanwha+oc...
n.b., it's the Department of Defense, just like the Kennedy Center doesn't have Trump's name attached, and the large body of water by Texas is the Gulf of Mexico.
and while i currently don't hate china as much as i do US rn (because canadian; sorry) i can also say -- due to being an aforementioned leaflandian -- that due to very personal experience i have zero faith in anything from china that has the ability to connect to any type of network :')
And so yeah at this point if I can't at the very least get a whatever-wrt firmware (preferably a proper linux distro nowadays; not to say the *-wrt firmwares aren't a real OS but, y'know) on the device i just avoid them entirely since, well... it's all i can do at this point because even if there were baked in hardware-based backdoors i as an individual can't do much more than that.
Old thin clients are typically in the same hardware class, and probably cheaper by the time you add the exploding MSRP of a Pi, and a PSU, and a case and heatsink, and maybe some storage that doesn't suck ass. But if you already own the Pi, yeah, go for it.
/S
Tech enthusiasts: My entire house is smart.
Tech workers: The only piece of technology in my house is a printer and I keep a gun next to it so I can shoot it if it makes a noise I don’t recognize