RFC 4339

IPv6 Host Configuration of DNS Server Information Approaches

📅 published February 2006, from ietf

IPv6 Host Configuration of DNS Server Information Approaches 🎀

okay bestie, this is RFC 4339, and it's basically a "pick your favorite" guide for how IPv6 hosts find their DNS servers 💅

  • RFC number: 4339
  • Working group: Network Working Group
  • Written by: J. Jeong, Ed. (ETRI/University of Minnesota). Ed. just means editor 🧚
  • Category: Informational
  • Date: February 2006
  • Obsoletes / updates: the title block doesn't list anything this RFC obsoletes or updates 🙈

Status of This Memo

this memo is here to give the Internet community some info 📚. It doesn't specify an Internet standard of any kind, and distribution is unlimited 💖.

Copyright (C) The Internet Society (2006). 🌸

IESG Note

the IESG note is the important tea ☕. This document describes three different approaches for configuring DNS name resolution server info in IPv6 hosts.

There is not an IETF consensus on which approach is preferred. The analysis was written by the proponents of each approach, so it does not represent an IETF consensus. 🫶

The 'RA option' and 'Well-known anycast' approaches in this document are not standardized. That means the analysis for them might not be completely applicable to any specific proposal that comes up in the future 🔮

Abstract

so this document covers three ways IPv6 hosts can get their recursive DNS server addresses: the RA option, the DHCPv6 option, and well-known anycast addresses for recursive DNS servers ✨. It breaks down the operational attributes of each one.

It also suggests which deployment scenarios fit each approach across four kinds of networks: ISP, enterprise, 3GPP, and unmanaged networks, while thinking about using more than one solution at once 🌈

Table of Contents

1. Introduction ....................................................3
2. Terminology .....................................................3
3. IPv6 DNS Configuration Approaches ...............................3
   3.1. RA Option ..................................................3
        3.1.1. Advantages ..........................................4
        3.1.2. Disadvantages .......................................5
        3.1.3. Observations ........................................5
   3.2. DHCPv6 Option ..............................................6
        3.2.1. Advantages ..........................................7
        3.2.2. Disadvantages .......................................8
        3.2.3. Observations ........................................9
   3.3. Well-known Anycast Addresses ...............................9
        3.3.1. Advantages .........................................10
        3.3.2. Disadvantages ......................................10
        3.3.3. Observations .......................................10
4. Interworking among IPv6 DNS Configuration Approaches ...........11
5. Deployment Scenarios ...........................................12
   5.1. ISP Network ...............................................12
        5.1.1. RA Option Approach .................................13
        5.1.2. DHCPv6 Option Approach .............................13
        5.1.3. Well-known Anycast Addresses Approach ..............14
   5.2. Enterprise Network ........................................14
   5.3. 3GPP Network ..............................................15
        5.3.1. Currently Available Mechanisms and
               Recommendations ....................................15
        5.3.2. RA Extension .......................................16
        5.3.3. Stateless DHCPv6 ...................................16
        5.3.4. Well-known Addresses ...............................17
        5.3.5. Recommendations ....................................18
   5.4. Unmanaged Network .........................................18
        5.4.1. Case A: Gateway Does Not Provide IPv6 at All .......18
        5.4.2. Case B: A Dual-stack Gateway Connected to a
               Dual-stack ISP .....................................19
        5.4.3. Case C: A Dual-stack Gateway Connected to
               an IPv4-only ISP ...................................19
        5.4.4. Case D: A Gateway Connected to an IPv6-only ISP ....19
6. Security Considerations ........................................19
   6.1. RA Option .................................................20
   6.2. DHCPv6 Option .............................................21
   6.3. Well-known Anycast Addresses ..............................21
7. Contributors ...................................................21
8. Acknowledgements ...............................................23
9. References .....................................................23
   9.1. Normative References ......................................23
   9.2. Informative References ....................................23

1. Introduction ✨

okay so IPv6 Neighbor Discovery (ND) and IPv6 Stateless Address Autoconfiguration are how nodes, fixed or mobile, get one or more IPv6 addresses, default routes, and some other parameters [1][2]. 💫

But if you want to reach stuff on the Internet by DNS name, like a web server, you also need at least one recursive DNS server configured so name resolution actually works 🌸

This document walks through three ways an IPv6 host can get its recursive DNS server addresses: (a) the RA option [6], (b) the DHCPv6 option [3]-[5], and (c) well-known anycast addresses for recursive DNS servers [7]. It also suggests which scenarios each one fits across four kinds of networks: (a) ISP network, (b) enterprise network, (c) 3GPP network, and (d) unmanaged network 🦋

Here's the vibe check: this document is only an analysis of each possible approach. It does not recommend a particular approach or combination of approaches. Some approaches might not get adopted at all after more discussion 🤷‍♀️

So the goal of this document is simple. It helps you pick the approach that's right for configuring IPv6 hosts with recursive DNS servers 🎯

2. Terminology 📖

this document uses the terminology described in [1]-[7]. It also defines one new term:

  • Recursive DNS Server (RDNSS): a server that provides a recursive DNS resolution service. 🧚

3. IPv6 DNS Configuration Approaches 💅

in this section, we get into the operational attributes of all three solutions, in detail 🔍

3.1. RA Option 🌈

the RA approach defines a brand new ND option called the RDNSS option, which carries a recursive DNS server address [6]. It reuses the existing ND transport mechanisms, which are advertisements and solicitations. This is giving "how hosts already learn about routers and prefixes" energy, which is iconic 👑

An IPv6 host can configure the IPv6 addresses of one or more RDNSSes through RA messages. Those are either sent periodically by a router, or solicited by a Router Solicitation (RS) 📡

Now for the catch 👀 This approach needs the RDNSS info to be configured in the routers that do the advertising. An operator can set that up manually, or do it some other way, like automatic configuration through a DHCPv6 client running on the router. One RA message with one RDNSS option can include as many RDNSS addresses as needed [6] 💖

