 other pieces of information to Router Advertisements). The desire, especially from DHCPv6 advocates, is to centrally provide all configuration from DHCPv6 servers. On the other hand, many were against mandating support of the DHCPv6 itself, which sometimes is considered as significant additional implementation effort. Especially mandating full DHCPv6 support just to provide bits of configuration information was seen as undesired. Partially due these discussions, a stateless variant of DHCPv6 emerged in the form of RFC 3736 [83], which allows implementation of only a minimal subset of DHCPv6 - essentially just INFORMATION-REQUEST and corre- sponding reply messages (Section 3.5.2). The DNS configuration options for DHCPv6 were standardized as early as 2003 [85]. However, the advocates for Router Advertise- ment based approach were very persistent, and managed to get Experimental RFC out in 2007, and evolved that into Standards Track RFC in 2010 [69]. The seven years between standards track RFCs has had an effect: hosts' and routers' support for a DHCPv6-based approach is more widespread than for the Router Advertisement-based approach. How- ever, as time passes, implementations will likely, and may have to, support both of these approaches. The DHCPv6 approach for RDNSS discovery was updated at 2012 with support for learning about RDNSSs that have special knowledge of some particular domain [86]. The new 'RDNSS Selection Option' communicates the IPv6 address of an RDNSS with a list of domains and network prefixes that the server has particular information about. With this information, a node can more wisely choose to which RDNSS it should send queries. This solution was developed for multi-interfaced use cases, where a node needs to decide which network interface to use for DNS queries. In addition to the abovementioned approaches, there was a proposal at November 2001 from Dave Thaler and Jun-ichiro itojun Hagino, which proposed a stateless approach and use of well-known site-local anycast addresses for DNS serve