draft-ietf-6man-rdnss-rfc6106bis-11.txt   draft-ietf-6man-rdnss-rfc6106bis-12.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 Samsung Electronics Intended status: Standards Track Samsung Electronics
Expires: September 15, 2016 L. Beloeil Expires: October 9, 2016 L. Beloeil
France Telecom R&D France Telecom R&D
S. Madanapalli S. Madanapalli
iRam Technologies iRam Technologies
March 14, 2016 April 7, 2016
IPv6 Router Advertisement Options for DNS Configuration IPv6 Router Advertisement Options for DNS Configuration
draft-ietf-6man-rdnss-rfc6106bis-11 draft-ietf-6man-rdnss-rfc6106bis-12
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 15, 2016. This Internet-Draft will expire on October 9, 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 7, line 11 skipping to change at page 7, line 11
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.
Note: The addresses for recursive DNS servers in the RDNSS option Note: The addresses for recursive DNS servers in the RDNSS option
MAY be link-local addresses. Such link-local addresses SHOULD be MAY be link-local addresses. Such link-local addresses SHOULD be
registered into the resolver repository along with the registered into the resolver repository along with the
corresponding link zone indices of the links that receive the corresponding link zone indices of the links that receive the
RDNSS option(s) for them. The link-local addresses MAY be RDNSS option(s) for them. The link-local addresses MAY be
represented with their link zone indices in the textual format for represented in the resolver repository with their link zone
scoped addresses as described in [RFC4007]. When a resolver sends indices in the textual format for scoped addresses as described in
a DNS query message to an RDNSS with a link-local address, it MUST [RFC4007]. When a resolver sends a DNS query message to an RDNSS
use the corresponding link. with a link-local address, it MUST use the corresponding link.
5.2. DNS Search List Option 5.2. DNS Search List Option
The DNSSL option contains one or more domain names of DNS suffixes. The DNSSL option contains one or more domain names of DNS suffixes.
All of the domain names share the same Lifetime value. If it is All of the domain names share the same Lifetime value. If it is
desirable to have different Lifetime values, multiple DNSSL options desirable to have different Lifetime values, multiple DNSSL options
can be used. Figure 2 shows the format of the DNSSL option. can be used. Figure 2 shows the format of the DNSSL option.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
skipping to change at page 10, line 7 skipping to change at page 10, line 7
6. Implementation Considerations 6. Implementation Considerations
The implementation considerations in this document include the The implementation considerations in this document include the
following three: (i) DNS repository management, (ii) synchronization following three: (i) DNS repository management, (ii) synchronization
between DNS server list and resolver repository, and (iii) between DNS server list and resolver repository, and (iii)
synchronization between DNS search list and resolver repository. synchronization between DNS search list and 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 following two data structures
(depending on where RAs are processed) should maintain the following SHOULD be synchronized with each other: (i) DNS Server List that
two data structures to be synchronized with each other: (i) DNS keeps the list of RDNSS addresses and (ii) DNS Search List that keeps
Server List that keeps the list of RDNSS addresses and (ii) DNS the list of DNS search domain names. Each entry in these two lists
Search List that keeps the list of DNS search domain names. Each consists of a pair of an RDNSS address (or DNSSL domain name) and
entry in these two lists consists of a pair of an RDNSS address (or Expiration-time as follows:
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. service in the network advertising the RDNSS option.
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 are used to perform DNS query searches for short, which are used to perform DNS query searches for short,
unqualified domain names for the RDNSS address, which is unqualified domain names for the RDNSS address, which is
advertised by the same RA message having the DNSSL option, in the advertised by the same RA message having the DNSSL option, in the
network advertising the DNSSL option. network advertising the DNSSL option.
skipping to change at page 11, line 20 skipping to change at page 11, line 17
any more for certain reasons in network management, e.g., the any more for certain reasons in network management, e.g., the
termination of the RDNSS or a renumbering situation. That is, the termination of the RDNSS or a renumbering situation. That is, the
RDNSS can resign from its DNS service because the machine running RDNSS can resign from its DNS service because the machine running
the RDNSS is out of service intentionally or unintentionally. the RDNSS is out of service intentionally or unintentionally.
Also, under the renumbering situation, the RDNSS's IPv6 address Also, under the renumbering situation, the RDNSS's IPv6 address
will be changed, so the previous RDNSS address should not be used will be changed, so the previous RDNSS address should not be used
any more. The processing of this RDNSS address is finished here. any more. The processing of this RDNSS address is finished here.
Otherwise, go to Step (c). Otherwise, go to Step (c).
Step (c): For each RDNSS address, if it already exists in the DNS Step (c): For each RDNSS address, if it already exists in the DNS
Server List, then just update the value of the Expiration-time Server List and the RDNSS option's Lifetime field is not set to
field according to the procedure specified in the third bullet of zero, then just update the value of the Expiration-time field
according to the procedure specified in the third bullet of
Section 6.1. Otherwise, go to Step (d). Section 6.1. Otherwise, go to Step (d).
Step (d): For each RDNSS address, if it does not exist in the DNS Step (d): For each RDNSS address, if it does not exist in the DNS
Server List, register the RDNSS address and Lifetime with the DNS Server List, register the RDNSS address and Lifetime with the DNS
Server List and then insert the RDNSS address in front of the Server List and then insert the RDNSS address as the first one in
Resolver Repository. In the case where the data structure for the the Resolver Repository. In the case where the data structure for
DNS Server List is full of RDNSS entries (that is, has more the DNS Server List is full of RDNSS entries (that is, has more
RDNSSes than the sufficient number discussed in Section 5.3.1), RDNSSes than the sufficient number discussed in Section 5.3.1),
delete from the DNS Server List the entry with the shortest delete from the DNS Server List the entry with the shortest
Expiration-time (i.e., the entry that will expire first). The Expiration-time (i.e., the entry that will expire first). The
corresponding RDNSS address is also deleted from the Resolver corresponding RDNSS address is also deleted from the Resolver
Repository. For the ordering of RDNSS addresses in an RDNSS Repository. For the ordering of RDNSS addresses in an RDNSS
option, position the first RDNSS address in the RDNSS option as option, position the first RDNSS address in the RDNSS option as
the first one in the Resolver Repository, the second RDNSS address the first one in the Resolver Repository, the second RDNSS address
in the option as the second one in the repository, and so on. in the option as the second one in the repository, and so on.
This ordering allows the RDNSS addresses in the RDNSS option to be This ordering allows the RDNSS addresses in the RDNSS option to be
preferred according to their order in the RDNSS option for the DNS preferred according to their order in the RDNSS option for the DNS
skipping to change at page 13, line 44 skipping to change at page 13, line 43
Protocol version 6 (ICMPv6) Parameters" registry (http:// Protocol version 6 (ICMPv6) Parameters" registry (http://
www.iana.org/assignments/icmpv6-parameters/ www.iana.org/assignments/icmpv6-parameters/
icmpv6-parameters.xhtml#icmpv6-parameters-5). icmpv6-parameters.xhtml#icmpv6-parameters-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, Bing Liu, and
The authors sincerely appreciate their contributions. Tassos Chatzithomaoglou. The authors sincerely appreciate their
contributions.
This document was supported by Institute for Information & This document was supported by Institute for Information &
communications Technology Promotion (IITP) grant funded by the Korea communications Technology Promotion (IITP) grant funded by the Korea
government (MSIP) [10041244, Smart TV 2.0 Software Platform]. 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.
 End of changes. 9 change blocks. 
22 lines changed or deleted 23 lines changed or added

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