Through ND and the RDNSS option, plus a prefix information option, an IPv6 host can configure its IPv6 address and its RDNSS at the same time [1][2]. The RA option for RDNSS can be used on any network that supports ND. Literally so flexible 🫶

The RA approach is useful in some mobile environments where RDNSS addresses keep changing. That's because the RA option has a lifetime field, which lets clients use RDNSSes that are closer to them. It can be set to a value that makes the client time out the entry and switch to another RDNSS address [6]. ⏱️

BUT, from an implementation point of view, the lifetime field makes things a bit more complex 😭 Instead of just writing the list of RDNSS addresses to a DNS configuration file like resolv.conf, you need a daemon running around (or a program that gets called at defined intervals) that keeps watching the lifetime of the RDNSSes all the time. Not me having to babysit a daemon 💀

Last thing for this part: the preference value of an RDNSS, which lives in the RDNSS option, lets IPv6 hosts pick a primary RDNSS out of several. This can be used for load balancing across RDNSSes 🍓

3.1.1. Advantages ✨

the RA option for RDNSS has a bunch of advantages, including:

  1. The RA option is an extension of the existing ND/Autoconfig mechanisms [1][2], and it does not require a change to the base ND protocol. 🎀
  2. This approach works well on a variety of link types, just like ND does. That includes point-to-point links, point-to-multipoint, and multipoint-to-multipoint links (i.e., Ethernet LANs). RFC 2461 [1] does say, though, that there may be some link types where ND isn't feasible. On those links, some other mechanism will be needed for DNS configuration 🦋
  3. All the info a host needs to run basic Internet apps (like email, web, ftp, and so on) can come from adding this one option to ND and address autoconfiguration. Using one mechanism is more reliable and easier to provide than learning RDNSS info through another protocol mechanism. Debugging gets harder and way more complex when you're juggling multiple protocol mechanisms 🫠
  4. This mechanism works across a broad range of scenarios because it leans on IPv6 ND. It works well on high-performance links (e.g., Ethernet LANs) and low-performance links (e.g., cellular networks). On the low-performance side, combining the RDNSS info with the other info in the RA means the host can learn everything it needs to use most Internet apps, like the web, in a single packet. That saves bandwidth AND cuts down the delay in learning the RDNSS info 🚀
  5. The RA approach could be used as a model for similar kinds of configuration info. New RA options for other server addresses, like an NTP server address that's common to all clients on a subnet, would be easy to define 🧚

3.1.2. Disadvantages 🙈

  1. ND is mostly implemented in the kernel of the operating system. So if ND supports configuring extra services like DNS servers, ND should be extended in the kernel and paired with a user-land process. DHCPv6, on the other hand, has more flexibility for extending service discovery, because it's an application layer protocol 🌸
  2. The current ND framework should be modified to make it easier to synchronize the RDNSS cache that ND keeps in kernel space with the DNS configuration file in user space. Writing to and rewriting the DNS configuration file (e.g., resolv.conf) from the kernel is unacceptable, so another approach is needed. One simple fix is a daemon that listens to what the kernel conveys and does those steps. But that kind of daemon isn't needed with the current ND framework 💀
  3. RDNSS addresses have to be configured at least at one router on every link where this info needs to be set up through the RA option 🔧

part 1 of 6 wraps here, but the good stuff keeps coming, bestie 🫶💖

3.1.3. Observations ✨

okay so the proposed RDNSS RA option, together with IPv6 ND and Autoconfiguration, lets a host grab everything it needs to use basic Internet stuff like the web, email, ftp, etc. 💻 this is the move wherever hosts use RAs to autoconfigure their addresses and every host on the subnet shares the same router and server addresses 🫶 if the config info can come from one single mechanism, that's preferable because it adds no extra delay and uses the minimum amount of bandwidth. 🦋 the vibe of environments like this is homes, public cellular networks, and enterprise environments where no per-host config is needed. iconic, no notes 💅

DHCPv6 is preferable where it's being used for address configuration AND there's a need for host-specific configuration [3]-[5]. 🎀 these are most likely to be enterprise environments where the local admin chooses to have per-host configuration control. ngl that's giving very "I run the whole building" energy 👑

3.2. DHCPv6 Option 🌸

okay bestie, DHCPv6 [3] includes the "DNS Recursive Name Server" option, which is how a host can grab a list of IP addresses of recursive DNS servers [5]. 🧚 this option carries a list of IPv6 addresses of RDNSSes that the host MAY send DNS queries to. the DNS servers are listed in order of preference for use by the DNS resolver on the host. (so the first one is literally the main character 👑)

the DNS Recursive Name Server option can be carried in any DHCPv6 Reply message, in response to either a Request or an Information request message 💜 so it can be used when DHCPv6 is handling address assignment, OR when DHCPv6 is only doing the other config stuff as stateless DHCPv6 [4]. it's giving flexibility, periodt ✨

stateless DHCPv6 can be deployed using DHCPv6 servers running on general-purpose computers, or on router hardware 🍓 several router vendors currently implement stateless DHCPv6 servers. the perk of deploying it in routers is that no special hardware is required, and it should work well for networks where DHCPv6 is needed for very straightforward config of network devices. simple and iconic 🦋

BUT routers can also act as DHCPv6 relay agents 🙈 in that case the DHCPv6 server doesn't have to live on the router; it can be on a general-purpose computer. this has the potential to give the operator of the DHCPv6 server more flexibility in how it responds to individual clients, who can easily be given different config info based on their identity or for any other reason. nothing stops adding this flexibility to a router, but generally, in current practice, DHCP servers on general-purpose hosts tend to have more config options than the ones embedded in routers. so the bigger computer wins the config buffet 🍰

DHCPv6 currently provides a mechanism for reconfiguring DHCPv6 clients that use stateful configuration assignment 💖 to do this, the DHCPv6 server sends a Reconfigure message to the client. the client validates the Reconfigure message, and then contacts the DHCPv6 server to get updated config info. by using this mechanism, it's currently possible to propagate new config info to DHCPv6 clients as it changes. it's literally a group chat update push ✨

