I think that’s the chief reason it’s failed to catch on at any meaningful rate. It may be good overall or have long-term effects, but if any one typical use asked you, “what will be different for me if I buy this?” there’s no answer.
I think that’s the chief reason it’s failed to catch on at any meaningful rate. It may be good overall or have long-term effects, but if any one typical use asked you, “what will be different for me if I buy this?” there’s no answer.
But maybe that's really only relevant for routable static addresses and consumers typically don't need any. I understood e.g. T-Mobile US consumer subscriptions are IPv6 only already now. (Not living there, so from hearsay) It's just transparent to the customer via NAT64 where needed? And obviously all somewhat recent phones just work, so no logo required.
I'm a T-Mobile US customer. This is correct - the only real address your phone gets is IPv6. I believe V4-only sites are reachable using 464XLAT (RFC6877, RFC7335) or equivalent.
Lots of purely technical things which have no impact on user experience take over old technologies.
The issue with IPv6 is that it has no visible impact on users -_and_ it's a major paradigm shift in terms of complexity and addressing scheme compared to v4.
Every year I secretly hope some major consortium with traction release "IPv4 2.0" with 8 bytes and get done with it.
How exactly would this work?
IPv4 data structures have four bytes/octets (4B) for addresses. So how do you fit 8B of addresses in 4B structures? You don't. So you have to update every network element—host (desktop, laptop, mobile, embedded), router, switch, firewall—to have a new data structure (and maybe new function/system calls, as the old ones assume the old structures). So all devices have to have updated network stacks, including long-lived ones that sometimes are not touched for a decade+.
And not just pure networking code: anything that touches (e.g.) DNS as well, as A records are 4B-only as well, so you need a new record type and deploy new DNS server and resolver code everywhere.
But of course if you have a 4B-only network elements/devices, they cannot talk to 8B-only devices/services, so you have to create translation mechanisms because some devices may not yet have the update 8B-capable network stack. And sometimes an 8B network is an island in a sea of 4B, so you have to have tunneling. Of course some may have both 4B and 8B, and want to talk to something has also has 4B and 8B, so now you have to have code for source/destination selection.
Those are the exact same challenges as with the IPv6 roll-out.
And of course "IPv4 1.0" continues to work, so what motivation is there for going to your "2.0"—just like what motivation is/was there for going to IPv6 when IPv4 is/was 'working'?
See "TCP and UDP with Bigger Addresses (TUBA), A Simple Proposal for Internet Addressing and Routing" for part of the discussion from back in the day (1993):
The problem of adoption with IPv6 is not technical. It's that IPv6 changes radically how we thing about IP networks.
IPv6 explodes all existing concepts of DHCP, DNS, NAT, etc. You have an entire generation of network, system and software engineers that have no clue at how IPv6 work, no existing infrastructure to learn it, and somehow expect that it's going to stick.
I say, let's solve the 90% that is really problematic with IPv4, being the number of adresses, and the rest is moved to some other standard.
I never understood this line of thinking.
You put your Layer 4 bits into a Layer 3 packet with a larger address space, then stuff that into a Layer 2 frame, and send it off onto the wire/air waves.
You can have DHCP(v6) if you wish. DNS is only different with a new record type (AAAA). NAT-y stuff can still be done, but stateful firewalls are not different.
The fact that you can—if you wish—have less infrastructure (no DHCP server, no NAT (but still SPI)) should make it easier to deal with, not harder.
Look, I don't know what to tell you, honestly.
I tend to think I'm fairly more litterate in networking than most software engineers. I am no network engineer, but I have spent most of the last decade writing networking software, including layer 2 VPNs.
I am also genuinely interested in understanding new tech.
Yet, IPv6 _terrifies_ me.
Every 2 years or so I'm in the mood of learning it. And every time, after reading docs on the subject, I'm like "Nope, I'll wait til I retire to get my IPv6 PhD".
Maybe that's just a matter of finding a proper, accessible documentation. I always end up thinking "okay so that's a total big bang I have to rethink entirely everything I know about L3".
As an example, let's say your ISP gives you the details:
WAN IP: 2001:db8:ffff:200::2/64 (like "203.0.113.2/24")
Default router: 2001:db8:ffff:200::1 (like "203.0.113.1")
Routed prefix: 2001:db8:42::/48 (like "192.168.0.0/16")
On a Linux router, you would set this up by doing: ip addr add 2001:db8:ffff:200::2/64 dev wan0
ip route add default via 2001:db8:ffff:200::1
ip addr add 2001:db8:42:1::1/64 dev lan0 [like "192.168.1.1/24"]
Then install radvd, put the following into /etc/radvd.conf and start the radvd daemon: interface lan0 {
AdvSendAdvert on;
prefix ::/64 { DeprecatePrefix on; };
RDNSS 2001:4860:4860::8888 { };
};
This is enough to give you a functioning network. Your machines will pick up the announcement, assign themselves addresses and default routes, and can talk to each other and the Internet. And as you can see, this L3 setup isn't any different to v4 -- you've got a WAN IP, a LAN IP and a route. Devices get IPs from 2001:db8:42:1::/64 like they get IPs from 192.168.1.0/24. The client autoconfig is different but it's a lot simpler than DHCP.What am I glossing over? Most ISPs aren't static, which means you need to automate the above setup, and even for a static ISP you'd need to persist the `ip` commands (e.g. via /etc/network/interfaces or whatever your distro uses to do network config). If your ISP needs ppp or VLANs or whatever then you gotta deal with those too, but that's not v6-specific.
You're also going to want a firewall, but that will look very similar to your v4 one: deny new connections from the WAN, allow new connections from the LAN, allow packets from existing connections in both directions. I can give you ip6tables or ferm for that if you want.
Lastly, I'll point this out explicitly, but you don't need NAT which is why there's no mention of it above. It's just not necessary. The ISP has an inbound route set for 2001:db8:42::/48 to your router, and a /48 is more than enough address space.
Other than that, those three commands + radvd config really are enough for a fully-functioning network. It doesn't seem terrifying to me, nor does it seem inaccessible to someone that already knows how v4 networks work.
I’m not the parent but I just end up not wanting to have to debug network traffic across two protocols where I don’t know how to deterministically work out which is in use.
Then I need to work out new firewall rules and replacements for things like Pi-hole, home DNS, etc. Realistically that’s just me reading docs for 10 minutes, and double-checking everything has the “work with ipv6 box” toggled.
But personally my hesitation is getting stuck in this in between and maintaining two network setups.
Not terrifying, just a lot of work I don’t need to do.
But thank you. Now I’m inspired to do it.
I think you mean "get started with it"? It's not easy to win against a competitor with a 25 year head start.