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.
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.
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
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?
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?
It isn't. Routing is good though.
And home routers have firewalls that block inbound connections by default -- including with no-NAT IPv6.
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.
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.
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.
> 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.
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)
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.
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.
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!!”.
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).
Private you can do whatever you want in the fd00:: range
fd00:1:/64 for vlan 1 fd00:2:/64 for vlan 2
etc
Or
fd00:ea7:cace::/64
fd00:b00b:13s::/64
Or have your hosts on
fd00:192:168:0::1 fd00:192:168:0::2 fd00:192:168:0::3
(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.
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.
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.
As such you still need an ipv4 network, so why bother with ipv6
CLAT should have been baked into the kernel 15 years ago.
NAT's RFC was 1994 - although port translation didn't come in until 1996. The same year that IPv6's RFC came in 1996.
Had ipv6 not been created until say 2010 I suspect it would have looked to be backwards compatible with the widespread use of NAT then.
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.
That's a perfectly valid IPv6 address and can be set up, if you own 1:1:1:1/32
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.
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
https://docs.opnsense.org/manual/how-tos/tayga.html
As such if your public IPv4 was 23.45.67.89 address
You'd forward 23.45:67.89 -> 2001:abc:ab23:2301::53
And vice versa.
Now the next issue is multi-homing.
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.
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 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.
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.
IPv4 has a lot of trouble since everyone is using 10/8 space for corporate networks.
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.
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.