the DHC Working Group has standardized an additional mechanism through which config info, including the list of RDNSSes, can be updated 🌈 the lifetime option for DHCPv6 [8] assigns a lifetime to config info obtained through DHCPv6. when the lifetime expires, the host contacts the DHCPv6 server to get updated config info, including the list of RDNSSes. this lifetime gives the network admin another way to configure hosts with new RDNSSes, by controlling the time at which the host refreshes the list. the admin is literally the DJ of the refresh schedule 🎧

the DHC Working Group has also discussed defining an extension to DHCPv6 that would allow multicast to provide config info to multiple hosts with a single DHCPv6 message 🔥 because of the lack of deployment experience, the WG has deferred consideration of multicast DHCPv6 configuration for now. experience with DHCPv4 hasn't identified a requirement for multicast message delivery, even in large service provider networks with tens of thousands of hosts that may start a DHCPv4 message exchange at the same time. the real-world proof is wild 😭

3.2.1. Advantages 🎀

the DHCPv6 option for RDNSS has a bunch of advantages, bestie. these include:

  1. DHCPv6 currently provides a general mechanism for sending network config info to clients. configuring DHCPv6 servers this way lets the network admin configure RDNSSes, the addresses of other network services, and location-specific info like time zones. ✨
  2. as a result, when the admin goes to configure DHCPv6, all the config info can be managed through a single service, typically with a single user interface and a single config database. one place, zero chaos 💅
  3. DHCPv6 allows host-specific config, so hosts on the same link can be configured with different RDNSSes and other config info. that's main character energy for every device 👑
  4. there's a mechanism for extending DHCPv6 to support sending additional config that hasn't been anticipated yet. future-proof era 🔮
  5. hosts that need other config info, like the addresses of SIP servers and NTP servers, are likely to need DHCPv6 for that other config anyway. so it's a package deal 🫶
  6. the spec for configuring RDNSSes through DHCPv6 is available as an RFC. no new protocol extensions (such as new options) are necessary. zero new homework 📚
  7. interoperability among independent implementations has been demonstrated. the different implementations actually get along, which is so rare and so iconic 🌸

3.2.2. Disadvantages 🙈

the DHCPv6 option for RDNSS has a few disadvantages, ngl. these include:

  1. updates currently require a message from the server (however, see [8]). 😭
  2. because DNS info is not contained in RA messages, the host must receive two messages from the router and must transmit at least one message to the router. on networks where bandwidth is at a premium, this is a disadvantage, although on most networks it's not a practical concern. lowkey not a big deal for most people 💜
  3. there's increased latency for initial configuration. in addition to waiting for an RA message, the client now has to exchange packets with a DHCPv6 server. even if it's installed locally on a router, this will slightly extend the time required to configure the client. for clients that are moving rapidly from one network to another, this will be a disadvantage. the fast-moving clients are NOT going to be happy about this 💀

3.2.3. Observations 🦋

in the general case, on general-purpose networks, stateless DHCPv6 provides significant advantages and no significant disadvantages. ✨ even when bandwidth is at a premium and low latency is desired, if hosts need other config info in addition to a list of RDNSSes, or if hosts must be configured selectively, those hosts will use DHCPv6, and using the DHCPv6 DNS recursive name server option will be advantageous. it all works out 🫶

however, we're aware of some applications where it would be preferable to put the RDNSS info into an RA packet 🧚 for example, in a mobile phone network, where bandwidth is at a premium and extremely low latency is desired. the DNS config based on RA should be standardized so these special applications can be handled using DNS info in the RA packet. the special-case squad deserves their moment 🌈

3.3. Well-known Anycast Addresses 💖

okay so anycast uses the same routing system as unicast [9]. however, the administrative entities are local ones. the local entities may accept unicast routes (including default routes) to anycast servers from adjacent entities. the administrative entities should not advertise their peer routes to their internal anycast servers, if they want to prohibit external access from some peers to the servers. if some advertisement is inevitable (such as with default routes), the packets to the servers should be blocked at the boundary of the entities. thus, for this anycast, not only unicast routing but also unicast ND protocols can be used as is. 🔒 the boundary rules are giving protective older sibling energy 🫶

first of all, the well-known anycast addresses approach is very different from what the IPv6 Working Group discussed in the past [7]. note that "anycast" in this memo is simpler than the version in RFC 1546 [9] and RFC 3513 [10], where it's assumed to be prohibited to have multiple servers on a single link sharing an anycast address. that means on a link, an anycast address is assumed to be unique. DNS clients today already have redundancy by having multiple well-known anycast addresses configured as RDNSS addresses. there's no point in having multiple RDNSSes sharing an anycast address on a single link. simplify, simplify 🍓

the approach with well-known anycast addresses is to set multiple well-known anycast addresses in clients' resolver config files from the beginning as, say, a factory default. thus, there's no transport mechanism and no packet format [7]. 🎁 no handshake, no drama 💅

an anycast address is an address shared by multiple servers (in this case, the servers are RDNSSes). a request from a client to the anycast address is routed to a server selected by the routing system. however, it is a bad idea to mandate a "site" boundary on anycast addresses, because most users don't have their own servers and want to reach their ISPs across their site boundaries. larger sites may also depend on their ISPs, or may have their own RDNSSes within "site" boundaries. the "site" wall is a no-go, bestie 🚫

3.3.1. Advantages 🌸

the basic advantage of the well-known addresses approach is that it uses no transport mechanism. thus, the following apply:

  1. there's no delay to get the response and no further delay from packet losses. ⚡
  2. the approach can be combined with any other configuration mechanisms, such as the RA-based approach and the DHCP-based approach, as well as the factory default configuration. mix and match, it's giving buffet ✨
  3. the approach works over any environment where DNS works. literally everywhere DNS lives 🌍

