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.
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. ;)
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.
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.
Really? I didn't know ISP-provided modems could even do that, I assumed they were like routers and isolated to the local network and what the ISP gives them access to. I just wish they would give me more than "well it's for security and it's corporate policy" or something, it just seems like some excuse, and their remedy is "buy your own router" (which isn't an option for me, too expensive).
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.
> 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.
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.
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.
If you have a network full of static addressed servers, you can go as small as you want. For WiFi networks random devices may connect to, you should just let them pick their own address in a /64 with SLAAC. You may choose to also let servers use SLAAC if you want to, in addition to their static address.
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.
But v6 _is_ backwards compatible though? It's got dual stack, Teredo, 6to4, 6rd, 6over4, ISATAP, 6in4/4in6, NAT64/DNS64, 464xlat, DS-lite, MAP-T/E, 4rd, LW4over6... how is this not backwards compatible? You could make a reasonable argument that it has too many backwards compatibility methods, even.
> 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
If your mental model of security relies on NAT then your mental model was wrong, and obsoleting it was the right thing to do.
If v6 made you realize this, then it seems it's more intuitive than v4+NAT was for you.
Instead of forwarding a port to a specific machine on the NAT page, you allow incoming traffic on that port to that machine on the firewall page. You'll want to add a stable IP to the host (in addition to the SLAAC rotating privacy IP if it already has one. One interface can have multiple addresses). That's pretty much it, except now you can allow the same port to multiple machines, where previously you could only forward to one (helpful for gaming, voip, etc. Wherever p2p works well). Firewall should already default deny incoming traffic just like ipv4.
That sounds easy, but I think you just inadvertently demonstrated the quagmire that many seem to perceive.
Suppose I've got a machine on the LAN and I want to open it up to the world on port 1025 with IPv6.
This can't happen with SLAAC? It has to be a new address? Does the ISP pick the prefix for that address? And one can't centrally-manage that address (because people keep saying that DHCPv6 isn't worth stuffing around with)? What happens when the router fails over to a backup ISP? How does dynamic DNS fit in with all of this?
Those questions don't really exist with IPv4, wherein: One can just set up a static DHCP assignment, forward port 1025, and [optionally] set up dynamic DNS -- and this all happens within the confines of a single home router.
If it's MAC based SLAAC, it'll be stable, so you could use it. Otherwise you add a stable address. You could use DHCP if you want. If you're using a backup ISP with dynamic DNS, your failover should be the same as ipv4. You can already have ips from both prefixes on the interface. You're also way past clueless home user stage if you have that setup at all, so I can't imagine ipv6 is the stumbling block.
Things would be nicer if NAT66 were used by default for home users though so the question of prefixes would disappear, and it'd perhaps match the "more advanced" home user ipv4 mental model. You'd just use e.g. fd00::2 as your server address.
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?
There are a shitload of people who maintain networks, like home or small business networks, that aren’t network administrators. Most of those people are not prepared to have their Chinese WiFi cameras, myriad smart appliances, and heck, even home computers easily individually accessible from the internet. It’s an extremely simple concept, no?
But lots of people want to do things like open up a few ports for a gaming console. You can obviously do it, but the inside network/outside network/poke a hole/simple ip addresses mental model makes it harder for people to just get frustrated and disable it. Of course absolutely nothing is impossible or more difficult from a technical networking perspective using IPv6. People want to learn as little as humanly possible to solve their problems. If the default easiest path is ‘disable the firewall, and suddenly you can use the LAN pvp mode with your 6th grade classmate’ then you better fucking believe that’s exactly what they’re going to do. The “well it’s not really that complicated” perspective is the main reason adoption of user-facing FOSS is lightyears behind commercial options.
I have ipv6 here in Europe. The router firewall configuration works basically the same as IPv4 port forwarding. You can add a firewall exception as easily as you can add a port forward. You can also turn the firewall off, globally or per device.
how is it a different mental model? instead of opening the port in NAT via forward feature, you open the port in the firewall. it is in fact significantly simpler while overall being the same actions you take when you want to "forward"
ridiculous, the vast vast majority of people just plug in what the ISP provides them, and thats it.
perhaps you could explain how its such a new paradigm and mental model that it simply confuses people? because I dont buy it, its without exaggerating a smaller difference in so far as this goes, than when people get a new microwave oven, and substantially less difference than when people switch phone brands.
Actually I think most people really do want that stuff accessible from the internet. Currently that requires a central server and a subscription, but imagine if it didn't. Imagine if you could log into your washing machine from anywhere instead of only when you're at home, and it would keep working even if LG went bankrupt.
nobody suggests they should be, the ONLY difference is that the routers will block inbound connections by default, and you open your port in the firewall section instead of the shitty router instead of the nat/port forwarding
Realistically, allocation is more complicated than that, and there are arguments that the current allocation scheme isn't futureproof enough. But if that happens, there's enough room to change it and still keep all existing allocations working.
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.
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)
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 :)
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.
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.
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.
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.
I assume you meant 10.x.x.x and 192.168.x.x -- (and 172.16.x.x?), ie the standard subnets for home router-modems (which are non-routing and so can't be used on the internet).
Of course... this would transitionally make the ipv6 internal addresses easier to understand in the context of typical migration... you have the public prefix and the public ipv6 addresses of your internal network map cleanly to the internal/nat'd ipv4 ... you could still use any ipv6 internally once most of the internet transitioned.. but it'd be easier to reason with at least... I still don't know WTF/HTF ipv6 addresses are issued, where or how I can centrally control static assignment to a given MAC.
Public IP6s are allocated the same as ipv4, either ask for a block (I assume you'll need your own AS and appropiate method to announce), or your ISP hands you a block (should be a /48 I think, or maybe a /56)
Private you can do whatever you want in the fd00:: range
(you don't have to have your router on :0 if you don't want to, just like you don't have to use .1 or .254 in a ipv4 /24)
If you want to allocate a given IP to a given mac address centrally then you need DHCPv6 as normal. The problem is that because dhcp isn't as required as it is under v4 (because of slacc), not all clients will support it, or support it properly. For desktops + servers you should be fine though.
AFAIK this was one of several things that was tried, but failed for various reasons. It's called "TUBA" - TCP/UDP with Bigger Addresses - adding extra address bits at a layer above IP so that IP remains compatible.
I think one of the main problems with it is that you have to update the whole internet anyway, just like you do with IPv6, so you make the protocol stack stupider for no real benefit.
Cool... now, what do I need to do to configure say OpnSense to give out my internal IPv4/6 addresses that way... and then what pain do I need to go through to secure my internal devices from externally oriented connection attempts?
The former is somewhat serious a question... I want some devices statically assigned and others dynamically, and I'd love to have them match, so where desired I can directly route to/from external over IPv6.
The problem with ipc6 is that transparent v4 support
My ISP gives me an ipv6 range of 2001:abc:ab23:: (well something very similar) routed down the pppoe tunnel (which autoestablishes ipv6 with a /128 IP, just like my ipv4 establishes with a /32)
I thus have my ipv6 vlan 2301 as 2001:abc:ab23:2301::/64
The router is at 2001:abc:ab23:2301:: (which is 2001:abc:ab23:2301:0:0:0:0)
My DNS server on that vlan is statically configured as 2001:abc:ab23:2301::53
My phone when I connect gets a slacc address 2001:abc:ab23:2301:so.me:thi.ng
I can't reach my DNS server from the outside world on 2001:abc:ab23:2301::53 because my firewall blocks it, but if I did allow it t would route through just fine
Remember none of this works with v4 though, you'd have to configure your router to do nat46 and nat64. I've never used such a router, but looks like its supported
My backup router is ipv4 only, so when 192.168.231.0/24 gets routed out my main ISP as normal, it's hidden behind an IP like 81.187.123.45. If I route traffic out of my backup 5g ISP it gets hidden behind that (it actually gets src-natted to a 10.x range, as it's a 4g ISP, it gets converted to a real public IP later)
My 4g doesn't support ipv6, and ipv6 is just a toy, but I expect I would use nat66 to map
2001:abc:ab23:2301::53
behind whatever IP range I was given for the backup route. I've not looked into nat66.
The other aspect is changing ISP. I don't plan on doing that, and ipv6 is only a toy protocol, hence I can just use my global address range. I could however use fd00:2301::53 for my internal DNS server (equivalent of 192.168.231.53) and nat66 it at the boundary, hiding fd00:2301:: behind 2001:abc:ab23:2301::
As the hide address is a /64 there's no need for port mapping, my traffic would emerge from 2001:abc:ab23:2301::53
ipv6 proponents talk about advertising half a dozen IPs to your end devices and renumbering them all dynamically and using mdns instead of static IPs. And they wonder why people thing ipv6 is crap.
An alternate to IPv6 would have been to store the NAT addresses in IPv4 somehwere. But the IPv4 options are fragile and normal NAT would likely destroy them. It would still require rewriting all of the networking and software. It would have engrained NAT everywhere and made lots of routing problems, like is that your or mine 10. network.
That's where the public prefix would be the differentiator... you could only access from external directly over IPv6, but it still represents the same device as the NAT ipv4 address.
Difference is it's all public after, it would ease the transition dramatically, and then you can just use whatever you want internally making /32 the minimal assigned block or whatever the prefix size is.
Stop saying IPv6 when talking about new protocol. IPv6 already exists and is better than potential IPv4 extension. There was a window twenty years ago for alternative but now IPv6 is usable and can access IPv4 hosts with NAT64. The only reason for IPv4 is inertia.
Routing would be complicated when have to deal with variable length addresses when half the hosts don't know about them and half the routers remove them. It wouldn't make up for rewriting all the software, we know how hard that was with IPv6.
Public websites almost always still have ipv4 to serve ipv4-only users who make up half of the American business internet. But note that v6 connectivity is better than v4 in basically every other country and basically every mobile network (which is where most of the users are).
The proper way to do ULA is to generate random 40-bit ID. Then your ULA are likely unique. Which means that if you want to connect or merge with another company, the networks are distinct.
IPv4 has a lot of trouble since everyone is using 10/8 space for corporate networks.
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.
If your ISP offers it, you should just try it. If not, do you have a website on a VPS or something? Try making that work with v6. It's really not a scary monster, it's mostly the same thing again but with long addresses, and a few convention changes that come with long addresses.
Examples of convention changes: end devices can each get several addresses for privacy and for being on multiple networks concurrently. SLAAC is stateless because addresses in a /64 are so endless there's no need to keep a central registry of which ones are already used. NAT is rare because it's no longer necessary, even though there is no internet police to stop you from using it (please try to avoid it). P2P is so much easier - applications can be written under the assumption connectivity is end-to-end with firewall hole punching.
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 a "vibe coded" specification from someone who doesn't understand the problem at all. Just like ipv6, you can't use ipv8 without upgrading the whole internet. The internet is mostly ipv6 capable and not at all ipv8 capable so why do you want to throw away that progress and reset the clock?
It's also just a worse design, centralising a bunch of things and trying to authoritatively define what counts as "a network" on both sides of the communication, unlike v4 and v6 where you just have raw bits and can interpret them how you want. I mean ipv8 defines the internet as a bunch of networks and a network as a bunch of computers. And a network is something that has an ASN. Your computers would be on your ISP's big network, not your small home network because you can't have a network inside a network. It also decreases the number of bits than we already have (in ipv6), limiting futureproofing. It also says every network device will log in with OAuth. Yes, really.
You know, I'm not sure I can explain how I feel about this properly without waving the shotgun around.