[unethical_ban]

Neat, I just finished getting acquainted with some IPv6 internals. Other than the long names and lack of DNS integration, it's really a great thing.

I've been meaning to mess with tailscale or similar, perhaps I'll take a look at this.

[simoncion]

> Other than ... lack of DNS integration...

I'm confused. What do you mean by this? Does dnsmasq not put the names of DHCPv6 clients into its hostname database? If ISC DHCPd is commanded to update DNS, does it only update for DHCP clients and not DHCPv6 clients?

[yosamino]

They probably mean that when using SLAAC - I guess the easiest way to get ipv6 connectivity - there is no equivalent to the way you can update DNS the way it would work with DHCPv4 or DHCPv6.

You pointed out one way - justuse DHCPv6, but that looses some of nice SLAAC properties.

A different way is to run mdns and let the devices announce their own hostnames.local.

Different tradeoffs, but in practice not too difficult to get to work.

I guess one could even do both...

[yjftsjthsd-h]

> You pointed out one way - justuse DHCPv6, but that looses some of nice SLAAC properties.

Android refuses to implement DHCPv6. So (if you have any Android devices in play) at best you can use DHCPv6 for some of your devices while still needing to also have SLAAC. And yes, mDNS might work, but that's another service (or two, right? One to resolve other devices, another to advertise this device) to run on every device, and you'd better hope that every device can run the needed services. Which... actually brings us back to Android; AFAICT, Android can resolve mDNS but doesn't show up itself. As someone who can and does SSH to my phone (termux), this is kind of a sticking point.

[simoncion]

> Android refuses to implement DHCPv6.

You should read [0]. It's... pretty amazing.

[0] <https://android-developers.googleblog.com/2025/09/simplifyin...>

[simoncion]

> They probably mean that when using SLAAC...

If that's the case, then you've got to think of SLAAC as operating exactly like IPv4 address autoconfiguration (sometimes called "IPv4LL")... except that you usually get globally-routable IP addresses out of it.

If you want the management niceties that you often get when using DHCP, then you have to use DHCP.

Some very loud purists might say "SLAAC is the only way to use IPv6!". I completely ignore the convenience of LAN-side prefix delegation and say two things:

1) "Good luck with telling your IPv6 clients about things like your preferred NTP server."

2) "For ages, Router Advertisements have had entirely independent 'autoconfigure your addresses', 'use stateful configuration for your "other" configuration' [0], and 'use stateful configuration for your addresses' bits. It's legal to have any number of them enabled. This is a deliberate choice by the folks defining IPv6."

In general, the folks who scream about how IPv6 NAT and DHCPv6 should not exist and should never be used should be ignored... at least about that topic.

[0] Things like NTP and DNS that other good stuff that DHCP can be used to tell hosts about.

[unethical_ban]

I mostly meant that DHCPv6 was an afterthought, and was complaining about the length of IPv6 addresses when they are truly random/EUI64. As a network guy who has had to write down or quickly type IP addresses down for troubleshooting thousands of times, v4 is much easier for humans to work with than a full v6.

(Oh and Android doesn't support DHCPv6 at all, but that doesn't matter much for server environments/DNS reachability).

In hindsight of EUI64 being shunned in favor of privacy addresses, plus how much of the IPv6 space is reserved for future use, I wonder if IPv6 could have achieved all of its goals with a 64 or 80 bit address instead of 128.

[simoncion]

> I mostly meant that DHCPv6 was an afterthought...

I'd call DHCPv6 "a recognition that a complete break from how IPv4 networks have been historically managed simply is not practical for many network operators... especially the larger ones".

And it's true that the DHCPv6 RFC (3315) was published in 2003; five years after the SLAAC RFC (2462). But it's also true that 2003 is twenty-three years from today. Regardless of how you feel about the five-year gap between 2462 and 3315, DHCPv6 has been available for nearly a quarter century. DHCPv6-PD (Prefix Delegation) is how every ISP that I've had that provided IPv6 service to my home [0] has provided globally-routable address space to my LAN. I assume that it's how it's done by most ISPs who don't want to have their customers deal with manually splitting up a wider-than-64 prefix onto their LAN.

But -like I said- I've only had experience with two US ISPs. Perhaps everyone else does it differently?