another advantage is that this approach only needs configuration of the DNS servers as a router (or configuration of a proxy router). considering that DNS servers do need configuration, the amount of overall configuration effort is proportional to the number of DNS servers, and it scales linearly. 📈 and in the simplest case, where a subscriber to an ISP doesn't have a DNS server, the subscriber naturally accesses the ISP's DNS servers, even though the subscriber and the ISP do nothing and there's no protocol to exchange DNS server info between them. zero effort, full access, the ultimate low-key flex 😌

3.3.2. Disadvantages 💀

the well-known anycast addresses approach requires that DNS servers (or routers near them, as a proxy) act as routers to advertise their anycast addresses to the routing system. this requires some configuration (see the last paragraph of the previous section on the scalability of the effort). 🧐 in addition, routers at the boundary of the "site" might need route filters configured to prevent providing DNS services for parties outside the "site", and to guard against the possibility of denial of service attacks on the internal DNS infrastructure. 🚨 that's the one tradeoff we can't ignore, bestie. stay safe out there 🫶

3.3.3. Observations

okay so if other approaches are used alongside this one, the well-known anycast addresses should also be set in RA or DHCP configuration files 🧚 that way users have way less setup to do ✨

the redundancy part is so important bestie 💅 having multiple RDNSSes is better when each server has its own anycast address, instead of several servers all sharing the same one. the reason is that with the shared version, stale servers can keep generating routes to that anycast address 💀 so in a routing domain (or domains sharing DNS servers), there will be only one server with an anycast address, unless the domain is so big that load distribution is necessary 🫶

small ISPs will run one RDNSS at each anycast address, and that address is shared by all the subscribers 🎀 large ISPs can run multiple RDNSSes at each anycast address to spread out and reduce load. the boundary between those RDNSSes may be fixed (redundancy is still provided by multiple addresses) or it may change dynamically 🦋 DNS packets with the well-known anycast addresses are not expected (though not prohibited) to cross ISP boundaries, because ISPs are expected to be able to take care of themselves 💖

the anycast stuff here is lowkey simpler than RFC 1546 [9] and RFC 3513 [10]. those docs assume it's administratively prohibited to have multiple servers on a single link sharing an anycast address 👀 so in this memo, anycast should be implemented as UNICAST of RFC 2461 [1] and RFC 3513 [10]. as a result, ND-related instability disappears ✨ so in the well-known anycast addresses approach, anycast can and should use the anycast address as a source unicast (according to RFC 3513 [10]) address of packets of UDP and TCP responses 🌈

with TCP, if a route flips and packets to an anycast address get routed to a new server, it's expected that the flip is detected by ICMP or sequence number inconsistency, and that the TCP connection is reset and retried 😭

4. Interworking among IPv6 DNS Configuration Approaches ✨

three approaches can work together for IPv6 host configuration of RDNSS 🌸 this section looks at how these approaches can interwork, so get comfy 🧚

for ordering between the RA and DHCP approaches, the O (Other stateful configuration) flag in the RA message can be used [6][28]. if no RDNSS option is included, an IPv6 host may perform DNS configuration through DHCPv6 [3]-[5] regardless of whether the O flag is set or not 💅

the well-known anycast addresses approach fully interworks with the other approaches 🫶 that means the other approaches can cut down on server configuration by using the well-known addresses as the default configuration. the clients preconfigured with the well-known anycast addresses can also be further configured to use other approaches to override those addresses, if configuration info from the other approaches is available 💜 otherwise, all the clients need to have the well-known anycast addresses preconfigured 😬 to use the anycast approach along with the two other approaches, there are three choices:

  1. the first choice is that well-known addresses are used as last resort, when an IPv6 host can't get RDNSS info through RA and DHCP. the well-known anycast addresses have to be preconfigured in all of the IPv6 hosts' resolver configuration files 🔥
  2. the second is that an IPv6 host can configure well-known addresses as the most preferable in its configuration file, even though either an RA option or a DHCP option is available 👑
  3. the last is that the well-known anycast addresses can be set in RA or DHCP configuration to reduce the configuration effort of users. according to either the RA or DHCP mechanism, the well-known addresses can be obtained by an IPv6 host. because this approach is the most convenient for users, the last option is recommended 🎀
Note: This section does not necessarily mean that this document suggests adopting all of these three approaches and making them interwork in the way described here. In fact, as a result of further discussion some approaches may not even be adopted at all. 🙈

5. Deployment Scenarios 🌈

regarding DNS configuration on the IPv6 host, the DNSOP Working Group is considering several mechanisms, such as the RA option, the DHCPv6 option, and well-known preconfigured anycast addresses, as of today. this document is a final result from that long thread 🧵 in this section, we suggest four applicable scenarios of those three approaches for IPv6 DNS configuration ✨

Note: In the applicable scenarios, authors do not implicitly push any specific approaches into the restricted environments. No enforcement is in each scenario, and all mentioned scenarios are probable. The main objective of this work is to provide a useful guideline for IPv6 DNS configuration. 💖

5.1. ISP Network 🌸

a characteristic of an ISP network is that multiple Customer Premises Equipment (CPE) devices are connected to IPv6 PE (Provider Edge) routers, and each PE connects multiple CPE devices to the backbone network infrastructure [11]. the CPEs may be hosts or routers 🏠

if the CPE is a router, there is a customer network connected to the ISP backbone through the CPE. typically, each customer network gets a different IPv6 prefix from an IPv6 PE router, but the same RDNSS configuration will be distributed 🦋

this section discusses how the different approaches to distributing DNS information compare in an ISP network 👀

5.1.1. RA Option Approach 💫

when the CPE is a host, the RA option for RDNSS can be used so the CPE gets RDNSS information and a /64 prefix for stateless address autoconfiguration at the same time, as soon as the host is attached to a new subnet [6]. because an IPv6 host must receive at least one RA message for stateless address autoconfiguration and router configuration, the host can receive RDNSS configuration information in the RA without the overhead of an additional message exchange 🚀

