draft-ietf-6man-dns-options-bis-00.txt   draft-ietf-6man-dns-options-bis-01.txt 
Network Working Group J. Jeong, Ed. Network Working Group J. Jeong, Ed.
Internet-Draft Brocade/ETRI Internet-Draft Brocade/ETRI
Obsoletes: 5006 (if approved) S. Park Obsoletes: 5006 (if approved) S. Park
Intended status: Standards Track SAMSUNG Electronics Intended status: Standards Track SAMSUNG Electronics
Expires: October 7, 2010 L. Beloeil Expires: November 19, 2010 L. Beloeil
France Telecom R&D France Telecom R&D
S. Madanapalli S. Madanapalli
Ordyn Technologies Ordyn Technologies
April 5, 2010 May 18, 2010
IPv6 Router Advertisement Options for DNS Configuration RFC 5006-bis IPv6 Router Advertisement Options for DNS Configuration RFC 5006-bis
draft-ietf-6man-dns-options-bis-00 draft-ietf-6man-dns-options-bis-01
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.
Status of This Memo Status of This Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
skipping to change at page 1, line 43 skipping to change at page 1, line 43
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 October 7, 2010. This Internet-Draft will expire on November 19, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 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
skipping to change at page 2, line 22 skipping to change at page 2, line 22
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Applicability Statements . . . . . . . . . . . . . . . . . 3 1.1. Applicability Statements . . . . . . . . . . . . . . . . . 3
1.2. Coexistence of RA Options and DHCP Options for DNS 1.2. Coexistence of RA Options and DHCP Options for DNS
Configuration . . . . . . . . . . . . . . . . . . . . . . 4 Configuration . . . . . . . . . . . . . . . . . . . . . . 4
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
5. Neighbor Discovery Extension . . . . . . . . . . . . . . . . . 6 5. Neighbor Discovery Extension . . . . . . . . . . . . . . . . . 5
5.1. Recursive DNS Server Option . . . . . . . . . . . . . . . 6 5.1. Recursive DNS Server Option . . . . . . . . . . . . . . . 5
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
6. Implementation Considerations . . . . . . . . . . . . . . . . 9 6. Implementation Considerations . . . . . . . . . . . . . . . . 9
6.1. DNS Repository Management . . . . . . . . . . . . . . . . 9 6.1. DNS Repository Management . . . . . . . . . . . . . . . . 9
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 . . . . . . . . . . . . . . . . . . . . . . . . 11 Repository . . . . . . . . . . . . . . . . . . . . . . . . 11
7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
10.1. Normative References . . . . . . . . . . . . . . . . . . . 14 10.1. Normative References . . . . . . . . . . . . . . . . . . . 13
10.2. Informative References . . . . . . . . . . . . . . . . . . 14 10.2. Informative References . . . . . . . . . . . . . . . . . . 14
1. Introduction 1. Introduction
The purpose of this document is to standardize IPv6 Router The purpose of this document is to standardize IPv6 Router
Advertisement (RA) option for DNS configuration in IPv6 hosts Advertisement (RA) option for DNS configuration in IPv6 hosts
specified in [RFC5006] and also to define a new RA option for Domain specified in an earlier experimental specification [RFC5006] and also
Name Search lists. to define a new RA option for Domain Name Search lists.
Neighbor Discovery (ND) for IP Version 6 and IPv6 Stateless Address Neighbor Discovery (ND) for IP Version 6 and IPv6 Stateless Address
Autoconfiguration provide ways to configure either fixed or mobile Autoconfiguration provide ways to configure either fixed or mobile
nodes with one or more IPv6 addresses, default routers and some other nodes with one or more IPv6 addresses, default routers and some other
parameters [RFC4861][RFC4862]. Most Internet services are identified parameters [RFC4861][RFC4862]. Most Internet services are identified
by using a DNS name. The two RA options defined in this document 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 provide the DNS information needed for an IPv6 host to reach Internet
services. services.
It is infeasible for nomadic hosts, such as laptops, to be configured It is infeasible to manually configure nomadic hosts each time they
manually with a DNS resolver each time they connect to a different connect to a different network. While a one-time static
wireless LAN (WLAN) such as IEEE 802.11 a/b/g [IEEE-802.11] configuration is possible, it is generally not desirable on general-
[IEEE-802.11a][IEEE-802.11b][IEEE-802.11g]. This document defines a purpose hosts such as laptops. For instance, locally defined name
mechanism based on IPv6 RA options to allow IPv6 hosts to perform the spaces would not be available to the host if it were to run its own
automatic DNS configuration. As an alternative to the DNS name server software directly connected to the global DNS.
configuration provided by DHCP [RFC3315][RFC3736][RFC3646], the RA-
based DNS configuration can allow network operators or users to The DNS information can also be provided through DHCP
select an appropriate automatic DNS configuration for IPv6 hosts, [RFC3315][RFC3736][RFC3646]. However, the access to DNS is a
depending on the types of their networks [RFC4339]. 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 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 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, where the delays in acquiring server address autoconfiguration, and where there is either no DHCPv6
addresses and communicating with the servers are critical, or where infrastructure at all or some hosts do not have a DHCPv6 client. The
the network operator or host operator does not want the additional intention is to enable the full configuration of basic networking
operational complexity of running DHCPv6 to provide the same information for hosts without requiring DHCPv6. However, when in
information to all hosts on the network. RA-based DNS configuration many networks some additional information needs to be distributed,
allows the host to acquire the DNS configuration (i.e., DNS recursive those networks are likely to employ DHCPv6. In these networks RA-
server addresses and DNS search list) for the link(s) to which the based DNS configuration may not be needed.
host is connected. Furthermore, it learns this DNS configuration
from the same RA message that provides configuration information for RA-based DNS configuration allows an IPv6 host to acquire the DNS
the link, thereby avoiding also running DHCPv6. This can be configuration (i.e., DNS recursive server addresses and DNS search
beneficial in some mobile environments, such as with Mobile IPv6 list) for the link(s) to which the host is connected. Furthermore,
[RFC3775]. 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 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 addresses approaches. and well-known anycast addresses 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.
[RFC4339]. To order the RA and DHCP approaches, the O (Other The rules governing the decision to use stateful configuration
stateful configuration) flag can be used in the RA message [RFC4861]. mechanisms are specified in [RFC4861]. Hosts conforming to this
The O flag is defined along with the M (Managed address specification MUST extract DNS information from Router Advertisement
configuration) flag in the Router Advertisement Message Format of messages, unless static DNS configuration has been specified by the
[RFC4861] as follows: user. If there is DNS information available from multiple Router
Advertisements and/or from DHCP, the host MUST maintain an ordered
Fields: list of this information as specified in Section 5.3.1.
M 1-bit "Managed address configuration" flag. When
set, it indicates that addresses are available via
Dynamic Host Configuration Protocol (DHCPv6) in
[RFC3315].
If the M flag is set, the O flag is redundant and
can be ignored because DHCPv6 will return all
available configuration information.
O 1-bit "Other configuration" flag. When set, it
indicates that other configuration information is
available via DHCPv6. Examples of such information
are DNS-related information or information on other
servers within the network.
Note: If neither M nor O flags are set, this indicates that no
information is available via DHCPv6.
Based on the definition of the O flag above, if RA options for DNS
configuration are included in the RA messages, an IPv6 host may
perform another DNS configuration through DHCPv6 only when the O flag
is set. On the other hand, if no RA options for DNS configuration
are included in the RA messages, an IPv6 host may perform DNS
configuration through DHCPv6 regardless of whether the O flag is set
or not.
2. Requirements Language 2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
3. Terminology 3. Terminology
This document uses the terminology described in [RFC4861] and This document uses the terminology described in [RFC4861] and
skipping to change at page 5, line 40 skipping to change at page 5, line 21
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 RDNSS option defined This document standardizes the ND option called RDNSS option defined
in [RFC5006] that contains the addresses of recursive DNS servers. in [RFC5006] that contains the addresses of recursive DNS servers.
This document also defines a new ND option called DNSSL option for This document also defines a new ND option called DNSSL option for
Domain Search List. This is for two reasons for the new option, the Domain Search List. This is to maintain parity with the DHCPv6
first is to maintain parity with the DHCPv6 options for DNS options and to ensure that there is necessary functionality to
configuration [RFC3646], so that RA and DHCPv6 do not unnecessarily determine the search domains.
diverge and so that RA can provide the same DNS configuration as
DHCPv6. The second reason is that a Domain Search List is useful to
support multi-homed hosts querying DNS servers which provide
different answers [ID-savolainen].
Existing ND transport mechanisms (i.e., advertisements and
solicitations) are used. This works in the same way that hosts learn
about routers and prefixes. An IPv6 host can configure the IPv6
addresses of one or more RDNSSes via RA messages periodically sent by
a router or solicited by a Router Solicitation (RS).
Through the RDNSS and DNSSL options, along with the prefix Existing ND message (i.e., Router Advertisement) is used to carry
information option based on the ND protocol ([RFC4861] and this information. An IPv6 host can configure the IPv6 addresses of
[RFC4862]), an IPv6 host can perform the network configuration of its one or more RDNSSes via RA messages. Through the RDNSS and DNSSL
IPv6 address and the DNS information simultaneously without needing options, along with the prefix information option based on the ND
DHCPv6 for the DNS configuration. The RA options for RDNSS and DNSSL protocol ([RFC4861] and [RFC4862]), an IPv6 host can perform the
can be used on any network that supports the use of ND. 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 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 new
skipping to change at page 8, line 37 skipping to change at page 8, line 13
be used. be 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 in the non-compressed form, using the be encoded in the non-compressed form, using the
technique described in Section 3.1 of [RFC1035]. The technique described in Section 3.1 of [RFC1035]. The
size of this field is a multiple of 8 octets. The size of this field is a multiple of 8 octets. The
remaining octets other than the encoding parts for remaining octets other than the encoding parts for
the domain names are padded with zeros. the domain names are padded with zeros.
Note: An RDNSS address or a DNSSL domain name MUST be used only as
long as both the RA router lifetime and the 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 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 checks whether the options are valid option) through RA messages, it checks whether the options are valid
or not as follow: or not as follow:
skipping to change at page 9, line 11 skipping to change at page 8, line 45
order; the value of the Length field in the RDNSS option is order; the value of the Length field in the RDNSS option is
greater than or equal to the minimum value (3) and also the value greater than or equal to the minimum value (3) and also the value
of the Length field in the DNSSL option is greater than or equal of the Length field in the DNSSL option is greater than or equal
to the minimum value (2). to the minimum value (2).
o If the DNS options are invalid, the host MUST discard the options; o If the DNS options are invalid, the host MUST discard the options;
for example, the Length field in the RDNSS option has a value less for example, the Length field in the RDNSS option has a value less
than 3 or the Length field in the DNSSL option has a value less than 3 or the Length field in the DNSSL option has a value less
than 2. than 2.
When the IPv6 host has gathered a sufficient number of RDNSS When the IPv6 host has gathered a sufficient number (e.g., three) of
addresses (or DNS search domain names), it MAY ignore additional RDNSS addresses (or DNS search domain names), it MAY ignore
RDNSS addresses (or DNS search domain names) within an RDNSS (or additional RDNSS addresses (or DNS search domain names) within an
DNSSL) option and/or additional RDNSS (or DNSSL) options within an RDNSS (or DNSSL) option and/or additional RDNSS (or DNSSL) options
RA. within an RA.
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 can keep
some DNS options from RA and some from DHCP; for example, two RDNSS
addresses (or DNS search domain names) from RA and one RDNSS address
(or DNS search domain name) from 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.
skipping to change at page 9, line 50 skipping to change at page 9, line 41
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:
o RDNSS address for DNS Server List: IPv6 address of the Recursive o RDNSS address for DNS Server List: IPv6 address of the Recursive
DNS Server, which is available for recursive DNS resolution DNS Server, which is available for recursive DNS resolution
service in the network advertising the RDNSS option; such a service in the network advertising the RDNSS option.
network is called "site" in this document.
o DNSSL domain name for DNS Search List: DNS suffix domain names, o DNSSL domain name for DNS Search List: DNS suffix domain names,
which is used to perform DNS query searches for short, unqualified which is used to perform DNS query searches for short, unqualified
domain names in the network advertising the DNSSL option; such a domain names in the network advertising the DNSSL option.
network is called "site" in this document.
o Expiration-time for DNS Server List or DNS Search List: The time o Expiration-time for DNS Server List or DNS Search List: The time
when this entry becomes invalid. Expiration-time is set to the when this entry becomes invalid. Expiration-time is set to the
value of the Lifetime field of the RDNSS option or DNSSL option value of the Lifetime field of the RDNSS option or DNSSL option
plus the current system time. Whenever a new RDNSS option with plus the current system time. Whenever a new RDNSS option with
the same address (or DNSSL option with the same domain name) is the same address (or DNSSL option with the same domain name) is
received on the same interface as a previous RDNSS option (or received on the same interface as a previous RDNSS option (or
DNSSL option), this field is updated to have a new expiration DNSSL option), this field is updated to have a new expiration
time. When Expiration-time becomes less than the current system time. When Expiration-time becomes less than the current system
time, this entry is regarded as expired. time, this entry is regarded as expired.
Note: An RDNSS address or a DNSSL domain name MUST be used only as
long as both the RA router lifetime and the option lifetime have
not expired. The reason is that 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]).
6.2. Synchronization between DNS Server List and Resolver Repository 6.2. Synchronization between DNS Server List and Resolver Repository
When an IPv6 host receives the information of multiple RDNSS When an IPv6 host receives the information of multiple RDNSS
addresses within a site through an RA message with RDNSS option(s), addresses within a network (e.g., campus network and company network)
it stores the RDNSS addresses (in order) into both the DNS Server through an RA message with RDNSS option(s), it stores the RDNSS
List and the Resolver Repository. The processing of the RDNSS addresses (in order) into both the DNS Server List and the Resolver
option(s) included in an RA message is as follows: Repository. The processing of the RDNSS option(s) included in an RA
message is as follows:
Step (a): Receive and parse the RDNSS option(s). For the RDNSS Step (a): Receive and parse the RDNSS option(s). For the RDNSS
addresses in each RDNSS option, perform Step (b) through Step (d). addresses in each RDNSS option, perform Step (b) through Step (d).
Note that Step (e) is performed whenever an entry expires in the Note that Step (e) is performed whenever an entry expires in the
DNS Server List. DNS Server List.
Step (b): For each RDNSS address, check the following: If the Step (b): For each RDNSS address, check the following: If the
RDNSS address already exists in the DNS Server List and the RDNSS RDNSS address already exists in the DNS Server List and the RDNSS
option's Lifetime field is set to zero, delete the corresponding option's Lifetime field is set to zero, delete the corresponding
RDNSS entry from both the DNS Server List and the Resolver RDNSS entry from both the DNS Server List and the Resolver
skipping to change at page 11, line 30 skipping to change at page 11, line 13
routers advertising RDNSS option(s) in a subnet, the RDNSSes that routers advertising RDNSS option(s) in a subnet, the RDNSSes that
have been announced recently are preferred. have been announced recently are preferred.
Step (e): Delete each expired entry from the DNS Server List, and Step (e): Delete each expired entry from the DNS Server List, and
delete the RDNSS address corresponding to the entry from the delete the RDNSS address corresponding to the entry from the
Resolver Repository. 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 site through an RA message with DNSSL option(s), it names within a network (e.g., campus network and company network)
stores the DNSSL domain names (in order) into both the DNS Search through an RA message with DNSSL option(s), it stores the DNSSL
List and the Resolver Repository. The processing of the DNSSL domain names (in order) into both the DNS Search List and the
option(s) included in an RA message is as follows: Resolver Repository. The processing of the DNSSL option(s) included
in an RA message is as follows:
Step (a): Receive and parse the DNSSL option(s). For the DNSSL Step (a): Receive and parse the DNSSL option(s). For the DNSSL
domain names in each DNSSL option, perform Step (b) through Step domain names in each DNSSL option, perform Step (b) through Step
(d). Note that Step (e) is performed whenever an entry expires in (d). Note that Step (e) is performed whenever an entry expires in
the DNS Search List. the DNS Search List.
Step (b): For each DNSSL domain name, check the following: If the 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 domain name already exists in the DNS Search List and the
DNSSL option's Lifetime field is set to zero, delete the DNSSL option's Lifetime field is set to zero, delete the
corresponding DNSSL entry from both the DNS Search List and the corresponding DNSSL entry from both the DNS Search List and the
skipping to change at page 13, line 49 skipping to change at page 13, line 33
DNSSL option (TBD) DNSSL option (TBD)
The IANA registry for these options is: The IANA registry for these options is:
http://www.iana.org/assignments/icmpv6-parameters http://www.iana.org/assignments/icmpv6-parameters
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, and Dan Wing. The authors sincerely appreciate their Nordmark, Dan Wing, and Jari Arkko. The authors sincerely appreciate
contributions. 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.
10.2. Informative References 10.2. Informative References
[RFC1034] Mockapetris, P., "Domain Names - Concepts and [RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities",
Facilities", RFC 1034, November 1987. RFC 1034, November 1987.
[RFC1035] Mockapetris, P., "Domain Names - Implementation and
Specification", RFC 1035, November 1987.
[RFC3315] Droms, R., Ed., "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., Ed., "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., Ed., "IPv6 Host Configuration of DNS
Server Information Approaches", RFC 4339,
February 2006.
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility [RFC1035] Mockapetris, P., "Domain Names - Implementation and
Support in IPv6", RFC 3775, June 2004. Specification", RFC 1035, November 1987.
[RFC3971] Arkko, J., Ed., "SEcure Neighbor Discovery (SEND)", [RFC3315] Droms, R., Ed., "Dynamic Host Configuration Protocol for
RFC 3971, March 2005. IPv6 (DHCPv6)", RFC 3315, July 2003.
[IEEE-802.11] ANSI/IEEE Std 802.11, "Part 11: Wireless LAN Medium [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol
Access Control (MAC) and Physical Layer (PHY) (DHCP) Service for IPv6", RFC 3736, April 2004.
Specifications", March 1999.
[IEEE-802.11a] IEEE Std 802.11a, "Part 11: Wireless LAN Medium [RFC3646] Droms, R., Ed., "DNS Configuration options for Dynamic
Access Control (MAC) and Physical Layer (PHY) Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3646,
specifications: High-speed Physical Layer in the 5 December 2003.
GHZ Band", September 1999.
[IEEE-802.11b] IEEE Std 802.11b, "Part 11: Wireless LAN Medium [RFC5006] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli,
Access Control (MAC) and Physical Layer (PHY) "IPv6 Router Advertisement Option for DNS Configuration",
specifications: Higher-Speed Physical Layer RFC 5006, September 2007.
Extension in the 2.4 GHz Band", September 1999.
[IEEE-802.11g] IEEE P802.11g/D8.2, "Part 11: Wireless LAN Medium [RFC4339] Jeong, J., Ed., "IPv6 Host Configuration of DNS Server
Access Control (MAC) and Physical Layer (PHY) Information Approaches", RFC 4339, February 2006.
specifications: Further Higher Data Rate Extension
in the 2.4 GHz Band", April 2003.
[RFC5358] Damas, J. and F. Neves, "Preventing Use of Recursive [RFC3971] Arkko, J., Ed., "SEcure Neighbor Discovery (SEND)",
Nameservers in Reflector Attacks", BCP 140, RFC 3971, March 2005.
RFC 5358, October 2008.
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress [RFC5358] Damas, J. and F. Neves, "Preventing Use of Recursive
Filtering: Defeating Denial of Service Attacks which Nameservers in Reflector Attacks", BCP 140, RFC 5358,
employ IP Source Address Spoofing", BCP 38, October 2008.
RFC 2827, May 2000.
[ID-savolainen] Savolainen, T., "Preventing Use of Recursive [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering:
Nameservers in Reflector Attacks", Work in Progress, Defeating Denial of Service Attacks which employ IP Source
February 2010. Address Spoofing", BCP 38, RFC 2827, May 2000.
[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.
Authors' Addresses Authors' Addresses
Jaehoon Paul Jeong (editor) Jaehoon Paul Jeong (editor)
Brocade Communications Systems/ETRI Brocade Communications Systems/ETRI
6000 Nathan Ln N 6000 Nathan Ln N
Plymouth, MN 55442 Plymouth, MN 55442
USA USA
Phone: +1 763 268 7173 Phone: +1 763 268 7173 +1 763 268 7173
Fax: +1 763 268 6800 Fax: +1 763 268 6800
EMail: pjeong@brocade.com EMail: pjeong@brocade.com
URI: http://www.cs.umn.edu/~jjeong/ URI: http://www.cs.umn.edu/~jjeong/
Soohong Daniel Park Soohong Daniel Park
Mobile Platform Laboratory Mobile Platform Laboratory
SAMSUNG Electronics SAMSUNG Electronics
416 Maetan-3dong, Yeongtong-Gu 416 Maetan-3dong, Yeongtong-Gu
Suwon, Gyeonggi-Do 443-742 Suwon, Gyeonggi-Do 443-742
Korea Korea
Phone: +82 31 200 4508 Phone: +82 31 200 4508 +82 31 200 4508
EMail: soohong.park@samsung.com EMail: soohong.park@samsung.com
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 02 3175 9391 Phone: +33 02 3175 9391 +33 02 3175 9391
EMail: luc.beloeil@orange-ftgroup.com EMail: luc.beloeil@orange-ftgroup.com
Syam Madanapalli Syam Madanapalli
Ordyn Technologies Ordyn Technologies
1st Floor, Creator Building, ITPL 1st Floor, Creator Building, ITPL
Bangalore - 560066 Bangalore - 560066
India India
Phone: +91-80-40383000 Phone: +91-80-40383000 +91-80-40383000
EMail: smadanapalli@gmail.com EMail: smadanapalli@gmail.com
 End of changes. 41 change blocks. 
184 lines changed or deleted 140 lines changed or added

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