Internet DRAFT - draft-gont-6man-slaac-dns-config-issues
draft-gont-6man-slaac-dns-config-issues
IPv6 maintenance Working Group (6man) F. Gont
Internet-Draft SI6 Networks / UTN-FRH
Updates: 6106 (if approved) P. Simerda
Intended status: Standards Track
Expires: August 30, 2015 W. Liu
Huawei Technologies
February 26, 2015
Current issues with DNS Configuration Options for SLAAC
draft-gont-6man-slaac-dns-config-issues-01
Abstract
RFC 6106 specifies two Neighbor Discovery options that can be
included in Router Advertisement messages to convey information about
DNS recursive servers and DNS Search Lists. Small lifetime values
for the aforementioned options have been found to cause
interoperability problems in those network scenarios in which these
options are used to convey DNS-related information. This document
analyzes the aforementioned problem, and formally updates RFC 6106
such that these issues are mitigated.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 30, 2015.
Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
Gont, et al. Expires August 30, 2015 [Page 1]
Internet-Draft SLAAC DNS Configuration Issues February 2015
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Changing the Semantics of the 'Lifetime' field of RDNSS and
DNSSL options . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Changing the Default Values of the 'Lifetime' field of RDNSS
and DNSSL options . . . . . . . . . . . . . . . . . . . . . . 4
4. Use of Router Solicitations for active Probing . . . . . . . 4
5. Sanitize the received RDNSS/DNSSL 'Lifetime' Values . . . . . 5
6. Security Considerations . . . . . . . . . . . . . . . . . . . 5
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5
8. Normative References . . . . . . . . . . . . . . . . . . . . 5
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5
1. Introduction
RFC 6106 [RFC6106] specifies two Neighbor Discovery (ND) [RFC4861]
options that can be included in Router Advertisement messages to
convey information about DNS recursive servers and DNS Search Lists.
Namely, the Recursive DNS Server (RDNSS) Option specifies the IPv6
addresses of recursive DNS servers, while the DNS Search List (DNSSL)
Option specifies a "search list" to be used when trying to resolve a
name by means of the DNS.
Each of this options include a "Lifetime" field which specifies the
maximum time, in seconds, during which the information included in
the option can be used by the receiving system. The aforementioned
"Lifetime" value is set as a function of the Neighbor Discovery
parameter 'MaxRtrAdvInterval', which specifies the maximum time
allowed between sending unsolicited multicast Router Advertisements
from an interface. The recommended bounds (MaxRtrAdvInterval <=
Lifetime <= 2*MaxRtrAdvInterval) have been found to be too short for
scenarios in which some Router Advertisement messages may be lost.
In such scenarios, hosts may fail to receive unsolicited Router
Advertisements and therefore fail to refresh the expiration time of
the DNS-related information previously learned through the RDNSS and
DNSSL options), thus eventually discarding the aforementioned DNS-
related information prematurely.
Some implementations consider the lack of DNS-related information as
a hard failure, thus causing configuration restart. This situation
Gont, et al. Expires August 30, 2015 [Page 2]
Internet-Draft SLAAC DNS Configuration Issues February 2015
is exacerbated in those implementations in which IPv6 connectivity
and IPv4 connectivity are bound together, and hence failure in the
configuration of one of them causes the whole link to be restarted.
This document formally updates RFC 6106 such that this issue is
mitigated.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
2. Changing the Semantics of the 'Lifetime' field of RDNSS and DNSSL
options
The semantics of the 'Lifetime' field of the RDNSS and DNSSL options
is updated as follows:
o The 'Lifetime' field indicates the amount of time during which the
aforementioned DNS-related information is expected to be stable.
A node is NOT required to discard the DNS-related information once
the Lifetime expires.
o If the information received in a RDNSS or DNSSL option is already
present in the corresponding local data structures, the
corresponding 'Expiration' time should be updated according to the
value in the 'Lifetime' field of the received option. A
'Lifetime' of '0' causes the corresponding information to be
discarded, as already specified in [RFC6106].
o If a host has already gathered a sufficient number of RDNSS
addresses (or DNS search domain names), and additional data is
received while the existing entries have not yet expired, the
received RDNSS addresses (or DNS search domain names) SHOULD be
ignored.
o If a host receives new RDNSS addresses (or DNS search domain
names), and some of the existing entries have expired, the newly-
learned information SHOULD be used to replace the expired entries.
o A host SHOULD flush configured DNS-related information when it has
any reason to believe that its network connectivity has changed in
some relevant way (e.g., there has been a "link change event").
When that happens, the host MAY send a Router Solicitation message
to re-learn the corresponding DNS-related information.
o The most-recently-updated information SHOULD have higher priority
over the other DNS-related information already present on the
local host.
Gont, et al. Expires August 30, 2015 [Page 3]
Internet-Draft SLAAC DNS Configuration Issues February 2015
We note that the original motivation for enforcing a short expiration
timeout value was to allow mobile nodes to prefer local RDNSSes to
remote RDNSSes. However, the above rules already allow for a timely
update of the corresponding DNS-related information.
3. Changing the Default Values of the 'Lifetime' field of RDNSS and
DNSSL options
The default RDNSS/DNSSL "Lifetime" value in current the current
router solutions vary between MaxRtrAdvInterval and
2*MaxRtrAdvInterval. This means that common packet loss rates can
lead to the problem described in this document.
One possible approach to mitigate this issue would be to avoid
'Lifetime' values that are on the same order as MaxRtrAdvInterval.
This solution would require, of course, changes in router software.
When specifying a better default value, the following aspects should
be considered:
o IPv6 will be used on many links (including IEEE 802.11) that
experience packet loss. Therefore losing a few packets in a short
period of time should not invalidate DNS configuration
information.
o Unsolicited Router Advertisements sent on Ethernet networks result
in packets that employ multicast Ethernet Destination Addresses.
A number of network elements (including those that perform
bridging between wireless networks and wired networks) have
problems with multicasted Ethernet frames, thus typically leading
to packet loss of some of those frames. Therefore, SLAAC
implementations should be able to cope with devices that can lose
several multicast packets in a row.
[RFC6106] is hereby updated as follows:
The default value of AdvRDNSSLifetime and AdvDNSSLLifetime MUST be
at least 10*MaxRtrAdvInterval so that the probability of hosts
receiving unsolicited Router Advertisements is increased.
4. Use of Router Solicitations for active Probing
According to RFC 6106, hosts MAY send Router Solicitations to avoid
expiry of RDNSS and DNSSL lifetimes. This technique could be
employed as a "last resort" when expiration of the RDNSS and DNSSL
information is imminent.
Gont, et al. Expires August 30, 2015 [Page 4]
Internet-Draft SLAAC DNS Configuration Issues February 2015
5. Sanitize the received RDNSS/DNSSL 'Lifetime' Values
A host that receives a RDNSS or DNSSL option that has a non-zero
Lifetime smaller than 10*MaxRtrAdvInterval should employ
10*MaxRtrAdvInterval as the Lifetime value of the corresponding RDNSS
or DNSSL option.
6. Security Considerations
This document does not introduce any additional security
considerations to those documented in the "Security Considerations"
section of [RFC6106].
7. Acknowledgements
The authors would like to thank Erik Nordmark and Mark Smith for
their valuable input on the topic covered by this document.
8. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007.
[RFC6106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli,
"IPv6 Router Advertisement Options for DNS Configuration",
RFC 6106, November 2010.
Authors' Addresses
Fernando Gont
SI6 Networks / UTN-FRH
Evaristo Carriego 2644
Haedo, Provincia de Buenos Aires 1706
Argentina
Phone: +54 11 4650 8472
Email: fgont@si6networks.com
URI: http://www.si6networks.com
Gont, et al. Expires August 30, 2015 [Page 5]
Internet-Draft SLAAC DNS Configuration Issues February 2015
Pavel Simerda
Phone: +420 775 996 256
Email: pavlix@pavlix.net
Will Liu
Huawei Technologies
Bantian, Longgang District
Shenzhen 518129
P.R. China
Email: liushucheng@huawei.com
Gont, et al. Expires August 30, 2015 [Page 6]