when the CPE is a router, the CPE may accept the RDNSS information from the RA on the interface connected to the ISP, and copy that information into the RAs advertised in the customer network 🎁

this approach is more valuable in the mobile host scenario, where the host must receive at least an RA message for detecting a new network, than it is in other scenarios generally. the administrator should still configure RDNSS information on the routers, though 🛠️ Secure ND [12] can provide extended security when RA messages are used 🔐

5.1.2. DHCPv6 Option Approach 📮

DHCPv6 can be used for RDNSS configuration through the DNS option, and it can provide other configuration information in the same message with RDNSS configuration [3]-[5]. the DHCPv6 DNS option is already in place for DHCPv6, as RFC 3646 [5] describes, and DHCPv6-lite or stateless DHCP [4] is not nearly as complex as a full DHCPv6 implementation 🙌 DHCP is a client-server model protocol, so ISPs can handle user identification on their network intentionally. also, authenticated DHCP [13] can be used for secure message exchange 🔒

the expected model for deploying IPv6 service by ISPs is to assign a prefix to each customer, which the customer gateway uses to assign a /64 prefix to each network in the customer's network 🏘️ Prefix delegation with DHCP (DHCPv6 PD) has already been adopted by ISPs for automating the assignment of the customer prefix to the customer gateway [15]. DNS configuration can be carried in the same DHCPv6 message exchange used for DHCPv6, which delivers that information efficiently along with any other configuration information needed by the customer gateway or customer network 📦 this service model can be useful to Home or SOHO subscribers 🍓 the Home or SOHO gateway, which is a customer gateway for the ISP, can then pass that RDNSS configuration information to the hosts in the customer network through DHCP 💌

5.1.3. Well-known Anycast Addresses Approach 🪄

the well-known anycast addresses approach is also a feasible and simple mechanism for ISPs [7] ✨ using well-known anycast addresses avoids some of the security risks of rogue messages sent through an external protocol such as RA or DHCPv6 🛡️ configuring hosts to use well-known anycast addresses requires no protocol or manual configuration, but configuring routing for the anycast addresses does require intervention from the network administrator 🧑‍💻 also, the number of special addresses would be equal to the number of RDNSSes that could be made available to subscribers 🔢

5.2. Enterprise Network 🏢

an enterprise network is defined as a network that has multiple internal links, one or more router connections to one or more providers, and that is actively managed by a network operations entity [14] 💼 an enterprise network can get network prefixes from an ISP by either manual configuration or prefix delegation [15]. in most cases, because an enterprise network manages its own DNS domains, it operates its own DNS servers for those domains 🗂️ these DNS servers within enterprise networks process recursive DNS name resolution requests from IPv6 hosts as RDNSSes 🧠 the RDNSS configuration in the enterprise network can be performed as it is in Section 4, where three approaches can be used together as follows:

  1. an IPv6 host can decide which approach is or may be used in its subnet with the O flag in the RA message [6][28]. as the first choice in Section 4, well-known anycast addresses can be used as a last resort when RDNSS information cannot be obtained through either an RA option or a DHCP option. this case needs IPv6 hosts to preconfigure the well-known anycast addresses in their DNS configuration files 🫠
  2. when the enterprise prefers the well-known anycast approach to the others, IPv6 hosts should preconfigure the well-known anycast addresses, as in the first choice 🎯
  3. the last choice is a more convenient and transparent way. it doesn't need IPv6 hosts to preconfigure the well-known anycast addresses, because the addresses are delivered to IPv6 hosts via either the RA option or the DHCPv6 option, as if they were unicast addresses. this way is most recommended for the sake of the user's convenience 💖🫶

5.3. 3GPP Network 📱

Okay so the IPv6 DNS config is basically the missing piece of IPv6 autoconfiguration 😭 and it's a super important part of basic IPv6 functionality in 3GPP User Equipment (UE). The big-picture 3GPP architecture is described in [16], and moving 3GPP networks over to IPv6 is analyzed in [17] and [18]. 🌸

Here's the vibe: in 3GPP there's a dedicated link between the UE and the GGSN called the Packet Data Protocol (PDP) Context. It gets created through the PDP Context activation procedure [19]. IPv4 and IPv6 traffic each get their own PDP context type ✨. If a UE user is talking IPv6 (aka they have an active IPv6 PDP context), you can't assume they also have an active IPv4 PDP context at the same time, so DNS queries could be going over IPv4. 🙈 So a 3GPP UE can be an IPv6 node, and it still needs some way to find its RDNSS address. Before any IP-based services (like web browsing or email) can work, the IPv6 (and IPv4) RDNSS addresses have to be discovered in the 3GPP UE. Not optional, bestie 💅

Section 5.3.1 gives a quick rundown of the mechanisms currently available in 3GPP networks, plus recommendations 🎀. Section 5.3.2 analyzes the Router Advertisement-based solution, Section 5.3.3 analyzes the Stateless DHCPv6 mechanism, and Section 5.3.4 analyzes the well-known addresses approach. Section 5.3.5 wraps everything up with the recommendations. 💜

5.3.1. Currently Available Mechanisms and Recommendations 🧚

