On 31-Mar-20 23:17, Mark Tinka wrote: > > > On 31/Mar/20 12:09, [email protected] wrote: > >> Note that there have been multiple requests for DHCPv6 to do this but >> every attempt has been shot down. > > Yep - thankfully, we have an option. > > Operating two address assignment protocols is just silly. > > At my house, I don't even bother with DHCPv6 for DNS. I just use the > IPv4 ones and let SLAAC assign IPv6 addresses to my devices. Just about > done with the purist madness around this.
There's purism (which I don't understand) and there's also historical baggage that is incredibly hard to get rid of. As I have reminded from time to time, SLAAC was designed and implemented for IPv6 *before* DHCP became a proven technology for IPv4 (i.e. many of us were still running around manually assigning IPv4 addresses to newly installed Suns and NCDs and the like). DHCPv6 was an afterthought. Unfortunately, the purism has made it impossible to have a rational discussion about engineering our way out of this historical duplication. On 01-Apr-20 05:01, Gert Doering wrote: ... > As soon as you have a larger routed network, mDNS falls short, and > (unless you have a windows domain) there are no existing mechanisms > to put a SLAAC v6 address into DNS... I think there's no *deployed* mechanism. DynDNS is said to work in the lab. There's also some hope that DNS-SD will alleviate this problem, but only if it gets deployed. > Yes, thanks, IETF. Well done. It's not because nobody has tried. But the bridge between theory and operations seems to be hard to cross. On 01-Apr-20 07:21, James R Cutler wrote: ... > Wouldn’t it be more cost effect in the long term to simply make SLAAC and > DHCPv6 cooperative and complementary attributes of end-to-end networking? Well, duh. What we need is more people with real operational smarts able to spend a lot of time and patience in the IETF. Yes, I know why that is hard. (I had operation smarts once; no longer.) But that is the only way we we can get a pragmatic approach into RFC text. Don't worry about the travel budget, because the IETF is going to have to do much more of its work remotely for the next couple of years anyway. But the time and patience investment is substantial. Stay well, Brian Carpenter
