idnits 2.17.1 draft-ietf-behave-nat64-discovery-heuristic-13.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 6 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 (November 27, 2012) is 4161 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: May 31, 2013 Nokia Siemens Networks 6 D. Wing 7 Cisco Systems 8 November 27, 2012 10 Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis 11 draft-ietf-behave-nat64-discovery-heuristic-13.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 domain name "ipv4only.arpa". The information learned 19 enables nodes to perform local IPv6 address synthesis and to 20 potentially avoid NAT64 on dual-stack and multi-interface 21 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 May 31, 2013. 40 Copyright Notice 42 Copyright (c) 2012 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 2. Requirements and Terminology . . . . . . . . . . . . . . . . . 3 59 2.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 4 60 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 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 Domain Names . . . . . . . . . . . . . . . . . 10 68 3.4. Message Flow Illustration . . . . . . . . . . . . . . . . 10 69 4. Operational Considerations for Hosting the IPv4-Only 70 Well-Known Name . . . . . . . . . . . . . . . . . . . . . . . 12 71 5. Operational Considerations for DNS64 Operator . . . . . . . . 12 72 5.1. Mapping of IPv4 Address Ranges to IPv6 Prefixes . . . . . 12 73 6. Exit Strategy . . . . . . . . . . . . . . . . . . . . . . . . 14 74 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 75 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 76 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 77 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 78 10.1. Normative References . . . . . . . . . . . . . . . . . . . 15 79 10.2. Informative References . . . . . . . . . . . . . . . . . . 16 80 Appendix A. Example of DNS Record Configuration . . . . . . . . . 16 81 Appendix B. About the IPv4 Address for the Well-Known Name . . . 17 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 84 1. Introduction 86 As part of the transition to IPv6, NAT64 [RFC6146] and DNS64 87 [RFC6147] technologies will be utilized by some access networks to 88 provide IPv4 connectivity for IPv6-only nodes [RFC6144]. DNS64 89 utilizes IPv6 address synthesis to create local IPv6 addresses for 90 peers having only IPv4 addresses, hence allowing DNS-using IPv6-only 91 nodes to communicate with IPv4-only peers. 93 However, DNS64 cannot serve applications not using DNS, such as those 94 receiving IPv4 address literals as referrals. Such applications 95 could nevertheless be able to work through NAT64, provided they are 96 able to create locally valid IPv6 addresses that would be translated 97 to the peers' IPv4 addresses. 99 Additionally, DNS64 is not able to do IPv6 address synthesis for 100 nodes running validating DNSSEC-enabled DNS resolvers, but instead 101 the synthesis must be done by the nodes themselves. In order to 102 perform IPv6 synthesis, nodes have to learn the IPv6 prefix(es) used 103 on the access network for protocol translation. A prefix, which may 104 be a Network Specific Prefix (NSP) or Well-Known Prefix (WKP) 105 [RFC6052], is referred to in this document as Pref64::/n [RFC6146]. 107 This document describes a best-effort method for applications and 108 nodes to learn the information required to perform local IPv6 address 109 synthesis. The IPv6 address synthesis procedure itself is out-of- 110 scope of this document. An example application is a browser 111 encountering IPv4 address literals in an IPv6-only access network. 112 Another example is a node running a validating security-aware DNS 113 resolver in an IPv6-only access network. 115 The knowledge of IPv6 address synthesis taking place may also be 116 useful if DNS64 and NAT64 are used in dual-stack enabled access 117 networks or if a node is multi-interfaced [RFC6418]. In such cases, 118 nodes may choose to prefer IPv4 or an alternative network interface 119 in order to avoid traversal through protocol translators. 121 It is important to note that use of this approach will not result in 122 a system that is as robust, secure, and well-behaved as an all-IPv6 123 system would be. Hence it is highly recommended to upgrade nodes' 124 destinations to IPv6 and utilize the described method only as a 125 transition solution. 127 2. Requirements and Terminology 128 2.1. Requirements 130 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 131 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 132 document are to be interpreted as described in [RFC2119]. 134 2.2. Terminology 136 NAT64 FQDN: a fully qualified domain name for a NAT64 protocol 137 translator. 139 Pref64::/n: a IPv6 prefix used for IPv6 address synthesis [RFC6146]. 141 Pref64::WKA: an IPv6 address consisting of Pref64::/n and WKA at any 142 of the locations allowed by RFC 6052 [RFC6052]. 144 Well-Known IPv4-only Name (WKN): the fully qualified domain name, 145 "ipv4only.arpa", well-known to have only A record(s). 147 Well-Known IPv4 Address (WKA): an IPv4 address that is well-known and 148 present in an A record for the well-known name. Two well-known IPv4 149 addresses are defined for Pref64::/n discovery purposes: 192.0.0.170 150 and 192.0.0.171. 152 3. Node Behavior 154 A node requiring information about the presence (or absence) of 155 NAT64, and one or more Pref64::/n used for protocol translation SHALL 156 send a DNS query for AAAA resource records of the Well-Known IPv4- 157 only Name (WKN) "ipv4only.arpa". The node MAY perform the DNS query 158 in both IPv6-only and dual-stack access networks. 160 When sending a DNS AAAA resource record query for the WKN, a node 161 MUST set the "Checking Disabled (CD)" bit to zero [RFC4035], as 162 otherwise the DNS64 server will not perform IPv6 address synthesis 163 (Section 3 of [RFC6147]) and hence would not reveal the Pref64::/n 164 used for protocol translation. 166 A DNS reply with one or more AAAA resource records indicates that the 167 access network is utilizing IPv6 address synthesis. In some 168 scenarios captive portals, or NXDOMAIN and NODATA hijacking, 169 performed by the access network may result in a false positive. One 170 method to detect such hijacking is to query a Fully Qualified Domain 171 Name (FQDN) that is known to be invalid (and normally return an empty 172 response or an error response) and see if it returns a valid resource 173 record. However, as long as the hijacked domain does not result in 174 AAAA resource record responses that contain well-known IPv4 address 175 in any location defined by RFC6052, the response will not disturb the 176 Pref64::/n learning procedure. 178 A node MUST look through all of the received AAAA resource records to 179 collect one or more Pref64::/n. The Pref64::/n list might include 180 the Well-Known Prefix 64:ff9b::/96 [RFC6052] or one or more Network- 181 Specific Prefixes. In the case of NSPs, the node SHALL determine the 182 used address format by searching the received IPv6 addresses for the 183 WKN's well-known IPv4 addresses. The node SHALL assume the well- 184 known IPv4 addresses might be found at the locations specified by 185 [RFC6052] section 2.2. The node MUST check on octet boundaries to 186 ensure a 32-bit well-known IPv4 address value is present only once in 187 an IPv6 address. In case another instance of the value is found 188 inside the IPv6 address, the node SHALL repeat the search with the 189 other well-known IPv4 address. 191 If only one Pref64::/n was present in the DNS response: a node SHALL 192 use that Pref64::/n for both local synthesis and for detecting 193 synthesis done by the DNS64 server on the network. 195 If more than one Pref64::/n was present in the DNS response: a node 196 SHOULD use all of them when determining whether other received IPv6 197 addresses are synthetic. The node MUST use all learned Pref64::/n 198 when performing local IPv6 address synthesis, and use the prefixes in 199 the order received from the DNS64 server. That is, when the node is 200 providing a list of locally synthesized IPv6 addresses to upper 201 layers, IPv6 addresses MUST be synthesized by using all discovered 202 Pref64::/n in the received order. 204 If the well-known IPv4 addresses are not found within the standard 205 locations, it indicates that the network is not using a standard 206 address format and the Pref64::/n cannot be determined. Developers 207 can over time learn of IPv6 translated address formats that are 208 extensions or alternatives to the standard formats. Developers MAY 209 at that point add additional steps to the described discovery 210 procedure. The additional steps are outside the scope of the present 211 document. 213 In case a node does not receive a positive DNS reply to the AAAA 214 resource record query, the node MAY perform a DNS A resource record 215 query for the well-known name. If the node receives a positive reply 216 to the DNS A resource record query it means the used recursive DNS 217 server is not a DNS64 server. 219 In the case of a negative response (NXDOMAIN, NODATA) or a DNS query 220 timeout: a DNS64 server is not available on the access network, the 221 access network filtered out the well-known query, or something went 222 wrong in the DNS resolution. All unsuccessful cases result in a node 223 being unable to perform local IPv6 address synthesis. In the case of 224 timeout, the node SHOULD retransmit the DNS query like any other DNS 225 query the node makes [RFC1035]. In the case of a negative response 226 (NXDOMAIN, NODATA), the node MUST obey the Time-To-Live [RFC1035] of 227 the response before resending the AAAA resource record query. The 228 node MAY monitor for DNS replies with IPv6 addresses constructed from 229 the WKP, in which case if any are observed the node SHOULD use the 230 WKP as if it were learned during the query for the well-known name. 232 To save Internet resources if possible, a node should perform 233 Pref64::/n discovery only when needed (e.g., when local synthesis is 234 required, a new network interface is connected to a new network, and 235 so forth). The node SHALL cache the replies it receives during the 236 Pref64::/n discovery procedure and it SHOULD repeat the discovery 237 process ten seconds before the Time-To-Live of the Well-Known Name's 238 synthetic AAAA resource record expires. 240 3.1. Validation of Discovered Pref64::/n 242 If a node is using an insecure channel between itself and a DNS64 243 server, or the DNS64 server is untrusted, it is possible for an 244 attacker to influence the node's Pref64::/n discovery procedures. 245 This may result in denial-of-service, redirection, man-in-the-middle, 246 or other attacks. 248 To mitigate against attacks, the node SHOULD communicate with a 249 trusted DNS64 server over a secure channel, or use DNSSEC. NAT64 250 operators SHOULD provide facilities for validating discovery of 251 Pref64::/n via a secure channel and/or DNSSEC protection. 253 It is important to understand that DNSSEC only validates that the 254 discovered Pref64::/n is the one that belongs to a domain used by 255 NAT64 FQDN. Importantly, the DNSSEC validation does not tell if the 256 node is at the network where the Pref64::/n is intended to be used. 257 Furthermore, DNSSEC validation cannot be utilized in the case of WKP. 259 3.1.1. DNSSEC Requirements for the Network 261 If the operator has chosen to support nodes performing validation of 262 discovered Pref64::/n with DNSSEC, the operator of the NAT64 device 263 MUST perform the following configurations. 265 1. Have one or more Fully Qualified Domain Names for the NAT64 266 translator entities (later referred as NAT64 FQDN). In the case 267 of more than one Pref64::/n being used in a network, e.g., for 268 load-balancing purposes, it is for network administrators to 269 decide whether a single NAT64's fully-qualified domain name maps 270 to more than one Pref64::/n, or whether there will be a dedicated 271 NAT64 FQDN per Pref64::/n. 273 2. Each NAT64 FQDN MUST have one or more DNS AAAA resource records 274 containing Pref64::WKA (Pref64::/n combined with WKA). 276 3. Each Pref64::WKA MUST have a PTR resource record that points to 277 the corresponding NAT64 FQDN. 279 4. Sign the NAT64 FQDNs' AAAA and A resource records with DNSSEC. 281 3.1.2. DNSSEC Requirements for the Node 283 A node SHOULD prefer a secure channel to talk to a DNS64 server, 284 whenever possible. In addition, a node that implements a DNSSEC 285 validating resolver MAY use the following procedure to validate 286 discovery of the Pref64::/n. 288 1. Heuristically find Pref64::/n candidates by making a AAAA 289 resource record query for "ipv4only.arpa" by following the 290 procedure in Section 3. This will result in IPv6 addresses 291 consisting of Pref64::/n combined with WKA, i.e., Pref64::WKA. 292 For each Pref64::/n that the node wishes to validate, the node 293 performs the following steps. 295 2. Send a DNS PTR resource record query for the IPv6 address of the 296 translator (for "ip6.arpa"), using the Pref64::WKA learned in 297 step 1. CNAME and DNAME results should be followed according to 298 the rules in RFC 1034 [RFC1034], RFC 1034 [RFC1035], and RFC 6672 299 [RFC6672]. The ultimate response will include one or more NAT64 300 FQDNs. 302 3. The node SHOULD compare the domains of learned NAT64 FQDNs to a 303 list of the node's trusted domains and choose a NAT64 FQDN that 304 matches. The means for a node to learn the trusted domains is 305 implementation-specific. If the node has no list of trusted 306 domains, the node MAY query the user whether the domain can be 307 trusted and MAY remember the answer for future use. If the node 308 has no trust for the domain, the discovery procedure is not 309 secure and the remaining steps described below MUST NOT be 310 performed. 312 4. Send a DNS AAAA resource record query for the NAT64 FQDN. 314 5. Verify the DNS AAAA resource record contains Pref64::WKA 315 addresses received at the step 1. It is possible that the NAT64 316 FQDN has multiple AAAA records, in which case the node MUST check 317 if any of the addresses match the ones obtained in step 1. The 318 node MUST ignore other responses and not use them for local IPv6 319 address synthesis. 321 6. Perform DNSSEC validation of the DNS AAAA response. 323 After the node has successfully performed the above five steps, the 324 node can consider Pref64::/n validated. 326 3.2. Connectivity Check 328 After learning a Pref64::/n, the node SHOULD perform a connectivity 329 check to ensure the learned Pref64::/n is functional. It could be 330 non-functional for a variety of reasons -- the discovery failed to 331 work as expected, the IPv6 path to the NAT64 is down, the NAT64 is 332 down, or the IPv4 path beyond the NAT64 is down. 334 There are two main approaches to determine if the learned Pref64::/n 335 is functional. The first approach is to perform a dedicated 336 connectivity check. The second approach is to simply attempt to use 337 the learned Pref64::/n. Each approach has some trade-offs (e.g., 338 additional network traffic or possible user-noticeable delay), and 339 implementations should carefully weigh which approach is appropriate 340 for their application and the network. 342 The node SHOULD use an implementation-specific connectivity check 343 server and a protocol of the implementation's choice, but if that is 344 not possible, a node MAY do a PTR resource record query of the 345 Pref64::WKA to get a NAT64 FQDN. The node then does an A resource 346 query of the NAT64 FQDN, which will return zero or more A resource 347 records pointing to connectivity check servers used by the network 348 operator. A negative response to the PTR or A resource query means 349 there are no connectivity check servers available. A network 350 operator that provides NAT64 services for a mix of nodes with and 351 without implementation-specific connectivity check servers SHOULD 352 assist nodes in their connectivity checks by mapping each NAT64 FQDN 353 to one or more DNS A resource records with IPv4 address(es) pointing 354 to connectivity check server(s). The Pref64::/n -based connectivity 355 check approach works only with NSPs, as it is not possible to 356 register A records for each different domain using WKP. The network 357 operator MUST disable ICMPv6 rate limiting for connectivity check 358 messages. 360 In case of multiple connectivity check servers being available for 361 use, the node chooses the first one, preferring implementation- 362 specific servers. 364 The connectivity check protocol used with implementation-specific 365 connectivity check servers is implementation-specific. 367 The connectivity check protocol used with connectivity check servers 368 pointed to by the NAT64 FQDN's A resource records is ICMPv6 369 [RFC4443]. The node performing a connectivity check against these 370 servers SHALL send an ICMPv6 Echo Request to an IPv6 address 371 synthesized by combining discovered Pref64::/n with an IPv4 address 372 of the server as specified in [RFC6052]. This will test the IPv6 373 path to the NAT64, the NAT64's operation, and the IPv4 path all the 374 way to the connectivity check server. If no response is received for 375 the ICMPv6 Echo Request, the node SHALL send another ICMPv6 Echo 376 Request, a second later. If still no response is received, the node 377 SHALL send a third ICMPv6 Echo Request two seconds later. If an 378 ICMPv6 Echo Response is received, the node knows the IPv6 path to the 379 connectivity check server is functioning normally. If, after the 380 three transmissions and three seconds since the last ICMPv6 Echo 381 Request, no response is received, the node learns this Pref64::/n 382 might not be functioning, and the node MAY choose a different 383 Pref64::/n (if available), choose to alert the user, or proceed 384 anyway hoping the problem is temporary or only with the connectivity 385 check itself. After all, the ICMPv6 is by design unreliable and 386 failure to receive ICMPv6 responses may not indicate anything other 387 than network failure to transport ICMPv6 messages through. 389 If no separate connectivity check is performed before local IPv6 390 address synthesis, a node MAY monitor success of connection attempts 391 performed with locally synthesized IPv6 addresses. Based on success 392 of these connections, and based on possible ICMPv6 error messages 393 received (such as Destination Unreachable messages), the node MAY 394 cease to perform local address synthesis and MAY restart the 395 Pref64::/n discovery procedures. 397 3.2.1. No Connectivity Checks Against ipv4only.arpa 399 Clients MUST NOT send a connectivity check to an address returned by 400 the ipv4only.arpa query. This is because, by design, no server will 401 be operated on the Internet at that address as such. Similarly, 402 network operators MUST NOT operate a server on that address. The 403 reason this address isn't used for connectivity checks is that 404 operators who neglect to operate a connectivity check server will 405 allow that traffic towards the Internet where it will be dropped and 406 cause a false negative connectivity check with the client (that is, 407 the NAT64 is working fine, but the connectivity check fails because a 408 server is not operating at "ipv4only.arpa" on the Internet and a 409 server is not operated by the NAT64 operator). Instead, for the 410 connectivity check, an additional DNS resource record is looked up 411 and used for the connectivity check. This ensures that packets don't 412 unnecessarily leak to the Internet and reduces the chance of a false 413 negative connectivity check. 415 3.3. Alternative Domain Names 417 Some applications, operating systems, devices, or networks may find 418 it advantageous to operate their own DNS infrastructure to perform a 419 function similar to "ipv4only.arpa", but using a different resource 420 record. The primary advantage is to ensure availability of the DNS 421 infrastructure and ensure the proper configuration of the DNS record 422 itself. For example, a company named Example might have their 423 application query "ipv4only.example.com". Other than the different 424 DNS resource record being queried, the rest of the operations are 425 anticipated to be identical to the steps described in this document. 427 3.4. Message Flow Illustration 429 The figure below gives an example illustration of a message flow in 430 the case of prefix discovery utilizing Pref64::/n validation. The 431 figure shows also a step where the procedure ends if no Pref64::/n 432 validation is performed. 434 In this example, three Pref64::/n are provided by the DNS64 server. 435 The first Pref64::/n is using an NSP, in this example "2001:db8: 436 42::/96". The second Pref64::/n is using an NSP, in this example 437 "2001:db8:43::/96". The third Pref64::/n is using the WKP. Hence, 438 when the Pref64::/n are combined with the WKA to form Pref64::WKA, 439 the synthetic IPv6 addresses returned by DNS64 server are "2001:db8: 440 42::192.0.0.170", "2001:db8:43::192.0.0.170", and "64:ff9b:: 441 192.0.0.170". The DNS64 server could also return synthetic addresses 442 containing the IPv4 address 192.0.0.171. 444 The validation is not done for the WKP, see Section 3.1. 446 Node DNS64 server 447 | | 448 | "AAAA" query for "ipv4only.arpa" | 449 |----------------------------------------------->| "A" query for 450 | | "ipv4only.arpa" 451 | |----------------> 452 | | 453 | | "A" response: 454 | | "192.0.0.170" 455 | | "192.0.0.171" 456 | |<---------------- 457 | +----------------------------+ 458 | | "AAAA" synthesis using | 459 | | three Pref64::/n. | 460 | +----------------------------+ 461 | "AAAA" response with: | 462 | "2001:db8:42::192.0.0.170" | 463 | "2001:db8:43::192.0.0.170" | 464 | "64:ff9b::192.0.0.170" | 465 |<-----------------------------------------------| 466 | | 467 +----------------------------------------------+ | 468 | If Pref64::/n validation is not performed, a | | 469 | node can fetch prefixes from AAAA responses | | 470 | at this point and skip the steps below. | | 471 +----------------------------------------------+ | 472 | | 473 | "PTR" query #1 for "2001:db8:42::192.0.0.170 | 474 |----------------------------------------------->| 475 | "PTR" query #2 for "2001:db8:43::192.0.0.170 | 476 |----------------------------------------------->| 477 | | 478 | "PTR" response #1 "nat64_1.example.com" | 479 |<-----------------------------------------------| 480 | "PTR" response #2 "nat64_2.example.com" | 481 |<-----------------------------------------------| 482 | | 483 +----------------------------------------------+ | 484 | Compare received domains to a trusted domain | | 485 | list and if matches are found, continue. | | 486 +----------------------------------------------+ | 487 | | 488 | "AAAA" query #1 for "nat64_1.example.com" | 489 |----------------------------------------------->| 490 | "AAAA" query #2 for "nat64_2.example.com" | 491 |----------------------------------------------->| 492 | | 493 | "AAAA" resp. #1 with "2001:db8:42::192.0.0.170 | 494 |<-----------------------------------------------| 495 | "AAAA" resp. #2 with "2001:db8:43::192.0.0.170 | 496 |<-----------------------------------------------| 497 | | 498 +----------------------------------------------+ | 499 | Validate AAAA responses and compare the IPv6 | | 500 | addresses to those previously learned. | | 501 +----------------------------------------------+ | 502 | | 503 +----------------------------------------------+ | 504 | Fetch the Pref64::/n from the validated | | 505 | responses and take into use. | | 506 +----------------------------------------------+ | 507 | | 509 Pref64::/n discovery procedure 511 4. Operational Considerations for Hosting the IPv4-Only Well-Known Name 513 The authoritative name server for the well-known name SHALL have DNS 514 record Time-To-Live (TTL) set to at least 60 minutes in order to 515 improve effectiveness of DNS caching. The exact TTL value will be 516 determined and tuned based on operational experiences. 518 The domain serving the well-known name MUST be signed with DNSSEC. 519 See also section 7. 521 5. Operational Considerations for DNS64 Operator 523 A network operator of a DNS64 server can guide nodes utilizing 524 heuristic discovery procedures by managing the responses a DNS64 525 server provides. 527 If the network operator would like nodes to utilize multiple 528 Pref64::/n, the operator needs to configure DNS64 servers to respond 529 with multiple synthetic AAAA records. As per Section 3 the nodes can 530 then use them all. 532 There are no guarantees on which of the Pref64::/n nodes will end up 533 using. If the operator wants nodes to specifically use a certain 534 Pref64::/n or periodically change the Pref64::/n they use, for 535 example for load balancing reasons, the only guaranteed method is to 536 make DNS64 servers return only a single synthetic AAAA resource 537 record, and have the Time-To-Live of that synthetic record such that 538 the node repeats the Pref64::/n discovery when required. 540 Besides choosing how many Pref64::/n to respond and what Time-To-Live 541 to use, DNS64 servers MUST NOT interfere with or perform other 542 special procedures for the queries related to the well-known name. 544 5.1. Mapping of IPv4 Address Ranges to IPv6 Prefixes 546 RFC 6147 [RFC6147] allows DNS64 implementations to be able to map 547 specific IPv4 address ranges to separate Pref64::/n. That allows 548 handling of special use IPv4 addresses [RFC5735]. The example setup 549 where this might be used is illustrated in Figure 1. The NAT64 "A" 550 is used when accessing IPv4-only servers in the datacenter, and the 551 NAT64 "B" is used for Internet access. 553 NAT64 "A" ----- IPv4-only servers in a datacenter 554 / 555 IPv6-only node----< 556 \ 557 NAT64 "B" ----- IPv4 Internet 559 Figure 1: NAT64s with IPv4 Address Ranges 561 The heuristic discovery method described herein does not support 562 learning of the possible rules used by a DNS64 server for mapping 563 specific IPv4 address ranges to separate Pref64::/n. Therefore, 564 nodes will use the same discovered Pref64::/n to synthesize IPv6 565 addresses from any IPv4 address. This can cause issues for routing 566 and connectivity establishment procedures. The operator of the NAT64 567 and the DNS64 ought to take this into account in the network design. 569 The network operators can help IPv6-only nodes by ensuring the nodes 570 do not have to work with IPv4 address literals for which special 571 mapping rules are used. That is, the IPv4-only servers addressed 572 from the special IPv4 address ranges ought to have signed AAAA 573 records, which allows IPv6-only nodes to avoid local address 574 synthesis. If the IPv6-only nodes are not using DNSSEC, then it is 575 enough if the network's DNS64 server returns synthetic AAAA resource 576 records pointing to IPv4-only servers. Avoiding the need for IPv6- 577 only nodes to perform address synthesis for IPv4 addresses belonging 578 to special ranges is the best approach to assist nodes. 580 If the IPv6-only nodes have no other choice than using IPv4-address 581 literals belonging to special IPv4 address ranges, and the IPv6-only 582 node will perform local synthesis by using the discovered Pref64::/n, 583 then the network ought to ensure with routing that the packets are 584 delivered to the correct NAT64. For example, a router in the path 585 from an IPv6-only host to NAT64s can forward the IPv6 packets to the 586 correct NAT64 as illustrated in Figure 2. The routing could be based 587 on the last 32-bits of the IPv6 address, but the network operator can 588 also use some other IPv6 address format allowed by RFC 6052 589 [RFC6052], if it simplifies routing setup. This setup requires 590 additional logic on the NAT64 providing connectivity to special IPv4 591 address ranges: it needs to be able to translate packets it receives 592 that are using the Pref64::/n used with Internet connections. 594 NAT64 "A" ----- IPv4-only servers in a datacenter 595 / 596 IPv6-only host----router 597 \ 598 NAT64 "B" ----- IPv4 Internet 600 Figure 2: NAT64s with Assisting Router 602 6. Exit Strategy 604 A day will come when this tool is no longer needed. At that point 605 the best suited techniques for implementing an exit strategy will be 606 documented. 608 A node SHOULD implement a configuration knob for disabling the 609 Pref64::/n discovery feature. 611 7. Security Considerations 613 The security considerations follow closely those of RFC 6147 614 [RFC6147]. The possible attacks are very similar in the case where 615 an attacker controls a DNS64 server and returns tampered IPv6 616 addresses to a node and in the case where an attacker causes the node 617 to use tampered Pref64::/n for local address synthesis. DNSSEC 618 cannot be used to validate responses created by a DNS64 server the 619 node has no trust relationship with. Hence this document does not 620 change the big picture for untrusted network scenarios. If an 621 attacker alters the Pref64::/n used by a DNS64 server or a node, the 622 traffic generated by the node will be delivered to an altered 623 destination. This can result in either a denial-of-service (DoS) 624 attack (if the resulting IPv6 addresses are not assigned to any 625 device), a flooding attack (if the resulting IPv6 addresses are 626 assigned to devices that do not wish to receive the traffic), or an 627 eavesdropping attack (in case the altered NSP is routed through the 628 attacker). 630 The zone serving the well-known name has to be protected with DNSSEC, 631 as otherwise it will be too attractive a target for attackers who 632 wish to alter nodes' Pref64::/n discovery procedures. 634 A node SHOULD implement a validating DNSSEC resolver for validating 635 the A response of the well-known name query. A node without a 636 validating DNSSEC resolver SHOULD request validation to be performed 637 by the recursive DNS server and use a secure channel when 638 communicating with the DNS64 server. 640 For Pref64::/n discovery validation, the access network SHOULD sign 641 the NAT64 translator's fully qualified domain name. A node SHOULD 642 use the algorithm described in Section 3.1 to validate each 643 discovered Pref64::/n. 645 Lastly, the best mitigation action against Pref64::/n discovery 646 attacks is to add IPv6 support for nodes' destinations and hence 647 reduce the need to perform local IPv6 address synthesis. 649 8. IANA Considerations 651 According to procedures described in [RFC3172] this document directs 652 IANA to reserve a second level domain from the .ARPA zone for the 653 well-known domain name. The well-known domain name could be, for 654 example, "ipv4only.arpa". 656 The well-known name needs to map to two different global IPv4 657 addresses. The addresses are to be taken from the IANA IPv4 Special 658 Purpose Address Registry [RFC5736], from the 192.0.0.0/24 address 659 block, and can be, for example, 192.0.0.170 and 192.0.0.171. The 660 addresses are to be documented to be of global scope, but they do not 661 need to be routable within local or global scopes. 663 9. Acknowledgements 665 Authors would like to thank Dmitry Anipko, Cameron Byrne, Aaron Yi 666 Ding Christian Huitema, Washam Fan, Peter Koch, Stephan Lagerholm, 667 Zhenqiang Li, Simon Perreault, Marc Petit-Huguenin, Andrew Sullivan, 668 and Dave Thaler, for significant improvement ideas and comments. 670 10. References 672 10.1. Normative References 674 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 675 STD 13, RFC 1034, November 1987. 677 [RFC1035] Mockapetris, P., "Domain names - implementation and 678 specification", STD 13, RFC 1035, November 1987. 680 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 681 Requirement Levels", BCP 14, RFC 2119, March 1997. 683 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 684 Rose, "Protocol Modifications for the DNS Security 685 Extensions", RFC 4035, March 2005. 687 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 688 Message Protocol (ICMPv6) for the Internet Protocol 689 Version 6 (IPv6) Specification", RFC 4443, March 2006. 691 [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 692 Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, 693 October 2010. 695 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 696 NAT64: Network Address and Protocol Translation from IPv6 697 Clients to IPv4 Servers", RFC 6146, April 2011. 699 [RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van 700 Beijnum, "DNS64: DNS Extensions for Network Address 701 Translation from IPv6 Clients to IPv4 Servers", RFC 6147, 702 April 2011. 704 [RFC6672] Rose, S. and W. Wijngaards, "DNAME Redirection in the 705 DNS", RFC 6672, June 2012. 707 10.2. Informative References 709 [RFC3172] Huston, G., "Management Guidelines & Operational 710 Requirements for the Address and Routing Parameter Area 711 Domain ("arpa")", BCP 52, RFC 3172, September 2001. 713 [RFC5735] Cotton, M. and L. Vegoda, "Special Use IPv4 Addresses", 714 BCP 153, RFC 5735, January 2010. 716 [RFC5736] Huston, G., Cotton, M., and L. Vegoda, "IANA IPv4 Special 717 Purpose Address Registry", RFC 5736, January 2010. 719 [RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for 720 IPv4/IPv6 Translation", RFC 6144, April 2011. 722 [RFC6418] Blanchet, M. and P. Seite, "Multiple Interfaces and 723 Provisioning Domains Problem Statement", RFC 6418, 724 November 2011. 726 Appendix A. Example of DNS Record Configuration 728 The following BIND-style examples illustrate how A and AAAA records 729 could be configured by a NAT64 operator. 731 The examples use Pref64::/n of 2001:db8::/96, both WKAs, and the 732 example.com domain. 734 The PTR record for reverse queries (Section 3.1.1 bullet 3): 736 $ORIGIN A.A.0.0.0.0.0.C\ 737 .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. 738 @ IN SOA ns1.example.com. hostmaster.example.com. ( 739 2003080800 12h 15m 3w 2h) 740 IN NS ns.example.com. 742 IN PTR nat64.example.com. 744 $ORIGIN B.A.0.0.0.0.0.C\ 745 .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. 746 @ IN SOA ns1.example.com. hostmaster.example.com. ( 747 2003080800 12h 15m 3w 2h) 748 IN NS ns.example.com. 750 IN PTR nat64.example.com. 752 If example.com does not use DNSSEC, the following configuration file 753 could be used. Please note that nat64.example.com has both an AAAA 754 record with the Pref64::/n and an A record for the connectivity check 755 (Section 3.1.1 bullet 2). 757 example.com. IN SOA ns.example.com. hostmaster.example.com. ( 758 2002050501 ; serial 759 100 ; refresh (1 minute 40 seconds) 760 200 ; retry (3 minutes 20 seconds) 761 604800 ; expire (1 week) 762 100 ; minimum (1 minute 40 seconds) 763 ) 765 example.com. IN NS ns.example.com. 767 nat64.example.com. 768 IN AAAA 2001:db8:0:0:0:0:C000:00AA 769 IN AAAA 2001:db8:0:0:0:0:C000:00AB 770 IN A 192.0.2.1 772 To DNSSEC sign the records, the owner of the example.com zone would 773 have RRSIG records for both the AAAA and A records for 774 nat64.example.com. As a normal DNSSEC requirement, the zone and its 775 parent also need to be signed. 777 Appendix B. About the IPv4 Address for the Well-Known Name 779 The IPv4 addresses for the well-known name cannot be non-global IPv4 780 addresses as listed in the Section 3 of [RFC5735]. Otherwise DNS64 781 servers might not perform AAAA record synthesis when the well-known 782 prefix is used, as stated in Section 3.1 of [RFC6052]. However, the 783 addresses do not have to be routable or allocated to any real node, 784 as no communications will be initiated to these IPv4 address. 786 Allocation of at least two IPv4 addresses improves the heuristics in 787 cases where the bit pattern of the primary IPv4 address appears more 788 than once in the synthetic IPv6 address (i.e., the NSP prefix 789 contains the same bit pattern as the IPv4 address). 791 If no well-known IPv4 addresses would be statically allocated for 792 this method, the heuristic would require sending of an additional A 793 query to learn the IPv4 addresses that would be then searched from 794 inside of the received IPv6 address. 796 Authors' Addresses 798 Teemu Savolainen 799 Nokia 800 Hermiankatu 12 D 801 FI-33720 Tampere 802 Finland 804 Email: teemu.savolainen@nokia.com 806 Jouni Korhonen 807 Nokia Siemens Networks 808 Linnoitustie 6 809 FI-02600 Espoo 810 Finland 812 Email: jouni.nospam@gmail.com 814 Dan Wing 815 Cisco Systems 816 170 West Tasman Drive 817 San Jose, California 95134 818 USA 820 Email: dwing@cisco.com