draft-ietf-6man-dns-options-bis-05.txt   draft-ietf-6man-dns-options-bis-06.txt 
Network Working Group J. Jeong Network Working Group J. Jeong
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: January 1, 2011 L. Beloeil Expires: January 8, 2011 L. Beloeil
France Telecom R&D France Telecom R&D
S. Madanapalli S. Madanapalli
Ordyn Technologies Ordyn Technologies
June 30, 2010 July 7, 2010
IPv6 Router Advertisement Options for DNS Configuration IPv6 Router Advertisement Options for DNS Configuration
draft-ietf-6man-dns-options-bis-05 draft-ietf-6man-dns-options-bis-06
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 January 1, 2011. This Internet-Draft will expire on January 8, 2011.
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 29 skipping to change at page 2, line 29
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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
5. Neighbor Discovery Extension . . . . . . . . . . . . . . . . . 5 5. Neighbor Discovery Extension . . . . . . . . . . . . . . . . . 5
5.1. Recursive DNS Server Option . . . . . . . . . . . . . . . 5 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 5.3.2. Warnings for DNS Options Configuration . . . . . . . . 9
6. Implementation Considerations . . . . . . . . . . . . . . . . 10
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 . . . . . . . . . . . . . . . . . . . . . . . . 11
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 . . . . . . . . . . . . . . . . . . . 13
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
10.1. Normative References . . . . . . . . . . . . . . . . . . . 14 10.1. Normative References . . . . . . . . . . . . . . . . . . . 15
10.2. Informative References . . . . . . . . . . . . . . . . . . 15 10.2. Informative References . . . . . . . . . . . . . . . . . . 15
Appendix A. Changes from RFC 5006 . . . . . . . . . . . . . . . . 15 Appendix A. Changes from RFC 5006 . . . . . . . . . . . . . . . . 16
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 an earlier experimental specification [RFC5006] and also specified in an earlier experimental specification [RFC5006] and also
to define a new RA option for Domain 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
skipping to change at page 9, line 39 skipping to change at page 9, line 39
In the case where the DNS options of RDNSS and DNSSL can be obtained 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 from multiple sources, such as RA and DHCP, the IPv6 host SHOULD keep
some DNS options from all sources. Unless explicitly specified for some DNS options from all sources. Unless explicitly specified for
the discovery mechanism, the exact number of addresses and domain the discovery mechanism, the exact number of addresses and domain
names to keep is a matter of local policy and implementation choice. names to keep is a matter of local policy and implementation choice.
However, it is RECOMMENDED that at least three RDNSS addresses (or However, it is RECOMMENDED that at least three RDNSS addresses (or
DNSSL domain names) can be stored from at least two different DNSSL domain names) can be stored from at least two different
sources. The DNS options from Router Advertisements and DHCP SHOULD sources. The DNS options from Router Advertisements and DHCP SHOULD
be stored into DNS Repository and Resolver Repository so that be stored into DNS Repository and Resolver Repository so that
information from DHCP appears there first and therefore takes information from DHCP appears there first and therefore takes
precedence. 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 which do not use SEND. Refer to Section 7 for
the detailed discussion on SEND for RA DNS options.
5.3.2. Warnings for DNS Options Configuration
There are two warnings for DNS options configuration: (i) warning for
multiple sources of DNS options and (ii) warning for multiple network
interfaces. First, in the case of multiple sources for DNS options
(e.g., 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 in
Multiple Interfaces (MIF) working group.
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 13, line 39 skipping to change at page 14, line 10
Also, an attacker could send an RA with a fraudulent RDNSS address, Also, an attacker could send an RA with a fraudulent RDNSS address,
which is presumably an easier avenue of attack than becoming a rogue which is presumably an easier avenue of attack than becoming a rogue
router and having to process all traffic for the subnet. This attack router and having to process all traffic for the subnet. This attack
is similar to Neighbor Discovery attacks that use Redirect or is similar to Neighbor Discovery attacks that use Redirect or
Neighbor Advertisement messages to redirect traffic to individual Neighbor Advertisement messages to redirect traffic to individual
addresses to malicious parties. In general, the attacks related to addresses to malicious parties. In general, the attacks related to
RDNSS and DNSSL are similar to both Neighbor Discovery attacks and RDNSS and DNSSL are similar to both Neighbor Discovery attacks and
attacks against unauthenticated DHCP, as both can be used for both attacks against unauthenticated DHCP, as both can be used for both
"wholesale" traffic redirection and more specific attacks. "wholesale" traffic redirection and more specific attacks.
If the Secure Neighbor Discovery (SEND) protocol [RFC3971] is used as
a security mechanism for ND, all the ND options including the RDNSS
and DNSSL options are automatically included in the signatures, so
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, SEND
cannot verify which one is or is not authorized to send the 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 DHCP servers. That means that an to provide protection from rogue DHCP servers. That means that an
attacker on other ports cannot insert bogus DNS servers using DHCPv6. attacker on other ports cannot insert bogus DNS servers using DHCPv6.
The corresponding technique for network devices is recommended to The corresponding technique for network devices is recommended to
block rogue Router Advertisement messages including the RDNSS and block rogue Router Advertisement messages including the RDNSS and
DNSSL options from unauthorized nodes. 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-fully qualified domain names. For this the victim queries non-fully qualified domain names. For this
attack, the DNS resolver in IPv6 hosts can mitigate the vulnerability attack, the DNS resolver in IPv6 hosts can mitigate the vulnerability
with the recommendations in [RFC1535], [RFC1536], and [RFC3646]. with the recommendations in [RFC1535], [RFC1536], and [RFC3646].
If the Secure Neighbor Discovery (SEND) protocol is used as a
security mechanism for ND, all the ND options including the RDNSS and
DNSSL options are automatically included in the signatures [RFC3971],
so the transport for the RA options is integrity-protected. However,
since any valid SEND router can still insert RDNSS and DNSSL options,
SEND cannot verify which one is or is not authorized to send the
options.
8. IANA Considerations 8. IANA Considerations
The RDNSS option defined in this document is using the IPv6 Neighbor The RDNSS option defined in this document is using the IPv6 Neighbor
Discovery Option type in RFC 5006 [RFC5006] assigned by the IANA as Discovery Option type in RFC 5006 [RFC5006] assigned by the IANA as
follows: follows:
Option Name Type Option Name Type
RDNSS option 25 RDNSS option 25
The IANA is requested to assign a new IPv6 Neighbor Discovery Option The IANA is requested to assign a new IPv6 Neighbor Discovery Option
 End of changes. 11 change blocks. 
19 lines changed or deleted 45 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/