I'm also convinced that the length of IPv6 addresses and the difficulty in typing them is a major reason for lack of adoption. Very seemingly small UX annoyances can have a large effect.
I've been convinced of this since around 2000. Every network utility dealing with IPv4 had... dotted quad addresses. You could remember them, you could read them, you could speak them to someone else. Brainwise, we can remember 3-5 things - segments, digits, etc. Remembering more is harder for the average person.
Having the 6 be literally dotted sextant(?) - 5.73.192.168.0.4 for example - would have been much much much easier to transition in to, and would have given us 64k x 4 billion addresses. Yes, it's not the near infinity we have with IPv6, where apparently every molecule in the universe can have multiple IP addresses or whatever the max number is. But it would have been much much easier to transition. 27 years later we're not transitioned from ipv4, and we've got another 27 years of dotted quad baked in to daily usage everywhere.
No, it wouldn't have taken 'exactly as much work to transition'. See another reply. In 2024, I'm still reading about BGP/routing table issues, and hardware having problems keeping up with IPv6 networking - it's just too large. How was this supposed to work in 1999?
A smaller stepped transition from 4 billion addresses to... 64k of those would have been an easier transition step, and the ease - mental, UI, training, testing, security, etc would have given everyone involved the confidence and positive feedback to tackle a next stage to IPv6 (eventually).
But even if they had the counter argument to "128 bit addresses are too long, 48 bit would have been better" is obviously not "that's the same thing just with 48 bit addresses!"
Part of this would just be transitory, but... would take up far less space. Even as late as last year, I'm reading stories about BGP issues and slowdowns because routing tables are too large/many for the hardware. In 2024. How on earth was this expected to work on hardware from 1999?
https://blog.apnic.net/wp-content/uploads/2023/01/Figure-1-%...
https://blog.apnic.net/wp-content/uploads/2023/01/Figure-14-...
Actually mDNS does exactly what they said just fine. You’re confusing it with the ability of a DHCP server to make updates in DNS on behalf of clients. There is more than one way to skin the cat. Both achieve the same affect, just differently.
> nor do they necessarily ever consider your local DNS server.
Hardcoded DNS servers are just as equally a thing with IPv4.
Rather, most routers add DHCP hostname requests to the local DNS routes. That doesn't require mDNS, nor would you want to replace it with mDNS as mDNS is more limited & flakier.
Ping foo on my machine results in foo.local being successfully pinged. Your mileage may vary.
> would potentially use mDNS if you have a ping that does such a thing
It's not a feature of ping, it's a feature of the name resolution setup on your machine (nsswitch and/or resolved on Linux).
> Rather, most routers add DHCP hostname requests to the local DNS routes
What do you mean?
Of course, but they aren't the baseline expectation like it is with ipv6 since ipv6 baseline assumption is SLAAC. And SLAAC is terrible. If you control all the devices on the network, like a cloud install, you can just pretend SLAAC doesn't exist and live in a much better world.
If it's a home network then you're stuck expecting at least some usage of SLAAC. And you're better off just not supporting ipv6 at all at that point
Why not? Are you saying your computer doesn't need to know the IP address of any dns server in order to be useful?
What do you mean when you say that SLAAC is terrible? Especially when you control all the devices on the network, you are in full control of what SLAAC manages for you. Also, SLAAC is the only way to use the IPv6 Privacy Extensions.
Things like RA and NDP would clue hosts into the local DNS server as well. You don't need DHCPv6 to advertise a local DNS server.
Indeed. I meant that if evaluating the two de novo, IPv4+NAT is harder.
Then there are crimes against network protocols like NAT66 that are borderline necessary in some situations because terrible ISPs have decided to dynamically alter IPv6 prefixes so they can charge extra for a static prefix.
I still think NAT makes everything harder than it should be, but I get why some people struggle with IPv6 if their ISP is particularly terrible.
Everyone should bomb Android bug reports with complaints about lack of DHCPv6 until they fix it. Then people can de-facto deprecate SLAAC. AFAIK Android is the only major offender here.
Some corporate networks already don't do SLAAC if they don't need Android to work on them.
Possibly, but I think it's also that some aspects of IPv6 are just badly designed, and subsequent updates only fixed some of the issues.
SLAAC, for example, is godawful stupid. And while DHCPv6 exists to fix some of that, critical aspects of the protocol, like prefix delegation, are manually configured. This is beyond idiotic and makes things like subnets massively more difficult than they have any right to be.
SLAAC and PD combine to create the worst sin of all - flakiness. It's hard to figure out why IPv6 isn't working because everything is telling you it is (it "auto configured" a valid IP despite not having any actual route to anywhere else, so helpful! /s). If IPv6 was literally just "IPv4 but 128-bit addresses instead of 32-bit ones" it almost certainly would have been adopted en masse by now. But it isn't, it made things more fragile and harder to configure for no goddamn reason.
And of course you then have ISPs doing silly stuff, like my ISP only gives me a /64 so I literally can't use IPv6 on my network since I want VLAN isolation. 18446744073709551615 possible addresses are given to me yet dividing that up into 3-5 subnets is completely impossible. Fucking stupid protocol.
The core of V6 -- longer IPs -- is great. SLAAC and /64 being the smallest need to be deprecated. It's asinine.
Really absolutely everything but longer IPs should be deprecated and was a mistake.
are you sure? what about homepods, Chromecasts, Hue bridges, kasa smart plugs, esphome, etc etc etc...?
How much are you willing to bet your home network on Android being the final user of SLAAC? And how much time do you want to invest in figuring that out in the first place?
Heck, I would have probably simply added an Options flag for "long address" to support longer addresses. With the first part of the address being the IPv4 address of some ISP backbone router and the next 3 words being a device address on the network (with the all-0 device address reserved for the router itself). Then you don't even need to upgrade most of the routers beyond configuring them to accept packets with that option set. It would have been so simple and elegant and we would have probably upgraded most of the world by 2001.
The quantity of existing deployments that need to change is much larger for v6 than it was for v4. The problem with deploying v6 isn't that it's too different from v4, the problem is that it's different at all. Your v7 will have the same problems.
Although https://www.rfc-editor.org/rfc/rfc7217 doesn't require a /64 or shorter prefix for its variant of address auto-configuration, for example Linux doesn't allow otherwise.