idnits 2.17.1 draft-ietf-behave-nat64-discovery-heuristic-16.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 9 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 1 instance 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 (March 12, 2013) is 4034 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Obsolete informational reference (is this intentional?): RFC 5735 (Obsoleted by RFC 6890) -- Obsolete informational reference (is this intentional?): RFC 5736 (Obsoleted by RFC 6890) Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Behave WG T. Savolainen 3 Internet-Draft Nokia 4 Intended status: Standards Track J. Korhonen 5 Expires: September 13, 2013 Nokia Siemens Networks 6 D. Wing 7 Cisco Systems 8 March 12, 2013 10 Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis 11 draft-ietf-behave-nat64-discovery-heuristic-16.txt 13 Abstract 15 This document describes a method for detecting the presence of DNS64 16 and for learning the IPv6 prefix used for protocol translation on an 17 access network. The method depends on the existence of a well-known 18 IPv4-only fully qualified domain name "ipv4only.arpa". The 19 information learned enables nodes to perform local IPv6 address 20 synthesis and to potentially avoid NAT64 on dual-stack and multi- 21 interface deployments. 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 September 13, 2013. 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Requirements and Terminology . . . . . . . . . . . . . . . . 3 59 2.1. Requirements . . . . . . . . . . . . . . . . . . . . . . 3 60 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 61 3. Node Behavior . . . . . . . . . . . . . . . . . . . . . . . . 4 62 3.1. Validation of Discovered Pref64::/n . . . . . . . . . . . 6 63 3.1.1. DNSSEC Requirements for the Network . . . . . . . . . 6 64 3.1.2. DNSSEC Requirements for the Node . . . . . . . . . . 7 65 3.2. Connectivity Check . . . . . . . . . . . . . . . . . . . 8 66 3.2.1. No Connectivity Checks Against ipv4only.arpa . . . . 9 67 3.3. Alternative Fully Qualified Domain Names . . . . . . . . 9 68 3.4. Message Flow Illustration . . . . . . . . . . . . . . . . 10 69 4. Operational Considerations for Hosting the IPv4-Only Well- 70 Known Name . . . . . . . . . . . . . . . . . . . . . . . . . 11 71 5. Operational Considerations for DNS64 Operator . . . . . . . . 12 72 5.1. Mapping of IPv4 Address Ranges to IPv6 Prefixes . . . . . 12 73 6. Exit Strategy . . . . . . . . . . . . . . . . . . . . . . . . 13 74 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 75 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 76 8.1. Domain Name Reservation Considerations . . . . . . . . . 14 77 8.2. IPv4 Address Allocation Considerations . . . . . . . . . 15 78 8.3. IAB Statement Regarding This .arpa Request . . . . . . . 16 79 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 80 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 81 10.1. Normative References . . . . . . . . . . . . . . . . . . 16 82 10.2. Informative References . . . . . . . . . . . . . . . . . 17 83 Appendix A. Example of DNS Record Configuration . . . . . . . . 17 84 Appendix B. About the IPv4 Address for the Well-Known Name . . . 19 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 87 1. Introduction 89 As part of the transition to IPv6, NAT64 [RFC6146] and DNS64 90 [RFC6147] technologies will be utilized by some access networks to 91 provide IPv4 connectivity for IPv6-only nodes [RFC6144]. DNS64 92 utilizes IPv6 address synthesis to create local IPv6 addresses for 93 peers having only IPv4 addresses, hence allowing DNS-using IPv6-only 94 nodes to communicate with IPv4-only peers. 96 However, DNS64 cannot serve applications not using DNS, such as those 97 receiving IPv4 address literals as referrals. Such applications 98 could nevertheless be able to work through NAT64, provided they are 99 able to create locally valid IPv6 addresses that would be translated 100 to the peers' IPv4 addresses. 102 Additionally, DNS64 is not able to do IPv6 address synthesis for 103 nodes running validating DNSSEC-enabled DNS resolvers, but instead 104 the synthesis must be done by the nodes themselves. In order to 105 perform IPv6 synthesis, nodes have to learn the IPv6 prefix(es) used 106 on the access network for protocol translation. A prefix, which may 107 be a Network Specific Prefix (NSP) or Well-Known Prefix (WKP) 108 [RFC6052], is referred to in this document as Pref64::/n [RFC6146]. 110 This document describes a best-effort method for applications and 111 nodes to learn the information required to perform local IPv6 address 112 synthesis. The IPv6 address synthesis procedure itself is out-of- 113 scope of this document. An example application is a browser 114 encountering IPv4 address literals in an IPv6-only access network. 115 Another example is a node running a validating security-aware DNS 116 resolver in an IPv6-only access network. 118 The knowledge of IPv6 address synthesis taking place may also be 119 useful if DNS64 and NAT64 are used in dual-stack enabled access 120 networks or if a node is multi-interfaced [RFC6418]. In such cases, 121 nodes may choose to prefer IPv4 or an alternative network interface 122 in order to avoid traversal through protocol translators. 124 It is important to note that use of this approach will not result in 125 a system that is as robust, secure, and well-behaved as an all-IPv6 126 system would be. Hence it is highly recommended to upgrade nodes' 127 destinations to IPv6 and utilize the described method only as a 128 transition solution. 130 2. Requirements and Terminology 132 2.1. Requirements 134 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 135 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 136 document are to be interpreted as described in [RFC2119]. 138 2.2. Terminology 140 NAT64 FQDN: a fully qualified domain name (FQDN) for a NAT64 protocol 141 translator. 143 Pref64::/n: a IPv6 prefix used for IPv6 address synthesis [RFC6146]. 145 Pref64::WKA: an IPv6 address consisting of Pref64::/n and WKA at any 146 of the locations allowed by RFC 6052 [RFC6052]. 148 Secure Channel: a communication channel a node has between itself and 149 a DNS64 server protecting DNS protocol related messages from 150 interception and tampering. The channel can be, for example, IPsec- 151 based virtual private network (VPN) tunnel or a link layer utilizing 152 data encryption technologies. 154 Well-Known IPv4-only Name (WKN): the fully qualified domain name, 155 "ipv4only.arpa", well-known to have only A record(s). 157 Well-Known IPv4 Address (WKA): an IPv4 address that is well-known and 158 present in an A record for the well-known name. Two well-known IPv4 159 addresses are defined for Pref64::/n discovery purposes: 192.0.0.170 160 and 192.0.0.171. 162 3. Node Behavior 164 A node requiring information about the presence (or absence) of 165 NAT64, and one or more Pref64::/n used for protocol translation SHALL 166 send a DNS query for AAAA resource records of the Well-Known 167 IPv4-only Name (WKN) "ipv4only.arpa". The node MAY perform the DNS 168 query in both IPv6-only and dual-stack access networks. 170 When sending a DNS AAAA resource record query for the WKN, a node 171 MUST set the "Checking Disabled (CD)" bit to zero [RFC4035], as 172 otherwise the DNS64 server will not perform IPv6 address synthesis 173 (Section 3 of [RFC6147]) and hence would not reveal the Pref64::/n 174 used for protocol translation. 176 A DNS reply with one or more AAAA resource records indicates that the 177 access network is utilizing IPv6 address synthesis. In some 178 scenarios captive portals, or NXDOMAIN and NODATA hijacking, 179 performed by the access network may result in a false positive. One 180 method to detect such hijacking is to query a fully qualified domain 181 name that is known to be invalid (and normally return an empty 182 response or an error response) and see if it returns a valid resource 183 record. However, as long as the hijacked domain does not result in 184 AAAA resource record responses that contain well-known IPv4 address 185 in any location defined by RFC6052, the response will not disturb the 186 Pref64::/n learning procedure. 188 A node MUST look through all of the received AAAA resource records to 189 collect one or more Pref64::/n. The Pref64::/n list might include 190 the Well-Known Prefix 64:ff9b::/96 [RFC6052] or one or more Network- 191 Specific Prefixes. In the case of NSPs, the node SHALL determine the 192 used address format by searching the received IPv6 addresses for the 193 WKN's well-known IPv4 addresses. The node SHALL assume the well- 194 known IPv4 addresses might be found at the locations specified by 195 [RFC6052] section 2.2. The node MUST check on octet boundaries to 196 ensure a 32-bit well-known IPv4 address value is present only once in 197 an IPv6 address. In case another instance of the value is found 198 inside the IPv6 address, the node SHALL repeat the search with the 199 other well-known IPv4 address. 201 If only one Pref64::/n was present in the DNS response: a node SHALL 202 use that Pref64::/n for both local synthesis and for detecting 203 synthesis done by the DNS64 server on the network. 205 If more than one Pref64::/n was present in the DNS response: a node 206 SHOULD use all of them when determining whether other received IPv6 207 addresses are synthetic. The node MUST use all learned Pref64::/n 208 when performing local IPv6 address synthesis, and use the prefixes in 209 the order received from the DNS64 server. That is, when the node is 210 providing a list of locally synthesized IPv6 addresses to upper 211 layers, IPv6 addresses MUST be synthesized by using all discovered 212 Pref64::/n in the received order. 214 If the well-known IPv4 addresses are not found within the standard 215 locations, it indicates that the network is not using a standard 216 address format or unexpected IPv4 addresses were used in the AAAA 217 resource record synthesis. In either case, the Pref64::/n cannot be 218 determined and the heuristic procedure has failed. Developers can 219 over time learn of IPv6 translated address formats that are 220 extensions or alternatives to the standard formats. Developers MAY 221 at that point add additional steps to the described discovery 222 procedure. The additional steps are outside the scope of the present 223 document. 225 In case a node does not receive a positive DNS reply to the AAAA 226 resource record query, the node MAY perform a DNS A resource record 227 query for the well-known name. If the node receives a positive reply 228 to the DNS A resource record query it means the used recursive DNS 229 server is not a DNS64 server. 231 In the case of a negative response (NXDOMAIN, NODATA) or a DNS query 232 timeout: a DNS64 server is not available on the access network, the 233 access network filtered out the well-known query, or something went 234 wrong in the DNS resolution. All unsuccessful cases result in a node 235 being unable to perform local IPv6 address synthesis. In the case of 236 timeout, the node SHOULD retransmit the DNS query like any other DNS 237 query the node makes [RFC1035]. In the case of a negative response 238 (NXDOMAIN, NODATA), the node MUST obey the Time-To-Live [RFC1035] of 239 the response before resending the AAAA resource record query. The 240 node MAY monitor for DNS replies with IPv6 addresses constructed from 241 the WKP, in which case if any are observed the node SHOULD use the 242 WKP as if it were learned during the query for the well-known name. 244 To save Internet resources if possible, a node should perform 245 Pref64::/n discovery only when needed (e.g., when local synthesis is 246 required, a new network interface is connected to a new network, and 247 so forth). The node SHALL cache the replies it receives during the 248 Pref64::/n discovery procedure and it SHOULD repeat the discovery 249 process ten seconds before the Time-To-Live of the Well-Known Name's 250 synthetic AAAA resource record expires. 252 3.1. Validation of Discovered Pref64::/n 254 If a node is using an insecure channel between itself and a DNS64 255 server, or the DNS64 server is untrusted, it is possible for an 256 attacker to influence the node's Pref64::/n discovery procedures. 257 This may result in denial-of-service, redirection, man-in-the-middle, 258 or other attacks. 260 To mitigate against attacks, the node SHOULD communicate with a 261 trusted DNS64 server over a secure channel, or use DNSSEC. NAT64 262 operators SHOULD provide facilities for validating discovery of 263 Pref64::/n via a secure channel and/or DNSSEC protection. 265 It is important to understand that DNSSEC only validates that the 266 discovered Pref64::/n is the one that belongs to a domain used by 267 NAT64 FQDN. Importantly, the DNSSEC validation does not tell if the 268 node is at the network where the Pref64::/n is intended to be used. 269 Furthermore, DNSSEC validation cannot be utilized in the case of WKP. 271 3.1.1. DNSSEC Requirements for the Network 273 If the operator has chosen to support nodes performing validation of 274 discovered Pref64::/n with DNSSEC, the operator of the NAT64 device 275 MUST perform the following configurations. 277 1. Have one or more fully qualified domain names for the NAT64 278 translator entities (later referred as NAT64 FQDN). In the case 279 of more than one Pref64::/n being used in a network, e.g., for 280 load-balancing purposes, it is for network administrators to 281 decide whether a single NAT64's fully qualified domain name maps 282 to more than one Pref64::/n, or whether there will be a dedicated 283 NAT64 FQDN per Pref64::/n. 285 2. Each NAT64 FQDN MUST have one or more DNS AAAA resource records 286 containing Pref64::WKA (Pref64::/n combined with WKA). 288 3. Each Pref64::WKA MUST have a PTR resource record that points to 289 the corresponding NAT64 FQDN. 291 4. Sign the NAT64 FQDNs' AAAA and A resource records with DNSSEC. 293 3.1.2. DNSSEC Requirements for the Node 295 A node SHOULD prefer a secure channel to talk to a DNS64 server, 296 whenever possible. In addition, a node that implements a DNSSEC 297 validating resolver MAY use the following procedure to validate 298 discovery of the Pref64::/n. 300 1. Heuristically find Pref64::/n candidates by making a AAAA 301 resource record query for "ipv4only.arpa" by following the 302 procedure in Section 3. This will result in IPv6 addresses 303 consisting of Pref64::/n combined with WKA, i.e., Pref64::WKA. 304 For each Pref64::/n that the node wishes to validate, the node 305 performs the following steps. 307 2. Send a DNS PTR resource record query for the IPv6 address of the 308 translator (for "ip6.arpa"), using the Pref64::WKA learned in 309 step 1. CNAME and DNAME results should be followed according to 310 the rules in RFC 1034 [RFC1034], RFC 1034 [RFC1035], and RFC 6672 311 [RFC6672]. The ultimate response will include one or more NAT64 312 FQDNs. 314 3. The node SHOULD compare the domains of learned NAT64 FQDNs to a 315 list of the node's trusted domains and choose a NAT64 FQDN that 316 matches. The means for a node to learn the trusted domains is 317 implementation-specific. If the node has no trust for the 318 domain, the discovery procedure is not secure and the remaining 319 steps described below MUST NOT be performed. 321 4. Send a DNS AAAA resource record query for the NAT64 FQDN. 323 5. Verify the DNS AAAA resource record contains Pref64::WKA 324 addresses received at the step 1. It is possible that the NAT64 325 FQDN has multiple AAAA records, in which case the node MUST check 326 if any of the addresses match the ones obtained in step 1. The 327 node MUST ignore other responses and not use them for local IPv6 328 address synthesis. 330 6. Perform DNSSEC validation of the DNS AAAA response. 332 After the node has successfully performed the above five steps, the 333 node can consider Pref64::/n validated. 335 3.2. Connectivity Check 337 After learning a Pref64::/n, the node SHOULD perform a connectivity 338 check to ensure the learned Pref64::/n is functional. It could be 339 non-functional for a variety of reasons -- the discovery failed to 340 work as expected, the IPv6 path to the NAT64 is down, the NAT64 is 341 down, or the IPv4 path beyond the NAT64 is down. 343 There are two main approaches to determine if the learned Pref64::/n 344 is functional. The first approach is to perform a dedicated 345 connectivity check. The second approach is to simply attempt to use 346 the learned Pref64::/n. Each approach has some trade-offs (e.g., 347 additional network traffic or possible user-noticeable delay), and 348 implementations should carefully weigh which approach is appropriate 349 for their application and the network. 351 The node SHOULD use an implementation-specific connectivity check 352 server and a protocol of the implementation's choice, but if that is 353 not possible, a node MAY do a PTR resource record query of the 354 Pref64::WKA to get a NAT64 FQDN. The node then does an A resource 355 query of the NAT64 FQDN, which will return zero or more A resource 356 records pointing to connectivity check servers used by the network 357 operator. A negative response to the PTR or A resource query means 358 there are no connectivity check servers available. A network 359 operator that provides NAT64 services for a mix of nodes with and 360 without implementation-specific connectivity check servers SHOULD 361 assist nodes in their connectivity checks by mapping each NAT64 FQDN 362 to one or more DNS A resource records with IPv4 address(es) pointing 363 to connectivity check server(s). The Pref64::/n -based connectivity 364 check approach works only with NSPs, as it is not possible to 365 register A records for each different domain using WKP. The network 366 operator MUST disable ICMPv6 rate limiting for connectivity check 367 messages. 369 In case of multiple connectivity check servers being available for 370 use, the node chooses the first one, preferring implementation- 371 specific servers. 373 The connectivity check protocol used with implementation-specific 374 connectivity check servers is implementation-specific. 376 The connectivity check protocol used with connectivity check servers 377 pointed to by the NAT64 FQDN's A resource records is ICMPv6 378 [RFC4443]. The node performing a connectivity check against these 379 servers SHALL send an ICMPv6 Echo Request to an IPv6 address 380 synthesized by combining discovered Pref64::/n with an IPv4 address 381 of the server as specified in [RFC6052]. This will test the IPv6 382 path to the NAT64, the NAT64's operation, and the IPv4 path all the 383 way to the connectivity check server. If no response is received for 384 the ICMPv6 Echo Request, the node SHALL send another ICMPv6 Echo 385 Request, a second later. If still no response is received, the node 386 SHALL send a third ICMPv6 Echo Request two seconds later. If an 387 ICMPv6 Echo Response is received, the node knows the IPv6 path to the 388 connectivity check server is functioning normally. If, after the 389 three transmissions and three seconds since the last ICMPv6 Echo 390 Request, no response is received, the node learns this Pref64::/n 391 might not be functioning, and the node MAY choose a different 392 Pref64::/n (if available), choose to alert the user, or proceed 393 anyway assuming the failure is temporary or with the connectivity 394 check itself. After all, the ICMPv6 is by design unreliable and 395 failure to receive ICMPv6 responses may not indicate anything other 396 than network failure to transport ICMPv6 messages through. 398 If no separate connectivity check is performed before local IPv6 399 address synthesis, a node MAY monitor success of connection attempts 400 performed with locally synthesized IPv6 addresses. Based on success 401 of these connections, and based on possible ICMPv6 error messages 402 received (such as Destination Unreachable messages), the node MAY 403 cease to perform local address synthesis and MAY restart the Pref64:: 404 /n discovery procedures. 406 3.2.1. No Connectivity Checks Against ipv4only.arpa 408 Clients MUST NOT send a connectivity check to an address returned by 409 the ipv4only.arpa query. This is because, by design, no server will 410 be operated on the Internet at that address as such. Similarly, 411 network operators MUST NOT operate a server on that address. The 412 reason this address isn't used for connectivity checks is that 413 operators who neglect to operate a connectivity check server will 414 allow that traffic towards the Internet where it will be dropped and 415 cause a false negative connectivity check with the client (that is, 416 the NAT64 is working fine, but the connectivity check fails because a 417 server is not operating at "ipv4only.arpa" on the Internet and a 418 server is not operated by the NAT64 operator). Instead, for the 419 connectivity check, an additional DNS resource record is looked up 420 and used for the connectivity check. This ensures that packets don't 421 unnecessarily leak to the Internet and reduces the chance of a false 422 negative connectivity check. 424 3.3. Alternative Fully Qualified Domain Names 426 Some applications, operating systems, devices, or networks may find 427 it advantageous to operate their own DNS infrastructure to perform a 428 function similar to "ipv4only.arpa", but using a different resource 429 record. The primary advantage is to ensure availability of the DNS 430 infrastructure and ensure the proper configuration of the DNS record 431 itself. For example, a company named Example might have their 432 application query "ipv4only.example.com". Other than the different 433 DNS resource record being queried, the rest of the operations are 434 anticipated to be identical to the steps described in this document. 436 3.4. Message Flow Illustration 438 The figure below gives an example illustration of a message flow in 439 the case of prefix discovery utilizing Pref64::/n validation. The 440 figure shows also a step where the procedure ends if no Pref64::/n 441 validation is performed. 443 In this example, three Pref64::/n are provided by the DNS64 server. 444 The first Pref64::/n is using an NSP, in this example "2001:db8:42::/ 445 96". The second Pref64::/n is using an NSP, in this example 446 "2001:db8:43::/96". The third Pref64::/n is using the WKP. Hence, 447 when the Pref64::/n are combined with the WKA to form Pref64::WKA, 448 the synthetic IPv6 addresses returned by DNS64 server are 449 "2001:db8:42::192.0.0.170", "2001:db8:43::192.0.0.170", and 450 "64:ff9b::192.0.0.170". The DNS64 server could also return synthetic 451 addresses containing the IPv4 address 192.0.0.171. 453 The validation is not done for the WKP, see Section 3.1. 455 Node DNS64 server 456 | | 457 | "AAAA" query for "ipv4only.arpa" | 458 |----------------------------------------------->| "A" query for 459 | | "ipv4only.arpa" 460 | |---------------> 461 | | 462 | | "A" response: 463 | | "192.0.0.170" 464 | | "192.0.0.171" 465 | |<--------------- 466 | +----------------------------+ 467 | | "AAAA" synthesis using | 468 | | three Pref64::/n. | 469 | +----------------------------+ 470 | "AAAA" response with: | 471 | "2001:db8:42::192.0.0.170" | 472 | "2001:db8:43::192.0.0.170" | 473 | "64:ff9b::192.0.0.170" | 474 |<-----------------------------------------------| 475 | | 476 +----------------------------------------------+ | 477 | If Pref64::/n validation is not performed, a | | 478 | node can fetch prefixes from AAAA responses | | 479 | at this point and skip the steps below. | | 480 +----------------------------------------------+ | 481 | | 482 | "PTR" query #1 for "2001:db8:42::192.0.0.170 | 483 |----------------------------------------------->| 484 | "PTR" query #2 for "2001:db8:43::192.0.0.170 | 485 |----------------------------------------------->| 486 | | 487 | "PTR" response #1 "nat64_1.example.com" | 488 |<-----------------------------------------------| 489 | "PTR" response #2 "nat64_2.example.com" | 490 |<-----------------------------------------------| 491 | | 492 +----------------------------------------------+ | 493 | Compare received domains to a trusted domain | | 494 | list and if matches are found, continue. | | 495 +----------------------------------------------+ | 496 | | 497 | "AAAA" query #1 for "nat64_1.example.com" | 498 |----------------------------------------------->| 499 | "AAAA" query #2 for "nat64_2.example.com" | 500 |----------------------------------------------->| 501 | | 502 | "AAAA" resp. #1 with "2001:db8:42::192.0.0.170 | 503 |<-----------------------------------------------| 504 | "AAAA" resp. #2 with "2001:db8:43::192.0.0.170 | 505 |<-----------------------------------------------| 506 | | 507 +----------------------------------------------+ | 508 | Validate AAAA responses and compare the IPv6 | | 509 | addresses to those previously learned. | | 510 +----------------------------------------------+ | 511 | | 512 +----------------------------------------------+ | 513 | Fetch the Pref64::/n from the validated | | 514 | responses and take into use. | | 515 +----------------------------------------------+ | 516 | | 518 Pref64::/n discovery procedure 520 4. Operational Considerations for Hosting the IPv4-Only Well-Known Name 522 The authoritative name server for the well-known name SHALL have DNS 523 record Time-To-Live (TTL) set to at least 60 minutes in order to 524 improve effectiveness of DNS caching. The exact TTL value will be 525 determined and tuned based on operational experiences. 527 The domain serving the well-known name MUST be signed with DNSSEC. 528 See also section 7. 530 5. Operational Considerations for DNS64 Operator 532 A network operator of a DNS64 server can guide nodes utilizing 533 heuristic discovery procedures by managing the responses a DNS64 534 server provides. 536 If the network operator would like nodes to utilize multiple Pref64:: 537 /n, the operator needs to configure DNS64 servers to respond with 538 multiple synthetic AAAA records. As per Section 3 the nodes can then 539 use them all. 541 There are no guarantees on which of the Pref64::/n nodes will end up 542 using. If the operator wants nodes to specifically use a certain 543 Pref64::/n or periodically change the Pref64::/n they use, for 544 example for load balancing reasons, the only guaranteed method is to 545 make DNS64 servers return only a single synthetic AAAA resource 546 record, and have the Time-To-Live of that synthetic record such that 547 the node repeats the Pref64::/n discovery when required. 549 Besides choosing how many Pref64::/n to respond and what Time-To-Live 550 to use, DNS64 servers MUST NOT interfere with or perform other 551 special procedures for the queries related to the well-known name. 553 5.1. Mapping of IPv4 Address Ranges to IPv6 Prefixes 555 RFC 6147 [RFC6147] allows DNS64 implementations to be able to map 556 specific IPv4 address ranges to separate Pref64::/n. That allows 557 handling of special use IPv4 addresses [RFC5735]. The example setup 558 where this might be used is illustrated in Figure 1. The NAT64 "A" 559 is used when accessing IPv4-only servers in the datacenter, and the 560 NAT64 "B" is used for Internet access. 562 NAT64 "A" ----- IPv4-only servers in a datacenter 563 / 564 IPv6-only node----< 565 \ 566 NAT64 "B" ----- IPv4 Internet 568 Figure 1: NAT64s with IPv4 Address Ranges 570 The heuristic discovery method described herein does not support 571 learning of the possible rules used by a DNS64 server for mapping 572 specific IPv4 address ranges to separate Pref64::/n. Therefore, 573 nodes will use the same discovered Pref64::/n to synthesize IPv6 574 addresses from any IPv4 address. This can cause issues for routing 575 and connectivity establishment procedures. The operator of the NAT64 576 and the DNS64 ought to take this into account in the network design. 578 The network operators can help IPv6-only nodes by ensuring the nodes 579 do not have to work with IPv4 address literals for which special 580 mapping rules are used. That is, the IPv4-only servers addressed 581 from the special IPv4 address ranges ought to have signed AAAA 582 records, which allows IPv6-only nodes to avoid local address 583 synthesis. If the IPv6-only nodes are not using DNSSEC, then it is 584 enough if the network's DNS64 server returns synthetic AAAA resource 585 records pointing to IPv4-only servers. Avoiding the need for 586 IPv6-only nodes to perform address synthesis for IPv4 addresses 587 belonging to special ranges is the best approach to assist nodes. 589 If the IPv6-only nodes have no other choice than using IPv4-address 590 literals belonging to special IPv4 address ranges, and the IPv6-only 591 node will perform local synthesis by using the discovered Pref64::/n, 592 then the network ought to ensure with routing that the packets are 593 delivered to the correct NAT64. For example, a router in the path 594 from an IPv6-only host to NAT64s can forward the IPv6 packets to the 595 correct NAT64 as illustrated in Figure 2. The routing could be based 596 on the last 32-bits of the IPv6 address, but the network operator can 597 also use some other IPv6 address format allowed by RFC 6052 598 [RFC6052], if it simplifies routing setup. This setup requires 599 additional logic on the NAT64 providing connectivity to special IPv4 600 address ranges: it needs to be able to translate packets it receives 601 that are using the Pref64::/n used with Internet connections. 603 NAT64 "A" ----- IPv4-only servers in a datacenter 604 / 605 IPv6-only host----router 606 \ 607 NAT64 "B" ----- IPv4 Interne 609 Figure 2: NAT64s with Assisting Router 611 6. Exit Strategy 613 A day will come when this tool is no longer needed. A node SHOULD 614 implement a configuration knob for disabling the Pref64::/n discovery 615 feature. 617 7. Security Considerations 619 The security considerations follow closely those of RFC 6147 620 [RFC6147]. The possible attacks are very similar in the case where 621 an attacker controls a DNS64 server and returns tampered IPv6 622 addresses to a node and in the case where an attacker causes the node 623 to use tampered Pref64::/n for local address synthesis. DNSSEC 624 cannot be used to validate responses created by a DNS64 server the 625 node has no trust relationship with. Hence this document does not 626 change the big picture for untrusted network scenarios. If an 627 attacker alters the Pref64::/n used by a DNS64 server or a node, the 628 traffic generated by the node will be delivered to an altered 629 destination. This can result in either a denial-of-service (DoS) 630 attack (if the resulting IPv6 addresses are not assigned to any 631 device), a flooding attack (if the resulting IPv6 addresses are 632 assigned to devices that do not wish to receive the traffic), or an 633 eavesdropping attack (in case the altered NSP is routed through the 634 attacker). 636 Even though well-known name's DNS A resource record would not 637 necessarily need to be protected with DNSSEC, as both the name and 638 IPv4 addresses well-known, for the DNS AAAA resource record queries 639 DNSSEC protection is required. Without DNSSEC, fake positive AAAA 640 responses could cause hosts to erroneously detect Pref64::/n, thus 641 allowing attacker to inject malicious Pref64::/n for hosts' synthesis 642 procedures. A signed ipv4only.arpa allows validating DNS64 servers 643 (see [RFC6147] Section 3 case 5, for example) to detect malicious 644 AAAA resource records. Therefore, the zone serving the well-known 645 name has to be protected with DNSSEC. 647 For Pref64::/n discovery validation, the access network SHOULD sign 648 the NAT64 translator's fully qualified domain name. A node SHOULD 649 use the algorithm described in Section 3.1 to validate each 650 discovered Pref64::/n. 652 The procedure of Section 3.1.2 requires a node using DNSSEC to 653 validate discovery of Pref64::/n to have a list of trusted domains. 654 In the case of not having matching domain at the step 3 of 655 Section 3.1.2 an implementation might be tempted to ask for a user to 656 add a received domain as trusted - temporarily or permanently. The 657 history has shown that average users are unable to properly handle 658 such queries, and tend to answer positively without thinking in an 659 attempt to get quickly forward. Therefore, unless the DNSSEC-using 660 implementation has a way to dynamically and reliably add trusted 661 domains, it is better to fail the Pref64::/n discovery procedure. 663 Lastly, the best mitigation action against Pref64::/n discovery 664 attacks is to add IPv6 support for nodes' destinations and hence 665 reduce the need to perform local IPv6 address synthesis. 667 8. IANA Considerations 669 8.1. Domain Name Reservation Considerations 670 According to procedures described in [RFC3172] and 671 [I-D.cheshire-dnsext-special-names] this document requests IANA to 672 delegate a new second level domain in the .ARPA zone for the well- 673 known domain name "ipv4only.arpa". The intention is that there will 674 not be any further delegation of names below the ipv4only.arpa 675 domain. The answers to seven questions of 676 [I-D.cheshire-dnsext-special-names] are as follows: 678 1. No, although this is a domain delegated under the .arpa 679 infrastructural identifier top level domain." 681 2. Yes. Any application attempting to perform NAT64 discovery will 682 query the name. 684 3. Yes, to the extent the API or library is affected by NAT64. 686 4. No. 688 5. No. 690 6. This name has effects for operators of NAT64/DNS64, but otherwise 691 is just another delegated .arpa domain. 693 7. The registry for .arpa is held at IANA, and only IANA needs to 694 take action here. 696 8.2. IPv4 Address Allocation Considerations 698 The well-known name needs to map to two different global IPv4 699 addresses, which are to be allocated as described in [RFC5736] and 700 [I-D.bonica-special-purpose]. The addresses are to be taken from the 701 IANA IPv4 Special Purpose Address Registry [RFC5736], and 192.0.0.170 702 and 192.0.0.171 are to be assigned to this document with parameters 703 shown below: 705 +----------------------+-------------------------------+ 706 | Attribute | Value | 707 +----------------------+-------------------------------+ 708 | Address Block | 192.0.0.170/32 | 709 | | 192.0.0.171/32 | 710 | Name | NAT64/DNS64 Discovery | 711 | RFC | RFC TBD Section 2.2. | 712 | Allocation Date | February 2013 | 713 | Termination Date | N/A | 714 | Source | False | 715 | Destination | False | 716 | Forwardable | False | 717 | Global | False | 718 | Reserved-by-protocol | True | 719 +----------------------+-------------------------------+ 721 The Record for IPv4 address allocation for IPv4 Special Purpose 722 Address Registry 724 The following two records should be added to .arpa to the name 725 servers run by ICANN/IANA: 727 ipv4only IN A 192.0.0.170 729 ipv4only IN A 192.0.0.171 731 8.3. IAB Statement Regarding This .arpa Request 733 With the publication of this document, the IAB approves of the 734 delegation of "ipv4only" in the .arpa domain. Under [RFC3172], the 735 IAB is requesting IANA to delegate and provision ipv4only.arpa as 736 written in this specification. However, the IAB does not take any 737 architectural or technical position about this specification. 739 9. Acknowledgements 741 Authors would like to thank Dmitry Anipko, Cameron Byrne, Aaron Yi 742 Ding Christian Huitema, Washam Fan, Peter Koch, Stephan Lagerholm, 743 Zhenqiang Li, Simon Perreault, Marc Petit-Huguenin, Andrew Sullivan, 744 and Dave Thaler, for significant improvement ideas and comments. 746 10. References 748 10.1. Normative References 750 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 751 STD 13, RFC 1034, November 1987. 753 [RFC1035] Mockapetris, P., "Domain names - implementation and 754 specification", STD 13, RFC 1035, November 1987. 756 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 757 Requirement Levels", BCP 14, RFC 2119, March 1997. 759 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 760 Rose, "Protocol Modifications for the DNS Security 761 Extensions", RFC 4035, March 2005. 763 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 764 Message Protocol (ICMPv6) for the Internet Protocol 765 Version 6 (IPv6) Specification", RFC 4443, March 2006. 767 [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 768 Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, 769 October 2010. 771 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 772 NAT64: Network Address and Protocol Translation from IPv6 773 Clients to IPv4 Servers", RFC 6146, April 2011. 775 [RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van 776 Beijnum, "DNS64: DNS Extensions for Network Address 777 Translation from IPv6 Clients to IPv4 Servers", RFC 6147, 778 April 2011. 780 [RFC6672] Rose, S. and W. Wijngaards, "DNAME Redirection in the 781 DNS", RFC 6672, June 2012. 783 10.2. Informative References 785 [I-D.bonica-special-purpose] 786 Cotton, M., Vegoda, L., Bonica, R., and B. Haberman, 787 "Special-Purpose IP Address Registries", draft-bonica- 788 special-purpose-07 (work in progress), January 2013. 790 [I-D.cheshire-dnsext-special-names] 791 Cheshire, S. and M. Krochmal, "Special-Use Domain Names", 792 draft-cheshire-dnsext-special-names-03 (work in progress), 793 September 2012. 795 [RFC3172] Huston, G., "Management Guidelines & Operational 796 Requirements for the Address and Routing Parameter Area 797 Domain ("arpa")", BCP 52, RFC 3172, September 2001. 799 [RFC5735] Cotton, M. and L. Vegoda, "Special Use IPv4 Addresses", 800 BCP 153, RFC 5735, January 2010. 802 [RFC5736] Huston, G., Cotton, M., and L. Vegoda, "IANA IPv4 Special 803 Purpose Address Registry", RFC 5736, January 2010. 805 [RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for 806 IPv4/IPv6 Translation", RFC 6144, April 2011. 808 [RFC6418] Blanchet, M. and P. Seite, "Multiple Interfaces and 809 Provisioning Domains Problem Statement", RFC 6418, 810 November 2011. 812 Appendix A. Example of DNS Record Configuration 813 The following BIND-style examples illustrate how A and AAAA records 814 could be configured by a NAT64 operator. 816 The examples use Pref64::/n of 2001:db8::/96, both WKAs, and the 817 example.com domain. 819 The PTR record for reverse queries (Section 3.1.1 bullet 3): 821 $ORIGIN A.A.0.0.0.0.0.C\ 822 .0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.IP6.ARPA. 823 @ IN SOA ns1.example.com. hostmaster.example.com. ( 824 2003080800 12h 15m 3w 2h) 825 IN NS ns.example.com. 827 IN PTR nat64.example.com. 829 $ORIGIN B.A.0.0.0.0.0.C\ 830 .0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.IP6.ARPA. 831 @ IN SOA ns1.example.com. hostmaster.example.com. ( 832 2003080800 12h 15m 3w 2h) 833 IN NS ns.example.com. 835 IN PTR nat64.example.com. 837 If example.com does not use DNSSEC, the following configuration file 838 could be used. Please note that nat64.example.com has both an AAAA 839 record with the Pref64::/n and an A record for the connectivity check 840 (Section 3.1.1 bullet 2). 842 example.com. IN SOA ns.example.com. hostmaster.example.com. ( 843 2002050501 ; serial 844 100 ; refresh (1 minute 40 seconds) 845 200 ; retry (3 minutes 20 seconds) 846 604800 ; expire (1 week) 847 100 ; minimum (1 minute 40 seconds) 848 ) 850 example.com. IN NS ns.example.com. 852 nat64.example.com. 853 IN AAAA 2001:db8:0:0:0:0:C000:00AA 854 IN AAAA 2001:db8:0:0:0:0:C000:00AB 855 IN A 192.0.2.1 857 To DNSSEC sign the records, the owner of the example.com zone would 858 have RRSIG records for both the AAAA and A records for 859 nat64.example.com. As a normal DNSSEC requirement, the zone and its 860 parent also need to be signed. 862 Appendix B. About the IPv4 Address for the Well-Known Name 864 The IPv4 addresses for the well-known name cannot be non-global IPv4 865 addresses as listed in the Section 3 of [RFC5735]. Otherwise DNS64 866 servers might not perform AAAA record synthesis when the well-known 867 prefix is used, as stated in Section 3.1 of [RFC6052]. However, the 868 addresses do not have to be routable or allocated to any real node, 869 as no communications will be initiated to these IPv4 address. 871 Allocation of at least two IPv4 addresses improves the heuristics in 872 cases where the bit pattern of the primary IPv4 address appears more 873 than once in the synthetic IPv6 address (i.e., the NSP prefix 874 contains the same bit pattern as the IPv4 address). 876 If no well-known IPv4 addresses would be statically allocated for 877 this method, the heuristic would require sending of an additional A 878 query to learn the IPv4 addresses that would be then searched from 879 inside of the received IPv6 address. 881 Authors' Addresses 883 Teemu Savolainen 884 Nokia 885 Hermiankatu 12 D 886 FI-33720 Tampere 887 Finland 889 Email: teemu.savolainen@nokia.com 891 Jouni Korhonen 892 Nokia Siemens Networks 893 Linnoitustie 6 894 FI-02600 Espoo 895 Finland 897 Email: jouni.nospam@gmail.com 898 Dan Wing 899 Cisco Systems 900 170 West Tasman Drive 901 San Jose, California 95134 902 USA 904 Email: dwing@cisco.com