3GPP has defined a mechanism where RDNSS addresses can be received during PDP context activation (that's a control plane mechanism). It's called the Protocol Configuration Options Information Element (PCO-IE) mechanism [20]. The RDNSS addresses can also be received over the air (using text messages) or typed in manually on the UE. Note that those last two are not very well scalable 🙃 The UE user most probably does not want to type IPv6 RDNSS addresses in manually, honestly who would. The use of well-known addresses is briefly discussed in Section 5.3.4.

So yeah, the mechanisms above most probably aren't sufficient for the 3GPP environment 😬 IPv6 is meant to operate in a zero-configuration manner, no matter what the underlying network infrastructure is. Typically the RDNSS address is needed to make an IPv6 node operational, so the DNS configuration should be as simple as the address autoconfiguration mechanism. Also, some near-future 3GPP UEs will have additional IP interfaces, and 3GPP-specific DNS configuration mechanisms (such as PCO-IE [20]) don't work for those interfaces. So a good IPv6 DNS configuration mechanism should also work in a multi-access network environment 🌈

From a 3GPP point of view, the best IPv6 DNS configuration solution is feasible for a huge number of IPv6-capable UEs (we're talking hundreds of millions in one operator's network!). It's automatic, so it requires no user action ✨ The suggestion is to standardize a lightweight, stateless mechanism that works in all network environments. That way it could be used for 3GPP, 3GPP2, and other access network technologies. So not only is a light, stateless IPv6 DNS configuration mechanism needed in 3GPP networks, 3GPP networks and UEs would also seriously benefit from it 🔥

5.3.2. RA Extension 🦋

The Router Advertisement extension [6] is a lightweight IPv6 DNS configuration mechanism. It needs minor changes to the 3GPP UE IPv6 stack and the Gateway GPRS Support Node (GGSN, which is the default router in the 3GPP architecture) IPv6 stack. This solution can be specified in the IETF (no action is needed in 3GPP) and then put into use in 3GPP UEs and GGSNs. Efficient, iconic 👑

Here's how it goes: an IPv6-capable UE configures its DNS info through an RA message sent by its default router (the GGSN). In other words, the RDNSS option for a recursive DNS server is included in the RA message. This is easily scalable for a massive number of UEs 💅 The operator can configure the RDNSS addresses on the GGSN as part of the normal GGSN configuration. The IPv6 RDNSS address gets received in the Router Advertisement, so an extra Round Trip Time (RTT) for asking for RDNSS addresses can be avoided. Main character energy 🌸

Now the cons 😭 This mechanism still needs standardization effort in the IETF, and the end nodes and routers need to support it. Still, the equipment software update should be pretty straightforward, and new IPv6 equipment could support the RA extension from day one ✨

5.3.3. Stateless DHCPv6 🎀

A DHCPv6-based solution needs Stateless DHCP [4] and DHCPv6 DNS options [5] implemented in the UE, plus a DHCPv6 server in the operator's network. One possible setup is for the GGSN to work as a DHCP relay 🧚

The pros of a stateless DHCPv6-based solution are:

  1. Stateless DHCPv6 is a standardized mechanism.
  2. DHCPv6 can be used to receive configuration information other than RDNSS addresses; e.g., SIP server addresses.
  3. DHCPv6 works in different network environments.
  4. When DHCPv6 service is deployed through a single, centralized server, the RDNSS configuration information can be updated by the network administrator at a single source. 🫶

Some issues with DHCPv6 in 3GPP networks are listed below 💀

  1. DHCPv6 requires an additional server in the network, unless the (Stateless) DHCPv6 functionality is integrated into an existing router. That means there might be one more server to maintain.
  2. DHCPv6 isn't necessarily needed for 3GPP UE IPv6 addressing (3GPP Stateless Address Autoconfiguration is typically used), and it isn't automatically implemented in 3GPP IPv6 UEs.
  3. Scalability and reliability of DHCPv6 in very large 3GPP networks (with tens or hundreds of millions of UEs) may be an issue. At the very least, redundancy needs to be taken care of. However, if the DHCPv6 service is integrated into network elements, such as a router operating system, then scalability and reliability are comparable with other DNS configuration approaches. ✨
  4. It's sub-optimal to use radio resources in 3GPP networks for DHCPv6 messages if a simpler alternative is available. 🙈
    • The use of stateless DHCPv6 adds one round-trip delay to the case where the UE could start transmitting data right after the Router Advertisement.
  5. If the DNS information (suddenly) changes, Stateless DHCPv6 can't automatically update the UE; see [21]. 😩

5.3.4. Well-known Addresses 🌈

Using well-known addresses is also a feasible and light mechanism for 3GPP UEs 💖 Those addresses can be preconfigured in the UE software, and the operator can make the matching configuration on the network side. So it's a super easy mechanism for the UE, but it does require some configuration work in the network. When using well-known addresses, the UE forwards queries to any of the preconfigured addresses. In the current proposal [7], IPv6 anycast addresses are suggested 🦋

Note: An IPv6 DNS configuration proposal based on well-known site-local addresses was developed by the IPv6 Working Group 🥹 It was seen as a feasible mechanism for 3GPP UEs, although no IETF consensus was reached on it. In the end, the deprecation of IPv6 site-local addresses made it impossible to standardize a mechanism that uses site-local addresses as well-known addresses. Still, as of this writing, the mechanism is implemented in some operating systems and 3GPP UEs as a last resort for IPv6 DNS configuration. Tragic, but iconic 💀

5.3.5. Recommendations 💜

It's suggested that a lightweight, stateless DNS configuration mechanism be specified as soon as possible ⭐ From a 3GPP UE and network point of view, the Router Advertisement-based mechanism looks the most promising 👑 The sooner a light, stateless mechanism gets specified, the sooner we can stop using well-known site-local addresses for IPv6 DNS configuration. Let's go, bestie 🫶

5.4. Unmanaged Network 🍓

There are four deployment scenarios of interest in unmanaged networks [22]:

  1. A gateway that does not provide IPv6 at all,
  2. A dual-stack gateway connected to a dual-stack ISP,
  3. A dual-stack gateway connected to an IPv4-only ISP, and
  4. A gateway connected to an IPv6-only ISP.

5.4.1. Case A: Gateway Does Not Provide IPv6 at All 🚫

In this case the gateway doesn't provide IPv6, and the ISP may or may not provide it. Automatic or Configured tunnels are the recommended transition mechanisms for this scenario ✨

The case where dual-stack hosts behind a NAT need access to an IPv6 RDNSS can't be entirely ruled out 👀 The DNS configuration mechanism has to work over the tunnel, and the underlying tunneling mechanism could implement NAT traversal. The tunnel server takes on the role of a relay (for both the DHCP and well-known anycast addresses approaches) 🧚

The RA-based mechanism is relatively straightforward in its operation, assuming the tunnel server is also the IPv6 router emitting RAs 💅 The well-known anycast addresses approach also seems simple to operate across the tunnel, but the deployment model using well-known anycast addresses in a tunneled environment is unclear or not well understood 🙈

5.4.2. Case B: A Dual-stack Gateway Connected to a Dual-stack ISP 🏠

This is similar to a typical IPv4 home user scenario, where DNS configuration parameters are obtained using DHCP. The exception is that Stateless DHCPv6 is used, as opposed to the IPv4 scenario, where the DHCP server is stateful (it maintains state for clients) 🌸

5.4.3. Case C: A Dual-stack Gateway Connected to an IPv4-only ISP 🌉

This is similar to Case B. If a gateway provides IPv6 connectivity by managing tunnels, then it's also supposed to provide access to an RDNSS. Like this, the tunnel for IPv6 connectivity originates from the dual-stack gateway instead of from the host 🦋

5.4.4. Case D: A Gateway Connected to an IPv6-only ISP ✨

This is similar to Case B 💖

6. Security Considerations 🔐

okay bestie, so security requirements depend entirely on the application, and they vary from app to app 💅. That means there's no generic requirement for DNS at the IP layer or the application layer. Not one. Every app gets to decide for itself.

⚠️ cryptographic security needs configured secret information, and full autoconfiguration and cryptographic security are mutually exclusive. People who insist on secure, full autoconfiguration will end up with false security, false autoconfiguration, or both. 😭

In some deployment scenarios [17], cryptographic security is required for applications. The secret information for that is preconfigured, and application-specific configuration data (including DNS data) can be securely configured through it 🔑. Here's the catch: if an application that needs cryptographic security depends on DNS, then that application also needs cryptographic security to DNS. So full autoconfiguration of DNS is not acceptable in that case 🙅‍♀️.

That said, with full autoconfiguration, weaker but still reasonable security is already being widely accepted, and it will keep being acceptable ✨.

Here's the logic. With full autoconfiguration there's no cryptographic security for the autoconfiguration itself, so it's already assumed that the local environment is secure enough that the information from the local autoconfiguration server has acceptable security even without cryptographic security. From there, the communication between the local DNS client and the local DNS server also has acceptable security 🫶.

When you're autoconfiguring recursive servers, DNSSEC may be overkill 🙈. DNSSEC [23]-[25] needs clients to be configured and reconfigured at root key roll-over [26][27]. Even if extra keys for secure key roll-over are added during initial configuration, they're just as vulnerable as the original keys to some forms of attack, like social hacking. Another issue with combining DNSSEC and autoconfiguration is that DNSSEC requires secure time. Secure time means secure communication with autoconfigured time servers, and that requires configured secret information. So, for the autoconfiguration to be secure, configured secret information is required anyway 🔁.

If DNSSEC [23]-[25] is used and the signatures are verified on the client host, a misconfigured DNS server may simply cause denial of service. Also, if the local routing environment isn't reliable, clients may be pointed at a false resolver that has the same IP address as the true one 😬.

6.1. RA Option 📡

The security of the RA option for RDNSS is the same as the security of the ND protocol [1][6]. The RA option doesn't add any new vulnerability 🙌.

Here's the tea ☕. The vulnerability of ND isn't worse, and it's a subset of the attacks that any node attached to a LAN can pull off no matter what ND does. A malicious node on a LAN can promiscuously receive packets meant for any router's MAC address, and it can send packets with the router's MAC address as the source MAC address in the L2 header. As a result, the L2 switches send packets addressed to the router over to the malicious node. This attack can also send redirects that tell hosts to send their traffic somewhere else. The malicious node can send unsolicited RA or NA replies, answer RS or NS requests, and so on. All of this is possible whether or not ND is implemented. So the RA option for RDNSS doesn't add to the vulnerability 💅.

Security issues with the ND protocol were discussed by the IETF SEND (Securing Neighbor Discovery) Working Group, and RFC 3971 for ND security has been published [12] 📚.

6.2. DHCPv6 Option 🎀

The DNS Recursive Name Server option can be used by an intruder DHCP server to make DHCP clients send DNS queries to an intruder DNS recursive name server [5]. The results of those misdirected queries can then be used to spoof DNS names 👀.

To avoid attacks through the DNS Recursive Name Server option, the DHCP client SHOULD require DHCP authentication (see "Authentication of DHCP messages" in RFC 3315 [3][13]) before it installs a list of DNS recursive name servers obtained through authenticated DHCP 🔒.

6.3. Well-known Anycast Addresses 🌐

The well-known anycast addresses approach isn't a protocol, so there's no need to secure the protocol itself 🧚.

Still, denial of service attacks on the DNS resolver system might be easier to pull off, because the anycast addresses being used are, by definition, well known 😭.

7. Contributors 🌸

Here are the lovely people who contributed to this document 💜.

Ralph Droms
Cisco Systems, Inc.
1414 Massachusetts Ave.
Boxboro, MA  01719
US

Phone: +1 978 936 1674
EMail: rdroms@cisco.com


Robert M. Hinden
Nokia
313 Fairchild Drive
Mountain View, CA  94043
US

Phone: +1 650 625 2004
EMail: bob.hinden@nokia.com
Ted Lemon
Nominum, Inc.
950 Charter Street
Redwood City, CA  94043
US

EMail: Ted.Lemon@nominum.com

Masataka Ohta
Tokyo Institute of Technology
2-12-1, O-okayama, Meguro-ku
Tokyo  152-8552
Japan

Phone: +81 3 5734 3299
Fax:   +81 3 5734 3299
EMail: mohta@necom830.hpcl.titech.ac.jp


Soohong Daniel Park
Mobile Platform Laboratory, SAMSUNG Electronics
416 Maetan-3dong, Yeongtong-Gu
Suwon, Gyeonggi-Do  443-742
Korea

Phone: +82 31 200 4508
EMail: soohong.park@samsung.com


Suresh Satapati
Cisco Systems, Inc.
San Jose, CA  95134
US

EMail: satapati@cisco.com


Juha Wiljakka
Nokia
Visiokatu 3
FIN-33720, TAMPERE
Finland

Phone: +358 7180 48372
EMail: juha.wiljakka@nokia.com

8. Acknowledgements 🫶

This document has really benefited from inputs by David Meyer, Rob Austein, Tatuya Jinmei, Pekka Savola, Tim Chown, Luc Beloeil, Christian Huitema, Thomas Narten, Pascal Thubert, and Greg Daley. Tony Bonanno also proofread it 🥹. The authors really appreciate all of their contributions 💖.

9. References 📖

9.1. Normative References

[1]  Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery
     for IP Version 6 (IPv6)", RFC 2461, December 1998.

[2]  Thomson, S. and T. Narten, "IPv6 Stateless Address
     Autoconfiguration", RFC 2462, December 1998.

[3]  Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M.
     Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)",
     RFC 3315, July 2003.

