The IPv6 Transition

IPv6 is _still_ not at the feature parity with IPv4!

I'm not kidding. For example, Android doesn't support stateful DHCPv6. And DHCPv6 doesn't have the _basic_ feature of DHCPv4: hostnames. You can't easily use it to do a quick survey of your network.

Then you have that @#&(^(&!@^ that is ULA.

With IPv4 we have a very useful pattern: you create an "internal" network that is stable and predictable. It's routed to the outside world through NAT. If the external connection goes down, the internal network is unaffected.

With IPv6 you're supposed to have ULA and the global routed addresses in parallel. So now the external connection goes down, and the router withdraws the prefix from the router advertisement. Half of the hosts lose their external addresses, but keep the ULAs. Half of the hosts don't implement prefix withdrawal, and keep both their ULAs and the normal addresses. Congrats, now these hosts can't talk to each other due to the ULA addresses being less preferred.

And of course, IPv6 hasn't improved on the PMTU. So if you're running an Internet service, you need to use something like 1400 MTU to make sure some of the misconfigured tunneled clients don't get shafted. There's now an RFC that makes it useful: https://datatracker.ietf.org/doc/html/rfc9268 , but it's Experimental and it'll need ~20 years to be deployed anyways.

IPv6, a story of recursive utter failure at all levels...

> Congrats, now these hosts can't talk to each other due to the ULA addresses being less preferred.

What do you mean by this? Are you taking about mDNS still referencing the withdrawn prefix?

If two hosts have both mutually accessible ULA and GUA addresses, they will prefer _GUAs_ to talk to each other. So the connection will be susceptible to the prefix withdrawal if the upstream goes down (BTW, IPv6 did nothing sane for multihoming either).

> Are you taking about mDNS still referencing the withdrawn prefix?

That too.

> dhcpv6

Just skip DHCPV6, just use SLAAC. Plus I've never seen DHCP hostnames work.

Now I just ping ff02::1 multicast to see what devices are on my network. Unfortunately much software makes it a pain to use link-local addresses but they're really convenient as they normally don't change across networks.

> Half of the hosts don't implement prefix withdrawal, and keep both their ULAs and the normal addresses. Congrats, now these hosts can't talk to each other due to the ULA addresses being less preferred.

I've had similar issues with crappy devices not relinquishing DHCPv4 IPs properly. Always fun trying to figure out why your laptop is dropped off your network after 20 minutes because it honors DHCP.

The lack of proper prefix widthdrawl sucks. Though it's something software should be able to handle by preferring ULA addresses when communicating locally.

> ping ff02::1 multicast

Wasn't this disabled for IPv4 for being a security concern? See the Linux net.ipv4.icmp_echo_ignore_broadcasts sysctl.

I wonder if this will stay enabled for IPv6.

You know that dhcpv6 servers like odhcpd (Openwrt) implement hairpin NAT along with IPv6-PD right?

> Plus I've never seen DHCP hostnames work

Over half the workstations at my office use DHCP hostnames and they work just fine. In fact I'll say exactly the opposite: I've never seen DHCP hostnames not work.

> Now I just ping ff02::1 multicast to see what devices are on my network.

Yeah, you see a bunch of MACs and... what next? How do you get the names?

How would it help? The LAN traffic between hosts in that LAN does not go through the router.

> Now I just ping ff02::1 multicast to see what devices are on my network. Unfortunately much software makes it a pain to use link-local addresses but they're really convenient as they normally don't change across networks.

How does that help? I don't want a list of IPs, I want to reach my devices by name (which DHCP makes easy).

> Just skip DHCPV6, just use SLAAC. Plus I've never seen DHCP hostnames work.

Here's how a part of my IPv4 network looks in my router's control panel: https://imgur.com/a/xZDUfqw , I can easily set up permanent local IPv4 addresses for the fixed infrastructure, and I can easily see which hosts are alive.

Yes, it's not 100% perfect, but it works most of the time just fine. Even with crappy IoT devices.

Here's how it looks for IPv6 and SLAAC: https://imgur.com/a/DiUNqTC - good luck trying to make sense of it.

mDNS (formerly known as Bonjour and other things) uses multicast names to call devices by name on the local subnet. It works most of the time on most of the modern OSes.

I mean both are fairly complex tables. The ipv6 addresses are longer, but really I'd use hostnames in either case. Ipv4 includes the client id's, dhcp lease time, Mac addresses, etc.

I just wish routers had better / easier support for local DNS. Also a true tld reserved for internal network names would be awesome. Technically `.internal` is undefined.

That said, I do use ipv4 for easy local addresses just because local DNS is such a PITA to setup. Though I use ipv6 in my hosts file for setting reliable access to specific hosts where the ip doesn't change.

To be fair work is the wrong term, but more "used" as in be implemented and utilized.

> I'd use hostnames in either case

How? There is no way to associate hostnames with addresses in IPv6 that works unversally. Stateful IPv6 is _not_ _supported_ by Android, for example.

And since _each_ _device_ handles its own address selection, there's no central way to say "hey, this is an IP camera, let it have a static ::1:2:3:4 address suffix".

Moreover, with IPv6 I'm losing an ability to do quick checks of the network health.

> How? There is no way to associate hostnames with addresses in IPv6 that works unversally.

It looks like SLAAC and RDNSS is supported by most modern OSes, including android.

It’s definitely much more painful currently, but no reason you couldn’t have your router broadcast RDNSS. Then in your routers local DNS registry associate IP camera at ::aac::eda3::1 to ‘ip-camera-1.internal’. In theory about as easy as configuring device at Mac ‘de:fe:34:21:00’ is set to IP 10.0.0.5 and host name.

In practice granted it looks like a PITA right now. Searching google hardly yields helpful or easy tutorials on this stuff. Many home WiFi routers are pretty behind too. Though pi hole looks to have some support for this stuff.

I wish DNS options were easier or better for configuring for small networks.

IMHO IPv6 can be pretty nice but really needs saner defaults and better software support. No wonder IPv6 has taken so long.

Oh, interesting. My machines have not had good mDNS support, so I have been hardcoding ULAs for LAN-only traffic.

RDNSS is simply a DNS server name, it doesn't do anything for the reverse process (host-to-server registration).

> Then in your routers local DNS registry associate IP camera at ::aac::eda3::1 to ‘ip-camera-1.internal’. In theory about as easy as configuring device at Mac ‘de:fe:34:21:00’ is set to IP 10.0.0.5 and host name.

I don't see how it works. RDNSS is purely unidirectional and doesn't affect the assigned IPv6 addresses.