[dns-operations] Comments welcome : draft-song-dnsop-ipv6only-dns-00
Davey Song
songlinjian at gmail.com
Fri Oct 10 21:11:06 UTC 2014
Hi everyone,
I have recently proposed a draft on the IPv6-only DNS deployment. Here is
the abstract of this draft:
Abstract
Focused on the IPv6 transition scenarios with IPv6-only networks,
this memo revisits the behavior and implicit inertia of DNS which may
hinder the IPv6-only DNS deployment. To ease the situation, this
memo intend to introduce a second infrastructure to support IPv6-only
DNS experiment and development, especially in the newly developed
IPv6 only network.
It is still an early version of a simple idea. I'm writing this letter to
collect the comments and feedback from the community, pro or con, which
will help us to better understand this issue and better preparation for a
IETF draft.
Anyone who will contribute this discussion, thank you in advance.
Best regards,
Davey
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20141011/3ba327b3/attachment.html>
-------------- next part --------------
DNSOP Working Group L. Song
Internet-Draft BII
Intended status: Standards Track P. Vixie
Expires: April 13, 2015 Farsight Security, Inc.
D. Ma
ZDNS
October 10, 2014
Considerations on IPv6-only DNS
draft-song-dnsop-IPv6only-DNS-00
Abstract
Focused on the IPv6 transition scenarios with IPv6-only networks,
this memo revisits the behavior and implicit inertia of DNS which may
hinder the IPv6-only DNS deployment. To ease the situation, this
memo intend to introduce a second infrastructure to support IPv6-only
DNS experiment and development, especially in the newly developed
IPv6 only network.
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 April 13, 2015.
Copyright Notice
Copyright (c) 2014 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
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
Song, et al. Expires April 13, 2015 [Page 1]
Internet-Draft IPv6-only DNS October 2014
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. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Revisit to current situation . . . . . . . . . . . . . . . . 4
3.1. DNS Referral Response Size limitation . . . . . . . . . . 4
3.2. Additional section in IPv4/IPv6 Environments . . . . . . 4
3.3. DNS proxy . . . . . . . . . . . . . . . . . . . . . . . . 5
4. An additional DNS architecture . . . . . . . . . . . . . . . 6
4.1. IANA function and operation . . . . . . . . . . . . . . . 6
4.2. IPv6-only Root server . . . . . . . . . . . . . . . . . . 8
4.3. IPv6-only Recursive Resolver . . . . . . . . . . . . . . 9
4.4. Relations with Existing 13 root . . . . . . . . . . . . . 9
5. Risk and Impact Considerations . . . . . . . . . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
9.1. Normative References . . . . . . . . . . . . . . . . . . 10
9.2. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction
It's commonly believed that the dual-stack model is the best practice
for IPv6 transition in which IPv4 and IPv6 function can work in
parallel without mutual interference. Based on this model, most
things are expected to be converted into IPv6 smoothly when IPv4
address pool run out. However dual-stack approach not only gives
IPv4/IPv6 capability on end system, network devices, DNS and
application servers, but also brings some problems (IPv4
fallback)[RFC6555] or even IPv4/IPv6 competition as a side effect
which makes the dual stack model complicated.
To accelerate the transition to a fully connected IPv6 network, there
are some works on IPv6-only experiments [RFC6586] and IETF standards
[RFC6333], [RFC7040] which verify IPv6 capability and support the
IPv6-only deployment. Particularly on domain name system in ISP
network, it's expected that more and more DNS resolvers or modules
will be provisioned with only IPv6 address. It is mainly due to
three aspects:
1) To save more free IPv4 addresses in deploying new DNS resolvers;
Song, et al. Expires April 13, 2015 [Page 2]
Internet-Draft IPv6-only DNS October 2014
2) To reduce the cost and risk of management in dual stack
environment;
3) To follow the inherent requirement in the IPv6 transition
scenarios, such as DS-Lite [RFC6333];
It's worthwhile to mention that the tunnel technology provides an
approach that allow IPv6-only network deployment become independent
from the rest of the world which makes the IPv6-only strategy much
porpular. In the IPv6-only network, the ISPs only provision IPv6
address to the end system, network and DNS element via DHCPv6.
However, IPv6-only resolver will face an Internet which are partly
running in IPv4 only environment and partly in dual-stack, yet with
IPv4-prefered paradigm. As a result, the DNS element in IPv6-only
environment is suggested to adopt proxy function and rely on the
upstream dual-stack DNS recursive server section 5.5 [1] in
[RFC6333]. However, using DNS proxy mechanism is a compromise in
IPv6 transition context, which still has implicit limitations
[RFC5625].
This memo revisits the behavior and implicit inertia of DNS in
existing architecture which may hinder the IPv6-only DNS deployment.
Given there are an increasing number of DNS resolvers who only speak
IPv6, this memo intends to introduce an additional DNS infrastructure
to break through the inertia such as the usage of DNS proxy and
response paradigm, which can support IPv6-only DNS experiment and
development, especially in the newly developed IPv6 only network.
2. Terminology
A: A resource record type used to specify an IPv4 address [RFC1034]
AAAA: A resource record type used to specify an IPv6 address
[RFC3596]
EDNS0: Version 0 of Extension mechanisms for DNS [RFC6891]
DNSSEC: DNS Security Extensions [RFC4033]
MTU: Maximum Transmission Unit, the maximum size for a datagram to be
forwarded on an interface without needing fragmentation [RFC0791],
[RFC2460]
Additional Section: Section in DNS query/response carrying RRs which
may be helpful in using the RRs in the other sections [RFC1034].
Note that in this memo the data in additional section is the A/AAAA
information of NS server, particular for root zone.
Song, et al. Expires April 13, 2015 [Page 3]
Internet-Draft IPv6-only DNS October 2014
3. Revisit to current situation
3.1. DNS Referral Response Size limitation
Due to the required minimum IP reassembly limit for IPv4, the
original DNS standard [RFC1034/1035] limited the UDP message size to
512 octets. It became a historical and practical hard DNS protocol
limit, no matter EDNS0 [RFC6891] was introduced. This limit presents
some special problems for zones wishing to (1) add more authority
servers or (2) advertise the IPv6 addresses of newly updated dual-
stack NS name servers, or (3) use DNSSEC.
In the context of this memo, the limitation is relaxed a little bit
due to the larger MTU of IPv6 (1280 octets) which will be taken as a
premise when we consider the new infrastructure.
3.2. Additional section in IPv4/IPv6 Environments
Given there is hard limitation in the DNS referral response size, the
implementations preferably decide to keep as much data as possible in
the UDP responses no matter it is "critical" or "courtesy"
Appendix B.2 in [RFC4472] . It is a typical case in priming exchange
between recursive resolver and root server. When a name server
resolver bootstrap, it performs the NS lookup for root zone. In the
response packet from root server, the additional section is supposed
to contain all the A & AAAA records of NS domain name. Ultimately,
when all 13 root name servers are assigned IPv6 addresses, the
priming response will increase in size to 800 bytes.
There are different strategies for root server operators to choose
which RRset (A or AAAA) should be in the additional data if not all
of the glue information can be included. Note that in dual-stack
environment, IPv4 glue and IPv6 glue of same zone are actually
competing for the room of DNS UDP packets. For example, in the
implementation of L root server which is run by ICANN, prefers to
return more IPv4 glues as much as possible. In that case only 2 out
10 IPv6 glues are included.
If we execute dig . ns @l.root-servers.net , we can simply found the
content in additional section as follows, no matter via IPv4 or IPv6
DNS transport.
;; ADDITIONAL SECTION:
a.root-servers.net. 518400 IN A 198.41.0.4
b.root-servers.net. 518400 IN A 192.228.79.201
Song, et al. Expires April 13, 2015 [Page 4]
Internet-Draft IPv6-only DNS October 2014
c.root-servers.net. 518400 IN A 192.33.4.12
d.root-servers.net. 518400 IN A 199.7.91.13
e.root-servers.net. 518400 IN A 192.203.230.10
f.root-servers.net. 518400 IN A 192.5.5.241
g.root-servers.net. 518400 IN A 192.112.36.4
h.root-servers.net. 518400 IN A 128.63.2.53
i.root-servers.net. 518400 IN A 192.36.148.17
j.root-servers.net. 518400 IN A 192.58.128.30
k.root-servers.net. 518400 IN A 193.0.14.129
l.root-servers.net. 518400 IN A 199.7.83.42
m.root-servers.net. 518400 IN A 202.12.27.33
a.root-servers.net. 518400 IN AAAA 2001:503:ba3e::2:30
b.root-servers.net. 518400 IN AAAA 2001:500:84::b
In the context of this memo, it is much less being right to follow
the existing response paradigm, when we consider the IPv6-only
resolver deployment. It's will be unrecoverable and become a
disaster, if (1)major part of IPv6 NS servers for Root zone are
absent and (2)the resolver did not issue one or more additional
queries for performance consideration.
It is also proposed that it will be wiser to take the transport of
DNS query as a hint to decide which additional data should be set.
There are two reasons why it is not adopted as an optimization. One
is that it breaks the model of independence of DNS transport and
resource records section 1.2 [2] in [RFC4472]. Another is that it
will bring unpredictable risk to the performance and stability of
current root server system.
3.3. DNS proxy
In IPv6-only networking, DNS proxy approach is recommended for
IPv6-only DNS element. On one hand, it benefits by avoiding the
difficulty to perform all DNS resolution over IPv6, given the fact
that NS server are still IPv4 only for large website which already
provide IPv6 services for their users, such as google, Yahoo and
Song, et al. Expires April 13, 2015 [Page 5]
Internet-Draft IPv6-only DNS October 2014
Wikipedia. On another hand, it lose the opportunity to perform a
full recursive resolver function via IPv6, at least in Root and TLD
level which is mainly IPv6-enabled.
In additional, as described in the beginning of [RFC5625], the DNS
proxy function is not an optimal solution to serve the IPv6-only
resolver requirement. Large packets cause by priming request or
DNSSEC validation packets will be blocked due to the proxy
implementation. It is suggested that: "To ensure full DNS protocol
interoperability it is preferred that client stub resolvers should
communicate directly with full-feature, upstream recursive resolvers
wherever possible."
As more and more NS servers updated to IPv6-enabled, the direct IPv6
resolution will be preferable in IPv6-only resolver. But regarding
the long-tail feature of IPv6 adoption in NS servers, certain back-
forward compatible mechanism should be designed, which indeed make an
incentive model for IPv6 adoption over IPv4 as well.
4. An additional DNS architecture
To support IPv6-only public testing and deployment in a wide scale
and avoid destabilizing the current root server system in the same
while, this memo proposes to setup a second infrastructure which is
basically composed of three parts : new IANA operations, IPv6-only
root servers and DNS resolvers.
4.1. IANA function and operation
Song, et al. Expires April 13, 2015 [Page 6]
Internet-Draft IPv6-only DNS October 2014
+------------+
|TLD operator|
+-----+------+
| TLD update
+------------v------------+
| |
|Vetting and Authorizing |
| |
+-----------+-------------+
|
+--------------v----------------+
| |
| Editing and Signing |
| |
+----+--------------------+-----+
| |
+-------v-------+ +--------v--------+
| | | |
| Existing Root | | IPv6-only Root |
| Zone Data | | Zone Data |
| | | |
+-------+-------+ +--------+--------+
| |
+----------v------+ +--------v--------+
| | | |
| Root servers: | | IPv6-only Root: |
| A,B,C,D,...,M | | X1,X2,X3... |
| | | |
+-----------------+ +-----------------+
Figure 1 New DNS Root architecture with IPv6-only Root zone
In the current practice of root zone management, IANA first receives
the TLD updates from TLD operators. After vetting and authorizing
process to confirm the changes to the Root zone, the Zone maintainer
(currently Verisign) will be notified to edit and sign the zone file,
then distribute to the 12 root server operators. In the current
architecture, one intuitive approach is to ask IANA to add at least
two additional letters "N" and "O" into the current 13 ones with
dedicated IPv6-only NS servers.
There are two reasons why it is not preferable. First, following the
DNS response mechanism from current Root servers, it is large
possibility that the newly added IPv6 glue information will not be
advertised via additional data. The second is that this approach
will bring the impact and risk to the current root server system
which is breaking our principle.
Song, et al. Expires April 13, 2015 [Page 7]
Internet-Draft IPv6-only DNS October 2014
In this memo we suggest IANA to produce an additional form of the DNS
root zone (variant root zone) as we depict in figure 1. The new DNS
root zone means there should be an additional forms of hint file and
new root zone file with different apex NS record set. Note that the
additional ZSK/KSK in DNSSEC process is optional for IANA.
The following example show the apex NS record set for IPv6-only
variant Root zone including address glue. This data would be
included in a variant root zone before DNSSEC signing, and would be
also be published as a "root hint" file.
. IN NS X1.iana-servers.net.
. IN NS X2.iana-servers.net.
$ORIGIN iana-servers.net.
X1 IN AAAA 2001:?:3::1
X2 IN AAAA 2001:?:4::2
In this case, although there exists two root zones, they are all
vetted and signed by unique IANA function which guarantee the "One
Internet" principle.
4.2. IPv6-only Root server
According to our goal in this memo, the new Root servers (Root
operator) will adopt the new strategies and technologies to better
serve the IPv6-only network. For example, the new server will return
the full IPv6 glue with higher priority in the priming response.
As to the operation requirement for IPv6-only Root server, there is
no particular difference from current practice of 13 root servers.
The only notable change is that the IPv6-only Root servers are
expected to subscribe the IPv6-only Root zone from IANA which will
transfer the Zone data via AXFR/IXFR as well. The users (resolver)
will following the guide of new hint file to find the IPv6-only Root
server as its entrance.
Although it is out of scope in this memo to discuss how to choose
IPv6-only operators to host the new root zone. But it is worthwhile
to mention how many operators can be present in the new root server
list. Based on that IPv6 MTU is 1280 octets, we can calculate that 7
more authority server can be added in the root zone if the DNS
referral response contain all the IPv4 and IPv6 address. Considering
the case that DNS referral response contain only IPv6 address for
Song, et al. Expires April 13, 2015 [Page 8]
Internet-Draft IPv6-only DNS October 2014
each NS server, the number of authority server for the root zone can
be expanded to 27.
4.3. IPv6-only Recursive Resolver
Given that IANA provides two forms of root zone, IPv6-only resolver
has the choice to different hint files. If they choose the new
IPv6-only hint file and make a priming request when it bootstrap,
they will get consistent information of IPv6 glue. It is important
especially when IPv6 network is not fully connected as IPv4. More
IPv6 glue received in resolver side means much more stable in this
regard.
As to the behavior of IPv6-only resolver, it receives all the IPv6
glue information from Root level via IPv6-only root. But when it
comes to TLD and second level domain which has no AAAA record for its
NS server, IPv6-only resolver should make a patch to fall back to
Proxy function to continue the services. It can run the two modes
simultaneous making the proxy as a backup or using happy
eyeballs[RFC6555] approach.
4.4. Relations with Existing 13 root
It is encouraging that current 12 root operators can allocate new
servers to host the IPv6-only root zone in parallel with existing
IPv6 dual stack servers.
5. Risk and Impact Considerations
TBD
1) IANA root zone management doubled. Single DNSSEC key or two keys?
2) Introduce new server/operator will cause risk to unstable
situation
3) Make recursive resolver complicated. Pro and Con analysis are
necessary. Is it worth for IPv6-only resolver to do so?
6. Security Considerations
TBD
7. IANA Considerations
IANA should produce an additional form of the DNS root zone (variant
root zone) to allow IPv6-only public testing and deployment in a wide
scale.
Song, et al. Expires April 13, 2015 [Page 9]
Internet-Draft IPv6-only DNS October 2014
8. Acknowledgements
TBD
9. References
9.1. Normative References
[I-D.ietf-dnsop-respsize]
Vixie, P., Kato, A., and J. Abley, "DNS Referral Response
Size Issues", draft-ietf-dnsop-respsize-15 (work in
progress), February 2014.
[I-D.lee-dnsop-scalingroot]
Lee, X., Vixie, P., and Z. Yan, "How to scale the DNS root
system?", draft-lee-dnsop-scalingroot-00 (work in
progress), July 2014.
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September
1981.
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
[RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi,
"DNS Extensions to Support IP Version 6", RFC 3596,
October 2003.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements", RFC
4033, March 2005.
[RFC4472] Durand, A., Ihren, J., and P. Savola, "Operational
Considerations and Issues with IPv6 DNS", RFC 4472, April
2006.
[RFC5625] Bellis, R., "DNS Proxy Implementation Guidelines", BCP
152, RFC 5625, August 2009.
[RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-
Stack Lite Broadband Deployments Following IPv4
Exhaustion", RFC 6333, August 2011.
[RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with
Dual-Stack Hosts", RFC 6555, April 2012.
Song, et al. Expires April 13, 2015 [Page 10]
Internet-Draft IPv6-only DNS October 2014
[RFC6586] Arkko, J. and A. Keranen, "Experiences from an IPv6-Only
Network", RFC 6586, April 2012.
[RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms
for DNS (EDNS(0))", STD 75, RFC 6891, April 2013.
[RFC7040] Cui, Y., Wu, J., Wu, P., Vautrin, O., and Y. Lee, "Public
IPv4-over-IPv6 Access Network", RFC 7040, November 2013.
9.2. URIs
[1] http://tools.ietf.org/html/rfc6333#section-5.5
[2] http://tools.ietf.org/html/rfc4472#section-1.2
Authors' Addresses
Linjian Song
BII
2508 Room, 25th Floor, Tower A, Time Fortune
Beijing 100028
P. R. China
Email: songlinjian at gmail.com
Paul Vixie
Farsight Security, Inc.
155 Bovet Road, #476
San Mateo, CA 94402
USA
Phone: +1 650 489 7919
Email: vixie at farsightsecurity.com
Di Ma
ZDNS
Beijing
P. R. China
Email: madi at zdns.cn
Song, et al. Expires April 13, 2015 [Page 11]
More information about the dns-operations
mailing list