idnits 2.17.1 draft-song-sunset4-ipv6only-dns-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 15 instances of lines with non-RFC2606-compliant FQDNs in the document. == There are 13 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 2 instances of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 27, 2014) is 3468 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 316 -- Looks like a reference, but probably isn't: '2' on line 318 == Unused Reference: 'I-D.ietf-dnsop-respsize' is defined on line 261, but no explicit reference was found in the text == Unused Reference: 'I-D.lee-dnsop-scalingroot' is defined on line 266, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 6555 (Obsoleted by RFC 8305) Summary: 2 errors (**), 0 flaws (~~), 6 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Sunset4 Working Group L. Song 3 Internet-Draft Beijing Internet Institute 4 Intended status: Informational P. Vixie 5 Expires: April 30, 2015 Farsight Security, Inc. 6 D. Ma 7 ZDNS 8 October 27, 2014 10 Considerations on IPv6-only DNS Development 11 draft-song-sunset4-ipv6only-dns-00 13 Abstract 15 Deployment of IPv6-only networks are impacted by assumptions of 16 IPv4-only or dual-stack transition scenarios. For example, these 17 assumptions are in the operations of DNS. This memo is problem 18 statement and hopes to eventually propose a mitigation technique. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on April 30, 2015. 37 Copyright Notice 39 Copyright (c) 2014 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. Revisit to current situation . . . . . . . . . . . . . . . . 3 57 3.1. DNS Referral Response Size limitation . . . . . . . . . . 3 58 3.2. Additional section in IPv4/IPv6 Environments . . . . . . 4 59 3.3. DNS proxy . . . . . . . . . . . . . . . . . . . . . . . . 5 60 4. Mitigation approach . . . . . . . . . . . . . . . . . . . . . 6 61 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 62 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 63 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 64 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 65 8.1. Normative References . . . . . . . . . . . . . . . . . . 6 66 8.2. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 7 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 69 1. Introduction 71 It's commonly believed that the dual-stack model is the best practice 72 for IPv6 transition in which IPv4 and IPv6 function can work in 73 parallel without mutual interference. Based on this model, IP stacks 74 and applications are expected to be converted into IPv6 smoothly when 75 IPv4 address pool run out. The dual-stack approach gives IPv4/IPv6 76 capability on end system, network devices, DNS and application 77 servers, but, as a side effect, brings additional problems, such as 78 IPv4 fallback [RFC6555] or even IPv4/IPv6 competition. This issue 79 makes the dual stack model more complicated to deploy and manage, and 80 overall network less reliable. 82 To accelerate the transition to a fully connected IPv6 network, 83 IPv6-only experiments [RFC6586]and IETF standards [RFC6333], 84 [RFC7040] are documented. Some techniques verify IPv6 capability and 85 support the IPv6-only deployment. In IPv6-only environments, DNS 86 resolvers or modules are provisioned only with IPv6 address. It is 87 mainly due to three aspects: 89 1) To save more free IPv4 addresses in deploying new DNS resolvers; 91 2) To reduce the cost and risk of management in dual stack 92 environment; 94 3) To follow the inherent requirement in the IPv6 transition 95 scenarios, such as DS-Lite [RFC6333]; 96 It's worthwhile to mention that the tunnel technology provides an 97 approach that allow IPv6-only network deployment become independent 98 from the rest of the world which makes the IPv6-only strategy much 99 porpular. In the IPv6-only network, the ISPs only provision IPv6 100 address to the end system, network and DNS element via DHCPv6. 101 However, IPv6-only resolver will face an Internet which are partly 102 running in IPv4 only environment and partly in dual-stack, yet with 103 IPv4-prefered paradigm. As a result, the DNS element in IPv6-only 104 environment is suggested to be forwarding requests by relying on the 105 upstream dual-stack DNS recursive server section 5.5 [1] in 106 [RFC6333]. However, using the DNS proxy mechanism is a compromise in 107 IPv6 transition context, which still has implicit limitations 108 [RFC5625]. 110 This memo revisits the behavior and implicit inertia of DNS in 111 existing architecture which my hinder the IPv6-only DNS development. 113 2. Terminology 115 A: A resource record type used to specify an IPv4 address [RFC1034] 117 AAAA: A resource record type used to specify an IPv6 address 118 [RFC3596] 120 EDNS0: Version 0 of Extension mechanisms for DNS [RFC6891] 122 DNSSEC: DNS Security Extensions [RFC4033] 124 MTU: Maximum Transmission Unit, the maximum size for a datagram to be 125 forwarded on an interface without needing fragmentation [RFC0791], 126 [RFC2460] 128 Additional Section: Section in DNS query/response carrying RRs which 129 may be helpful in using the RRs in the other sections [RFC1034]. 130 Note that in this memo the data in additional section is the A/AAAA 131 information of NS server, particular for root zone. 133 3. Revisit to current situation 135 3.1. DNS Referral Response Size limitation 137 Due to the required minimum IP reassembly limit for IPv4, the 138 original DNS standard [RFC1034][RFC1035] limited the UDP message size 139 to 512 octets. It became an historical and practical hard DNS 140 protocol limit, even after EDNS0 [RFC6891] was introduced to mitigate 141 this issue[draft-ietf-dnsop-respsize-15]. This limit presents s for 142 zones wishing to (1) add more authority servers or (2) advertise the 143 IPv6 addresses of newly updated dual-stack NS name servers, or (3) 144 use DNSSEC. 146 In the context of this memo, the limitation may be relaxed due to the 147 larger base MTU of IPv6 (1280 octets) which is the default for 148 IPv6-only networks. 150 3.2. Additional section in IPv4/IPv6 Environments 152 Given there is hard limitation in the DNS referral response size, the 153 implementations preferably decide to keep as much data as possible in 154 the UDP responses no matter it is "critical" or "courtesy" 155 Appendix B.2 in [RFC4472] . It is a typical case in priming exchange 156 between recursive resolver and root server. When a name server 157 resolver bootstrap, it performs the NS lookup for root zone. In the 158 response packet from root server, the additional section is supposed 159 to contain all the A & AAAA records of NS domain name. Ultimately, 160 when all 13 root name servers are assigned IPv6 addresses, the 161 priming response will increase in size to 800 bytes. 163 There are different strategies for root server operators to choose 164 which RRset (A or AAAA) should be in the additional data if not all 165 of the glue information can be included. Note that in dual-stack 166 environment, IPv4 glue and IPv6 glue of same zone are actually 167 competing for the room of DNS UDP packets. For example, some of DNS 168 root servers prefer to return as many IPv4 glue records as possible. 169 In that case only 2 out 10 IPv6 glues are included as shown below, 170 irrespective of IPv4 or IPv6 DNS transport. 172 ;; ADDITIONAL SECTION: 174 a.root-servers.net. 518400 IN A 198.41.0.4 176 b.root-servers.net. 518400 IN A 192.228.79.201 178 c.root-servers.net. 518400 IN A 192.33.4.12 180 d.root-servers.net. 518400 IN A 199.7.91.13 182 e.root-servers.net. 518400 IN A 192.203.230.10 184 f.root-servers.net. 518400 IN A 192.5.5.241 186 g.root-servers.net. 518400 IN A 192.112.36.4 188 h.root-servers.net. 518400 IN A 128.63.2.53 190 i.root-servers.net. 518400 IN A 192.36.148.17 191 j.root-servers.net. 518400 IN A 192.58.128.30 193 k.root-servers.net. 518400 IN A 193.0.14.129 195 l.root-servers.net. 518400 IN A 199.7.83.42 197 m.root-servers.net. 518400 IN A 202.12.27.33 199 a.root-servers.net. 518400 IN AAAA 2001:503:ba3e::2:30 201 b.root-servers.net. 518400 IN AAAA 2001:500:84::b 203 In the context of IPv6-only deployments, these glue records are much 204 less optimal. They are based on IPv4 or dual-stack assumptions, 205 where IPv4 is still dominant. It may negatively impact the IPv6 206 services in IPv6-only deployments. 208 If the glue set sent in the response is correlated with the IP 209 version of the DNS transport, then the answer, in most cases, will be 210 more optimal. There are two reasons why it is not adopted as an 211 optimization. One is that it breaks the model of independence of DNS 212 transport and resource records section 1.2 [2] in [RFC4472]. Another 213 is that it will bring unpredictable risk to the performance and 214 stability of current root server system. 216 3.3. DNS proxy 218 In IPv6-only networking, DNS proxy approach is recommended for 219 IPv6-only DNS element. On one hand, it avoids the difficulty to 220 perform all DNS resolution over IPv6 transport, given that still many 221 networks on Internet are only on IPv4. On another hand, it loses the 222 opportunity to perform a full recursive resolver function via IPv6, 223 at least in Root and TLD level which are mostly IPv6 enabled. 225 In additional, as described in the beginning of [RFC5625], the DNS 226 proxy function is not an optimal solution to serve the IPv6-only 227 resolver requirement. Large packets caused by priming request or 228 DNSSEC validation packets will be blocked due to the proxy 229 implementation. It is suggested that: "To ensure full DNS protocol 230 interoperability it is preferred that client stub resolvers should 231 communicate directly with full-feature, upstream recursive resolvers 232 wherever possible." 234 As more and more NS servers updated to IPv6 transport and reachable 235 over the IPv6 Internet, the direct IPv6 resolution will be preferable 236 in IPv6-only resolver. But regarding the long-tail feature of IPv6 237 adoption in NS servers, certain back-forward compatible mechanism 238 should be designed, which indeed make an incentive model for IPv6 239 adoption over IPv4 as well. 241 4. Mitigation approach 243 TBD 245 5. Security Considerations 247 TBD 249 6. IANA Considerations 251 TBD 253 7. Acknowledgements 255 TBD 257 8. References 259 8.1. Normative References 261 [I-D.ietf-dnsop-respsize] 262 Vixie, P., Kato, A., and J. Abley, "DNS Referral Response 263 Size Issues", draft-ietf-dnsop-respsize-15 (work in 264 progress), February 2014. 266 [I-D.lee-dnsop-scalingroot] 267 Lee, X., Vixie, P., and Z. Yan, "How to scale the DNS root 268 system?", draft-lee-dnsop-scalingroot-00 (work in 269 progress), July 2014. 271 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 272 1981. 274 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 275 STD 13, RFC 1034, November 1987. 277 [RFC1035] Mockapetris, P., "Domain names - implementation and 278 specification", STD 13, RFC 1035, November 1987. 280 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 281 (IPv6) Specification", RFC 2460, December 1998. 283 [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, 284 "DNS Extensions to Support IP Version 6", RFC 3596, 285 October 2003. 287 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 288 Rose, "DNS Security Introduction and Requirements", RFC 289 4033, March 2005. 291 [RFC4472] Durand, A., Ihren, J., and P. Savola, "Operational 292 Considerations and Issues with IPv6 DNS", RFC 4472, April 293 2006. 295 [RFC5625] Bellis, R., "DNS Proxy Implementation Guidelines", BCP 296 152, RFC 5625, August 2009. 298 [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 299 Stack Lite Broadband Deployments Following IPv4 300 Exhaustion", RFC 6333, August 2011. 302 [RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with 303 Dual-Stack Hosts", RFC 6555, April 2012. 305 [RFC6586] Arkko, J. and A. Keranen, "Experiences from an IPv6-Only 306 Network", RFC 6586, April 2012. 308 [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms 309 for DNS (EDNS(0))", STD 75, RFC 6891, April 2013. 311 [RFC7040] Cui, Y., Wu, J., Wu, P., Vautrin, O., and Y. Lee, "Public 312 IPv4-over-IPv6 Access Network", RFC 7040, November 2013. 314 8.2. URIs 316 [1] http://tools.ietf.org/html/rfc6333#section-5.5 318 [2] http://tools.ietf.org/html/rfc4472#section-1.2 320 Authors' Addresses 322 Linjian Song 323 Beijing Internet Institute 324 2508 Room, 25th Floor, Tower A, Time Fortune 325 Beijing 100028 326 P. R. China 328 Email: songlinjian@gmail.com 329 Paul Vixie 330 Farsight Security, Inc. 331 155 Bovet Road, #476 332 San Mateo, CA 94402 333 USA 335 Phone: +1 650 489 7919 336 Email: vixie@farsightsecurity.com 338 Di Ma 339 ZDNS 340 Beijing 341 P. R. China 343 Email: madi@zdns.cn