> Oh and Android doesn't support DHCPv6 at all...

Oh, but it does! And in the most useless way -for an ordinary end user- possible! It uses DHCPv6... but only for prefix delegation! [1]

It's almost as if the folks who make the decisions for the Android project have never used an Android device anywhere except for a Very Large Professionally-Managed Enterprise Network.

> In hindsight of EUI64 being shunned in favor of privacy addresses...

If by "privacy addresses", you mean the "periodically generate a new temporary address and use that for new outbound connections" thing, then I shun "privacy" addresses [2]... but I recognize that I may hold an minority opinion.

> ...plus how much of the IPv6 space is reserved for future use, I wonder if IPv6 could have achieved all of its goals with a 64 or 80 bit address instead of 128.

Sure, maybe. But -IMO- it's way better to have much too much address space than to have too little. Plus, if we ever manage to stop playing the "crab bucket" game and get our asses off of this rock, we might appreciate all the extra address space as we set up very long range networks connected by very high-latency links.

Somewhat related: I've read discussions from actually-informed folks who express the opinion -given our quarter-century of hindsight- it's pretty clear that (de facto because of SLAAC) reserving 64 of the address for the host part was quite a bit of a waste of address space. I wonder if they would have made the addresses 32 bits shorter if they'd reduced the host part by 32 bits.

[0] Granted, that's only two ISPs -Comcast and Monkeybrains-, but

1) Those two ISPs span like (fuck me to death, I'm old) quite a bit more than twenty years of personal ISP history

2) Comcast is either the or one of the largest ISPs in the US. They also -notably- run an all-IPv6 infrastructure network. I don't claim that they obviously know the right way to manage IPv6 networks, but I will claim that they have a lot of experience with it.

[1] <https://android-developers.googleblog.com/2025/09/simplifyin...>

[2] in part because of the wide spread of the "use a user-configurable DUID along with the IAID" mechanism for generation of the host part of the address (rather than relying on the interface's MAC address), and in part because there are eleven-zillion ways to track a World Wide Web user that have absolutely nothing to do with that user's IP address. IMO, all the "privacy" addresses add is complication.

[labcomputer]

> Things like NTP and DNS that other good stuff that DHCP can be used to tell hosts about.

Look up RFC 6106 (published 15 years ago). Router advertisements have carried DNS resolver info for a long time now.

Once again, the old adage “IPv6 haters don’t understand IPv6” applies.

As much as I would like hosts to use the local NTP server, most will ignore the NTP server you specify in DHCP anyway, so it’s kind of a moot point.

Edit: RFC 6016 actually supersedes RFC 5006 from 2007. That’s nearly two full decades we have had DNS info in RAs. That’s the year Itanium2 came out (any greybeards here old enough to remember that one?)

[simoncion]

> ...the old adage “IPv6 haters don’t understand IPv6” applies.

I'm an IPv6 hater. Sure. [0][1][2]

> ...RFC 6106...

Yes. I'm quite aware of the RDNSS field in RAs. In past experience from ten-ish years ago, [3] I found that it is unreliably recognized... some systems would use the data in it, and others would only ignore it. In contrast, DHCPv6 worked fine on everything I tested it on except for Android. Might this be because RFC 6106 was published in 2010, while RFC 3315 ("stateful" DHCPv6) was published in 2003, and RFC 3736 ("stateless" DHCPv6) was published in 2004? Maybe.

> ...RFC 6016 actually supersedes RFC 5006 from 2007.

An attentive reader notes that RFC 5006 is an experimental RFC. It took another four years for a non-experimental version of the standard to be published.

So, anyway. Yeah, I should have said

  Things like NTP and (sometimes) DNS and that other good stuff...

Whoops. But, my point stands... how do you communicate to clients the network's preferred NTP servers or nearly all of the other stuff that DHCPv6 communicates if one choses to use only SLAAC?

[0] <https://news.ycombinator.com/item?id=47565087>

[1] <https://news.ycombinator.com/item?id=47358229>

[2] <https://news.ycombinator.com/item?id=47101182>

[3] Perhaps things have gotten better in the intervening years? Should I find myself bored as hell one evening, I'll see what the state of device/OS support is.

[denkmoon]

What do you mean by lack of DNS integration?