idnits 2.17.1 draft-ietf-behave-nat64-discovery-heuristic-06.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 (March 12, 2012) is 4425 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 normative reference: RFC 5735 (Obsoleted by RFC 6890) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). 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, 2012 Nokia Siemens Networks 6 D. Wing 7 Cisco Systems 8 March 12, 2012 10 Discovery of IPv6 Prefix Used for IPv6 Address Synthesis 11 draft-ietf-behave-nat64-discovery-heuristic-06.txt 13 Abstract 15 This document describes a method for detecting presence of DNS64 and 16 for learning IPv6 prefix used for protocol translation on an access 17 network. The method depends on existence of a well-known IPv4-only 18 domain name "ipv4only.arpa". The information learned enables nodes 19 to perform local IPv6 address synthesis and to potentially avoid 20 traversal through NAT64 on dual-stack accesses 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 September 13, 2012. 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. Secure Learning of Pref64::/n . . . . . . . . . . . . . . 6 63 3.1.1. DNSSEC Requirements for the Network . . . . . . . . . 6 64 3.1.2. Node Behavior . . . . . . . . . . . . . . . . . . . . 6 65 3.2. Connectivity Check . . . . . . . . . . . . . . . . . . . . 7 66 3.2.1. No Connectivity Checks Against ipv4only.arpa . . . . . 8 67 3.3. Alternative Domain Names . . . . . . . . . . . . . . . . . 8 68 4. Operational Considerations for Hosting the IPv4-Only 69 Well-Known Name . . . . . . . . . . . . . . . . . . . . . . . 9 70 5. DNS(64) Entity Considerations . . . . . . . . . . . . . . . . 9 71 6. Exit Strategy . . . . . . . . . . . . . . . . . . . . . . . . 9 72 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 73 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 74 8.1. About the IPv4 Address for the Well-Known Name . . . . . . 10 75 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 76 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 77 10.1. Normative References . . . . . . . . . . . . . . . . . . . 11 78 10.2. Informative References . . . . . . . . . . . . . . . . . . 12 79 Appendix A. Example of DNS Record Configuration . . . . . . . . . 12 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 82 1. Introduction 84 As part of the transition to IPv6, NAT64 [RFC6146] and DNS64 85 [RFC6147] technologies will be utilized by some access networks to 86 provide IPv4 connectivity for IPv6-only nodes [RFC6144]. The DNS64 87 utilizes IPv6 address synthesis to create local IPv6 presentations of 88 peers having only IPv4 addresses, hence allowing DNS-using IPv6-only 89 nodes to communicate with IPv4-only peers. 91 However, DNS64 cannot serve applications not using DNS, such as those 92 receiving IPv4 address literals as referrals. Such applications 93 could nevertheless be able to work through NAT64, provided they are 94 able to create locally valid IPv6 presentations of peers' IPv4 95 addresses. 97 Additionally, DNS64 is not able to do IPv6 address synthesis for 98 nodes running validating DNSSEC enabled DNS resolvers, but instead 99 the synthesis must be done by the nodes themselves. In order to 100 perform IPv6 synthesis nodes have to learn the IPv6 prefix(es) used 101 on the access network for protocol translation. The prefixes, which 102 may be Network Specific Prefixes (NSP) or Well-Known Prefixes (WKP) 103 [RFC6052], are referred in this document as Pref64::/n [RFC6146]. 105 This document describes a best effort method for applications and 106 nodes to learn the information required to perform local IPv6 address 107 synthesis. The IPv6 address synthesis procedure itself is out-of- 108 scope of this document. An example application is a browser 109 encountering IPv4 address literals in an IPv6-only access network. 110 Another example is a node running validating security aware DNS 111 resolver in an IPv6-only access network. 113 The knowledge of IPv6 address synthesis taking place may also be 114 useful if DNS64 and NAT64 are present in dual-stack enabled access 115 networks or if a node is multi-interfaced [RFC6418]. In such cases 116 nodes may choose to prefer IPv4 or alternative network interface in 117 order to avoid traversal through protocol translators. 119 It is important to notice that use of this approach will not result 120 in as robust, secure, and good behaving system as an all-IPv6 system 121 would be. Hence it is highly recommended to upgrade nodes' 122 destinations to IPv6 and utilize the described method only as a 123 short-term solution. 125 2. Requirements and Terminology 126 2.1. Requirements 128 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 129 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 130 document are to be interpreted as described in [RFC2119]. 132 2.2. Terminology 134 NAT64 FQDN: One or more fully qualified domain names for NAT64 135 protocol translator entity. 137 Pref64::/n: The IPv6 prefix used on IPv6 address synthesis [RFC6146]. 139 Well-Known IPv4-only Name (WKN): a fully qualified domain name, 140 "ipv4only.arpa", well-known to have only A record. 142 Well-Known IPv4 Address: an IPv4 address that is well-known and 143 mapped to the well-known name. 145 3. Node Behavior 147 A node requiring information about presence of NAT64 and the 148 Pref64::/n used for protocol translation SHALL send a DNS query for 149 AAAA records of a well-known IPv4-only fully qualified domain name: 150 "ipv4only.arpa". The node MAY also need to perform DNS query for the 151 A record of the well-known name in order to learn what is the IPv4 152 address of the well-known name. The node may perform this check in 153 both IPv6-only and dual-stack access networks. 155 When sending AAAA query for the well-known name a node MUST set 156 "Checking Disabled (CD)" bit to zero, as otherwise the DNS64 will not 157 perform IPv6 address synthesis hence does not reveal the Pref64::/n 158 used for protocol translation. 160 A DNS reply with one or more non-empty AAAA records indicates that 161 the access network is utilizing IPv6 address synthesis. A node MUST 162 look through all of the received AAAA records to collect one or more 163 Pref64::/n. Pref64::/n list may include Well-Known Prefix 64: 164 ff9b::/96 [RFC6052] or one or more Network-Specific Prefixes. In the 165 case of NSPs the node SHALL search for the IPv4 address of the well- 166 known name inside of the received IPv6 addresses to determine the 167 used address format. 169 An IPv4 address of the well-known name should be found inside 170 synthetic IPv6 address at some of the locations described in 171 [RFC6052]. If the searched IPv4 address is not found on any of the 172 standard locations the network must be using different formatting. 174 Developers may over time learn on IPv6 translated address formats 175 that are extensions or alternatives to the standard formats. 176 Developers MAY at that point add additional steps to the described 177 discovery procedures. The additional steps are outside the scope of 178 the present document. 180 The node should ensure a 32-bit IPv4 address value is present only 181 once in an IPv6 address. In case another instance of the value is 182 found inside the IPv6, the node shall repeat the search with another 183 IPv4 address, if possible. 185 In the case only one Pref64::/n was present in the DNS response: a 186 node shall use that Pref64::/n for both local synthesis and for 187 detecting synthesis done by the DNS64 entity on the network. 189 In the case of more than one Pref64::/n were present in the DNS 190 response: a node SHOULD use all of them when determining whether 191 other received IPv6 addresses are synthetic. However, for selecting 192 Pref64::/n for the local IPv6 address synthesis node MUST use the 193 following prioritization order, of which purpose is to avoid use of 194 Pref64::/n containing suffixes reserved for the future [RFC6052]: 196 1. Use NSP having /96 prefix 198 2. Use WKP prefix 200 3. Use longest available NSP prefix 202 In the case of NXDOMAIN response or an empty AAAA reply: the DNS64 is 203 not available on the access network, network filtered the well-known 204 query on purpose, or something went wrong in the DNS resolution. All 205 unsuccessful cases result in unavailability of a node to perform 206 local IPv6 address synthesis. The node MAY periodically resend AAAA 207 query to check if DNS64 has become available or possibly temporary 208 problem cleared. The node MAY perform A query for the well-known 209 name to learn whether the Pref64::/n discovery framework is available 210 at all (see section 6 about Exit Strategy). The node MAY also 211 continue monitoring DNS replies with IPv6 addresses constructed from 212 WKP, in which case the node MAY use the WKP as if it were learned 213 during the query for well-known name. 215 To save Internet's resources, if possible, a node should perform 216 Pref64::/n discovery only when needed (e.g. when local synthesis is 217 required, cached reply timeouts, new network interface is started, 218 and so forth). The node SHALL cache the replies it receives during 219 Pref64::/n discovery procedure and it SHALL repeat the discovery 220 process when one third of the Time-To-Live of the Well-Known Name's 221 synthetic AAAA DNS response is remaining. 223 3.1. Secure Learning of Pref64::/n 225 If a node is using insecure channel between itself and DNS64, or 226 DNS64 entity itself is untrusted, it is possible for an attacker to 227 influence node's Pref64::/n detection procedures. This may result in 228 denial-of-service, redirection, man-in-the-middle, or other attacks. 229 To protect against these attacks the node SHOULD communicate with 230 trusted DNS64 over secure channel or use DNSSEC. NAT64 operators 231 SHOULD provide facilities for secure learning of Pref64::/n: a secure 232 channel and/or DNSSEC protection. 234 3.1.1. DNSSEC Requirements for the Network 236 If the operator has chosen to support nodes performing Pref64::/n 237 learning securely with DNSSEC, the operator of the NAT64 device MUST 238 perform the following configurations. 240 1. Have one or more fully qualified domain names for the NAT64 241 translator entities (later referred as NAT64 FQDN). In the case 242 of more than one Pref64::/n being used in a network, e.g. for 243 load-balancing purposes, it is for network administrators to 244 decide whether a single NAT64's fully qualified domain name maps 245 to more than one Pref64::/n, or whether there will be dedicated 246 NAT64 FQDN per Pref64::/n. 248 2. Each NAT64 FQDN MUST have one or more DNS AAAA resource records 249 with each IPv6 address consisting of Pref64::/n and 0's for the 250 elements after the actual prefix. 252 3. Each Pref64::/n MUST HAVE PTR record that points to corresponding 253 NAT64 FQDN. 255 4. Sign the NAT64 FQDNs' AAAA and A records with DNSSEC. 257 3.1.2. Node Behavior 259 A node SHOULD prefer secure channel to talk to DNS64, whenever 260 possible. In addition, a node that implements DNSSEC validating 261 resolver MAY use the following procedure to secure discovery of the 262 Pref64::/n. 264 1. Heuristically find out a Pref64::/n candidate by making AAAA 265 query for the "ipv4only.arpa" by following the procedure in 266 Section 3. This will return one or more AAAA resource records. 267 For each of those AAAA resource records node wishes to use 268 securely, the node performs the following steps. 270 2. Send DNS PTR query for the IPv6 address of the translator (for 271 "ipv6.arpa"), using the Pref64::/n from the step 1 and zeroes for 272 the elements after the actual prefix length. This will return 273 the NAT64 FQDN. 275 3. Send DNS AAAA query for the NAT64 FQDN. 277 4. Verify the DNS AAAA response matches the address obtained in step 278 1. It is possible that the NAT64 FQDN maps to multiple AAAA 279 records, in which case the node has to check if any of the 280 responses matches to the address obtained in step 1. The node 281 must ignore other responses and not to use those for local IPv6 282 address synthesis. 284 5. Perform DNSSEC validation of the DNS AAAA response. 286 After the node has successfully performed the above five steps, the 287 node can consider Pref64::/n securely learned. 289 3.2. Connectivity Check 291 After learning Pref64::/n, the node SHOULD perform connectivity check 292 to ensure the learned Pref64::/n is functional. It could be non- 293 functional for a variety of reasons -- the discovery failed to work 294 as expected, the IPv6 path to the NAT64 is down, the NAT64 is down, 295 or the IPv4 path beyond the NAT64 is down. 297 There are two main approaches to determine if the learned Pref64::/n 298 is functional. The first approach is to perform a dedicated 299 connectivity check. The second approach is to simply attempt to use 300 the learned Pref64::/n. Each approach has some trade-offs (e.g., 301 additional network traffic or possible user-noticable delay), and 302 implementations should carefully weight which approach is appropriate 303 for their application and the network. 305 The node SHOULD use implementation specific connectivity check 306 server, but if that is not possible a node MAY do a PTR query of the 307 Pref64::/n that may return a hostname. The node then does an A query 308 of that hostname, which may return zero, one or more A resource 309 records pointing to connectivity check servers used by the network 310 operator. Negative response to PTR or A query means there are no 311 connectivity check servers available. The operator of a NAT64 entity 312 MAY assist nodes in their connectivity checks by mapping each NAT64 313 FQDN to one or more DNS A resource records with IPv4 address(es) 314 pointing to connectivity check server(s). 316 In case of one or more connectivity check servers being available for 317 use, the node chooses the first one preferring vendor specific 318 servers, if multiple are available. The node MAY perform separate 319 connectivity check by sending an ICMPv6 Echo Request to IPv6 address 320 synthesized by combining discovered Pref64::/n with an IPv4 address 321 of the server used for the connectivity check. This will test the 322 IPv6 path to the NAT64, the NAT64's operation, and the IPv4 path all 323 the way to the connectivity check server. Alternatively the node MAY 324 utilize implementation specific connectivity check protocol. If no 325 response is received for the ICMPv6 Echo Request, the node sends 326 another ICMPv6 Echo Request, a second later. If still no response is 327 received, it sends a third ICMPv6 Echo Request 3 seconds later. If 328 an ICMPv6 Echo Response is received, the node knows the IPv6 path to 329 the connectivity check server is functioning normally. If, after the 330 three transmissions of the ICMPv6 Echo Request, no response is 331 received, the node learns this Pref64::/n may not be functioning, and 332 the node MAY choose a different NAT64 (if a different NAT64 is 333 available), choose to alert the user, or proceed anyway hoping the 334 problem is temporal or only with the connectivity check itself. 336 If no separate connectivity check is performed before local IPv6 337 address synthesis, a node may monitor success of connection attempts 338 performed with locally synthetized IPv6 addresses. Based on success 339 of these connections, and based on possible ICMPv6 error messages 340 received (such as Destination Unreachable Message), the mode MAY 341 cease to perform local address synthesis and MAY restart Pref64::/n 342 discovery procedures. 344 3.2.1. No Connectivity Checks Against ipv4only.arpa 346 Clients MUST NOT send a connectivity check to the address returned in 347 the ipv4only.arpa query. This is because, by design, no server will 348 be operated on the Internet at that address as such. Similarly, 349 network operators MUST NOT operate a server on that address. The 350 reason this address isn't used for connectivity checks is that 351 operators who neglect to operate a connectivity check server will 352 allow that traffic towards the Internet where it will be dropped and 353 cause a false negative connectivity check with the client (that is, 354 the NAT64 is working fine, but the connectivity check fails because a 355 server is not operating at ipv4-only.arpa on the Internet and a 356 server is not operated by the NAT64 operator). Instead, for the 357 connectivity check, an additional DNS resource record is looked up 358 and used for the connectivity check. This ensures that packets don't 359 unnecessarily leak to the Internet and reduces the chance of a false 360 negative connectivity check. 362 3.3. Alternative Domain Names 364 Some applications, operating systems, devices, or networks may find 365 it advantageous to operate their own DNS infrastructure to perform a 366 function similar to ipv4-only.arpa, but using a different resource 367 record. The primary advantage is to ensure availability of the DNS 368 infrastructure and ensure the proper configuration of the DNS record 369 itself. DNS For example, a company named Example might have their 370 application query ipv4-only.example.com. Other than the different 371 DNS resource record being queried, the rest of the operations are 372 anticipated to be identical to the steps described in this document. 374 4. Operational Considerations for Hosting the IPv4-Only Well-Known Name 376 The authoritative name server for the well-known name shall have DNS 377 record Time-To-Live (TTL) set to a long value in order to improve 378 effectiveness of DNS caching. The exact TTL value depends on 379 availability time for the used public IPv4 address. 381 The domain serving the well-known name must be signed with DNSSEC. 382 See also Security Considerations section. 384 It is expected that volumes for well-known name related queries are 385 roughly SOMETHING, TBD. The infrastructure required to serve well- 386 known name is SOMETHING, TBD. 388 5. DNS(64) Entity Considerations 390 DNS(64) servers MUST NOT interfere or perform special procedures for 391 the queries related to the well-known name until the time has arrived 392 for the exit strategy to be defined and deployed. 394 6. Exit Strategy 396 A day will come when this tool is no longer needed. At that point 397 best suited techniques for implementing exit strategy will be 398 documented. In the global scope the exit strategy may include 399 sending NXDOMAIN replies by the authoritative name server of the 400 well-known name with a very long TTL. 402 A node implementation receiving NXDOMAIN response for the A query of 403 the well-known name means SHOULD consider this tool as temporarily 404 disabled. 406 A node SHOULD implement configuration option for disabling the 407 Pref64::/n discovery feature. 409 7. Security Considerations 411 The security considerations follow closely those of RFC6147 412 [RFC6147]. If an attacker manages to change the Pref64::/n node 413 discovers, the traffic generated by the node will be delivered to 414 altered destination. This can result in either a denial-of-service 415 (DoS) attack (if the resulting IPv6 addresses are not assigned to any 416 device), a flooding attack (if the resulting IPv6 addresses are 417 assigned to devices that do not wish to receive the traffic), or an 418 eavesdropping attack (in case the altered NSP is routed through the 419 attacker). 421 The zone serving the well-known name has to be protected with DNSSEC, 422 as otherwise it will be too attractive target for attackers who wish 423 to alter nodes' Pref64::/n discovery procedures. 425 A node SHOULD implement validating DNSSEC resolver for validating the 426 A response of the well-known name query. A node without validating 427 DNSSEC resolver SHOULD request validation to be performed by the used 428 recursive DNS server and use secure channel when communicating with 429 the DNS64. 431 For the secure Pref64::/n discovery the access network SHOULD sign 432 the NAT64 translator's fully qualified domain name. A node SHOULD 433 use the algorithm described in Section 3.1 in order to securely learn 434 the Pref64::/n. 436 Lastly, best mitigation action against Pref64::/n discovery attacks 437 is to add IPv6 support for nodes' destinations and hence reduce need 438 to perform local IPv6 address synthesis. 440 8. IANA Considerations 442 According to procedures described in RFC3172 this document requests 443 IANA and IAB to reserve a second level domain from the .ARPA zone for 444 the well-known domain name. The well-known domain name could be, for 445 example, "ipv4only.arpa". 447 The well-known name also needs to map to one but preferably to two 448 different public IPv4 addresses. 450 8.1. About the IPv4 Address for the Well-Known Name 452 The IPv4 address for the well-known name, if possible, should be 453 chosen so that it is unlikely to appear more than once within an IPv6 454 address and also as easy as possible to find from within the 455 synthetic IPv6 address. An address not listed in the Section 3 of 457 [RFC5735] is required as otherwise DNS64 entity may not perform AAAA 458 record synthesis. The address does not have to be routable or 459 allocated to any node, as no communications are initiated to the IPv4 460 address. 462 Allocating two IPv4 addresses would improve the heuristics in cases 463 where the primary IPv4 address' bit pattern appears more than once in 464 the synthetic IPv6 address (NSP prefix contains the same bit pattern 465 as the IPv4 address). 467 If no well-known IPv4 address is statically allocated for this 468 method, the heuristic requires sending additional A query to learn 469 the IPv4 address that is sought inside the received IPv6 address. 470 Without knowing IPv4 address it is impossible to determine address 471 format used by DNS64. 473 9. Acknowledgements 475 Authors would like to thank Andrew Sullivan, Washam Fan, Cameron 476 Byrne, Zhenqiang Li, Dave Thaler, Peter Koch, and Christian Huitema 477 for significant improvement ideas and comments. 479 10. References 481 10.1. Normative References 483 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 484 Requirement Levels", BCP 14, RFC 2119, March 1997. 486 [RFC5735] Cotton, M. and L. Vegoda, "Special Use IPv4 Addresses", 487 BCP 153, RFC 5735, January 2010. 489 [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 490 Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, 491 October 2010. 493 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 494 NAT64: Network Address and Protocol Translation from IPv6 495 Clients to IPv4 Servers", RFC 6146, April 2011. 497 [RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van 498 Beijnum, "DNS64: DNS Extensions for Network Address 499 Translation from IPv6 Clients to IPv4 Servers", RFC 6147, 500 April 2011. 502 10.2. Informative References 504 [RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for 505 IPv4/IPv6 Translation", RFC 6144, April 2011. 507 [RFC6418] Blanchet, M. and P. Seite, "Multiple Interfaces and 508 Provisioning Domains Problem Statement", RFC 6418, 509 November 2011. 511 Appendix A. Example of DNS Record Configuration 513 The following BIND-style examples illustrate how A and AAAA records 514 could be configured by NAT64 operator. 516 The examples use Pref64::/n of 2001:db8::/96 and example.com domain. 518 The PTR record for reverse queries (Section 3.1.1 bullet 3): 520 $ORIGIN 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. 521 @ IN SOA ns1.example.com. hostmaster.example.com. ( 522 2003080800 12h 15m 3w 2h) 523 IN NS ns.example.com. 525 IN PTR nat64.example.com. 527 If the example.com does not use DNSSEC, the following configuration 528 file could be used. Please note the nat64.example.com has both AAAA 529 record with the Pref64::/n and A record for the connectivity check 530 (Section 3.1.1 bullet 2). 532 example.com. IN SOA ns.example.com. hostmaster.example.com. ( 533 2002050501 ; serial 534 100 ; refresh (1 minute 40 seconds) 535 200 ; retry (3 minutes 20 seconds) 536 604800 ; expire (1 week) 537 100 ; minimum (1 minute 40 seconds) 538 ) 540 example.com. IN NS ns.example.com. 542 nat64.example.com. 543 IN AAAA 2001:db8:0:0:0:0:0 nat64.example.com. 544 IN A 192.0.2.1 546 If the example.com does use DNSSEC, the following configuration file 547 could be used for A and AAAA records: 549 example.com. IN SOA ns.example.com. hostmaster.example.com. ( 550 2002050501 ; serial 551 100 ; refresh (1 minute 40 seconds) 552 200 ; retry (3 minutes 20 seconds) 553 604800 ; expire (1 week) 554 100 ; minimum (1 minute 40 seconds) 555 ) 557 example.com. IN RRSIG SOA 5 2 100 20090803071330 ( 558 20090704071330 17000 example.com. 559 TVgWsNQvsFmeNHAeccGi7+UI7KwcE9TXPuSvmV9yyJwo 560 4FvHkxVC1H+98EtrmbR4c/XcdUzdfgn+q+lBqNsnbAit 561 xFERwPxzxbX0+yeCdHbBjHe7OuOc2Gc+CH6SbT2lKwVi 562 iEx3ySqqNoVScoUyhRdnPV2A1LV0yd9GtG9mI4w= ) 564 example.com. IN NS ns.example.com. 565 example.com. IN RRSIG NS 5 2 100 20090803071330 ( 566 20090704071330 17000 example.com. 567 Xuw7saDDi6+5Z7SmtC7FC2npPOiE8F9qMR87eA0egG0I 568 B+xFx7pIogoVIDpOd1h3jqYivhblpCoDSBQb2oMbVy3B 569 SX5cF0r7Iu/xKP8XrV4DjNiugpa+NnhEIaRqG5uoPFbX 570 4cYT51yNq70I5mJvvajJu7UjmdHl26ZlnK33xps= ) 572 nat64.example.com. 573 IN AAAA 2001:db8:0:0:0:0:0 nat64.example.com. 574 IN RRSIG SOA 5 2 100 20090803071330 ( 575 20090704071330 17000 example.net. 576 TVgWsNQvsFmeNHAeccGi7+UI7KwcE9TXPuSvmV9yyJwo 577 4FvHkxVC1H+98EtrmbR4c/XcdUzdfgn+q+lBqNsnbAit 578 xFERwPxzxbX0+yeCdHbBjHe7OuOc2Gc+CH6SbT2lKwVi 579 iEx3ySqqNoVScoUyhRdnPV2A1LV0yd9GtG9mI4w= ) 581 nat64.example.com. 582 IN A 192.0.2.1 584 Authors' Addresses 586 Teemu Savolainen 587 Nokia 588 Hermiankatu 12 D 589 FI-33720 Tampere 590 Finland 592 Email: teemu.savolainen@nokia.com 593 Jouni Korhonen 594 Nokia Siemens Networks 595 Linnoitustie 6 596 FI-02600 Espoo 597 Finland 599 Email: jouni.nospam@gmail.com 601 Dan Wing 602 Cisco Systems 603 170 West Tasman Drive 604 San Jose, California 95134 605 USA 607 Email: dwing@cisco.com