idnits 2.17.1 draft-hazeyama-sunset4-dns-a-filter-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 10, 2013) is 3943 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 3736 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 3315 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 3633 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 6145 (Obsoleted by RFC 7915) -- Obsolete informational reference (is this intentional?): RFC 6555 (Obsoleted by RFC 8305) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group H. Hazeyama 3 Internet-Draft NAIST / WIDE Project 4 Intended status: Informational T. Ishihara 5 Expires: January 11, 2014 Univ. of Tokyo / WIDE Project 6 O. Nakamura 7 Keio Univ. / WIDE Project 8 July 10, 2013 10 DNS A Record Filtering for the migration from dual stack networks to 11 IPv6 only networks. 12 draft-hazeyama-sunset4-dns-a-filter-00 14 Abstract 16 Filtering out of A records of a DNS response on a DNS proxy, we call 17 it ``DNS A record filtering'', is an effective and efficient solution 18 as a smooth migration to IPv6 only networks. DNS A record filtering 19 can mitigate fallback problems of dual stack nodes on IPv6 only 20 environment. This memo mentions the components of the DNS A record 21 filter solution, procedure of DNS queries and refers current issues. 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on January 11, 2014. 40 Copyright Notice 42 Copyright (c) 2013 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 59 2. Technology and Terminology . . . . . . . . . . . . . . . . . . 3 60 3. The mechanism of DNS A Record Filtering . . . . . . . . . . . 4 61 3.1. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 4 62 3.2. Components . . . . . . . . . . . . . . . . . . . . . . . . 4 63 3.3. Procedure . . . . . . . . . . . . . . . . . . . . . . . . 6 64 3.3.1. IPv6-only hosts . . . . . . . . . . . . . . . . . . . 6 65 3.3.2. IPv6-full-capable dual stack host . . . . . . . . . . 6 66 3.3.3. IPv6-partial-capable dual stack host . . . . . . . . . 7 67 4. Discussions . . . . . . . . . . . . . . . . . . . . . . . . . 9 68 4.1. Limitation for IPv4 only applications . . . . . . . . . . 9 69 4.2. CNAME of the reply to an type A query . . . . . . . . . . 9 70 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 71 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 72 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 73 7.1. Normative References . . . . . . . . . . . . . . . . . . . 10 74 7.2. Informative References . . . . . . . . . . . . . . . . . . 10 75 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 11 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 78 1. Introduction 80 In an IPv6 only network [RFC6586], that is composed of DHCP6 and 81 DNS64/NAT64, IPv4/IPv6 dual stack hosts have fallback problems due to 82 the partial IPv6 capability, happy eyeball functions [RFC6555], 83 default route on IPv4 link local address due to the link local 84 assumption[RFC3927], arrival timings of DNS responses, and so on. 86 As well as so-called DNS AAAA record filtering in IPv4 only networks, 87 filtering out of A records of a DNS response on a DNS proxy, we call 88 it ``DNS A record filter proxy'', is an effective and efficient 89 solution to mitigate fallback problems of dual stack nodes on IPv6 90 only environment. 92 DNS A record filtering solution allows dual stack nodes to resolve 93 names both by IPv4 and IPv6 by notifying the IPv4 address of an DNS A 94 record filter proxy through DHCP4 and the IPv6 address of the DNS A 95 record filter proxy through DHCP6. On the other hand, a DNS A record 96 filter proxy forces dual stack nodes to conduct actual communications 97 after the name query procedure through IPv6, by telling only AAAA or 98 NAT64 mapped AAAA records to dual stack nodes. In this solution, no 99 special action is required on dual stack nodes. A network operator 100 can choose DNS64 and NAT64 location along with their design policy. 102 1.1. Requirements Language 104 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 105 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 106 document are to be interpreted as described in RFC 2119 [RFC2119]. 108 2. Technology and Terminology 110 In this document, the following terms are used. "Dual Stack" refers 111 to a technique for providing complete support for both Internet 112 protocols -- IPv4 and IPv6 -- in hosts and routers [RFC4213]. 114 "NAT64" refers to a Network Address Translator - Protocol Translator 115 defined in [RFC6052], [RFC6144], [RFC6145], [RFC6146], [RFC6384]. 117 "DNS64" refers DNS extensions to use NAT64 translation from IPv6 118 clients to IPv4 servers with name resolution mechanisms that is 119 defined in [RFC6147]. 121 "DHCP4" refers Dynamic Host Configuration Protocol for IPv4 that is 122 defined in [RFC2131]. 124 "DHCP6" refers Dynamic Host Configuration Protocol for IPv6. So 125 called "Stateful DHCP6" is defined in [RFC3315] and "Stateless DHCP6" 126 is defined in [RFC3736]. "DHCP-PD" or "DHCPv6 Prefix Delegation" 127 refers IPv6 Prefix Options for DHCP6 that is initially defined in 128 [RFC3633] and updated in [RFC6603]. 130 "ND" refers Neighbor Discovery for IP version 6 (IPv6) that is 131 defined in [RFC4861] and updated in [RFC5942]. 133 3. The mechanism of DNS A Record Filtering 135 3.1. Assumptions 137 The DNS A record filtering simply filters out ``A record'' entry of a 138 DNS reply on a DNS proxy. As our assumption, the DNS A record 139 filtering solution is mainly used in an IPv6 only network by 140 combining DNS64/NAT64, DHCP4 and DHCP6. 142 We also assume that hosts are dual stack capable, that is, hosts have 143 ND function and the IPv6 address assignment function by RA at least. 144 Stateful DHCP6, Stateless DHCP6 and IPv6 DNS query functions are 145 preferable to be equipped by hosts. 147 3.2. Components 149 The components of the network, where this DNS A record filtering is 150 employed, are as follows; 152 o DHCP4 server: this DHCP4 server offers a private IPv4 address to 153 mitigate the long fall back problem due to the IPv4 link local 154 assumption. The DHCP4 server also offers the IPv4 address of the 155 DNS A record filter proxy. To avoid the selection of the IPv4 by 156 Happy Eyeball [RFC6555] in a dual stack host, this DHCP4 server 157 MUST NOT provide the IPv4 default route. 159 o DHCP6 server: this DHCP6 server MUST provide the IPv6 address of 160 the DNS A record filter proxy. Both stateful DHCP6 and stateless 161 DHCP6 can be employed. If the subnet is composed of a security 162 switch and/or security wi-fi controllers, stateful DHCP6 is prefer 163 to avoid the blocking due to the multiple temporary IPv6 address 164 on a host. 166 o DNS A record filter proxy : this DNS proxy is the key component of 167 this solution. The DNS proxy SHOULD be located on the leaf 168 subnet. The DNS proxy has a private IPv4 address that SHOULD be 169 the same subnet address provided by the DHCP4. The DNS proxy has 170 an IPv6 address that is announced to hosts through DHCP6. 172 o DNS64 server : at least, one DNS64 server is required. The DNS A 173 record filter proxy forwards all queries to this DNS64 server 174 directly, or several DNS forwarder can be placed for load 175 balancing of DNS64 servers 177 o Authoritative DNS servers : these authoritative DNS servers would 178 be queried by DNS64 servers. These authoritative DNS servers MUST 179 NOT return inappropriate replies mentioned in [RFC4074] to kick 180 the fallback function of DNS64 servers 182 o NAT64 translators : at least, one NAT64 translator is placed that 183 can be reached by hosts through IPv6. A NAT64 translator can be 184 settled as the gateway of the leaf subnet, or an aggregated 185 translator of the intra network, or a global reachable open 186 translator. Several NAT64 translators can be registered in DNS64 187 servers for the load balancing or for handling different IPv4 188 prefixes by each NAT64 translrator. 190 Figure 1 shows a sample network topology of this solution. 192 +-----------------+ 193 |Authoritative DNS| 194 +-----------------+ 195 | 196 +------ IPv6 Internet ------+ +---- IPv4 Internet ---+ 197 | | 198 +--------------+ +-------+ +------+ 199 | IPv6 router | | DNS64 | | NAT64| 200 +--------------+ +-------+ +------+ 201 | | | 202 +--------------- IPv6 backbone ----------------------+ 203 | 204 +----------+ +-----------+ +--------+ +--------+ 205 | A Record | | IPv6 | | DHCP6 | | DHCP4 | 206 | Filter | | Router | | server | | server | 207 | Proxy | +-----------+ +--------+ +--------+ 208 +----------+ | | | 209 | | | | 210 +--- /64 prefix segment, closed private IPv4 segment ------+ 211 | | 212 | | 213 +----------------+ +------------------+ 214 |ipv6-only hosts | | dual stack hosts | 215 +----------------+ +------------------+ 217 A sample network topology of DNS A record filtering 218 Figure 1 220 3.3. Procedure 222 3.3.1. IPv6-only hosts 224 The procedure on IPv6-only hosts is as follows; 226 o The host connects to the leaf subnet in layer 2 level. 228 o The host gets global IPv6 address through RA or stateful DHCP6, 229 and also learns the IPv6 address of the DNS A record filter proxy. 231 o When the host connects to an URL, the hosts queries by type ANY or 232 by type AAAA to the DNS A record filter proxy through IPv6. 234 o The DNS A record filter proxy forwards the received the type ANY 235 query to the upper DNS forwarder or DNS64 server. 237 o When the DNS64 server receives the query, the DNS64 server 238 forwards the issued FQDN to the upper authoritative DNS. 240 * If the FQDN has AAAA record, the DNS64 returns AAAA record to 241 the DNS A record filter proxy. 243 * If the FQDN has only A record, the DNS64 returns NAT64 prefix 244 mapped AAAA record to the DNS A record filter proxy. 246 * The DNS64 server or the upper DNS forwarder may return A record 247 to the DNS A record filter proxy with AAAA record. 249 o When the DNS A record filter proxy receives the reply, the DNS A 250 record filter proxy filters out A record if the reply contains A 251 record. 253 o The DNS A record filter proxy returns only AAAA records to the 254 host. 256 o The host access to the issued URL through the IPv6 address of the 257 destination or the NAT64 prefix mapped address. 259 3.3.2. IPv6-full-capable dual stack host 261 An IPv6-full-capable dual stack node equips DHCP6 function and IPv6 262 DNS query function, therefore, IPv6-full-capable dual stack node can 263 send DNS queries through both IPv4 and IPv6. 265 The procedure on IPv6-full-capable dual stack hosts (like Windows 7, 266 etc.) is as follows; 268 o The host connects to the leaf subnet in layer 2 level. 270 o The host gets a global IPv6 address through RA or stateful DHCP6, 271 and also learns the IPv6 address of the DNS A record filter proxy. 273 o The host also gets a private IPv4 address through DHCP4, and also 274 learns the IPv4 address of the DNS A record filter proxy. 276 o The network connectivity check sequence of the Operating System 277 may run, then, IPv6 will be selected on the host because the IPv4 278 is not global reachable. 280 o When the host connects to an URL, the host queries by type ANY to 281 the DNS A record filter proxy through IPv6. 283 o The DNS A record filter proxy forwards the received type ANY query 284 to the upper DNS forwarder or DNS64 server. 286 o When the DNS64 server receives the query, the DNS64 server 287 forwards the issued FQDN to the upper authoritative DNS. 289 * If the FQDN has AAAA record, the DNS64 returns AAAA record to 290 the DNS A record filter proxy. 292 * If the FQDN has only A record, the DNS64 returns NAT64 prefix 293 mapped AAAA record to the DNS A record filter proxy. 295 * The DNS64 server or the upper DNS forwarder may return A record 296 to the DNS A record filter proxy with AAAA record. 298 o When the DNS A record filter proxy receives the reply, the DNS A 299 record filter proxy filters out A record if the reply contains A 300 record. 302 o The DNS A record filter proxy returns only AAAA records to the 303 host. 305 o The host access to the issued URL by using the IPv6 address of the 306 destination or the NAT64 prefix mapped address. 308 3.3.3. IPv6-partial-capable dual stack host 310 An IPv6-partial-capable dual stack node does not equip either DHCP6 311 function or IPv6 DNS query function, therefore, IPv6-partial-capable 312 dual stack node will send DNS queries through only IPv4. However, 313 IPv6-partial-capable dual stack can recognize AAAA record or IPv6 314 address. 316 The procedure on IPv6-partial-capable dual stack host is as follows; 318 o The host connects to the leaf subnet in layer 2 level. 320 o The host gets a global IPv6 address through RA. 322 o The host also gets a private IPv4 address through DHCP4, and also 323 learns the IPv4 address of the DNS A record filter proxy. 325 o The network connectivity check sequence of the Operating System 326 may run, then, IPv6 may be selected on the IPv6-preferred host 327 because the IPv4 is not global reachable. In some case, the 328 network connectivity check may pass by name resolution to the 329 anchor server, or the network connectivity may run again with 330 certain interval. 332 o When the host connects to an URL, the host queries by type ANY to 333 the DNS A record filter proxy through IPv4. 335 o The DNS A record filter proxy forwards the received type ANY query 336 to the upper DNS forwarder or DNS64 server through IPv6. 338 o When the DNS64 server receives the query, the DNS64 server 339 forwards the issued FQDN to the upper authoritative DNS. 341 * If the FQDN has AAAA record, the DNS64 returns AAAA record to 342 the DNS A record filter proxy. 344 * If the FQDN has only A record, the DNS64 returns NAT64 prefix 345 mapped AAAA record to the DNS A record filter proxy. 347 * The DNS64 server or the upper DNS forwarder may return A record 348 to the DNS A record filter proxy with AAAA record. 350 o When the DNS A record filter proxy receives the reply, the DNS A 351 record filter proxy filter out A record if the reply contains A 352 record. 354 o The DNS A record filter proxy returns only AAAA records to the 355 host. 357 o The host access to the issued URL by using the IPv6 address of the 358 destination or the NAT64 prefix mapped address. 360 4. Discussions 362 4.1. Limitation for IPv4 only applications 364 As mentioned in [RFC6586], IPv4-only (or IPv6-incapable) applications 365 exist. Such IPv4-only applications will not work on this DNS A 366 record filtering environment. It is preferable that such IPv4-only 367 applications become dual stack applications if possible. 369 4.2. CNAME of the reply to an type A query 371 We conducted a field trial of this DNS A record filter solution in 372 Interop Tokyo 2013. We provided an IPv6-only Wi-Fi access with this 373 DNS A record filter solution. We used the current Debian release and 374 bind 9.9.2-p1 patch provided from WIDE project as the DNS A Record 375 filter proxy. 377 In the hot stage of Interop Tokyo 2013, we met a trouble case of the 378 current DNS A record filter. In the trouble case, a host used 379 Firefox browser and crawled several web pages for test. In some web 380 page, several contents were lost. We inspected by packet captures, 381 the reply of the A query to the host arrived faster than the arrival 382 of the reply of AAAA record. The reply of A query contained as type 383 CNAME, that was not filtered in the current bind A filter patch. 384 (The A filter patch removed type A record of the CNAME.) On the 385 other hand, in a successful case, the reply of AAAA record, that 386 contained type CNAME and type AAAA of the CNAME, arrived faster than 387 the type A reply. 389 Of course, we have to conduct further investigation and tests, the 390 CNAME on a type A reply would be removed by DNS A filter proxy as 391 well as type A record on the type A reply. 393 5. Security Considerations 395 As well as mentioned in [RFC6586], the use of IPv6 instead of IPv4 by 396 itself does not make a big security difference. 398 6. IANA Considerations 400 This document has no IANA implications. 402 7. References 403 7.1. Normative References 405 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 406 Requirement Levels", BCP 14, RFC 2119, March 1997. 408 [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol 409 (DHCP) Service for IPv6", RFC 3736, April 2004. 411 [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms 412 for IPv6 Hosts and Routers", RFC 4213, October 2005. 414 7.2. Informative References 416 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 417 RFC 2131, March 1997. 419 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 420 and M. Carney, "Dynamic Host Configuration Protocol for 421 IPv6 (DHCPv6)", RFC 3315, July 2003. 423 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 424 Host Configuration Protocol (DHCP) version 6", RFC 3633, 425 December 2003. 427 [RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic 428 Configuration of IPv4 Link-Local Addresses", RFC 3927, 429 May 2005. 431 [RFC4074] Morishita, Y. and T. Jinmei, "Common Misbehavior Against 432 DNS Queries for IPv6 Addresses", RFC 4074, May 2005. 434 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 435 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 436 September 2007. 438 [RFC5942] Singh, H., Beebee, W., and E. Nordmark, "IPv6 Subnet 439 Model: The Relationship between Links and Subnet 440 Prefixes", RFC 5942, July 2010. 442 [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 443 Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, 444 October 2010. 446 [RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for 447 IPv4/IPv6 Translation", RFC 6144, April 2011. 449 [RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation 450 Algorithm", RFC 6145, April 2011. 452 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 453 NAT64: Network Address and Protocol Translation from IPv6 454 Clients to IPv4 Servers", RFC 6146, April 2011. 456 [RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van 457 Beijnum, "DNS64: DNS Extensions for Network Address 458 Translation from IPv6 Clients to IPv4 Servers", RFC 6147, 459 April 2011. 461 [RFC6384] van Beijnum, I., "An FTP Application Layer Gateway (ALG) 462 for IPv6-to-IPv4 Translation", RFC 6384, October 2011. 464 [RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with 465 Dual-Stack Hosts", RFC 6555, April 2012. 467 [RFC6586] Arkko, J. and A. Keranen, "Experiences from an IPv6-Only 468 Network", RFC 6586, April 2012. 470 [RFC6603] Korhonen, J., Savolainen, T., Krishnan, S., and O. Troan, 471 "Prefix Exclude Option for DHCPv6-based Prefix 472 Delegation", RFC 6603, May 2012. 474 Appendix A. Acknowledgments 476 T. Jinmei of Internet Systems Consortium for providing DNS A filter 477 patch of Bind 9. 479 O. Onoe of Sony Corporation for his deep inspection and testing of 480 end node devices in WIDE project meeting in September 2012. 482 Interop Tokyo 2013 NOC members and Nano Opt Media for providing a 483 field trial of this DNS A Record Filter solution as a service 484 network. Especially, K. Mano of A10 Networks and STM members for 485 their deep inspection and testing. 487 Authors' Addresses 489 Hiroaki Hazeyama 490 NAIST / WIDE Project 491 Takayama 8916-5 492 Nara, 493 Japan 495 Phone: +81 743 72 5216 496 Email: hiroa-ha@is.naist.jp 497 Tomohiro Ishihara 498 Univ. of Tokyo / WIDE Project 499 3-8-1 Komaba, Meguro 500 Tokyo, 501 Japan 503 Email: sho@c.u-tokyo.ac.jp 505 Osamu Nakamura 506 Keio Univ. / WIDE Project 507 5322 Endo 508 Kanagawa, 509 Japan 511 Email: osamu@wide.ad.jp