draft-ietf-6man-rdnss-rfc6106bis-06.txt   draft-ietf-6man-rdnss-rfc6106bis-07.txt 
Network Working Group J. Jeong Network Working Group J. Jeong
Internet-Draft Sungkyunkwan University Internet-Draft Sungkyunkwan University
Obsoletes: 6106 (if approved) S. Park Obsoletes: 6106 (if approved) S. Park
Intended status: Standards Track SAMSUNG Electronics Intended status: Standards Track Korean Bible University
Expires: April 11, 2016 L. Beloeil Expires: September 7, 2016 L. Beloeil
France Telecom R&D France Telecom R&D
S. Madanapalli S. Madanapalli
iRam Technologies iRam Technologies
October 9, 2015 March 6, 2016
IPv6 Router Advertisement Options for DNS Configuration IPv6 Router Advertisement Options for DNS Configuration
draft-ietf-6man-rdnss-rfc6106bis-06 draft-ietf-6man-rdnss-rfc6106bis-07
Abstract Abstract
This document specifies IPv6 Router Advertisement options to allow This document specifies IPv6 Router Advertisement options to allow
IPv6 routers to advertise a list of DNS recursive server addresses IPv6 routers to advertise a list of DNS recursive server addresses
and a DNS Search List to IPv6 hosts. and a DNS Search List to IPv6 hosts.
This document obsoletes RFC 6106 and allows a higher default value of This document obsoletes RFC 6106 and allows a higher default value of
the lifetime of the RA DNS options to avoid the frequent expiry of the lifetime of the RA DNS options to avoid the frequent expiry of
the options on links with a relatively high rate of packet loss. the options on links with a relatively high rate of packet loss.
skipping to change at page 1, line 47 skipping to change at page 1, line 47
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 11, 2016. This Internet-Draft will expire on September 7, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 38 skipping to change at page 2, line 38
5.2. DNS Search List Option . . . . . . . . . . . . . . . . . . 7 5.2. DNS Search List Option . . . . . . . . . . . . . . . . . . 7
5.3. Procedure of DNS Configuration . . . . . . . . . . . . . . 8 5.3. Procedure of DNS Configuration . . . . . . . . . . . . . . 8
5.3.1. Procedure in IPv6 Host . . . . . . . . . . . . . . . . 8 5.3.1. Procedure in IPv6 Host . . . . . . . . . . . . . . . . 8
5.3.2. Warnings for DNS Options Configuration . . . . . . . . 9 5.3.2. Warnings for DNS Options Configuration . . . . . . . . 9
6. Implementation Considerations . . . . . . . . . . . . . . . . 9 6. Implementation Considerations . . . . . . . . . . . . . . . . 9
6.1. DNS Repository Management . . . . . . . . . . . . . . . . 10 6.1. DNS Repository Management . . . . . . . . . . . . . . . . 10
6.2. Synchronization between DNS Server List and Resolver 6.2. Synchronization between DNS Server List and Resolver
Repository . . . . . . . . . . . . . . . . . . . . . . . . 10 Repository . . . . . . . . . . . . . . . . . . . . . . . . 10
6.3. Synchronization between DNS Search List and Resolver 6.3. Synchronization between DNS Search List and Resolver
Repository . . . . . . . . . . . . . . . . . . . . . . . . 12 Repository . . . . . . . . . . . . . . . . . . . . . . . . 12
7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12
7.1. Security Threats . . . . . . . . . . . . . . . . . . . . . 13 7.1. Security Threats . . . . . . . . . . . . . . . . . . . . . 12
7.2. Recommendations . . . . . . . . . . . . . . . . . . . . . 14 7.2. Recommendations . . . . . . . . . . . . . . . . . . . . . 12
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
10.1. Normative References . . . . . . . . . . . . . . . . . . . 15 10.1. Normative References . . . . . . . . . . . . . . . . . . . 14
10.2. Informative References . . . . . . . . . . . . . . . . . . 15 10.2. Informative References . . . . . . . . . . . . . . . . . . 14
Appendix A. Changes from RFC 5006 . . . . . . . . . . . . . . . . 17 Appendix A. Changes from RFC 5006 . . . . . . . . . . . . . . . . 15
Appendix B. Changes from RFC 6106 . . . . . . . . . . . . . . . . 17 Appendix B. Changes from RFC 6106 . . . . . . . . . . . . . . . . 16
1. Introduction 1. Introduction
The purpose of this document is to standardize an IPv6 Router The purpose of this document is to standardize an IPv6 Router
Advertisement (RA) option for DNS Recursive Server Addresses used for Advertisement (RA) option for DNS Recursive Server Addresses used for
the DNS name resolution in IPv6 hosts. This RA option was originally the DNS name resolution in IPv6 hosts. This RA option was originally
specified in an earlier Experimental specification [RFC5006]. This specified in an earlier Experimental specification [RFC5006]. This
document obsoletes [RFC6106], allowing a higher default value of the document obsoletes [RFC6106], allowing a higher default value of the
lifetime of the RA DNS options to avoid the frequent expiry of the lifetime of the RA DNS options to avoid the frequent expiry of the
options on links with a relatively high rate of packet loss, and also options on links with a relatively high rate of packet loss, and also
skipping to change at page 3, line 50 skipping to change at page 3, line 50
document defines a mechanism based on IPv6 RA options to allow IPv6 document defines a mechanism based on IPv6 RA options to allow IPv6
hosts to perform the automatic DNS configuration. hosts to perform the automatic DNS configuration.
1.1. Applicability Statements 1.1. Applicability Statements
RA-based DNS configuration is a useful alternative in networks where RA-based DNS configuration is a useful alternative in networks where
an IPv6 host's address is autoconfigured through IPv6 stateless an IPv6 host's address is autoconfigured through IPv6 stateless
address autoconfiguration and where there is either no DHCPv6 address autoconfiguration and where there is either no DHCPv6
infrastructure at all or some hosts do not have a DHCPv6 client. The infrastructure at all or some hosts do not have a DHCPv6 client. The
intention is to enable the full configuration of basic networking intention is to enable the full configuration of basic networking
information for hosts without requiring DHCPv6. However, when in information for hosts without requiring DHCPv6. However, for
many networks some additional information needs to be distributed, networks that need to distribute additional information, DHCPv6 is
those networks are likely to employ DHCPv6. In these networks, RA- likely to be employed. In these networks, RA-based DNS configuration
based DNS configuration may not be needed. may not be needed.
RA-based DNS configuration allows an IPv6 host to acquire the DNS RA-based DNS configuration allows an IPv6 host to acquire the DNS
configuration (i.e., DNS recursive server addresses and DNS Search configuration (i.e., DNS recursive server addresses and DNS Search
List) for the link(s) to which the host is connected. Furthermore, List) for the link(s) to which the host is connected. Furthermore,
the host learns this DNS configuration from the same RA message that the host learns this DNS configuration from the same RA message that
provides configuration information for the link, thereby avoiding provides configuration information for the link.
also running DHCPv6.
The advantages and disadvantages of the RA-based approach are The advantages and disadvantages of the RA-based approach are
discussed in [RFC4339] along with other approaches, such as the DHCP discussed in [RFC4339] along with other approaches, such as the DHCP
and well-known anycast address approaches. and well-known anycast address approaches.
1.2. Coexistence of RA Options and DHCP Options for DNS Configuration 1.2. Coexistence of RA Options and DHCP Options for DNS Configuration
Two protocols exist to configure the DNS information on a host, the Two protocols exist to configure the DNS information on a host, the
Router Advertisement options described in this document and the Router Advertisement options described in this document and the
DHCPv6 options described in [RFC3646]. They can be used together. DHCPv6 options described in [RFC3646]. They can be used together.
skipping to change at page 5, line 22 skipping to change at page 5, line 22
and the second is the DNS Search List for DNS search domain names. and the second is the DNS Search List for DNS search domain names.
o Resolver Repository: Configuration repository with RDNSS addresses o Resolver Repository: Configuration repository with RDNSS addresses
and a DNS Search List that a DNS resolver on the host uses for DNS 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/ name resolution; for example, the Unix resolver file (i.e., /etc/
resolv.conf) and Windows registry. resolv.conf) and Windows registry.
4. Overview 4. Overview
This document standardizes the ND option called the RDNSS option This document standardizes the ND option called the RDNSS option
defined in [RFC5006] that contains the addresses of recursive DNS defined in [RFC6106] that contains the addresses of recursive DNS
servers. This document also defines a new ND option called the DNSSL servers. This document also standardizes the ND option called the
option for the Domain Search List. This is to maintain parity with DNSSL option defined in [RFC6106] that contains the Domain Search
the DHCPv6 options and to ensure that there is necessary List. This is to maintain parity with the DHCPv6 options and to
functionality to determine the search domains. ensure that there is necessary functionality to determine the search
domains.
The existing ND message (i.e., Router Advertisement) is used to carry The existing ND message (i.e., Router Advertisement) is used to carry
this information. An IPv6 host can configure the IPv6 addresses of this information. An IPv6 host can configure the IPv6 addresses of
one or more RDNSSes via RA messages. Through the RDNSS and DNSSL one or more RDNSSes via RA messages. Through the RDNSS and DNSSL
options, along with the prefix information option based on the ND options, along with the prefix information option based on the ND
protocol ([RFC4861] and [RFC4862]), an IPv6 host can perform the protocol ([RFC4861] and [RFC4862]), an IPv6 host can perform the
network configuration of its IPv6 address and the DNS information network configuration of its IPv6 address and the DNS information
simultaneously without needing DHCPv6 for the DNS configuration. The simultaneously without needing DHCPv6 for the DNS configuration. The
RA options for RDNSS and DNSSL can be used on any network that RA options for RDNSS and DNSSL can be used on any network that
supports the use of ND. supports the use of ND.
This approach requires the manual configuration or other automatic This approach requires the manual configuration or other automatic
mechanisms (e.g., DHCPv6 or vendor proprietary configuration mechanisms (e.g., DHCPv6 or vendor proprietary configuration
mechanisms) to configure the DNS information in routers sending the mechanisms) to configure the DNS information in routers sending the
advertisements. The automatic configuration of RDNSS addresses and a advertisements. The automatic configuration of RDNSS addresses and a
DNS Search List in routers is out of scope for this document. DNS Search List in routers is out of scope for this document.
5. Neighbor Discovery Extension 5. Neighbor Discovery Extension
The IPv6 DNS configuration mechanism in this document needs two new The IPv6 DNS configuration mechanism in this document needs two ND
ND options in Neighbor Discovery: (i) the Recursive DNS Server options in Neighbor Discovery: (i) the Recursive DNS Server (RDNSS)
(RDNSS) option and (ii) the DNS Search List (DNSSL) option. option and (ii) the DNS Search List (DNSSL) option.
5.1. Recursive DNS Server Option 5.1. Recursive DNS Server Option
The RDNSS option contains one or more IPv6 addresses of recursive DNS The RDNSS option contains one or more IPv6 addresses of recursive DNS
servers. All of the addresses share the same Lifetime value. If it servers. All of the addresses share the same Lifetime value. If it
is desirable to have different Lifetime values, multiple RDNSS is desirable to have different Lifetime values, multiple RDNSS
options can be used. Figure 1 shows the format of the RDNSS option. options can be used. Figure 1 shows the format of the RDNSS option.
0 1 2 3 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 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
skipping to change at page 6, line 38 skipping to change at page 6, line 38
by the IANA: 25 by the IANA: 25
Length 8-bit unsigned integer. The length of the option Length 8-bit unsigned integer. The length of the option
(including the Type and Length fields) is in units of (including the Type and Length fields) is in units of
8 octets. The minimum value is 3 if one IPv6 address 8 octets. The minimum value is 3 if one IPv6 address
is contained in the option. Every additional RDNSS is contained in the option. Every additional RDNSS
address increases the length by 2. The Length field address increases the length by 2. The Length field
is used by the receiver to determine the number of is used by the receiver to determine the number of
IPv6 addresses in the option. IPv6 addresses in the option.
Lifetime 32-bit unsigned integer. The maximum time, in Lifetime 32-bit unsigned integer. The maximum time in
seconds (relative to the time the packet is sent), seconds (relative to the time the packet is received)
over which this RDNSS address MAY be used for name over which these RDNSS addresses MAY be used for name
resolution. The value of Lifetime SHOULD by default resolution. The value of Lifetime SHOULD by default
be at least 3 * MaxRtrAdvInterval where be at least 3 * MaxRtrAdvInterval where
MaxRtrAdvInterval is the Maximum RA Interval defined MaxRtrAdvInterval is the Maximum RA Interval defined
in [RFC4861]. A value of all one bits (0xffffffff) in [RFC4861]. A value of all one bits (0xffffffff)
represents infinity. A value of zero means that the represents infinity. A value of zero means that the
RDNSS address MUST no longer be used. RDNSS addresses MUST no longer be used.
Addresses of IPv6 Recursive DNS Servers Addresses of IPv6 Recursive DNS Servers
One or more 128-bit IPv6 addresses of the recursive One or more 128-bit IPv6 addresses of the recursive
DNS servers. The number of addresses is determined DNS servers. The number of addresses is determined
by the Length field. That is, the number of by the Length field. That is, the number of
addresses is equal to (Length - 1) / 2. addresses is equal to (Length - 1) / 2.
Note: The addresses for recursive DNS servers in the RDNSS option Note: The addresses for recursive DNS servers in the RDNSS option
MAY be link-local addresses. Such link-local addresses SHOULD be MAY be link-local addresses. Such link-local addresses SHOULD be
registered into the resolver repository along with the registered into the resolver repository along with the
corresponding link zone indices of the links that receive the corresponding link zone indices of the links that receive the
RDNSS option(s) for them. The link zone indices SHOULD be RDNSS option(s) for them. The link-local addresses MAY be
represented in the textual format for scoped addresses as represented with their link zone indices in the textual format for
described in [RFC4007]. When a resolver sends a DNS query message scoped addresses as described in [RFC4007]. When a resolver sends
to an RDNSS with a link-local address, it MUST use the a DNS query message to an RDNSS with a link-local address, it MUST
corresponding link. use the corresponding link.
5.2. DNS Search List Option 5.2. DNS Search List Option
The DNSSL option contains one or more domain names of DNS suffixes. 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 All of the domain names share the same Lifetime value. If it is
desirable to have different Lifetime values, multiple DNSSL options desirable to have different Lifetime values, multiple DNSSL options
can be used. Figure 2 shows the format of the DNSSL option. can be used. Figure 2 shows the format of the DNSSL option.
0 1 2 3 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 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
skipping to change at page 7, line 49 skipping to change at page 7, line 49
by the IANA: 31 by the IANA: 31
Length 8-bit unsigned integer. The length of the option Length 8-bit unsigned integer. The length of the option
(including the Type and Length fields) is in units of (including the Type and Length fields) is in units of
8 octets. The minimum value is 2 if at least one 8 octets. The minimum value is 2 if at least one
domain name is contained in the option. The Length domain name is contained in the option. The Length
field is set to a multiple of 8 octets to accommodate field is set to a multiple of 8 octets to accommodate
all the domain names in the field of Domain Names of all the domain names in the field of Domain Names of
DNS Search List. DNS Search List.
Lifetime 32-bit unsigned integer. The maximum time, in Lifetime 32-bit unsigned integer. The maximum time in
seconds (relative to the time the packet is sent), seconds (relative to the time the packet is received)
over which this DNSSL domain name MAY be used for over which these DNSSL domain names MAY be used for
name resolution. The Lifetime value has the same name resolution. The Lifetime value has the same
semantics as with the RDNSS option. That is, semantics as with the RDNSS option. That is,
Lifetime SHOULD by default be at least Lifetime SHOULD by default be at least
3 * MaxRtrAdvInterval. A value of all one bits 3 * MaxRtrAdvInterval. A value of all one bits
(0xffffffff) represents infinity. A value of zero (0xffffffff) represents infinity. A value of zero
means that the DNSSL domain name MUST no longer be means that the DNSSL domain names MUST no longer be
used. used.
Domain Names of DNS Search List Domain Names of DNS Search List
One or more domain names of DNS Search List that MUST One or more domain names of DNS Search List that MUST
be encoded using the technique described in Section be encoded as described in Section 3.1 of [RFC1035].
3.1 of [RFC1035]. By this technique, each domain By this technique, each domain name is represented as
name is represented as a sequence of labels ending in a sequence of labels ending in a zero octet, defined
a zero octet, defined as domain name representation. as domain name representation. For more than one
For more than one domain name, the corresponding domain name, the corresponding domain name
domain name representations are concatenated as they representations are concatenated as they are. Note
are. Note that for the simple decoding, the domain that for the simple decoding, the domain names MUST
names MUST NOT be encoded in a compressed form, as NOT be encoded in a compressed form, as described in
described in Section 4.1.4 of [RFC1035]. Because the Section 4.1.4 of [RFC1035]. Because the size of this
size of this field MUST be a multiple of 8 octets, field MUST be a multiple of 8 octets, for the minimum
for the minimum multiple including the domain name multiple including the domain name representations,
representations, the remaining octets other than the the remaining octets other than the encoding parts of
encoding parts of the domain name representations the domain name representations MUST be padded with
MUST be padded with zeros. zeros.
5.3. Procedure of DNS Configuration 5.3. Procedure of DNS Configuration
The procedure of DNS configuration through the RDNSS and DNSSL The procedure of DNS configuration through the RDNSS and DNSSL
options is the same as with any other ND option [RFC4861]. options is the same as with any other ND option [RFC4861].
5.3.1. Procedure in IPv6 Host 5.3.1. Procedure in IPv6 Host
When an IPv6 host receives DNS options (i.e., RDNSS option and DNSSL When an IPv6 host receives DNS options (i.e., RDNSS option and DNSSL
option) through RA messages, it processes the options as follows: option) through RA messages, it processes the options as follows:
skipping to change at page 9, line 34 skipping to change at page 9, line 34
interfaces. First, in the case of multiple sources for DNS options 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 (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 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 host uses DNS information and what source addresses it uses to send
DNS queries. As a result, configurations where different information DNS queries. As a result, configurations where different information
is provided by different sources may lead to problems. Therefore, is provided by different sources may lead to problems. Therefore,
the network administrator needs to configure DNS options in multiple the network administrator needs to configure DNS options in multiple
sources in order to prevent such problems from happening. sources in order to prevent such problems from happening.
Second, if different DNS information is provided on different network Second, if different DNS information is provided on different network
interfaces, this can lead to inconsistent behavior. The IETF is interfaces, this can lead to inconsistent behavior. The IETF worked
working on solving this problem for both DNS and other information on solving this problem for both DNS and other information obtained
obtained by multiple interfaces [MIF-PROBLEM][MIF-PRACTICE]. by multiple interfaces [RFC6418][RFC6419], and standardized the
solution for RDNSS selection for multi-interfaced nodes in [RFC6731],
which is based on DHCP.
6. Implementation Considerations 6. Implementation Considerations
Note: This non-normative section gives some hints for implementing Note: This non-normative section gives some hints for implementing
the processing of the RDNSS and DNSSL options in an IPv6 host. the processing of the RDNSS and DNSSL options in an IPv6 host.
For the configuration and management of DNS information, the For the configuration and management of DNS information, the
advertised DNS configuration information can be stored and managed in advertised DNS configuration information can be stored and managed in
both the DNS Repository and the Resolver Repository. both the DNS Repository and the Resolver Repository.
In environments where the DNS information is stored in user space and In environments where the DNS information is stored in user space and
ND runs in the kernel, it is necessary to synchronize the DNS ND runs in the kernel, it is necessary to synchronize the DNS
information (i.e., RDNSS addresses and DNS search domain names) in information (i.e., RDNSS addresses and DNS search domain names) in
kernel space and the Resolver Repository in user space. For the kernel space and the Resolver Repository in user space. In these
synchronization, an implementation where ND works in the kernel environments, a user space application cannot receive RA via an
should provide a write operation for updating DNS information from ICMPv6 socket using the standard advanced socket application program
the kernel to the Resolver Repository. One simple approach is to interface (API) in [RFC3542]. For the synchronization, an
have a daemon (or a program that is called at defined intervals) that implementation where ND works in the kernel should provide a write
keeps monitoring the Lifetimes of RDNSS addresses and DNS search operation for updating DNS information from the kernel to the
domain names all the time. Whenever there is an expired entry in the Resolver Repository. One simple approach is to have a daemon (or a
DNS Repository, the daemon can delete the corresponding entry from program that is called at defined intervals) that keeps monitoring
the Resolver Repository. 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 6.1. DNS Repository Management
For DNS repository management, the kernel or user-space process For DNS repository management, the kernel or user-space process
(depending on where RAs are processed) should maintain two data (depending on where RAs are processed) should maintain two data
structures: (i) DNS Server List that keeps the list of RDNSS structures: (i) DNS Server List that keeps the list of RDNSS
addresses and (ii) DNS Search List that keeps the list of DNS search 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 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: RDNSS address (or DNSSL domain name) and Expiration-time as follows:
skipping to change at page 12, line 13 skipping to change at page 12, line 13
entry is deleted from the Resolver Repository. entry is deleted from the Resolver Repository.
6.3. Synchronization between DNS Search List and Resolver Repository 6.3. Synchronization between DNS Search List and Resolver Repository
When an IPv6 host receives the information of multiple DNSSL domain When an IPv6 host receives the information of multiple DNSSL domain
names within a network (e.g., campus network and company network) names within a network (e.g., campus network and company network)
through an RA message with DNSSL option(s), it stores the DNSSL through an RA message with DNSSL option(s), it stores the DNSSL
domain names (in order) into both the DNS Search List and the domain names (in order) into both the DNS Search List and the
Resolver Repository. The processing of the DNSSL consists of (i) 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 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 handling of expired DNSSLs. The processing of DNSSL option(s) is the
follows: same with that of RDNSS option(s) in Section 6.2 except Step (b).
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,
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 In Step (b), if the DNSSL domain name already exists in the DNS
expires in the DNS Search List, the expired entry is deleted from Search List and the DNSSL option's Lifetime field is set to zero,
the DNS Search List, and also the DNSSL domain name corresponding delete the corresponding DNSSL entry from both the DNS Search List
to the entry is deleted from the Resolver Repository. and the Resolver Repository in order to prevent the DNSSL domain name
from being used any more for certain reasons in network management,
e.g., the termination of the usage of the DNSSL domain name. That
is, the DNSSL domain name may not be used any more by the policy of
the network.
7. Security Considerations 7. Security Considerations
In this section, we analyze security threats related to DNS options In this section, we analyze security threats related to DNS options
and then suggest recommendations to cope with such security threats. and then suggest recommendations to cope with such security threats.
7.1. Security Threats 7.1. Security Threats
For the RDNSS option, an attacker could send an RA with a fraudulent For the RDNSS option, an attacker could send an RA with a fraudulent
RDNSS address, misleading IPv6 hosts into contacting an unintended RDNSS address, misleading IPv6 hosts into contacting an unintended
DNS server for DNS name resolution. Also, for the DNSSL option, an DNS server for DNS name resolution. Also, for the DNSSL option, an
attacker can let IPv6 hosts resolve a host name without a DNS suffix 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 into an unintended host's IP address with a fraudulent DNS Search
List. List. These attacks are similar to ND attacks specified in [RFC4861]
that use Redirect or Neighbor Advertisement messages to redirect
These attacks are similar to Neighbor Discovery attacks that use traffic to individual addresses of malicious parties.
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 However, the security of these RA options for DNS configuration does
not affect ND protocol security [RFC4861]. This is because learning not affect ND protocol security [RFC4861]. This is because learning
DNS information via the RA options cannot be worse than learning bad DNS information via the RA options cannot be worse than learning bad
router information via the RA options. Therefore, the vulnerability router information via the RA options. Therefore, the vulnerability
of ND is not worse and is a subset of the attacks that any node of ND is not worse and is a subset of the attacks that any node
attached to a LAN can do independently of ND. attached to a LAN can do independently of ND.
7.2. Recommendations 7.2. Recommendations
The Secure Neighbor Discovery (SEND) protocol [RFC3971] is used as a The Secure Neighbor Discovery (SEND) protocol [RFC3971] MAY be used
security mechanism for ND. It is RECOMMENDED that ND use SEND to 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 allow all the ND options including the RDNSS and DNSSL options to be
automatically included in the signatures. Through SEND, the automatically included in the signatures. Other approaches specified
transport for the RA options is integrity protected; that is, SEND in [RFC4861] can be used for securing the RA options for DNS
can prevent the spoofing of these DNS options with signatures. Also, configuration.
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.
It is common for network devices such as switches to include It is common for network devices such as switches to include
mechanisms to block unauthorized ports from running a DHCPv6 server mechanisms to block unauthorized ports from running a DHCPv6 server
to provide protection from rogue DHCPv6 servers [RFC7610]. That to provide protection from rogue DHCPv6 servers [RFC7610]. That
means that an attacker on other ports cannot insert bogus DNS servers means that an attacker on other ports cannot insert bogus DNS servers
using DHCPv6. The corresponding technique for network devices is using DHCPv6. The corresponding technique for network devices is
RECOMMENDED to block rogue Router Advertisement messages [RFC6104] RECOMMENDED to block rogue Router Advertisement messages [RFC6104]
including the RDNSS and DNSSL options from unauthorized nodes. including the RDNSS and DNSSL options from unauthorized nodes.
An attacker may provide a bogus DNS Search List option in order to 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 cause the victim to send DNS queries to a specific DNS server when
the victim queries non-FQDNs (fully qualified domain names). For the victim queries non-FQDNs (fully qualified domain names). For
this attack, the DNS resolver in IPv6 hosts can mitigate the this attack, the DNS resolver in IPv6 hosts can mitigate the
vulnerability with the recommendations mentioned in [RFC1535], vulnerability with the recommendations mentioned in [RFC1535],
[RFC1536], and [RFC3646]. [RFC1536], and [RFC3646].
8. IANA Considerations 8. IANA Considerations
The RDNSS option defined in this document uses the IPv6 Neighbor The RDNSS option defined in this document uses the IPv6 Neighbor
Discovery Option type defined in RFC 5006 [RFC5006], which was Discovery Option type defined in RFC 6106 [RFC6106], which was
assigned by the IANA as follows: assigned by the IANA as follows:
Option Name Type Option Name Type
Recursive DNS Server Option 25 Recursive DNS Server Option 25
The DNSSL option defined in this document uses the IPv6 Neighbor The DNSSL option defined in this document uses the IPv6 Neighbor
Discovery Option type defined in RFC 6106 [RFC6106], which was Discovery Option type defined in RFC 6106 [RFC6106], which was
assigned by the IANA as follows: assigned by the IANA as follows:
Option Name Type Option Name Type
skipping to change at page 15, line 19 skipping to change at page 13, line 50
Protocol version 6 (ICMPv6) Parameters" registry (http:// Protocol version 6 (ICMPv6) Parameters" registry (http://
www.iana.org/assignments/icmpv6-parameters/ www.iana.org/assignments/icmpv6-parameters/
icmpv6-parameters.xhtml#icmpv6-parameters-5). icmpv6-parameters.xhtml#icmpv6-parameters-5).
9. Acknowledgements 9. Acknowledgements
This document has greatly benefited from inputs by Robert Hinden, This document has greatly benefited from inputs by Robert Hinden,
Pekka Savola, Iljitsch van Beijnum, Brian Haberman, Tim Chown, Erik Pekka Savola, Iljitsch van Beijnum, Brian Haberman, Tim Chown, Erik
Nordmark, Dan Wing, Jari Arkko, Ben Campbell, Vincent Roca, Tony Nordmark, Dan Wing, Jari Arkko, Ben Campbell, Vincent Roca, Tony
Cheneau, Fernando Gont, Jen Linkova, Ole Troan, Mark Smith, Tatuya Cheneau, Fernando Gont, Jen Linkova, Ole Troan, Mark Smith, Tatuya
Jinmei, Lorenzo Colitti, Tore Anderson, and David Farmer. The Jinmei, Lorenzo Colitti, Tore Anderson, David Farmer, and Bing Liu.
authors sincerely appreciate their contributions. The authors sincerely appreciate their contributions.
10. References 10. References
10.1. Normative References 10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
Soliman, "Neighbor Discovery for IP version 6 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
(IPv6)", RFC 4861, September 2007. September 2007.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Stateless Address Autoconfiguration", RFC 4862, Address Autoconfiguration", RFC 4862, September 2007.
September 2007.
[RFC1035] Mockapetris, P., "Domain names - implementation and [RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987. specification", STD 13, RFC 1035, November 1987.
[RFC4007] Deering, S., Haberman, B., Jinmei, T., Nordmark, E., [RFC4007] Deering, S., Haberman, B., Jinmei, T., Nordmark, E., and
and B. Zill, "IPv6 Scoped Address Architecture", B. Zill, "IPv6 Scoped Address Architecture", RFC 4007,
RFC 4007, March 2005. March 2005.
10.2. Informative References 10.2. Informative References
[RFC1034] Mockapetris, P., "Domain names - concepts and [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
facilities", STD 13, RFC 1034, November 1987. STD 13, RFC 1034, November 1987.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
C., and M. Carney, "Dynamic Host Configuration and M. Carney, "Dynamic Host Configuration Protocol for
Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003. IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3736] Droms, R., "Stateless Dynamic Host Configuration [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol
Protocol (DHCP) Service for IPv6", RFC 3736, (DHCP) Service for IPv6", RFC 3736, April 2004.
April 2004.
[RFC3646] Droms, R., "DNS Configuration options for Dynamic [RFC3646] Droms, R., "DNS Configuration options for Dynamic Host
Host Configuration Protocol for IPv6 (DHCPv6)", Configuration Protocol for IPv6 (DHCPv6)", RFC 3646,
RFC 3646, December 2003. December 2003.
[RFC5006] Jeong, J., Park, S., Beloeil, L., and S. [RFC5006] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli,
Madanapalli, "IPv6 Router Advertisement Option for "IPv6 Router Advertisement Option for DNS Configuration",
DNS Configuration", RFC 5006, September 2007. RFC 5006, September 2007.
[RFC6106] Jeong, J., Park, S., Beloeil, L., and S. [RFC6106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli,
Madanapalli, "IPv6 Router Advertisement Options for "IPv6 Router Advertisement Options for DNS Configuration",
DNS Configuration", RFC 6106, November 2010. RFC 6106, November 2010.
[RFC4339] Jeong, J., "IPv6 Host Configuration of DNS Server [RFC4339] Jeong, J., "IPv6 Host Configuration of DNS Server
Information Approaches", RFC 4339, February 2006. Information Approaches", RFC 4339, February 2006.
[RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
"SEcure Neighbor Discovery (SEND)", RFC 3971, Neighbor Discovery (SEND)", RFC 3971, March 2005.
March 2005.
[RFC6104] Chown, T. and S. Venaas, "Rogue IPv6 Router [RFC6104] Chown, T. and S. Venaas, "Rogue IPv6 Router Advertisement
Advertisement Problem Statement", RFC 6104, Problem Statement", RFC 6104, February 2011.
February 2011.
[RFC7610] Gont, F., Liu, W., and G. Van de Velde, "DHCPv6- [RFC7610] Gont, F., Liu, W., and G. Van de Velde, "DHCPv6-Shield:
Shield: Protecting against Rogue DHCPv6 Servers", Protecting against Rogue DHCPv6 Servers", RFC 7610,
RFC 7610, August 2015. August 2015.
[RFC1535] Gavron, E., "A Security Problem and Proposed [RFC1535] Gavron, E., "A Security Problem and Proposed Correction
Correction With Widely Deployed DNS Software", With Widely Deployed DNS Software", RFC 1535,
RFC 1535, October 1993. October 1993.
[RFC1536] Kumar, A., Postel, J., Neuman, C., Danzig, P., and [RFC1536] Kumar, A., Postel, J., Neuman, C., Danzig, P., and S.
S. Miller, "Common DNS Implementation Errors and Miller, "Common DNS Implementation Errors and Suggested
Suggested Fixes", RFC 1536, October 1993. Fixes", RFC 1536, October 1993.
[MIF-PROBLEM] Blanchet, M. and P. Seite, "Multiple Interfaces [RFC6418] Blanchet, M. and P. Seite, "Multiple Interfaces and
Problem Statement", Work in Progress, August 2010. Provisioning Domains Problem Statement", RFC 6418,
November 2011.
[MIF-PRACTICE] Wasserman, M. and P. Seite, "Current Practices for [RFC6419] Wasserman, M. and P. Seite, "Current Practices for
Multiple Interface Hosts", Work in Progress, Multiple-Interface Hosts", RFC 6419, November 2011.
August 2010.
[CSI-SEND-CERT] Gagliano, R., Krishnan, S., and A. Kukec, [RFC6731] Savolainen, T., Kato, J., and T. Lemon, "Improved
"Certificate profile and certificate management for Recursive DNS Server Selection for Multi-Interfaced
SEND", Work in Progress, October 2010. Nodes", RFC 6731, December 2012.
[RFC3542] Stevens, W., Thomas, M., Nordmark, E., and T. Jinmei,
"Advanced Sockets Application Program Interface (API) for
IPv6", RFC 3542, May 2003.
Appendix A. Changes from RFC 5006 Appendix A. Changes from RFC 5006
The following changes were made from RFC 5006 "IPv6 Router The following changes were made from RFC 5006 "IPv6 Router
Advertisement Option for DNS Configuration": Advertisement Option for DNS Configuration":
o Added the DNS Search List (DNSSL) option to support the o Added the DNS Search List (DNSSL) option to support the
advertisement of DNS suffixes used in the DNS search along with advertisement of DNS suffixes used in the DNS search along with
RDNSS option in RFC 5006. RDNSS option in RFC 5006.
skipping to change at page 18, line 34 skipping to change at page 17, line 17
DNSSL options should be limited is removed. By this removal, when DNSSL options should be limited is removed. By this removal, when
the set of unique DNSSL values are not equivalent, none of them the set of unique DNSSL values are not equivalent, none of them
are ignored for hostname lookups. are ignored for hostname lookups.
Authors' Addresses Authors' Addresses
Jaehoon Paul Jeong Jaehoon Paul Jeong
Department of Software Department of Software
Sungkyunkwan University Sungkyunkwan University
2066 Seobu-Ro, Jangan-Gu 2066 Seobu-Ro, Jangan-Gu
Suwon, Gyeonggi-Do 440-746 Suwon, Gyeonggi-Do 16419
Republic of Korea Republic of Korea
Phone: +82 31 299 4957 Phone: +82 31 299 4957
Fax: +82 31 290 7996 Fax: +82 31 290 7996
EMail: pauljeong@skku.edu EMail: pauljeong@skku.edu
URI: http://cpslab.skku.edu/people-jaehoon-jeong.php URI: http://iotlab.skku.edu/people-jaehoon-jeong.php
Soohong Daniel Park Soohong Daniel Park
Software R&D Center Department of Computer Software
SAMSUNG Electronics Korean Bible University
129 Samsung-Ro, Yeongtong-Gu 205 SangGye7-Dong, Nowon-Gu
Suwon, Gyeonggi-Do 443-742 Seoul 01757
Republic of Korea Republic of Korea
Phone: +82 31 279 8876 Phone: +82 2 950 5494
EMail: soohong.park@samsung.com EMail: daniel@bible.ac.kr
Luc Beloeil Luc Beloeil
France Telecom R&D France Telecom R&D
42, rue des coutures 42, rue des coutures
BP 6243 BP 6243
14066 CAEN Cedex 4 14066 CAEN Cedex 4
France France
Phone: +33 2 40 44 97 40 Phone: +33 2 40 44 97 40
EMail: luc.beloeil@orange-ftgroup.com EMail: luc.beloeil@orange-ftgroup.com
Syam Madanapalli Syam Madanapalli
iRam Technologies iRam Technologies
#H304, Shriram Samruddhi, Thubarahalli #H304, Shriram Samruddhi, Thubarahalli
Bangalore - 560066 Bangalore - 560066
India India
EMail: smadanapalli@gmail.com EMail: smadanapalli@gmail.com
 End of changes. 50 change blocks. 
216 lines changed or deleted 159 lines changed or added

This html diff was produced by rfcdiff 1.44. The latest version is available from http://tools.ietf.org/tools/rfcdiff/