Re: Why used DHCPv6 when RA has RDNSS and DNSSL?
> DHCPv6-PD works, and AFAIK it is implemented by every vendor wanting to > be taken seriously. > > HNCP probably works too. Time will tell, if/when it is actually > implemented at a scale making it possible to test it outside the lab. > > HNCP is currently irrelevant wrt end host addressing. It depends on > either DHCPv6 or SLAAC there. As one of the authors of DHCPv6 PD, I might be biased. But PD was analysed in detail for the homenet use case and was found wanting. It does not support multiple sources of information (think multihoming). Hierarchical PD does not deal with arbitrary topologies. Think having to implement a spanning tree with PD. HNCP is the IETF's answer to this. Considering how poorly hosts deal with multiple addresses, I'm not sure we have operational experience justifying pushing even more addresses to hosts (ref /64). If we want to discuss how to deal with multiple links, I always thought the idea of multilink subnet routing, with the same /64 crossing multiple links showed promise. Regardless I think experience has shown that the "anarchy" that SLAAC brings with it has operational issues. Forcing the use of DHCP for address assignment. Or requiring modifications to SLAAC, e.g. introduction of something like the ARO option. Cheers, Ole
Re: Why used DHCPv6 when RA has RDNSS and DNSSL?
> DHCPv6 took itself out of the running when it failed to provide the > default gateway to its clients. I just posted an updated version of what was the "Universal RA option" draft. It is now the "Universal IPv6 Configuration Option", which includes support for default gateway in DHCPv6. https://datatracker.ietf.org/doc/draft-troan-6man-universal-ra-option/?include_text=1 Best regards, Ole
Re: Linux and ULA support and default route
Holger, >>> Imagine a setup with *two* routers. One of them has broken Internet, >>> the other is working. How can the hosts decide if both keep announcing >>> themselves as "I can reach anything"? >> >> in the general case the host still has to take the 'I can reach anything' >> announcement with a pinch of salt. >> and it should be able to try both (or more) connections and react >> accordingly when one fails. > ...which is the default host behaviour if the OS supports RFC4861. > Sadly some "user friendly" network mangers breaks this and setting a > static route with a better metric to just one(!) router. not really. that only covers the first hop. any failure anywhere else along the path would not be dealt with by 4861. cheers, Ole
