doc: Add RFC documents

1 files changed, 1067 insertions, 0 deletions

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,
+              <http://www.rfc-editor.org/info/rfc2119>.
+
+   [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,
+              <http://www.rfc-editor.org/info/rfc4861>.
+
+   [RFC4862]  Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
+              Address Autoconfiguration", RFC 4862,
+              DOI 10.17487/RFC4862, September 2007,
+              <http://www.rfc-editor.org/info/rfc4862>.
+
+   [RFC1035]  Mockapetris, P., "Domain names - implementation and
+              specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
+              November 1987, <http://www.rfc-editor.org/info/rfc1035>.
+
+   [RFC4007]  Deering, S., Haberman, B., Jinmei, T., Nordmark, E., and
+              B. Zill, "IPv6 Scoped Address Architecture", RFC 4007,
+              DOI 10.17487/RFC4007, March 2005,
+              <http://www.rfc-editor.org/info/rfc4007>.
+
+9.2.  Informative References
+
+   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
+              STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
+              <http://www.rfc-editor.org/info/rfc1034>.
+
+   [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, <http://www.rfc-editor.org/info/rfc3315>.
+
+   [RFC3736]  Droms, R., "Stateless Dynamic Host Configuration Protocol
+              (DHCP) Service for IPv6", RFC 3736, DOI 10.17487/RFC3736,
+              April 2004, <http://www.rfc-editor.org/info/rfc3736>.
+
+   [RFC3646]  Droms, R., Ed., "DNS Configuration options for Dynamic
+              Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3646,
+              DOI 10.17487/RFC3646, December 2003,
+              <http://www.rfc-editor.org/info/rfc3646>.
+
+
+
+
+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,
+              <http://www.rfc-editor.org/info/rfc6106>.
+
+   [RFC4339]  Jeong, J., Ed., "IPv6 Host Configuration of DNS Server
+              Information Approaches", RFC 4339, DOI 10.17487/RFC4339,
+              February 2006, <http://www.rfc-editor.org/info/rfc4339>.
+
+   [RFC3971]  Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander,
+              "SEcure Neighbor Discovery (SEND)", RFC 3971,
+              DOI 10.17487/RFC3971, March 2005,
+              <http://www.rfc-editor.org/info/rfc3971>.
+
+   [RFC3118]  Droms, R., Ed., and W. Arbaugh, Ed., "Authentication for
+              DHCP Messages", RFC 3118, DOI 10.17487/RFC3118, June 2001,
+              <http://www.rfc-editor.org/info/rfc3118>.
+
+   [RFC6104]  Chown, T. and S. Venaas, "Rogue IPv6 Router Advertisement
+              Problem Statement", RFC 6104, DOI 10.17487/RFC6104,
+              February 2011, <http://www.rfc-editor.org/info/rfc6104>.
+
+   [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,
+              <http://www.rfc-editor.org/info/rfc6105>.
+
+   [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,
+              <http://www.rfc-editor.org/info/rfc7610>.
+
+   [RFC1535]  Gavron, E., "A Security Problem and Proposed Correction
+              With Widely Deployed DNS Software", RFC 1535,
+              DOI 10.17487/RFC1535, October 1993,
+              <http://www.rfc-editor.org/info/rfc1535>.
+
+   [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,
+              <http://www.rfc-editor.org/info/rfc1536>.
+
+   [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,
+              <http://www.rfc-editor.org/info/rfc6418>.
+
+   [RFC6419]  Wasserman, M. and P. Seite, "Current Practices for
+              Multiple-Interface Hosts", RFC 6419, DOI 10.17487/RFC6419,
+              November 2011, <http://www.rfc-editor.org/info/rfc6419>.
+
+   [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,
+              <http://www.rfc-editor.org/info/rfc6731>.
+
+   [ICMPv6]   IANA, "Internet Control Message Protocol version 6
+              (ICMPv6) Parameters",
+              <http://www.iana.org/assignments/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]
+