doc: Add RFC documents

1 files changed, 1067 insertions, 0 deletions

diff --git a/doc/rfc/rfc6106.txt b/doc/rfc/rfc6106.txt
new file mode 100644
index 0000000..4b49a43
--- /dev/null
+++ b/doc/rfc/rfc6106.txt
@@ -0,0 +1,1067 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                          J. Jeong
+Request for Comments: 6106                                  Brocade/ETRI
+Obsoletes: 5006                                                  S. Park
+Category: Standards Track                            SAMSUNG Electronics
+ISSN: 2070-1721                                               L. Beloeil
+                                                      France Telecom R&D
+                                                          S. Madanapalli
+                                                       iRam Technologies
+                                                           November 2010
+
+
+        IPv6 Router Advertisement Options for DNS Configuration
+
+Abstract
+
+   This document specifies IPv6 Router Advertisement options to allow
+   IPv6 routers to advertise a list of DNS recursive server addresses
+   and a DNS Search List to IPv6 hosts.
+
+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 5741.
+
+   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/rfc6106.
+
+Copyright Notice
+
+   Copyright (c) 2010 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.
+
+
+
+
+Jeong, et al.                Standards Track                    [Page 1]
+
+RFC 6106                   IPv6 RA DNS Options             November 2010
+
+
+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. Procedure of DNS Configuration .............................8
+           5.3.1. Procedure in IPv6 Host ..............................8
+           5.3.2. Warnings for DNS Options Configuration .............10
+   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 ........................................13
+      7.1. Security Threats ..........................................13
+      7.2. Recommendations ...........................................14
+   8. IANA Considerations ............................................15
+   9. Acknowledgements ...............................................15
+   10. References ....................................................16
+      10.1. Normative References .....................................16
+      10.2. Informative References ...................................16
+   Appendix A.  Changes from RFC 5006 ................................18
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Jeong, et al.                Standards Track                    [Page 2]
+
+RFC 6106                   IPv6 RA DNS Options             November 2010
+
+
+1.  Introduction
+
+   The purpose of this document is to standardize an IPv6 Router
+   Advertisement (RA) option for DNS Recursive Server Addresses used for
+   the DNS name resolution in IPv6 hosts.  This RA option was specified
+   in an earlier Experimental specification [RFC5006].  This document is
+   also to define a new RA option for Domain Name Search Lists for an
+   enhanced DNS configuration.  Thus, this document obsoletes [RFC5006],
+   which only defines the RA option for DNS Recursive Server Addresses.
+
+   Neighbor Discovery (ND) for IP version 6 and IPv6 stateless address
+   autoconfiguration provide ways to configure either fixed or mobile
+   nodes with one or more IPv6 addresses, default routers, and some
+   other parameters [RFC4861][RFC4862].  Most Internet services are
+   identified by using a DNS name.  The two RA options defined in this
+   document provide the DNS information needed for an IPv6 host to reach
+   Internet services.
+
+   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 name
+   spaces would not be available to the host if it were to run its own
+   name server software directly connected to the global DNS.
+
+   The DNS information can also be provided through DHCP
+   [RFC3315][RFC3736][RFC3646].  However, the access to DNS is a
+   fundamental requirement for almost all hosts, so IPv6 stateless
+   autoconfiguration 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 IPv6 RA options to allow IPv6
+   hosts to perform the 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 stateless
+   address autoconfiguration and where there is either no DHCPv6
+   infrastructure at all or 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, when in
+
+
+
+
+
+Jeong, et al.                Standards Track                    [Page 3]
+
+RFC 6106                   IPv6 RA DNS Options             November 2010
+
+
+   many networks some additional information needs to be distributed,
+   those networks are likely to employ DHCPv6.  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 DNS Search
+   List) 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, thereby avoiding
+   also running DHCPv6.
+
+   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
+   Router Advertisement options described in this document and the
+   DHCPv6 options described 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 Router Advertisement
+   messages, unless static DNS configuration has been specified by the
+   user.  If there is DNS information available from multiple Router
+   Advertisements 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 described in [RFC4861] and
+   [RFC4862].  In addition, four new terms are defined below:
+
+   o  Recursive DNS Server (RDNSS): Server that provides a recursive DNS
+      resolution service for translating domain names into IP addresses
+      as defined in [RFC1034] and [RFC1035].
+
+   o  RDNSS Option: IPv6 RA option to deliver the RDNSS information to
+      IPv6 hosts [RFC4861].
+
+
+
+
+
+
+Jeong, et al.                Standards Track                    [Page 4]
+
+RFC 6106                   IPv6 RA DNS Options             November 2010
+
+
+   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: 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 Neighbor
+      Cache and Destination Cache for Neighbor Discovery [RFC4861].  The
+      first data structure is the DNS Server List for RDNSS addresses
+      and the second is the DNS Search List for DNS search domain names.
+
+   o  Resolver Repository: Configuration repository with RDNSS addresses
+      and a DNS Search List that a DNS resolver on the host uses for DNS
+      name resolution; for example, the Unix resolver file (i.e., /etc/
+      resolv.conf) and Windows registry.
+
+4.  Overview
+
+   This document standardizes the ND option called the RDNSS option
+   defined in [RFC5006] that contains the addresses of recursive DNS
+   servers.  This document also defines a new ND option called the DNSSL
+   option for the Domain Search List.  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., Router Advertisement) 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] and [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 any network that
+   supports the use of ND.
+
+   This approach requires the manual configuration or other 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
+   DNS Search List in routers is out of scope for this document.
+
+5.  Neighbor Discovery Extension
+
+   The IPv6 DNS configuration mechanism in this document needs two new
+   ND options in Neighbor Discovery: (i) the Recursive DNS Server
+   (RDNSS) option and (ii) the DNS Search List (DNSSL) option.
+
+
+
+Jeong, et al.                Standards Track                    [Page 5]
+
+RFC 6106                   IPv6 RA DNS Options             November 2010
+
+
+5.1.  Recursive DNS Server Option
+
+   The RDNSS option contains one or more IPv6 addresses of recursive DNS
+   servers.  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: Recursive DNS Server (RDNSS) Option Format
+
+
+   Fields:
+     Type          8-bit identifier of the RDNSS option type as assigned
+                   by the 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 sent),
+                   over which this RDNSS address MAY be used for name
+                   resolution.  Hosts MAY send a Router Solicitation to
+                   ensure the RDNSS information is fresh before the
+                   interval expires.  In order to provide fixed hosts
+                   with stable DNS service and allow mobile hosts to
+                   prefer local RDNSSes to remote RDNSSes, the value of
+                   Lifetime SHOULD be bounded as
+                   MaxRtrAdvInterval <= Lifetime <= 2*MaxRtrAdvInterval
+                   where MaxRtrAdvInterval is the Maximum RA Interval
+                   defined in [RFC4861].  A value of all one bits
+                   (0xffffffff) represents infinity.  A value of zero
+                   means that the RDNSS address MUST no longer be used.
+
+
+
+Jeong, et al.                Standards Track                    [Page 6]
+
+RFC 6106                   IPv6 RA DNS Options             November 2010
+
+
+     Addresses of IPv6 Recursive DNS Servers
+                   One or more 128-bit IPv6 addresses of the recursive
+                   DNS servers.  The number of addresses is determined
+                   by the Length field.  That is, the number of
+                   addresses is equal to (Length - 1) / 2.
+
+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                :
+     |                                                               |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+              Figure 2: DNS Search List (DNSSL) Option Format
+
+  Fields:
+    Type          8-bit identifier of the DNSSL option type as assigned
+                  by the 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 field of Domain Names of
+                  DNS Search List.
+
+    Lifetime      32-bit unsigned integer.  The maximum time, in
+                  seconds (relative to the time the packet is sent),
+                  over which this DNSSL domain name MAY be used for
+                  name resolution.  The Lifetime value has the same
+                  semantics as with the RDNSS option.  That is, Lifetime
+                  SHOULD be bounded as follows:
+                  MaxRtrAdvInterval <= Lifetime <= 2*MaxRtrAdvInterval.
+
+
+
+
+
+Jeong, et al.                Standards Track                    [Page 7]
+
+RFC 6106                   IPv6 RA DNS Options             November 2010
+
+
+                  A value of all one bits (0xffffffff) represents
+                  infinity.  A value of zero means that the DNSSL
+                  domain name MUST no longer be used.
+
+    Domain Names of DNS Search List
+                  One or more domain names of DNS Search List that MUST
+                  be encoded using the technique described in Section
+                  3.1 of [RFC1035].  By this technique, each domain
+                  name is represented as a sequence of labels ending in
+                  a zero octet, defined as 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 a compressed form, as
+                  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.
+
+   Note:  An RDNSS address or a DNSSL domain name MUST be used only as
+      long as both the RA router Lifetime (advertised by a Router
+      Advertisement message [RFC4861]) and the corresponding option
+      Lifetime have not expired.  The reason is that in the current
+      network to which an IPv6 host is connected, the RDNSS may not be
+      currently reachable, that the DNSSL domain name is not valid any
+      more, or that these options do not provide service to the host's
+      current address (e.g., due to network ingress filtering
+      [RFC2827][RFC5358]).
+
+5.3.  Procedure of DNS Configuration
+
+   The procedure of DNS configuration through the RDNSS and DNSSL
+   options is the same as with any other ND option [RFC4861].
+
+5.3.1.  Procedure in IPv6 Host
+
+   When an IPv6 host receives DNS options (i.e., RDNSS option and DNSSL
+   option) 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 the value of the
+      Length field in the DNSSL option is greater than or equal to the
+      minimum value (2).
+
+
+
+
+
+Jeong, et al.                Standards Track                    [Page 8]
+
+RFC 6106                   IPv6 RA DNS Options             November 2010
+
+
+   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.
+
+   When the IPv6 host has gathered a sufficient number (e.g., three) of
+   RDNSS addresses (or DNS search domain names), it SHOULD maintain
+   RDNSS addresses (or DNS search domain names) by the sufficient number
+   such that the latest received RDNSS or DNSSL is more preferred to the
+   old ones; that is, when the number of RDNSS addresses (or DNS search
+   domain names) is already the sufficient number, the new one replaces
+   the old one that will expire first in terms of Lifetime.  As an
+   exceptional case, if the received RDNSS addresses (or DNS search
+   domain names) already exist in the IPv6 host, their Lifetime fields
+   update their Expiration-time, that is, when the corresponding DNS
+   information expires in the IPv6 host; note that when the Lifetime
+   field has zero, the corresponding RDNSS (or DNS search domain name)
+   is deleted from the IPv6 host.  Except for this update, the IPv6 host
+   SHOULD ignore other RDNSS addresses (or DNS search domain names)
+   within an RDNSS (or a DNSSL) option and/or additional RDNSS (or
+   DNSSL) options within an RA.  Refer to Section 6 for the detailed
+   procedure.  Note that the sufficient number is a system parameter, so
+   it can be determined by a local policy.  Also, separate parameters
+   can be specified for the sufficient number of RDNSS addresses and
+   that of DNS search domain names, respectively.  In this document,
+   three is RECOMMENDED as a sufficient number considering both the
+   robust DNS query and the reasonably time-bounded recognition of the
+   unreachability of DNS servers.
+
+   In the case where the DNS options of RDNSS and DNSSL can be obtained
+   from multiple sources, such as RA 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.
+   However, the ability to store at least three RDNSS addresses (or
+   DNSSL domain names) from at least two different sources is
+   RECOMMENDED.  The DNS options from Router Advertisements and DHCP
+   SHOULD be stored into 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 RA for DNS queries.  On the other hand, for DNS
+   options announced by RA, 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.  Refer to Section 7 for
+   the detailed discussion on SEND for RA DNS options.
+
+
+
+
+
+
+Jeong, et al.                Standards Track                    [Page 9]
+
+RFC 6106                   IPv6 RA DNS Options             November 2010
+
+
+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., RA 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 information
+   is provided by different sources may lead to problems.  Therefore,
+   the network administrator needs to configure DNS options in multiple
+   sources in order to prevent such problems from happening.
+
+   Second, if different DNS information is provided on different network
+   interfaces, this can lead to inconsistent behavior.  The IETF is
+   working on solving this problem for both DNS and other information
+   obtained by multiple interfaces [MIF-PROBLEM][MIF-PRACTICE].
+
+6.  Implementation Considerations
+
+   Note:  This non-normative section gives some hints for implementing
+      the processing of the RDNSS and DNSSL options in an IPv6 host.
+
+   For the configuration and management of DNS information, the
+   advertised DNS configuration information can be stored and managed in
+   both the DNS Repository and the Resolver Repository.
+
+   In environments where the DNS information is stored in user space and
+   ND runs in the kernel, it is necessary to synchronize the DNS
+   information (i.e., RDNSS addresses and DNS search domain names) in
+   kernel space and the Resolver Repository in user space.  For the
+   synchronization, an implementation where ND works in the kernel
+   should provide a write operation for updating DNS information from
+   the kernel to the Resolver Repository.  One simple approach is to
+   have a daemon (or a program that is called at defined intervals) that
+   keeps monitoring the Lifetimes of RDNSS addresses and DNS search
+   domain names all the time.  Whenever there is an expired entry in the
+   DNS Repository, the daemon can delete the corresponding entry from
+   the Resolver Repository.
+
+6.1.  DNS Repository Management
+
+   For DNS repository management, the kernel or user-space process
+   (depending on where RAs are processed) should maintain two data
+   structures: (i) DNS Server List that keeps the list of RDNSS
+   addresses and (ii) DNS Search List that 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:
+
+
+
+Jeong, et al.                Standards Track                   [Page 10]
+
+RFC 6106                   IPv6 RA DNS Options             November 2010
+
+
+   o  RDNSS address for DNS Server List: IPv6 address of the Recursive
+      DNS Server, which is available for recursive DNS resolution
+      service in the network advertising the RDNSS option.
+
+   o  DNSSL domain name for DNS Search List: DNS suffix domain names,
+      which are used to perform DNS query searches for short,
+      unqualified domain names in the network advertising the DNSSL
+      option.
+
+   o  Expiration-time for DNS Server List or DNS Search List: 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 system 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 field is updated to have a new Expiration-
+      time.  When Expiration-time becomes less than the current system
+      time, this entry is regarded as expired.
+
+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) into 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:
+
+      Step (a): Receive and parse the RDNSS option(s).  For the RDNSS
+      addresses in each RDNSS option, perform Steps (b) through (d).
+
+      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 situation.  That is, the
+      RDNSS can resign from its DNS service because the machine running
+      the RDNSS is out of service intentionally or unintentionally.
+      Also, under the renumbering situation, 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).
+
+
+
+
+
+Jeong, et al.                Standards Track                   [Page 11]
+
+RFC 6106                   IPv6 RA DNS Options             November 2010
+
+
+      Step (c): For each RDNSS address, if it already exists in the DNS
+      Server List, 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).
+
+      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 in front of 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
+      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 the 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 (e.g., campus network and company network)
+   through an RA message with DNSSL option(s), it stores the DNSSL
+   domain names (in order) into both the DNS Search List 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 as
+   follows:
+
+      Step (a): Receive and parse the DNSSL option(s).  For the DNSSL
+      domain names in each DNSSL option, perform Steps (b) through (d).
+
+      Step (b): For each DNSSL domain name, check the following: If the
+      DNSSL domain name already exists in the DNS Search List and the
+      DNSSL option's Lifetime field is set to zero, delete the
+      corresponding DNSSL entry from both the DNS Search List and the
+      Resolver Repository in order to prevent the DNSSL domain name from
+      being used any more for certain reasons in network management,
+
+
+
+Jeong, et al.                Standards Track                   [Page 12]
+
+RFC 6106                   IPv6 RA DNS Options             November 2010
+
+
+      e.g., the termination of the RDNSS or a renaming situation.  That
+      is, the RDNSS can resign from its DNS service because the machine
+      running the RDNSS is out of service intentionally or
+      unintentionally.  Also, under the renaming situation, the DNSSL
+      domain names will be changed, so the previous domain names should
+      not be used any more.  The processing of this DNSSL domain name is
+      finished here.  Otherwise, go to Step (c).
+
+      Step (c): For each DNSSL domain name, if it already exists in the
+      DNS Server List, 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).
+
+      Step (d): For each DNSSL domain name, if it does not exist in the
+      DNS Search List, register the DNSSL domain name and Lifetime with
+      the DNS Search List and then insert the DNSSL domain name in front
+      of the Resolver Repository.  In the case where the data structure
+      for the DNS Search List is full of DNSSL domain name entries (that
+      is, has more DNSSL domain names than the sufficient number
+      discussed in Section 5.3.1), delete from the DNS Server List the
+      entry with the shortest Expiration-time (i.e., the entry that will
+      expire first).  The corresponding DNSSL domain name is also
+      deleted from the Resolver Repository.  For the ordering of DNSSL
+      domain names in a DNSSL option, position the first DNSSL domain
+      name in the DNSSL option as the first one in the Resolver
+      Repository, the second DNSSL domain name in the option as the
+      second one in the repository, and so on.  This ordering allows the
+      DNSSL domain names in the DNSSL option to be preferred according
+      to their order in the DNSSL option for the DNS domain name used by
+      the DNS query.  The processing of these DNSSL domain name is
+      finished here.
+
+      The handling of expired DNSSLs is as follows: Whenever an entry
+      expires in the DNS Search List, the expired entry is deleted from
+      the DNS Search List, and also the DNSSL domain name corresponding
+      to the entry is deleted from the Resolver Repository.
+
+7.  Security Considerations
+
+   In this section, we analyze security threats related to DNS options
+   and then suggest 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
+
+
+
+
+Jeong, et al.                Standards Track                   [Page 13]
+
+RFC 6106                   IPv6 RA DNS Options             November 2010
+
+
+   attacker can let IPv6 hosts resolve a host name without a DNS suffix
+   into an unintended host's IP address with a fraudulent DNS Search
+   List.
+
+   These attacks are similar to Neighbor Discovery attacks that use
+   Redirect or Neighbor Advertisement messages to redirect traffic to
+   individual addresses of malicious parties.  That is, as a rogue
+   router, a malicious node on a LAN can promiscuously receive packets
+   for any router's Media Access Control (MAC) address and send packets
+   with the router's MAC address as the source MAC address in the Layer
+   2 (L2) header.  As a result, L2 switches send packets addressed to
+   the router to the malicious node.  Also, this attack can send
+   redirects that tell the hosts to send their traffic somewhere else.
+   The malicious node can send unsolicited RA or Neighbor Advertisement
+   (NA) replies, answer RS or Neighbor Solicitation (NS) requests, etc.
+   Thus, the attacks related to RDNSS and DNSSL are similar to both
+   Neighbor Discovery attacks and attacks against unauthenticated DHCP,
+   as both can be used for both "wholesale" traffic redirection and more
+   specific attacks.
+
+   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 independently of ND.
+
+7.2.  Recommendations
+
+   The Secure Neighbor Discovery (SEND) protocol [RFC3971] is used as a
+   security mechanism for ND.  It is RECOMMENDED that ND use SEND to
+   allow all the ND options including the RDNSS and DNSSL options to be
+   automatically included in the signatures.  Through SEND, the
+   transport for the RA options is integrity protected; that is, SEND
+   can prevent the spoofing of these DNS options with signatures.  Also,
+   SEND enables an IPv6 host to verify that the sender of an RA is
+   actually a router authorized to act as a router.  However, since any
+   valid SEND router can still insert RDNSS and DNSSL options, the
+   current SEND cannot verify which one is or is not authorized to send
+   the options.  Thus, this verification of the authorized routers for
+   ND options will be required.  [CSI-SEND-CERT] specifies the usage of
+   extended key for the certificate deployed in SEND.  This document
+   defines the roles of routers (i.e., routers acting as proxy and
+   address owner) and explains the authorization of the roles.  The
+   mechanism in this document can be extended to verify which routers
+   are authorized to insert RDNSS and DNSSL options.
+
+
+
+
+
+Jeong, et al.                Standards Track                   [Page 14]
+
+RFC 6106                   IPv6 RA DNS Options             November 2010
+
+
+   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 DHCP servers.  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 Router Advertisement messages including the RDNSS and
+   DNSSL options from unauthorized nodes.
+
+   An attacker may provide a bogus DNS Search List 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 defined in RFC 5006 [RFC5006], which was
+   assigned by the IANA as follows:
+
+                 Option Name                   Type
+                 Recursive DNS Server Option   25
+
+   The IANA has assigned a new IPv6 Neighbor Discovery Option type for
+   the DNSSL option defined in this document:
+
+                 Option Name                   Type
+                 DNS Search List Option        31
+
+   These options have been registered in the "Internet Control Message
+   Protocol version 6 (ICMPv6) Parameters" registry
+   (http://www.iana.org).
+
+9.  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, and Tony
+   Cheneau.  The authors sincerely appreciate their contributions.
+
+
+
+
+
+
+
+
+
+
+
+Jeong, et al.                Standards Track                   [Page 15]
+
+RFC 6106                   IPv6 RA DNS Options             November 2010
+
+
+10.  References
+
+10.1.  Normative References
+
+   [RFC2119]        Bradner, S., "Key words for use in RFCs to Indicate
+                    Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC4861]        Narten, T., Nordmark, E., Simpson, W., and H.
+                    Soliman, "Neighbor Discovery for IP version 6
+                    (IPv6)", RFC 4861, September 2007.
+
+   [RFC4862]        Thomson, S., Narten, T., and T. Jinmei, "IPv6
+                    Stateless Address Autoconfiguration", RFC 4862,
+                    September 2007.
+
+   [RFC1035]        Mockapetris, P., "Domain names - implementation and
+                    specification", STD 13, RFC 1035, November 1987.
+
+10.2.  Informative References
+
+   [RFC1034]        Mockapetris, P., "Domain names - concepts and
+                    facilities", STD 13, RFC 1034, November 1987.
+
+   [RFC3315]        Droms, R., Bound, J., Volz, B., Lemon, T., Perkins,
+                    C., and M. Carney, "Dynamic Host Configuration
+                    Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
+
+   [RFC3736]        Droms, R., "Stateless Dynamic Host Configuration
+                    Protocol (DHCP) Service for IPv6", RFC 3736,
+                    April 2004.
+
+   [RFC3646]        Droms, R., "DNS Configuration options for Dynamic
+                    Host Configuration Protocol for IPv6 (DHCPv6)",
+                    RFC 3646, December 2003.
+
+   [RFC5006]        Jeong, J., Park, S., Beloeil, L., and S.
+                    Madanapalli, "IPv6 Router Advertisement Option for
+                    DNS Configuration", RFC 5006, September 2007.
+
+   [RFC4339]        Jeong, J., "IPv6 Host Configuration of DNS Server
+                    Information Approaches", RFC 4339, February 2006.
+
+   [RFC3971]        Arkko, J., Kempf, J., Zill, B., and P. Nikander,
+                    "SEcure Neighbor Discovery (SEND)", RFC 3971,
+                    March 2005.
+
+
+
+
+
+
+Jeong, et al.                Standards Track                   [Page 16]
+
+RFC 6106                   IPv6 RA DNS Options             November 2010
+
+
+   [RFC5358]        Damas, J. and F. Neves, "Preventing Use of Recursive
+                    Nameservers in Reflector Attacks", BCP 140,
+                    RFC 5358, October 2008.
+
+   [RFC2827]        Ferguson, P. and D. Senie, "Network Ingress
+                    Filtering: Defeating Denial of Service Attacks which
+                    employ IP Source Address Spoofing", BCP 38,
+                    RFC 2827, May 2000.
+
+   [RFC1535]        Gavron, E., "A Security Problem and Proposed
+                    Correction With Widely Deployed DNS Software",
+                    RFC 1535, October 1993.
+
+   [RFC1536]        Kumar, A., Postel, J., Neuman, C., Danzig, P., and
+                    S. Miller, "Common DNS Implementation Errors and
+                    Suggested Fixes", RFC 1536, October 1993.
+
+   [MIF-PROBLEM]    Blanchet, M. and P. Seite, "Multiple Interfaces
+                    Problem Statement", Work in Progress, August 2010.
+
+   [MIF-PRACTICE]   Wasserman, M. and P. Seite, "Current Practices for
+                    Multiple Interface Hosts", Work in Progress,
+                    August 2010.
+
+   [CSI-SEND-CERT]  Gagliano, R., Krishnan, S., and A. Kukec,
+                    "Certificate profile and certificate management for
+                    SEND", Work in Progress, October 2010.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Jeong, et al.                Standards Track                   [Page 17]
+
+RFC 6106                   IPv6 RA DNS Options             November 2010
+
+
+Appendix A.  Changes from RFC 5006
+
+   The following changes were made from RFC 5006 "IPv6 Router
+   Advertisement Option for DNS Configuration":
+
+   o  Added the DNS Search List (DNSSL) option to support the
+      advertisement of DNS suffixes used in the DNS search along with
+      RDNSS option in RFC 5006.
+
+   o  Clarified the coexistence of RA options and DHCP options for DNS
+      configuration.
+
+   o  Modified the procedure in IPv6 host:
+
+      *  Clarified the procedure for DNS options in an IPv6 host.
+
+      *  Specified a sufficient number of RDNSS addresses or DNS search
+         domain names as three.
+
+      *  Specified a way to deal with DNS options from multiple sources,
+         such as RA and DHCP.
+
+   o  Modified the implementation considerations for DNSSL option
+      handling.
+
+   o  Modified the security considerations to consider more attack
+      scenarios and the corresponding possible solutions.
+
+   o  Modified the IANA considerations to require another IPv6 Neighbor
+      Discovery Option type for the DNSSL option.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Jeong, et al.                Standards Track                   [Page 18]
+
+RFC 6106                   IPv6 RA DNS Options             November 2010
+
+
+Authors' Addresses
+
+   Jaehoon Paul Jeong
+   Brocade Communications Systems/ETRI
+   6000 Nathan Ln N
+   Plymouth, MN  55442
+   USA
+
+   Phone: +1 763 268 7173
+   Fax:   +1 763 268 6800
+   EMail: pjeong@brocade.com
+   URI:   http://www.cs.umn.edu/~jjeong/
+
+
+   Soohong Daniel Park
+   Digital Media & Communications R&D Center
+   SAMSUNG Electronics
+   416 Maetan-3dong, Yeongtong-Gu
+   Suwon, Gyeonggi-Do  443-742
+   Korea
+
+   Phone: +82 31 279 8876
+   EMail: soohong.park@samsung.com
+
+
+   Luc Beloeil
+   France Telecom R&D
+   42, rue des coutures
+   BP 6243
+   14066 CAEN Cedex 4
+   France
+
+   Phone: +33 2 40 44 97 40
+   EMail: luc.beloeil@orange-ftgroup.com
+
+
+   Syam Madanapalli
+   iRam Technologies
+   #H304, Shriram Samruddhi, Thubarahalli
+   Bangalore - 560066
+   India
+
+   EMail: smadanapalli@gmail.com
+
+
+
+
+
+
+
+
+Jeong, et al.                Standards Track                   [Page 19]
+