Hopefully once Google and other stats get over 50% there will be a “look at the majority” effect. Most ISPs in my country already support IPv6 with a couple IPv6 only with NAT64 on the edge. But I guess we’ll just have to see.
I really hope you’re right. I’m one of those people who believe that we should simply abolish IPv4 completely. We have zero need for IPv4 and dual-stack networks are way more prone to errors and complexity.
People usually say that IPv6 is hard and IPv6 addresses aren’t “memorable” but that’s mostly BS because with the :: aka “reduced format” they can be even simpler than IPv4. Others might say it is dangerous without understanding how NAT isn’t necessary and how a firewall should work. Another common argument against deprecating IPv4 is that we should keep compatibility with older devices, to which I say… IPv6 support was introduced in Windows XP SP2 (2004).
IPv6 is great, largely simply networks, make things more efficient and allows for more complex scenarios that are hard to deal with in IPv4. Multihoming, advanced load balancing, network level split DNS, direct peer-to-peer communication, totally abolishing DHCP in a usable way etc.
Completely agree with your dual-stack networks are more prone to errors and IPv6 networks are simpler than their IPv4 counterparts. Firewalls are easier to understand than port mapping NATs. Simpler is better for security.
I’ve tried running my home network with IPv6 only and NAT64 on my edge but more than a couple devices seem to only understand IPv4. I feel like these devices will be the ones that hold back the IPv6 only approach.
@apearson> I’ve tried running my home network with IPv6 only and NAT64 on my edge but more than a couple devices seem to only understand IPv4. I feel like these devices will be the ones that hold back the IPv6 only approach.
One of my two Roku Ultras finally is acquiring an IPv6 address, but no idea if it is doing any streaming with it. The other hasn’t acquired an IPv6 address yet. Even though the two have the same marketing name, they are different internal hardware models. But at least it is a sign that Roku Labs is at least aware that there is something called IPv6!
What are those devices? Poorly designed IoT stuff? I’ve some experience with the embedded / industrial world I remember working with Telit modems and manuals / documentation pushed people really hard into getting IPv6 working.
I’m currently doing a very specific thing with IPv6 in one of my setups. So the ISP on that site provides a very good Wifi6 router with IPv4 + IPv6 (PD/SLAAC) dual-stack networking.
Everyone’s first thought is to replace the router ISP entirely, however it isn’t necessary in that case. I simply added a cheap ARM device (NanoPi NEO2, 512M of RAM) running OpenWRT to handle most of the network while still keeping the router’s ISP as gateway and wifi AP.
In the ISP router I’ve disabled IPv4 DHCP, set it to a static IP. Kept IPv6 PD / SLAAC settings as provided by the ISP. Then I configured the OpenWRT box to do DHCPv4 + dual stack DNS (SmartDNS, encrypted etc) while the ISP router advertises the IPv6 prefix and acts as gateway for both IPv4 and IPv6. OpenWrt is 192.168.1.1 + fe80:1c0:5208::1, and the ISP router is 192.168.1.254.
My devices will get their IPv4 from the OpenWRT box via DHCP and their IPv6 from the ISP via PD / SLAAC. DNS in both cases is provided by the OpenWRT box. With option ra_preference'high' devices in the network will set their IPv6 DNS server to fe80:1c0:5208::1 (my OpenWRT box) instead of what the ISP router advertises that has a lower priority.
I think the biggest problem with IPv6 adoption is that it does not come with a full transitional package that’s mandatory for all IPv6 capable nodes.
If A has IPv6, but B doesn’t, then A can’t use IPv6 to reach B. If both A and B has IPv6 but there is no v6 route between A and B, then A cannot use IPv6 to reach B.
What should have been done instead is that the transition mechanisms should have made sure that anyone can pick up IPv6 and use IPv6 exclusively on their own discretion and then transitional mechanisms would ensure that everything works. Whenever a node has both public v6 and v4 addresses it should be ready to translate when a packet needs to be routed into the v4 internet.
This would basically mean a few things:
A scheme that allows self assignment/calculation of a globally unique v6 address without administration or registration.
Automatic NAT64 when the destination is v4 using a fixed well known prefix.
Automatic tunneling when the destination is v6 and there are v4 nodes in the path. To make this work we need a scheme that allows finding the appropriate v4 gateway for a given v6 address if it’s a registered/officially assigned address and not a self assigned/calculated one (perhaps using an .arpa domain for this).
Emulated v4 layer to make v4 only applications work when the network is v6 only.
There is no DNS64, clients would look up both A and AAAA records and use the methods above to reach the destination.
When a node has no v4 neighbors, then it can use v6 natively, somewhere upstream there will be a router that’s dual stack and can translate the traffic if needed.
With all these in place, v4 hosts can begin using v6 without significant service degradation and would allow enabling v6 by default.
If we had done it this way, the transition would have finished long ago.
I believe it was actually done in the way you say. There’s NAT64 that ISP should implement that and there’s RFC6052 with a reserved prefix for translation. 64:ff9b::/96 for the global internet and ::ffff:0:0/96 for local stuff. I guess the problem is that ISPs aren’t capable / don’t have the interest in having NAT64 running.
There are still tons of ISPs refusing to have IPv6. For instance in my country only one of the three major ISPs has IPv6.
Hopefully once Google and other stats get over 50% there will be a “look at the majority” effect. Most ISPs in my country already support IPv6 with a couple IPv6 only with NAT64 on the edge. But I guess we’ll just have to see.
I really hope you’re right. I’m one of those people who believe that we should simply abolish IPv4 completely. We have zero need for IPv4 and dual-stack networks are way more prone to errors and complexity.
People usually say that IPv6 is hard and IPv6 addresses aren’t “memorable” but that’s mostly BS because with the
::aka “reduced format” they can be even simpler than IPv4. Others might say it is dangerous without understanding how NAT isn’t necessary and how a firewall should work. Another common argument against deprecating IPv4 is that we should keep compatibility with older devices, to which I say… IPv6 support was introduced in Windows XP SP2 (2004).IPv6 is great, largely simply networks, make things more efficient and allows for more complex scenarios that are hard to deal with in IPv4. Multihoming, advanced load balancing, network level split DNS, direct peer-to-peer communication, totally abolishing DHCP in a usable way etc.
Completely agree with your dual-stack networks are more prone to errors and IPv6 networks are simpler than their IPv4 counterparts. Firewalls are easier to understand than port mapping NATs. Simpler is better for security.
I’ve tried running my home network with IPv6 only and NAT64 on my edge but more than a couple devices seem to only understand IPv4. I feel like these devices will be the ones that hold back the IPv6 only approach.
@apearson> I’ve tried running my home network with IPv6 only and NAT64 on my edge but more than a couple devices seem to only understand IPv4. I feel like these devices will be the ones that hold back the IPv6 only approach.
One of my two Roku Ultras finally is acquiring an IPv6 address, but no idea if it is doing any streaming with it. The other hasn’t acquired an IPv6 address yet. Even though the two have the same marketing name, they are different internal hardware models. But at least it is a sign that Roku Labs is at least aware that there is something called IPv6!
That’s great to hear! One of the IPv4 only devices I have is a Roku
What are those devices? Poorly designed IoT stuff? I’ve some experience with the embedded / industrial world I remember working with Telit modems and manuals / documentation pushed people really hard into getting IPv6 working.
They’re all IoT type devices (scale, Robo Vac, alarm) :/
Sad.
I’m currently doing a very specific thing with IPv6 in one of my setups. So the ISP on that site provides a very good Wifi6 router with IPv4 + IPv6 (PD/SLAAC) dual-stack networking.
Everyone’s first thought is to replace the router ISP entirely, however it isn’t necessary in that case. I simply added a cheap ARM device (NanoPi NEO2, 512M of RAM) running OpenWRT to handle most of the network while still keeping the router’s ISP as gateway and wifi AP.
In the ISP router I’ve disabled IPv4 DHCP, set it to a static IP. Kept IPv6 PD / SLAAC settings as provided by the ISP. Then I configured the OpenWRT box to do DHCPv4 + dual stack DNS (SmartDNS, encrypted etc) while the ISP router advertises the IPv6 prefix and acts as gateway for both IPv4 and IPv6. OpenWrt is
192.168.1.1+fe80:1c0:5208::1, and the ISP router is192.168.1.254.My devices will get their IPv4 from the OpenWRT box via DHCP and their IPv6 from the ISP via PD / SLAAC. DNS in both cases is provided by the OpenWRT box. With option
ra_preference 'high'devices in the network will set their IPv6 DNS server tofe80:1c0:5208::1(my OpenWRT box) instead of what the ISP router advertises that has a lower priority.I think the biggest problem with IPv6 adoption is that it does not come with a full transitional package that’s mandatory for all IPv6 capable nodes.
If A has IPv6, but B doesn’t, then A can’t use IPv6 to reach B. If both A and B has IPv6 but there is no v6 route between A and B, then A cannot use IPv6 to reach B.
What should have been done instead is that the transition mechanisms should have made sure that anyone can pick up IPv6 and use IPv6 exclusively on their own discretion and then transitional mechanisms would ensure that everything works. Whenever a node has both public v6 and v4 addresses it should be ready to translate when a packet needs to be routed into the v4 internet.
This would basically mean a few things:
When a node has no v4 neighbors, then it can use v6 natively, somewhere upstream there will be a router that’s dual stack and can translate the traffic if needed.
With all these in place, v4 hosts can begin using v6 without significant service degradation and would allow enabling v6 by default.
If we had done it this way, the transition would have finished long ago.
I believe it was actually done in the way you say. There’s NAT64 that ISP should implement that and there’s RFC6052 with a reserved prefix for translation.
64:ff9b::/96for the global internet and::ffff:0:0/96for local stuff. I guess the problem is that ISPs aren’t capable / don’t have the interest in having NAT64 running.