[4]  Droms, R., "Stateless Dynamic Host Configuration Protocol (DHCP)
     Service for IPv6", RFC 3736, April 2004.

[5]  Droms, R., "DNS Configuration options for Dynamic Host
     Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, December
     2003.

9.2. Informative References

[6]  Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, "IPv6
     Router Advertisement Option for DNS Configuration", Work in
     Progress, September 2005.

[7]  Ohta, M., "Preconfigured DNS Server Addresses", Work in
     Progress, February 2004.

[8]  Venaas, S., Chown, T., and B. Volz, "Information Refresh Time
     Option for Dynamic Host Configuration Protocol for IPv6 (DHCPv6)",
     RFC 4242, November 2005.

[9]  Partridge, C., Mendez, T., and W. Milliken, "Host Anycasting
     Service", RFC 1546, November 1993.

[10] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6)
     Addressing Architecture", RFC 3513, April 2003.

[11] Lind, M., Ksinant, V., Park, S., Baudot, A., and P. Savola,
     "Scenarios and Analysis for Introducing IPv6 into ISP Networks",
     RFC 4029, March 2005.

[12] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
     Neighbor Discovery (SEND)", RFC 3971, March 2005.

[13] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages",
     RFC 3118, June 2001.

[14] Bound, J., "IPv6 Enterprise Network Scenarios", RFC 4057, June
     2005.

