From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc8106.txt | 1067 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1067 insertions(+) create mode 100644 doc/rfc/rfc8106.txt (limited to 'doc/rfc/rfc8106.txt') diff --git a/doc/rfc/rfc8106.txt b/doc/rfc/rfc8106.txt new file mode 100644 index 0000000..6bcba61 --- /dev/null +++ b/doc/rfc/rfc8106.txt @@ -0,0 +1,1067 @@ + + + + + + +Internet Engineering Task Force (IETF) J. Jeong +Request for Comments: 8106 Sungkyunkwan University +Obsoletes: 6106 S. Park +Category: Standards Track Samsung Electronics +ISSN: 2070-1721 L. Beloeil + Orange + S. Madanapalli + NTT Data + March 2017 + + + IPv6 Router Advertisement Options for DNS Configuration + +Abstract + + This document specifies IPv6 Router Advertisement (RA) options + (called "DNS RA options") to allow IPv6 routers to advertise a list + of DNS Recursive Server Addresses and a DNS Search List to IPv6 + hosts. + + This document, which obsoletes RFC 6106, defines a higher default + value of the lifetime of the DNS RA options to reduce the likelihood + of expiry of the options on links with a relatively high rate of + packet loss. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc8106. + + + + + + + + + + + + + +Jeong, et al. Standards Track [Page 1] + +RFC 8106 IPv6 DNS RA Options March 2017 + + +Copyright Notice + + Copyright (c) 2017 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + +Table of Contents + + 1. Introduction ....................................................3 + 1.1. Applicability Statements ...................................3 + 1.2. Coexistence of RA Options and DHCP Options for DNS + Configuration ..............................................4 + 2. Requirements Language ...........................................4 + 3. Terminology .....................................................4 + 4. Overview ........................................................5 + 5. Neighbor Discovery Extension ....................................5 + 5.1. Recursive DNS Server Option ................................6 + 5.2. DNS Search List Option .....................................7 + 5.3. DNS Configuration Procedure ................................8 + 5.3.1. Procedure in IPv6 Hosts .............................9 + 5.3.2. Warnings for DNS Options Configuration ..............9 + 6. Implementation Considerations ..................................10 + 6.1. DNS Repository Management .................................10 + 6.2. Synchronization between DNS Server List and + Resolver Repository .......................................11 + 6.3. Synchronization between DNS Search List and + Resolver Repository .......................................12 + 7. Security Considerations ........................................12 + 7.1. Security Threats ..........................................12 + 7.2. Recommendations ...........................................13 + 8. IANA Considerations ............................................13 + 9. References .....................................................14 + 9.1. Normative References ......................................14 + 9.2. Informative References ....................................14 + Appendix A. Changes from RFC 6106 .................................17 + Acknowledgements ..................................................18 + Authors' Addresses ................................................19 + + + + + +Jeong, et al. Standards Track [Page 2] + +RFC 8106 IPv6 DNS RA Options March 2017 + + +1. Introduction + + The purpose of this document is to standardize IPv6 Router + Advertisement (RA) options (DNS RA options) for DNS Recursive Server + Addresses used for DNS name resolution in IPv6 hosts, and also for a + DNS Search List (DNSSL) of domain suffixes. + + IPv6 Neighbor Discovery (ND) and IPv6 Stateless Address + Autoconfiguration (SLAAC) provide ways to configure either fixed or + mobile nodes with one or more IPv6 addresses, default routers, and + some other parameters [RFC4861] [RFC4862]. + + It is infeasible to manually configure nomadic hosts each time they + connect to a different network. While a one-time static + configuration is possible, it is generally not desirable on general- + purpose hosts such as laptops. For instance, locally defined + namespaces would not be available to the host if it were to run its + own recursive name server directly connected to the global DNS. + + The DNS information can also be provided through DHCPv6 [RFC3315] + [RFC3736] [RFC3646]. However, access to DNS is a fundamental + requirement for almost all hosts, so IPv6 SLAAC cannot stand on its + own as an alternative deployment model in any practical network + without any support for DNS configuration. + + These issues are not pressing in dual-stack networks as long as a DNS + server is available on the IPv4 side, but they become more critical + with the deployment of IPv6-only networks. As a result, this + document defines a mechanism based on DNS RA options to allow IPv6 + hosts to perform automatic DNS configuration. + +1.1. Applicability Statements + + RA-based DNS configuration is a useful alternative in networks where + an IPv6 host's address is autoconfigured through IPv6 SLAAC and where + either (i) there is no DHCPv6 infrastructure at all or (ii) some + hosts do not have a DHCPv6 client. The intention is to enable the + full configuration of basic networking information for hosts without + requiring DHCPv6. However, for networks that need to distribute + additional information, DHCPv6 is likely to be employed. In these + networks, RA-based DNS configuration may not be needed. + + RA-based DNS configuration allows an IPv6 host to acquire the DNS + configuration (i.e., DNS Recursive Server Addresses and the DNSSL) + for the link(s) to which the host is connected. Furthermore, the + host learns this DNS configuration from the same RA message that + provides configuration information for the link. + + + + +Jeong, et al. Standards Track [Page 3] + +RFC 8106 IPv6 DNS RA Options March 2017 + + + The advantages and disadvantages of the RA-based approach are + discussed in [RFC4339] along with other approaches, such as the DHCP + and well-known anycast address approaches. + +1.2. Coexistence of RA Options and DHCP Options for DNS Configuration + + Two protocols exist to configure the DNS information on a host: the + RA options specified in this document and the DHCPv6 options + specified in [RFC3646]. They can be used together. The rules + governing the decision to use stateful configuration mechanisms are + specified in [RFC4861]. Hosts conforming to this specification MUST + extract DNS information from RA messages, unless static DNS + configuration has been specified by the user. If there is DNS + information available from multiple RAs and/or from DHCP, the host + MUST maintain an ordered list of this information as specified in + Section 5.3.1. + +2. Requirements Language + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in [RFC2119]. + +3. Terminology + + This document uses the terminology defined in [RFC4861] and + [RFC4862]. In addition, six new terms are defined below: + + o Recursive DNS Server (RDNSS): A server that provides a recursive + DNS resolution service for translating domain names into IP + addresses or resolving PTR records as defined in [RFC1034] and + [RFC1035]. + + o RDNSS Option: An IPv6 RA option to deliver the RDNSS information + to IPv6 hosts [RFC4861]. + + o DNS Search List (DNSSL): The list of DNS suffix domain names used + by IPv6 hosts when they perform DNS query searches for short, + unqualified domain names. + + o DNSSL Option: An IPv6 RA option to deliver the DNSSL information + to IPv6 hosts. + + o DNS Repository: Two data structures for managing DNS configuration + information in the IPv6 protocol stack, in addition to the + Neighbor Cache and Destination Cache for Neighbor Discovery + + + + + +Jeong, et al. Standards Track [Page 4] + +RFC 8106 IPv6 DNS RA Options March 2017 + + + [RFC4861]. The first data structure is the DNS Server List for + RDNSS addresses, and the second is the DNSSL for DNS search domain + names. + + o Resolver Repository: Configuration repository with RDNSS addresses + and a DNSSL that a DNS resolver on the host uses for DNS name + resolution -- for example, the UNIX resolver file (i.e., + /etc/resolv.conf) and the Windows registry. + +4. Overview + + This document standardizes an ND option called the "RDNSS option", + which contains the addresses of RDNSSes. This document also + standardizes an ND option called the "DNSSL option", which contains + the DNSSL. This is to maintain parity with the DHCPv6 options and to + ensure that there is necessary functionality to determine the search + domains. + + The existing ND message (i.e., RA) is used to carry this information. + An IPv6 host can configure the IPv6 addresses of one or more RDNSSes + via RA messages. Through the RDNSS and DNSSL options, along with the + Prefix Information option based on the ND protocol [RFC4861] + [RFC4862], an IPv6 host can perform the network configuration of its + IPv6 address and the DNS information simultaneously without needing + DHCPv6 for the DNS configuration. The RA options for RDNSS and DNSSL + can be used on networks that support the use of ND. + + This approach requires manual configuration or automatic mechanisms + (e.g., DHCPv6 or vendor-proprietary configuration mechanisms) to + configure the DNS information in routers sending the advertisements. + The automatic configuration of RDNSS addresses and a DNSSL in routers + is out of scope for this document. + +5. Neighbor Discovery Extension + + The IPv6 DNS configuration mechanism described in this document needs + two ND options in Neighbor Discovery: (i) the RDNSS option and + (ii) the DNSSL option. + + + + + + + + + + + + + +Jeong, et al. Standards Track [Page 5] + +RFC 8106 IPv6 DNS RA Options March 2017 + + +5.1. Recursive DNS Server Option + + The RDNSS option contains one or more IPv6 addresses of RDNSSes. All + of the addresses share the same Lifetime value. If it is desirable + to have different Lifetime values, multiple RDNSS options can be + used. Figure 1 shows the format of the RDNSS option. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Length | Reserved | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Lifetime | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + : Addresses of IPv6 Recursive DNS Servers : + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 1: RDNSS Option Format + + Fields: + + Type 8-bit identifier of the RDNSS option type as assigned by + IANA: 25 + + Length 8-bit unsigned integer. The length of the option + (including the Type and Length fields) is in units of + 8 octets. The minimum value is 3 if one IPv6 address is + contained in the option. Every additional RDNSS address + increases the length by 2. The Length field is used by + the receiver to determine the number of IPv6 addresses in + the option. + + Lifetime 32-bit unsigned integer. The maximum time in seconds + (relative to the time the packet is received) over which + these RDNSS addresses MAY be used for name resolution. + The value of Lifetime SHOULD by default be at least + 3 * MaxRtrAdvInterval, where MaxRtrAdvInterval is the + maximum RA interval as defined in [RFC4861]. A value of + all one bits (0xffffffff) represents infinity. A value + of zero means that the RDNSS addresses MUST no longer + be used. + + + + + + + + +Jeong, et al. Standards Track [Page 6] + +RFC 8106 IPv6 DNS RA Options March 2017 + + + Addresses of IPv6 Recursive DNS Servers + One or more 128-bit IPv6 addresses of the RDNSSes. The + number of addresses is determined by the Length field. + That is, the number of addresses is equal to + (Length - 1) / 2. + + Note: The addresses for RDNSSes in the RDNSS option MAY be link-local + addresses. Such link-local addresses SHOULD be registered in + the Resolver Repository along with the corresponding link zone + indices of the links that receive the RDNSS option(s) for them. + The link-local addresses MAY be represented in the Resolver + Repository with their link zone indices in the textual format + for scoped addresses as described in [RFC4007]. When a + resolver sends a DNS query message to an RDNSS identified by a + link-local address, it MUST use the corresponding link. + + The rationale of the default value of the Lifetime field is as + follows. The Router Lifetime field, set by AdvDefaultLifetime, + has the default of 3 * MaxRtrAdvInterval as specified in + [RFC4861], so such a default or a larger default can allow for + the reliability of DNS options even under the loss of RAs on + links with a relatively high rate of packet loss. Note that + the ratio of AdvDefaultLifetime to MaxRtrAdvInterval is the + number of unsolicited multicast RAs sent by the router. Since + the DNS option entries can survive for at most three + consecutive losses of RAs containing DNS options, the default + value of the Lifetime lets the DNS option entries be resilient + to packet-loss environments. + +5.2. DNS Search List Option + + The DNSSL option contains one or more domain names of DNS suffixes. + All of the domain names share the same Lifetime value. If it is + desirable to have different Lifetime values, multiple DNSSL options + can be used. Figure 2 shows the format of the DNSSL option. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Length | Reserved | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Lifetime | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + : Domain Names of DNS Search List : + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + + +Jeong, et al. Standards Track [Page 7] + +RFC 8106 IPv6 DNS RA Options March 2017 + + + Figure 2: DNSSL Option Format + + Fields: + + Type 8-bit identifier of the DNSSL option type as assigned by + IANA: 31 + + Length 8-bit unsigned integer. The length of the option + (including the Type and Length fields) is in units of + 8 octets. The minimum value is 2 if at least one domain + name is contained in the option. The Length field is set + to a multiple of 8 octets to accommodate all the domain + names in the "Domain Names of DNS Search List" field. + + Lifetime 32-bit unsigned integer. The maximum time in seconds + (relative to the time the packet is received) over which + these DNSSL domain names MAY be used for name resolution. + The Lifetime value has the same semantics as the + semantics for the RDNSS option. That is, Lifetime SHOULD + by default be at least 3 * MaxRtrAdvInterval. A value of + all one bits (0xffffffff) represents infinity. A value + of zero means that the DNSSL domain names MUST no longer + be used. + + Domain Names of DNS Search List + One or more domain names of the DNSSL that MUST be + encoded as described in Section 3.1 of [RFC1035]. With + this technique, each domain name is represented as a + sequence of labels ending in a zero octet, defined as a + domain name representation. For more than one domain + name, the corresponding domain name representations are + concatenated as they are. Note that for the simple + decoding, the domain names MUST NOT be encoded in the + compressed form described in Section 4.1.4 of [RFC1035]. + Because the size of this field MUST be a multiple of + 8 octets, for the minimum multiple including the domain + name representations, the remaining octets other than the + encoding parts of the domain name representations MUST be + padded with zeros. + +5.3. DNS Configuration Procedure + + The procedure for DNS configuration through the RDNSS and DNSSL + options is the same as it is with any other ND option [RFC4861]. + + + + + + + +Jeong, et al. Standards Track [Page 8] + +RFC 8106 IPv6 DNS RA Options March 2017 + + +5.3.1. Procedure in IPv6 Hosts + + When an IPv6 host receives DNS options (i.e., RDNSS and DNSSL + options) through RA messages, it processes the options as follows: + + o The validity of DNS options is checked with the Length field; + that is, the value of the Length field in the RDNSS option is + greater than or equal to the minimum value (3) and satisfies the + requirement that (Length - 1) % 2 == 0. The value of the Length + field in the DNSSL option is greater than or equal to the minimum + value (2). Also, the validity of the RDNSS option is checked with + the "Addresses of IPv6 Recursive DNS Servers" field; that is, the + addresses should be unicast addresses. + + o If the DNS options are valid, the host SHOULD copy the values of + the options into the DNS Repository and the Resolver Repository in + order. Otherwise, the host MUST discard the options. Refer to + Section 6 for the detailed procedure. + + In the case where the DNS information of RDNSS and DNSSL can be + obtained from multiple sources, such as RAs and DHCP, the IPv6 host + SHOULD keep some DNS options from all sources. Unless explicitly + specified for the discovery mechanism, the exact number of addresses + and domain names to keep is a matter of local policy and + implementation choice as a local configuration option. However, in + the case of multiple sources, the ability to store a total of at + least three RDNSS addresses (or DNSSL domain names) from the multiple + sources is RECOMMENDED. The DNS options from RAs and DHCP SHOULD be + stored in the DNS Repository and Resolver Repository so that + information from DHCP appears there first and therefore takes + precedence. Thus, the DNS information from DHCP takes precedence + over that from RAs for DNS queries. On the other hand, for DNS + options announced by RAs, if some RAs use the Secure Neighbor + Discovery (SEND) protocol [RFC3971] for RA security, they MUST be + preferred over those that do not use SEND. Also, DNS options + announced by RAs via SEND MUST be preferred over those announced by + unauthenticated DHCP [RFC3118]. Refer to Section 7 for a detailed + discussion of SEND for DNS RA options. + +5.3.2. Warnings for DNS Options Configuration + + There are two warnings for DNS options configuration: (i) warning for + multiple sources of DNS options and (ii) warning for multiple network + interfaces. First, in the case of multiple sources for DNS options + (e.g., RAs and DHCP), an IPv6 host can configure its IP addresses + from these sources. In this case, it is not possible to control how + the host uses DNS information and what source addresses it uses to + send DNS queries. As a result, configurations where different + + + +Jeong, et al. Standards Track [Page 9] + +RFC 8106 IPv6 DNS RA Options March 2017 + + + information is provided by different mechanisms for autoconfiguration + may lead to problems. Therefore, the network administrator needs to + carefully configure different DNS options in the multiple mechanisms + for autoconfiguration in order to minimize the impact of such + problems [DHCPv6-SLAAC]. + + Second, if different DNS information is provided on different network + interfaces, this can lead to inconsistent behavior. The IETF worked + on solving this problem for both DNS and other information obtained + from multiple interfaces [RFC6418] [RFC6419] and standardized a + DHCP-based solution for RDNSS selection for multi-interfaced nodes as + described in [RFC6731]. + +6. Implementation Considerations + + The implementation considerations in this document include the + following three: (i) DNS repository management, (ii) synchronization + between the DNS Server List and the Resolver Repository, and + (iii) synchronization between the DNSSL and the Resolver Repository. + + Note: The implementations that are updated according to this document + will still interoperate with the existing implementations + according to [RFC6106]. This is because the main change in + this document is the increase of the default Lifetime of DNS + options, considering lossy links. + +6.1. DNS Repository Management + + For DNS repository management, the following two data structures + SHOULD be synchronized with the Resolver Repository: (i) the DNS + Server List, which keeps the list of RDNSS addresses and (ii) the + DNSSL, which keeps the list of DNS search domain names. Each entry + in these two lists consists of a pair of an RDNSS address (or DNSSL + domain name) and Expiration-time as follows: + + o RDNSS address for DNS Server List: IPv6 address of the RDNSS that + is available for recursive DNS resolution service in the network + advertising the RDNSS option. + + o DNSSL domain name for DNSSL: DNS suffix domain name that is used + to perform DNS query searches for short, unqualified domain names. + + o Expiration-time for DNS Server List or DNSSL: The time when this + entry becomes invalid. Expiration-time is set to the value of the + Lifetime field of the RDNSS option or DNSSL option plus the + current time. Whenever a new RDNSS option with the same address + (or DNSSL option with the same domain name) is received on the + same interface as a previous RDNSS option (or DNSSL option), this + + + +Jeong, et al. Standards Track [Page 10] + +RFC 8106 IPv6 DNS RA Options March 2017 + + + field is updated to have a new Expiration-time. When the current + time becomes larger than Expiration-time, this entry is regarded + as expired, so it should not be used any more. Note that the DNS + information for the RDNSS and DNSSL options need not be dropped if + the expiry of the RA router lifetime happens. This is because + these options have their own lifetime values. + +6.2. Synchronization between DNS Server List and Resolver Repository + + When an IPv6 host receives the information of multiple RDNSS + addresses within a network (e.g., campus network and company network) + through an RA message with RDNSS option(s), it stores the RDNSS + addresses (in order) in both the DNS Server List and the Resolver + Repository. The processing of the RDNSS consists of (i) the + processing of RDNSS option(s) included in an RA message and (ii) the + handling of expired RDNSSes. The processing of RDNSS option(s) is as + follows: + + o Step (a): Receive and parse the RDNSS option(s). For the RDNSS + addresses in each RDNSS option, perform Steps (b) through (d). + + o Step (b): For each RDNSS address, check the following: If the + RDNSS address already exists in the DNS Server List and the RDNSS + option's Lifetime field is set to zero, delete the corresponding + RDNSS entry from both the DNS Server List and the Resolver + Repository in order to prevent the RDNSS address from being used + any more for certain reasons in network management, e.g., the + termination of the RDNSS or a renumbering scenario. That is, the + RDNSS can resign from its DNS service because the machine running + the RDNSS is out of service intentionally or unintentionally. + Also, in the renumbering scenario, the RDNSS's IPv6 address will + be changed, so the previous RDNSS address should not be used any + more. The processing of this RDNSS address is finished here. + Otherwise, go to Step (c). + + o Step (c): For each RDNSS address, if it already exists in the DNS + Server List and the RDNSS option's Lifetime field is not set to + zero, then just update the value of the Expiration-time field + according to the procedure specified in the third bullet of + Section 6.1. Otherwise, go to Step (d). + + o Step (d): For each RDNSS address, if it does not exist in the DNS + Server List, register the RDNSS address and Lifetime with the DNS + Server List and then insert the RDNSS address as the first one in + the Resolver Repository. In the case where the data structure for + the DNS Server List is full of RDNSS entries (that is, has more + RDNSSes than the sufficient number discussed in Section 5.3.1), + delete from the DNS Server List the entry with the shortest + + + +Jeong, et al. Standards Track [Page 11] + +RFC 8106 IPv6 DNS RA Options March 2017 + + + Expiration-time (i.e., the entry that will expire first). The + corresponding RDNSS address is also deleted from the Resolver + Repository. For the ordering of RDNSS addresses in an RDNSS + option, position the first RDNSS address in the RDNSS option as + the first one in the Resolver Repository, the second RDNSS address + in the option as the second one in the repository, and so on. + This ordering allows the RDNSS addresses in the RDNSS option to be + preferred according to their order in the RDNSS option for DNS + name resolution. The processing of these RDNSS addresses is + finished here. + + The handling of expired RDNSSes is as follows: Whenever an entry + expires in the DNS Server List, the expired entry is deleted from the + DNS Server List, and also the RDNSS address corresponding to the + entry is deleted from the Resolver Repository. + +6.3. Synchronization between DNS Search List and Resolver Repository + + When an IPv6 host receives the information of multiple DNSSL domain + names within a network through an RA message with DNSSL option(s), it + stores the DNSSL domain names (in order) in both the DNSSL and the + Resolver Repository. The processing of the DNSSL consists of (i) the + processing of DNSSL option(s) included in an RA message and (ii) the + handling of expired DNSSLs. The processing of DNSSL option(s) is the + same as the processing of RDNSS option(s) as described in + Section 6.2. + +7. Security Considerations + + In this section, we analyze security threats related to DNS options + and then make recommendations to cope with such security threats. + +7.1. Security Threats + + For the RDNSS option, an attacker could send an RA with a fraudulent + RDNSS address, misleading IPv6 hosts into contacting an unintended + DNS server for DNS name resolution. Also, for the DNSSL option, an + attacker can let IPv6 hosts resolve a hostname without a DNS suffix + into an unintended host's IP address with a fraudulent DNSSL. These + attacks are similar to ND attacks specified in [RFC4861] that use + Redirect or Neighbor Advertisement messages to redirect traffic to + individual addresses of malicious parties. + + + + + + + + + +Jeong, et al. Standards Track [Page 12] + +RFC 8106 IPv6 DNS RA Options March 2017 + + + However, the security of these RA options for DNS configuration does + not affect ND protocol security [RFC4861]. This is because learning + DNS information via the RA options cannot be worse than learning bad + router information via the RA options. Therefore, the vulnerability + of ND is not worse and is a subset of the attacks that any node + attached to a LAN can do. + +7.2. Recommendations + + The Secure Neighbor Discovery (SEND) protocol [RFC3971] is designed + as a security mechanism for ND. In this case, ND can use SEND to + allow all the ND options, including the RDNSS and DNSSL options, to + be automatically signed with digital signatures. + + It is common for network devices such as switches to include + mechanisms to block unauthorized ports from running a DHCPv6 server + to provide protection from rogue DHCPv6 servers [RFC7610]. That + means that an attacker on other ports cannot insert bogus DNS servers + using DHCPv6. The corresponding technique for network devices is + RECOMMENDED to block rogue RA messages that include the RDNSS and + DNSSL options from unauthorized nodes [RFC6104] [RFC6105]. + + An attacker may provide a bogus DNSSL option in order to cause the + victim to send DNS queries to a specific DNS server when the victim + queries non-FQDNs (fully qualified domain names). For this attack, + the DNS resolver in IPv6 hosts can mitigate the vulnerability with + the recommendations mentioned in [RFC1535], [RFC1536], and [RFC3646]. + +8. IANA Considerations + + The RDNSS option defined in this document uses the IPv6 Neighbor + Discovery Option type assigned by IANA as follows: + + Option Name Type + ----------------------------------- + Recursive DNS Server Option 25 + + The DNSSL option defined in this document uses the IPv6 Neighbor + Discovery Option type assigned by IANA as follows: + + Option Name Type + ----------------------------------- + DNS Search List Option 31 + + These options are registered in the "IPv6 Neighbor Discovery Option + Formats" registry [ICMPv6]. + + + + + +Jeong, et al. Standards Track [Page 13] + +RFC 8106 IPv6 DNS RA Options March 2017 + + +9. References + +9.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + . + + [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, + "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, + DOI 10.17487/RFC4861, September 2007, + . + + [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless + Address Autoconfiguration", RFC 4862, + DOI 10.17487/RFC4862, September 2007, + . + + [RFC1035] Mockapetris, P., "Domain names - implementation and + specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, + November 1987, . + + [RFC4007] Deering, S., Haberman, B., Jinmei, T., Nordmark, E., and + B. Zill, "IPv6 Scoped Address Architecture", RFC 4007, + DOI 10.17487/RFC4007, March 2005, + . + +9.2. Informative References + + [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", + STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, + . + + [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, + C., and M. Carney, "Dynamic Host Configuration Protocol + for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, + July 2003, . + + [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol + (DHCP) Service for IPv6", RFC 3736, DOI 10.17487/RFC3736, + April 2004, . + + [RFC3646] Droms, R., Ed., "DNS Configuration options for Dynamic + Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, + DOI 10.17487/RFC3646, December 2003, + . + + + + +Jeong, et al. Standards Track [Page 14] + +RFC 8106 IPv6 DNS RA Options March 2017 + + + [RFC6106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, + "IPv6 Router Advertisement Options for DNS Configuration", + RFC 6106, DOI 10.17487/RFC6106, November 2010, + . + + [RFC4339] Jeong, J., Ed., "IPv6 Host Configuration of DNS Server + Information Approaches", RFC 4339, DOI 10.17487/RFC4339, + February 2006, . + + [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, + "SEcure Neighbor Discovery (SEND)", RFC 3971, + DOI 10.17487/RFC3971, March 2005, + . + + [RFC3118] Droms, R., Ed., and W. Arbaugh, Ed., "Authentication for + DHCP Messages", RFC 3118, DOI 10.17487/RFC3118, June 2001, + . + + [RFC6104] Chown, T. and S. Venaas, "Rogue IPv6 Router Advertisement + Problem Statement", RFC 6104, DOI 10.17487/RFC6104, + February 2011, . + + [RFC6105] Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C., and J. + Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105, + DOI 10.17487/RFC6105, February 2011, + . + + [RFC7610] Gont, F., Liu, W., and G. Van de Velde, "DHCPv6-Shield: + Protecting against Rogue DHCPv6 Servers", BCP 199, + RFC 7610, DOI 10.17487/RFC7610, August 2015, + . + + [RFC1535] Gavron, E., "A Security Problem and Proposed Correction + With Widely Deployed DNS Software", RFC 1535, + DOI 10.17487/RFC1535, October 1993, + . + + [RFC1536] Kumar, A., Postel, J., Neuman, C., Danzig, P., and S. + Miller, "Common DNS Implementation Errors and Suggested + Fixes", RFC 1536, DOI 10.17487/RFC1536, October 1993, + . + + [DHCPv6-SLAAC] + Liu, B., Jiang, S., Gong, X., Wang, W., and E. Rey, + "DHCPv6/SLAAC Interaction Problems on Address and + DNS Configuration", Work in Progress, + draft-ietf-v6ops-dhcpv6-slaac-problem-07, August 2016. + + + + +Jeong, et al. Standards Track [Page 15] + +RFC 8106 IPv6 DNS RA Options March 2017 + + + [RFC6418] Blanchet, M. and P. Seite, "Multiple Interfaces and + Provisioning Domains Problem Statement", RFC 6418, + DOI 10.17487/RFC6418, November 2011, + . + + [RFC6419] Wasserman, M. and P. Seite, "Current Practices for + Multiple-Interface Hosts", RFC 6419, DOI 10.17487/RFC6419, + November 2011, . + + [RFC6731] Savolainen, T., Kato, J., and T. Lemon, "Improved + Recursive DNS Server Selection for Multi-Interfaced + Nodes", RFC 6731, DOI 10.17487/RFC6731, December 2012, + . + + [ICMPv6] IANA, "Internet Control Message Protocol version 6 + (ICMPv6) Parameters", + . + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Jeong, et al. Standards Track [Page 16] + +RFC 8106 IPv6 DNS RA Options March 2017 + + +Appendix A. Changes from RFC 6106 + + The following changes were made from RFC 6106 ("IPv6 Router + Advertisement Options for DNS Configuration"): + + o This document allows a higher default value of the lifetime of the + DNS RA options than RFC 6106 in order to avoid the frequent expiry + of the options on links with a relatively high rate of packet + loss; at the same time, this document also makes additional + clarifications. The lifetime's lower bound of + 2 * MaxRtrAdvInterval was shown to lead to the expiry of these + options on links with a relatively high rate of packet loss. To + avoid this problem, this revision relaxes the lower bound and sets + a higher default value of 3 * MaxRtrAdvInterval. + + o The text regarding the generation of a Router Solicitation message + to ensure that the RDNSS information is fresh before the expiry of + the RDNSS option is removed in order to prevent multicast traffic + on the link from increasing. + + o The addresses for RDNSSes in the RDNSS option can be not only + global addresses but also link-local addresses. The link-local + addresses for RDNSSes should be registered in the Resolver + Repository along with the corresponding link zone indices. + + o RFC 6106 recommended that the number of RDNSS addresses that + should be learned and maintained through the RDNSS RA option + should be limited to three. This document removes that + recommendation; thus, the number of RDNSS addresses to maintain is + determined by an implementer's local policy. + + o RFC 6106 recommended that the number of DNS search domains that + should be learned and maintained through the DNSSL RA option + should be limited to three. This document removes that + recommendation; thus, when the set of unique DNSSL values are not + equivalent, none of them may be ignored for hostname lookups + according to an implementer's local policy. + + o The guidance of the specific implementation for the + synchronization of the DNS Repository and Resolver Repository in + the kernel space and user space is removed. + + o The key words "SHOULD" and "RECOMMENDED" (RFC 2119) are removed in + the recommendation of using SEND as a security mechanism for ND. + Instead of using these key words, SEND is specified as only a + possible security mechanism for ND. + + + + + +Jeong, et al. Standards Track [Page 17] + +RFC 8106 IPv6 DNS RA Options March 2017 + + +Acknowledgements + + This document has greatly benefited from inputs by Robert Hinden, + Pekka Savola, Iljitsch van Beijnum, Brian Haberman, Tim Chown, Erik + Nordmark, Dan Wing, Jari Arkko, Ben Campbell, Vincent Roca, Tony + Cheneau, Fernando Gont, Jen Linkova, Ole Troan, Mark Smith, Tatuya + Jinmei, Lorenzo Colitti, Tore Anderson, David Farmer, Bing Liu, and + Tassos Chatzithomaoglou. The authors sincerely appreciate their + contributions. + + This document was supported by an Institute for Information & + communications Technology Promotion (IITP) grant funded by the Korean + government (MSIP) [10041244, Smart TV 2.0 Software Platform]. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Jeong, et al. Standards Track [Page 18] + +RFC 8106 IPv6 DNS RA Options March 2017 + + +Authors' Addresses + + Jaehoon Paul Jeong + Department of Software + Sungkyunkwan University + 2066 Seobu-Ro, Jangan-Gu + Suwon, Gyeonggi-Do 16419 + Republic of Korea + + Phone: +82 31 299 4957 + Fax: +82 31 290 7996 + Email: pauljeong@skku.edu + URI: http://iotlab.skku.edu/people-jaehoon-jeong.php + + + Soohong Daniel Park + Software R&D Center + Samsung Electronics + Seoul R&D Campus D-Tower, 56, Seongchon-Gil, Seocho-Gu + Seoul 06765 + Republic of Korea + + Email: soohong.park@samsung.com + + + Luc Beloeil + Orange + 5 rue Maurice Sibille + BP 44211 + 44042 Nantes Cedex 1 + France + + Phone: +33 2 28 56 11 84 + Email: luc.beloeil@orange.com + + + Syam Madanapalli + NTT Data + #H304, Shriram Samruddhi, Thubarahalli + Bangalore 560066 + India + + Phone: +91 959 175 7926 + Email: smadanapalli@gmail.com + + + + + + + +Jeong, et al. Standards Track [Page 19] + -- cgit v1.2.3