> 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.