[15] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host
     Configuration Protocol (DHCP) version 6", RFC 3633, December
     2003.

[16] Wasserman, M., "Recommendations for IPv6 in Third Generation
     Partnership Project (3GPP) Standards", RFC 3314, September 2002.

[17] Soininen, J., "Transition Scenarios for 3GPP Networks", RFC
     3574, August 2003.

[18] Wiljakka, J., "Analysis on IPv6 Transition in Third Generation
     Partnership Project (3GPP) Networks", RFC 4215, October 2005.

[19] 3GPP TS 23.060 V5.4.0, "General Packet Radio Service (GPRS);
     Service description; Stage 2 (Release 5)", December 2002.

[20] 3GPP TS 24.008 V5.8.0, "Mobile radio interface Layer 3
     specification; Core network protocols; Stage 3 (Release 5)",
     June 2003.

[21] Chown, T., Venaas, S., and A. Vijayabhaskar, "Renumbering
     Requirements for Stateless Dynamic Host Configuration Protocol
     for IPv6 (DHCPv6)", RFC 4076, May 2005.

[22] Huitema, C., Austein, R., Satapati, S., and R. van der Pol,
     "Unmanaged Networks IPv6 Transition Scenarios", RFC 3750, April
     2004.

[23] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
     "DNS Security Introduction and Requirements", RFC 4033, March
     2005.

[24] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
     "Resource Records for the DNS Security Extensions", RFC 4034,
     March 2005.

[25] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
     "Protocol Modifications for the DNS Security Extensions", RFC
     4035, March 2005.

[26] Kolkman, O. and R. Gieben, "DNSSEC Operational Practices", Work
     in Progress, October 2005.

[27] Guette, G. and O. Courtay, "Requirements for Automated Key
     Rollover in DNSSEC", Work in Progress, January 2005.

[28] Park, S., Madanapalli, S., and T. Jinmei, "Considerations on M
     and O Flags of IPv6 Router Advertisement", Work in Progress,
     March 2005.

Author's Address 🎀

Jaehoon Paul Jeong (editor)
ETRI/Department of Computer Science and Engineering
University of Minnesota
117 Pleasant Street SE
Minneapolis, MN  55455
US

Phone: +1 651 587 7774
Fax:   +1 612 625 2002
EMail: jjeong@cs.umn.edu
URI:   http://www.cs.umn.edu/~jjeong/

Copyright (C) The Internet Society (2006).

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 🌈

Intellectual Property ✨

okay bestie, let's talk about the legal stuff, but make it cute 💅. The IETF takes no position on whether any Intellectual Property Rights or other rights claimed about the tech in this doc are valid, or how far they reach, and it might or might not have licenses for them 🙈. It also hasn't done its own independent search for any of those rights 🔍. If you want the rules about rights in RFC docs, check out BCP 78 and BCP 79 📜.

Copies of IPR disclosures sent to the IETF Secretariat are a thing, and so are assurances that licenses will be available 🎀. You can also find the results of any attempt to get a general license or permission for implementers or users of this spec to use those proprietary rights. Everything lives in the IETF online IPR repository at http://www.ietf.org/ipr 🦋.

And here's the big ask: the IETF invites anyone who's interested to flag any copyrights, patents, patent applications, or other proprietary rights that might cover tech needed to implement this standard 🫶. Send that info to the IETF at ietf-ipr@ietf.org 💌. Speak up, babe, it's giving transparency ✨.

Acknowledgement

and last but not least, a shoutout to whoever keeps the lights on for the RFC Editor 🌸. Funding for the RFC Editor function comes from the IETF Administrative Support Activity (IASA) 💜. Thank you, IASA, you're iconic 👑🌈.

📦 where this page comes from