draft-ietf-6man-rdnss-rfc6106bis-08.txt   draft-ietf-6man-rdnss-rfc6106bis-09.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 Korean Bible University Intended status: Standards Track Korean Bible University
Expires: September 7, 2016 L. Beloeil Expires: September 12, 2016 L. Beloeil
France Telecom R&D France Telecom R&D
S. Madanapalli S. Madanapalli
iRam Technologies iRam Technologies
March 6, 2016 March 11, 2016
IPv6 Router Advertisement Options for DNS Configuration IPv6 Router Advertisement Options for DNS Configuration
draft-ietf-6man-rdnss-rfc6106bis-08 draft-ietf-6man-rdnss-rfc6106bis-09
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 September 7, 2016. This Internet-Draft will expire on September 12, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2016 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
skipping to change at page 2, line 35 skipping to change at page 2, line 35
4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
5. Neighbor Discovery Extension . . . . . . . . . . . . . . . . . 5 5. Neighbor Discovery Extension . . . . . . . . . . . . . . . . . 5
5.1. Recursive DNS Server Option . . . . . . . . . . . . . . . 6 5.1. Recursive DNS Server Option . . . . . . . . . . . . . . . 6
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 . . . . . . . . . . . . . . . . . . . . . . . . 11 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 . . . . . . . . . . . . . . . . . . . 12 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12
7.1. Security Threats . . . . . . . . . . . . . . . . . . . . . 12 7.1. Security Threats . . . . . . . . . . . . . . . . . . . . . 12
7.2. Recommendations . . . . . . . . . . . . . . . . . . . . . 13 7.2. Recommendations . . . . . . . . . . . . . . . . . . . . . 12
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
10.1. Normative References . . . . . . . . . . . . . . . . . . . 14 10.1. Normative References . . . . . . . . . . . . . . . . . . . 14
10.2. Informative References . . . . . . . . . . . . . . . . . . 14 10.2. Informative References . . . . . . . . . . . . . . . . . . 14
Appendix A. Changes from RFC 6106 . . . . . . . . . . . . . . . . 16 Appendix A. Changes from RFC 6106 . . . . . . . . . . . . . . . . 15
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] and was specified in an earlier Experimental specification [RFC5006] and was
later published as a Standards Track in [RFC6106]. This document later published as a Standards Track in [RFC6106]. This document
obsoletes [RFC6106], allowing a higher default value of the lifetime obsoletes [RFC6106], allowing a higher default value of the lifetime
of the RA DNS options to avoid the frequent expiry of the options on of the RA DNS options to avoid the frequent expiry of the options on
skipping to change at page 10, line 4 skipping to change at page 10, line 4
solution for RDNSS selection for multi-interfaced nodes in [RFC6731], solution for RDNSS selection for multi-interfaced nodes in [RFC6731],
which is based on DHCP. 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. These two
repositories should be synchronized however the processing of RA DNS
In environments where the DNS information is stored in user space and options are implemented in the kernel space or user space.
ND runs in the kernel, it is necessary to synchronize the DNS
information (i.e., RDNSS addresses and DNS search domain names) in
kernel space and the Resolver Repository in user space. In these
environments, a user space application cannot receive RA via an
ICMPv6 socket using the standard advanced socket Application Program
Interface (API) in [RFC3542]. For the synchronization, an
implementation where ND works in the kernel should provide a write
operation for updating DNS information from the kernel to the
Resolver Repository. One simple approach is to have a daemon (or a
program that is called at defined intervals) that keeps monitoring
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 18 skipping to change at page 12, line 8
finished here. finished here.
The handling of expired RDNSSes is as follows: Whenever an entry The handling of expired RDNSSes is as follows: Whenever an entry
expires in the DNS Server List, the expired entry is deleted from the expires in the DNS Server List, the expired entry is deleted from the
DNS Server List, and also the RDNSS address corresponding to the DNS Server List, and also the RDNSS address corresponding to the
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 through an RA message with DNSSL option(s), it
through an RA message with DNSSL option(s), it stores the DNSSL stores the DNSSL domain names (in order) into both the DNS Search
domain names (in order) into both the DNS Search List and the List and the Resolver Repository. The processing of the DNSSL
Resolver Repository. The processing of the DNSSL consists of (i) the consists of (i) the processing of DNSSL option(s) included in an RA
processing of DNSSL option(s) included in an RA message and (ii) the message and (ii) the handling of expired DNSSLs. The processing of
handling of expired DNSSLs. The processing of DNSSL option(s) is the DNSSL option(s) is the same with that of RDNSS option(s) in Section
same with that of RDNSS option(s) in Section 6.2 except Step (b). 6.2 except Step (b).
In Step (b), if the DNSSL domain name already exists in the DNS In Step (b), if the DNSSL domain name already exists in the DNS
Search List and the DNSSL option's Lifetime field is set to zero, Search List and the DNSSL option's Lifetime field is set to zero,
delete the corresponding DNSSL entry from both the DNS Search List delete the corresponding DNSSL entry from both the DNS Search List
and the Resolver Repository in order to prevent the DNSSL domain name and the Resolver Repository in order to prevent the DNSSL domain name
from being used any more for certain reasons in network management, from being used any more for certain reasons in network management,
e.g., the termination of the usage of the DNSSL domain name. That 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 is, the DNSSL domain name may not be used any more by the policy of
the network. the network.
skipping to change at page 13, line 11 skipping to change at page 12, line 50
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. attached to a LAN can do.
7.2. Recommendations 7.2. Recommendations
The Secure Neighbor Discovery (SEND) protocol [RFC3971] MAY be used The Secure Neighbor Discovery (SEND) protocol [RFC3971] is designed
as a security mechanism for ND. In this case, ND can 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. Other approaches specified automatically included in the signatures. Other approaches specified
in [RFC4861] can be used for securing the RA options for DNS in [RFC4861] can be used for securing the RA options for DNS
configuration. configuration.
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
skipping to change at page 14, line 15 skipping to change at page 14, line 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, David Farmer, and Bing Liu. Jinmei, Lorenzo Colitti, Tore Anderson, David Farmer, and Bing Liu.
The authors sincerely appreciate their contributions. The authors sincerely appreciate their contributions.
This document was supported by Institute for Information &
communications Technology Promotion (IITP) grant funded by the Korea
government (MSIP) [10041244, Smart TV 2.0 Software Platform].
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, "Neighbor Discovery for IP version 6 Soliman, "Neighbor Discovery for IP version 6
(IPv6)", RFC 4861, September 2007. (IPv6)", RFC 4861, September 2007.
skipping to change at page 16, line 5 skipping to change at page 15, line 45
Provisioning Domains Problem Statement", RFC 6418, Provisioning Domains Problem Statement", RFC 6418,
November 2011. November 2011.
[RFC6419] Wasserman, M. and P. Seite, "Current Practices for [RFC6419] Wasserman, M. and P. Seite, "Current Practices for
Multiple-Interface Hosts", RFC 6419, November 2011. Multiple-Interface Hosts", RFC 6419, November 2011.
[RFC6731] Savolainen, T., Kato, J., and T. Lemon, "Improved [RFC6731] Savolainen, T., Kato, J., and T. Lemon, "Improved
Recursive DNS Server Selection for Multi-Interfaced Recursive DNS Server Selection for Multi-Interfaced
Nodes", RFC 6731, December 2012. 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 6106 Appendix A. Changes from RFC 6106
The following changes were made from RFC 6106 "IPv6 Router The following changes were made from RFC 6106 "IPv6 Router
Advertisement Options for DNS Configuration": Advertisement Options for DNS Configuration":
o The generation of Router Solicitation to ensure that the RDNSS o The generation of Router Solicitation to ensure that the RDNSS
information is fresh before the expiry of the RDNSS option is information is fresh before the expiry of the RDNSS option is
removed in order to prevent multicast traffic on the link from removed in order to prevent multicast traffic on the link from
increasing. increasing.
skipping to change at page 17, line 5 skipping to change at page 16, line 28
o The recommendation that at most three RDNSS addresses to maintain o The recommendation that at most three RDNSS addresses to maintain
by RDNSS options should be limited is removed. By this removal, by RDNSS options should be limited is removed. By this removal,
the number of RDNSSes to maintain is up to an implementer's local the number of RDNSSes to maintain is up to an implementer's local
policy. policy.
o The recommendation that at most three DNS domains to maintain by o The recommendation that at most three DNS domains to maintain by
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.
o The guidance of the specific implementation for the
synchronization of the DNS Repository and Resolver Repository on
the kernel space and user space is removed.
o The usage of the keywords of SHOULD and RECOMMENDED in RFC 2119 is
removed in the recommendation of using SEND for secure ND.
Instead of the keywords, SEND is specified as a possible solution
for secure ND.
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 16419 Suwon, Gyeonggi-Do 16419
Republic of Korea Republic of Korea
Phone: +82 31 299 4957 Phone: +82 31 299 4957
 End of changes. 14 change blocks. 
37 lines changed or deleted 32 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/