I recently troubleshot an installation for someone where at some point in the past they'd picked 1.1.1.0/24 as their address range because "all that 192 stuff was silly and too complicated".
You know, I'm not sure I can explain how I feel about this properly without waving the shotgun around.
I had a gig for a contractor of some banks once. One of the banks was using 5.0.0.0/8 internally. I asked the guy if it doesn't lead to issues. All the time, he said. When they first came in, they just assigned each bank 1.0.0.0/8, 2.0.0.0/8, and so on. Number ten feels really lucky, he said.
As long as it's strictly separated from the internet it works. The Internetwork Packet Exchange, used for cellular roaming, is a parallel global internet with its own addresses and allocation policies.
This story is so silly it must be true. Thank you, made me laugh out loud.
LOL, they should have just used a 10.x space instead if they wanted slightly simpler numbers.
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.
I dunno, seems like it could be a bit vague. Does 45 refer to 45 Webley or 45 GAP? Could possibly also refer to 45 Colt I guess, if you're boring. But 45 Colt, 45 ACP, 45 Colt Government?
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. ;)
Didn't AT&T do that and Cloudflare made them change it when they aquired that space?
I got a "home" Verizon box, and the first thing I did was change the DNS setting... 1.1.1.1 wasn't working, and I wanted to change it back to default. Verizon's tech support are idiots... they literally wouldn't give me the default DNS IP because they were concerned about security.
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.
Quantenna used 1.1.1.1 for RPC to their wifi chip in their SDK by default. Should not have been exposed to global routing but of course people screwed that up.
https://medium.com/@mrtcve/atts-misuse-of-cloudflare-dns-ip-...
My ISP won't give me the router credentials because they claim that that would somehow risk their network interconnectivity or something. I have no idea how this makes any sense since a router (shouldn't) give me that level of access, but maybe I'm missing something?
If the router is also the modem, it can have diagnostic stuff that could (I am careful to point out: theoretically) cause them a big support headache in one way or another.
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.
Or they didn't want you to know the IP(s) so you could easily block it
Sounds like they blocked Cloudflare but couldn't block Google
Funny enough their problems really began in earnest about seven or eight years ago...
Sounds like someones on the path to sovereign citizenship. I can't wait for our cyber-sovereign citizenships who deny various IP ranges coming from the government's domain naming system.
Yet another thing ipv6 solves. Yeah you can do the officially supported fdXX:XXXX:XXXX:... but you can also just pick something like 1::1 and it's unlikely to conflict with the current global range.
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.
"all that 192 stuff was silly and too complicated... but this fd00: stuff is easy peasy!"
Agreed 100%! I know there's tough challenges to making this reality, but if https://serverspace.io/about/blog/ipv8-explained-what-we-kno... could be an IRL thing, I would buy company network equipment and use computer OSes that supported this draft standard.
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.0.0/24 -> fd00:0::/64
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.
One thing I don't appreciate... Is the nature of NAT protected my internal/home network before... now, I have to actually configure firewall settings etc. to protect IPv6 issued addresses internally.
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.
> Not to mention, that I really don't understand how IPs are supposed to be provisioned to devices on IPv6.
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.
Which doubly sucks in terms of assigning a DNS name to an IP/PC... and/or opening the assignment to less restricted access... feels just problematic to me.
Again, I don't know any of IPv6 enough to use it really right or wrong.
And there's always static configuration, useful for servers.
I doubt any endpoints are entirely ipv6.
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!!”.
> I doubt any endpoints are entirely ipv6.
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.
I'm largely with you... I would think they'd take the IPv4 block and have a direct/virtual block that just extends it to more addresses... so it could be an IPv4 NAT or IPv6 direct.
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.
you can use 1234 if you want, that's also unused space
> Yet another thing ipv6 solves. ... it's unlikely to conflict with the current global range
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.
All global IPv6 addresses start with 2. This is by design. Pedantically, 3 is also reserved for global. Some other prefixes are also reserved, like fd for the ULA (local) range.
The point of IPv6 was to make the addresses so long they are easy to manage.
>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.
I know that on my hosted server, I never bothered to set it up, because I didn't know how to properly configure or sub-net it. I know it's skill issue, but really feels significantly more complicated and even harder to understand than NAT even.
Not to mention, at home, most of the ads I do see (PiHole) are IPv6 addresses.
It seems to have absolutely terrible ergonomics as a technology, in nearly every conceivable way.
It's literally impossible to avoid long addresses being long or short addresses running out. One of those is a worse problem.
The length isn’t the only thing that makes the ergonomics suck. The lack of backwards compatibility sucks. The “you don’t have to use NAT anymore” is great theoretically, but it renders a lot of casual network maintainers mental model of network security obsolete without a clear and simple alternative. The shorthand is not intuitive (though it’s not CIDR-level counterintuitive). Really, there’s way too much about working in IPv6 that’s not intuitive with even very solid IPv4 network knowledge.
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.
you fling around words like "network maintainers" quite casually, dont you? :)
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?
No network is "smaller" than /64. All end-networks are /64.
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. :)
(Pedantically) Maximum prefix length of /64 is only required if you want/need SLAAC. If you're assigning static addresses or using DHCPv6 for assignment you can go as small as you want. It's not weird to see /127 for tunnel subnets, for example.
I didn't want to encourage non-standard behavior, but you are correct. Tunnels are a common use the same way /31s can be used in IPv4.
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.
How many /24s does your organisation have? With IPv6, one block is almost always sufficient.
It's mental that my fairly techy-orientated but otherwise pretty standard UK ISP provides me with a /48 as default.
So I have 1.2 million million million million IPv6 addresses available.
That ought to be enough, eh?
The point of IPv6 was to make the addresses so long that we don't run out of them in 20 years or so.
There fixed that for you.
The problem is NAT solved the same problem more easily and cheaply. It was at the cost of making it difficult for every host to talk directly to every other host, but it turned out most of the people building networks didn't want that feature anyway.
We already ran out of ipv4 about 15 years AGO.
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)
The argument is that IPv6 addresses are UUIDs and any random block is unlikely to collide with any other random address.
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
Thanks for the reply. I'm reminded every now and then of the magnitude of the address space in v6. Then I do nothing with that information and slowly lose appreciation for the size again :)
https://xkcd.com/865/
Respectfully I don't think they explained it well.
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.
If you can't remember 192.168 you definitely can't remember a randomly picked ULA. So just use fd00. It's not any worse than 192.168.
True, I was thinking more about the allocation discussion than the "easy to remember".
Anyone in IT who allocates 1.1.1.0/24 because 192.168.0.0/24 is hard, should be allocated to trash pickup.