draft-ietf-6man-rdnss-rfc6106bis-00.txt   draft-ietf-6man-rdnss-rfc6106bis-01.txt 
Network Working Group J. Jeong Network Working Group J. Jeong
Internet-Draft Sungkyunkwan Univ./ETRI Internet-Draft Sungkyunkwan Univ./ETRI
Obsoletes: 6106 (if approved) S. Park Obsoletes: 6106 (if approved) S. Park
Intended status: Standards Track SAMSUNG Electronics Intended status: Standards Track SAMSUNG Electronics
Expires: January 22, 2016 L. Beloeil Expires: February 11, 2016 L. Beloeil
France Telecom R&D France Telecom R&D
S. Madanapalli S. Madanapalli
iRam Technologies iRam Technologies
July 21, 2015 August 10, 2015
IPv6 Router Advertisement Options for DNS Configuration IPv6 Router Advertisement Options for DNS Configuration
draft-ietf-6man-rdnss-rfc6106bis-00 draft-ietf-6man-rdnss-rfc6106bis-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.
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 January 22, 2016. This Internet-Draft will expire on February 11, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 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
skipping to change at page 2, line 28 skipping to change at page 2, line 28
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 . . . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . 6
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 . . . . . . . . . . . . . . . . 10 6. Implementation Considerations . . . . . . . . . . . . . . . . 9
6.1. DNS Repository Management . . . . . . . . . . . . . . . . 10 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 . . . . . . . . . . . . . . . . . . . . . . . . 11 Repository . . . . . . . . . . . . . . . . . . . . . . . . 10
6.3. Synchronization between DNS Search List and Resolver 6.3. Synchronization between DNS Search List and Resolver
Repository . . . . . . . . . . . . . . . . . . . . . . . . 12 Repository . . . . . . . . . . . . . . . . . . . . . . . . 11
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 . . . . . . . . . . . . . . . . . . . . . 13
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
10.1. Normative References . . . . . . . . . . . . . . . . . . . 15 10.1. Normative References . . . . . . . . . . . . . . . . . . . 14
10.2. Informative References . . . . . . . . . . . . . . . . . . 16 10.2. Informative References . . . . . . . . . . . . . . . . . . 15
Appendix A. Changes from RFC 5006 . . . . . . . . . . . . . . . . 17 Appendix A. Changes from RFC 5006 . . . . . . . . . . . . . . . . 16
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 specified the DNS name resolution in IPv6 hosts. This RA option was specified
in an earlier Experimental specification [RFC5006]. This document is in an earlier Experimental specification [RFC5006]. This document is
also to define a new RA option for Domain Name Search Lists for an also to define a new RA option for Domain Name Search Lists for an
enhanced DNS configuration. Thus, this document obsoletes [RFC5006], enhanced DNS configuration. Thus, this document obsoletes [RFC5006],
which only defines the RA option for DNS Recursive Server Addresses. which only defines the RA option for DNS Recursive Server Addresses.
skipping to change at page 6, line 34 skipping to change at page 6, line 34
(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 sent),
over which this RDNSS address MAY be used for name over which this RDNSS address MAY be used for name
resolution. Hosts MAY send a Router Solicitation to resolution. The value of Lifetime SHOULD by default
ensure the RDNSS information is fresh before the be at least 3 * MaxRtrAdvInterval where
interval expires. The value of Lifetime SHOULD by
default 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 address 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.
skipping to change at page 8, line 22 skipping to change at page 8, line 13
domain name representations are concatenated as they domain name representations are concatenated as they
are. Note that for the simple decoding, the domain are. Note that for the simple decoding, the domain
names MUST NOT be encoded in a compressed form, as names MUST NOT be encoded in a compressed form, as
described in Section 4.1.4 of [RFC1035]. Because the described in Section 4.1.4 of [RFC1035]. Because the
size of this field MUST be a multiple of 8 octets, size of this field MUST be a multiple of 8 octets,
for the minimum multiple including the domain name for the minimum multiple including the domain name
representations, the remaining octets other than the representations, the remaining octets other than the
encoding parts of the domain name representations encoding parts of the domain name representations
MUST be padded with zeros. MUST be padded with zeros.
Note: An RDNSS address or a DNSSL domain name MUST be used only as
long as both the RA router Lifetime (advertised by a Router
Advertisement message [RFC4861]) and the corresponding option
Lifetime have not expired. The reason is that in the current
network to which an IPv6 host is connected, the RDNSS may not be
currently reachable, that the DNSSL domain name is not valid any
more, or that these options do not provide service to the host's
current address (e.g., due to network ingress filtering
[RFC2827][RFC5358]).
5.3. Procedure of DNS Configuration 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 5 skipping to change at page 8, line 34
is, the value of the Length field in the RDNSS option is greater is, the value of the Length field in the RDNSS option is greater
than or equal to the minimum value (3), and the value of the than or equal to the minimum value (3), and the value of the
Length field in the DNSSL option is greater than or equal to the Length field in the DNSSL option is greater than or equal to the
minimum value (2). minimum value (2).
o If the DNS options are valid, the host SHOULD copy the values of o If the DNS options are valid, the host SHOULD copy the values of
the options into the DNS Repository and the Resolver Repository in the options into the DNS Repository and the Resolver Repository in
order. Otherwise, the host MUST discard the options. Refer to order. Otherwise, the host MUST discard the options. Refer to
Section 6 for the detailed procedure. Section 6 for the detailed procedure.
When the IPv6 host has gathered a sufficient number (e.g., three) of
RDNSS addresses (or DNS search domain names), it SHOULD maintain
RDNSS addresses (or DNS search domain names) by the sufficient number
such that the latest received RDNSS or DNSSL is more preferred to the
old ones; that is, when the number of RDNSS addresses (or DNS search
domain names) is already the sufficient number, the new one replaces
the old one that will expire first in terms of Lifetime. As an
exceptional case, if the received RDNSS addresses (or DNS search
domain names) already exist in the IPv6 host, their Lifetime fields
update their Expiration-time, that is, when the corresponding DNS
information expires in the IPv6 host; note that when the Lifetime
field has zero, the corresponding RDNSS (or DNS search domain name)
is deleted from the IPv6 host. Except for this update, the IPv6 host
SHOULD ignore other RDNSS addresses (or DNS search domain names)
within an RDNSS (or a DNSSL) option and/or additional RDNSS (or
DNSSL) options within an RA. Refer to Section 6 for the detailed
procedure. Note that the sufficient number is a system parameter, so
it can be determined by a local policy. Also, separate parameters
can be specified for the sufficient number of RDNSS addresses and
that of DNS search domain names, respectively. In this document,
three is RECOMMENDED as a sufficient number considering both the
robust DNS query and the reasonably time-bounded recognition of the
unreachability of DNS servers.
In the case where the DNS options of RDNSS and DNSSL can be obtained 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, the ability to store at least three RDNSS addresses (or However, the ability to store at least three RDNSS addresses (or
DNSSL domain names) from at least two different sources is DNSSL domain names) from at least two different sources is
RECOMMENDED. The DNS options from Router Advertisements and DHCP RECOMMENDED. The DNS options from Router Advertisements and DHCP
SHOULD be stored into the DNS Repository and Resolver Repository so SHOULD be stored into the DNS Repository and Resolver Repository so
that information from DHCP appears there first and therefore takes that information from DHCP appears there first and therefore takes
skipping to change at page 16, line 34 skipping to change at page 15, line 43
Madanapalli, "IPv6 Router Advertisement Option for Madanapalli, "IPv6 Router Advertisement Option for
DNS Configuration", RFC 5006, September 2007. DNS Configuration", RFC 5006, September 2007.
[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 Neighbor Discovery (SEND)", RFC 3971, "SEcure Neighbor Discovery (SEND)", RFC 3971,
March 2005. March 2005.
[RFC5358] Damas, J. and F. Neves, "Preventing Use of Recursive
Nameservers in Reflector Attacks", BCP 140,
RFC 5358, October 2008.
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress
Filtering: Defeating Denial of Service Attacks which
employ IP Source Address Spoofing", BCP 38,
RFC 2827, May 2000.
[RFC1535] Gavron, E., "A Security Problem and Proposed [RFC1535] Gavron, E., "A Security Problem and Proposed
Correction With Widely Deployed DNS Software", Correction With Widely Deployed DNS Software",
RFC 1535, October 1993. RFC 1535, October 1993.
[RFC1536] Kumar, A., Postel, J., Neuman, C., Danzig, P., and [RFC1536] Kumar, A., Postel, J., Neuman, C., Danzig, P., and
S. Miller, "Common DNS Implementation Errors and S. Miller, "Common DNS Implementation Errors and
Suggested Fixes", RFC 1536, October 1993. Suggested Fixes", RFC 1536, October 1993.
[MIF-PROBLEM] Blanchet, M. and P. Seite, "Multiple Interfaces [MIF-PROBLEM] Blanchet, M. and P. Seite, "Multiple Interfaces
Problem Statement", Work in Progress, August 2010. Problem Statement", Work in Progress, August 2010.
 End of changes. 12 change blocks. 
66 lines changed or deleted 21 lines changed or added

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