idnits 2.17.1 draft-ietf-behave-nat64-discovery-heuristic-08.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 (May 14, 2012) is 4363 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: November 15, 2012 Nokia Siemens Networks 6 D. Wing 7 Cisco Systems 8 May 14, 2012 10 Discovery of IPv6 Prefix Used for IPv6 Address Synthesis 11 draft-ietf-behave-nat64-discovery-heuristic-08.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 November 15, 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 . . . . . . . . . . . . . . . . . 9 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 . . . . . . . . . . . . . . . . . . . 9 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 . . . . . . . . . . . . . . . . . . 11 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 and if the A record even exists (see 153 also Section 6 Exit Strategy). The node may perform this check in 154 both IPv6-only and dual-stack access networks. 156 When sending AAAA query for the well-known name, a node MUST set 157 "Checking Disabled (CD)" bit to zero, as otherwise the DNS64 will not 158 perform IPv6 address synthesis and hence would not reveal the 159 Pref64::/n used for protocol translation. 161 A DNS reply with one or more non-empty AAAA records indicates that 162 the access network is utilizing IPv6 address synthesis. A node MUST 163 look through all of the received AAAA records to collect one or more 164 Pref64::/n. Pref64::/n list may include Well-Known Prefix 64: 165 ff9b::/96 [RFC6052] or one or more Network-Specific Prefixes. In the 166 case of NSPs the node SHALL search for the IPv4 address of the well- 167 known name inside of the received IPv6 addresses to determine the 168 used address format. 170 An IPv4 address of the well-known name should be found inside 171 synthetic IPv6 address at some of the locations described in 172 [RFC6052]. If the searched IPv4 address is not found on any of the 173 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. The node MAY also 208 continue monitoring for DNS replies with IPv6 addresses constructed 209 from WKP, in which case the node SHOULD use the WKP as if it were 210 learned during the query for the well-known name. 212 To save Internet's resources, if possible, a node should perform 213 Pref64::/n discovery only when needed (e.g. when local synthesis is 214 required, cached reply timeouts, new network interface is started, 215 and so forth). The node SHALL cache the replies it receives during 216 Pref64::/n discovery procedure and it SHALL repeat the discovery 217 process when one third of the Time-To-Live of the Well-Known Name's 218 synthetic AAAA DNS response is remaining. 220 3.1. Secure Learning of Pref64::/n 222 If a node is using insecure channel between itself and DNS64, or 223 DNS64 entity itself is untrusted, it is possible for an attacker to 224 influence node's Pref64::/n detection procedures. This may result in 225 denial-of-service, redirection, man-in-the-middle, or other attacks. 226 To protect against these attacks the node SHOULD communicate with 227 trusted DNS64 over secure channel or use DNSSEC. NAT64 operators 228 SHOULD provide facilities for secure learning of Pref64::/n: a secure 229 channel and/or DNSSEC protection. 231 3.1.1. DNSSEC Requirements for the Network 233 If the operator has chosen to support nodes performing Pref64::/n 234 learning securely with DNSSEC, the operator of the NAT64 device MUST 235 perform the following configurations. 237 1. Have one or more fully qualified domain names for the NAT64 238 translator entities (later referred as NAT64 FQDN). In the case 239 of more than one Pref64::/n being used in a network, e.g. for 240 load-balancing purposes, it is for network administrators to 241 decide whether a single NAT64's fully qualified domain name maps 242 to more than one Pref64::/n, or whether there will be dedicated 243 NAT64 FQDN per Pref64::/n. 245 2. Each NAT64 FQDN MUST have one or more DNS AAAA resource records 246 with each IPv6 address consisting of Pref64::/n and 0's for the 247 elements after the actual prefix. 249 3. Each Pref64::/n MUST HAVE PTR record that points to corresponding 250 NAT64 FQDN. 252 4. Sign the NAT64 FQDNs' AAAA and A records with DNSSEC. 254 3.1.2. Node Behavior 256 A node SHOULD prefer secure channel to talk to DNS64, whenever 257 possible. In addition, a node that implements DNSSEC validating 258 resolver MAY use the following procedure to secure discovery of the 259 Pref64::/n. 261 1. Heuristically find out a Pref64::/n candidate by making AAAA 262 query for the "ipv4only.arpa" by following the procedure in 263 Section 3. This will return one or more AAAA resource records. 264 For each of those AAAA resource records node wishes to use 265 securely, the node performs the following steps. 267 2. Send DNS PTR query for the IPv6 address of the translator (for 268 "ipv6.arpa"), using the Pref64::/n from the step 1 and zeroes for 269 the elements after the actual prefix length. This will return 270 the NAT64 FQDN. 272 3. The node SHOULD compare the domain of the NAT64 FQDN with node's 273 list of trusted domains. The means for node to learn the trusted 274 domains is implementation specific. If the node has no list of 275 trusted domains, the node MAY query user whether the domain can 276 be trusted. The node MAY remember the answer for future use. If 277 the node has no trust for the domain, the discovery procedure is 278 not secure and remaining steps described below are not needed. 280 4. Send DNS AAAA query for the NAT64 FQDN. 282 5. Verify the DNS AAAA response matches the address obtained in step 283 1. It is possible that the NAT64 FQDN maps to multiple AAAA 284 records, in which case the node has to check if any of the 285 responses matches to the address obtained in step 1. The node 286 must ignore other responses and not to use those for local IPv6 287 address synthesis. 289 6. Perform DNSSEC validation of the DNS AAAA response. 291 After the node has successfully performed the above five steps, the 292 node can consider Pref64::/n securely learned. 294 3.2. Connectivity Check 296 After learning Pref64::/n, the node SHOULD perform connectivity check 297 to ensure the learned Pref64::/n is functional. It could be non- 298 functional for a variety of reasons -- the discovery failed to work 299 as expected, the IPv6 path to the NAT64 is down, the NAT64 is down, 300 or the IPv4 path beyond the NAT64 is down. 302 There are two main approaches to determine if the learned Pref64::/n 303 is functional. The first approach is to perform a dedicated 304 connectivity check. The second approach is to simply attempt to use 305 the learned Pref64::/n. Each approach has some trade-offs (e.g., 306 additional network traffic or possible user-noticable delay), and 307 implementations should carefully weight which approach is appropriate 308 for their application and the network. 310 The node SHOULD use implementation specific connectivity check 311 server, but if that is not possible a node MAY do a PTR query of the 312 Pref64::/n that may return a hostname. The node then does an A query 313 of that hostname, which may return zero, one or more A resource 314 records pointing to connectivity check servers used by the network 315 operator. Negative response to PTR or A query means there are no 316 connectivity check servers available. The operator of a NAT64 entity 317 MAY assist nodes in their connectivity checks by mapping each NAT64 318 FQDN to one or more DNS A resource records with IPv4 address(es) 319 pointing to connectivity check server(s). 321 In case of one or more connectivity check servers being available for 322 use, the node chooses the first one preferring vendor specific 323 servers, if multiple are available. The node MAY perform separate 324 connectivity check by sending an ICMPv6 Echo Request to IPv6 address 325 synthesized by combining discovered Pref64::/n with an IPv4 address 326 of the server used for the connectivity check. This will test the 327 IPv6 path to the NAT64, the NAT64's operation, and the IPv4 path all 328 the way to the connectivity check server. Alternatively the node MAY 329 utilize implementation specific connectivity check protocol. If no 330 response is received for the ICMPv6 Echo Request, the node sends 331 another ICMPv6 Echo Request, a second later. If still no response is 332 received, it sends a third ICMPv6 Echo Request 3 seconds later. If 333 an ICMPv6 Echo Response is received, the node knows the IPv6 path to 334 the connectivity check server is functioning normally. If, after the 335 three transmissions of the ICMPv6 Echo Request, no response is 336 received, the node learns this Pref64::/n may not be functioning, and 337 the node MAY choose a different NAT64 (if a different NAT64 is 338 available), choose to alert the user, or proceed anyway hoping the 339 problem is temporal or only with the connectivity check itself. 341 If no separate connectivity check is performed before local IPv6 342 address synthesis, a node may monitor success of connection attempts 343 performed with locally synthetized IPv6 addresses. Based on success 344 of these connections, and based on possible ICMPv6 error messages 345 received (such as Destination Unreachable Message), the mode MAY 346 cease to perform local address synthesis and MAY restart Pref64::/n 347 discovery procedures. 349 3.2.1. No Connectivity Checks Against ipv4only.arpa 351 Clients MUST NOT send a connectivity check to the address returned in 352 the ipv4only.arpa query. This is because, by design, no server will 353 be operated on the Internet at that address as such. Similarly, 354 network operators MUST NOT operate a server on that address. The 355 reason this address isn't used for connectivity checks is that 356 operators who neglect to operate a connectivity check server will 357 allow that traffic towards the Internet where it will be dropped and 358 cause a false negative connectivity check with the client (that is, 359 the NAT64 is working fine, but the connectivity check fails because a 360 server is not operating at ipv4-only.arpa on the Internet and a 361 server is not operated by the NAT64 operator). Instead, for the 362 connectivity check, an additional DNS resource record is looked up 363 and used for the connectivity check. This ensures that packets don't 364 unnecessarily leak to the Internet and reduces the chance of a false 365 negative connectivity check. 367 3.3. Alternative Domain Names 369 Some applications, operating systems, devices, or networks may find 370 it advantageous to operate their own DNS infrastructure to perform a 371 function similar to ipv4-only.arpa, but using a different resource 372 record. The primary advantage is to ensure availability of the DNS 373 infrastructure and ensure the proper configuration of the DNS record 374 itself. DNS For example, a company named Example might have their 375 application query ipv4-only.example.com. Other than the different 376 DNS resource record being queried, the rest of the operations are 377 anticipated to be identical to the steps described in this document. 379 4. Operational Considerations for Hosting the IPv4-Only Well-Known Name 381 The authoritative name server for the well-known name shall have DNS 382 record Time-To-Live (TTL) set to a long value in order to improve 383 effectiveness of DNS caching. The exact TTL value depends on 384 availability time for the used public IPv4 address. 386 The domain serving the well-known name must be signed with DNSSEC. 387 See also Security Considerations section. 389 5. DNS(64) Entity Considerations 391 DNS(64) servers MUST NOT interfere or perform special procedures for 392 the queries related to the well-known name until the time has arrived 393 for the exit strategy to be defined and deployed. 395 6. Exit Strategy 397 A day will come when this tool is no longer needed. At that point 398 best suited techniques for implementing exit strategy will be 399 documented. 401 A node SHOULD implement configuration knob for disabling the 402 Pref64::/n discovery feature. 404 7. Security Considerations 406 The security considerations follow closely those of RFC6147 408 [RFC6147]. If an attacker manages to change the Pref64::/n node 409 discovers, the traffic generated by the node will be delivered to 410 altered destination. This can result in either a denial-of-service 411 (DoS) attack (if the resulting IPv6 addresses are not assigned to any 412 device), a flooding attack (if the resulting IPv6 addresses are 413 assigned to devices that do not wish to receive the traffic), or an 414 eavesdropping attack (in case the altered NSP is routed through the 415 attacker). 417 The zone serving the well-known name has to be protected with DNSSEC, 418 as otherwise it will be too attractive target for attackers who wish 419 to alter nodes' Pref64::/n discovery procedures. 421 A node SHOULD implement validating DNSSEC resolver for validating the 422 A response of the well-known name query. A node without validating 423 DNSSEC resolver SHOULD request validation to be performed by the used 424 recursive DNS server and use secure channel when communicating with 425 the DNS64. 427 For the secure Pref64::/n discovery the access network SHOULD sign 428 the NAT64 translator's fully qualified domain name. A node SHOULD 429 use the algorithm described in Section 3.1 in order to securely learn 430 the Pref64::/n. 432 Lastly, best mitigation action against Pref64::/n discovery attacks 433 is to add IPv6 support for nodes' destinations and hence reduce need 434 to perform local IPv6 address synthesis. 436 8. IANA Considerations 438 According to procedures described in RFC3172 this document requests 439 IANA and IAB to reserve a second level domain from the .ARPA zone for 440 the well-known domain name. The well-known domain name could be, for 441 example, "ipv4only.arpa". 443 The well-known name also needs to map to two different public IPv4 444 addresses. 446 8.1. About the IPv4 Address for the Well-Known Name 448 The IPv4 addresses for the well-known name must not be special use 449 IPv4 addresses as listed in the Section 3 of [RFC5735], as otherwise 450 DNS64 entities may not perform AAAA record synthesis. However, the 451 addresses do not have to be routable or allocated to any real node, 452 as no communications will be initiated to these IPv4 address. 454 Allocation of two IPv4 addresses improves the heuristics in cases 455 where the bit pattern of the primary IPv4 address appears more than 456 once in the synthetic IPv6 address (NSP prefix contains the same bit 457 pattern as the IPv4 address). 459 If no well-known IPv4 addresses were to be statically allocated for 460 this method, the heuristic would require sending of an additional A 461 query to learn the IPv4 addresses that would be sought inside the 462 received IPv6 address. 464 9. Acknowledgements 466 Authors would like to thank Cameron Byrne, Christian Huitema, Washam 467 Fan, Peter Koch, Stephan Lagerholm, Zhenqiang Li, Andrew Sullivan, 468 and Dave Thaler, for significant improvement ideas and comments. 470 10. References 472 10.1. Normative References 474 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 475 Requirement Levels", BCP 14, RFC 2119, March 1997. 477 [RFC5735] Cotton, M. and L. Vegoda, "Special Use IPv4 Addresses", 478 BCP 153, RFC 5735, January 2010. 480 [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 481 Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, 482 October 2010. 484 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 485 NAT64: Network Address and Protocol Translation from IPv6 486 Clients to IPv4 Servers", RFC 6146, April 2011. 488 [RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van 489 Beijnum, "DNS64: DNS Extensions for Network Address 490 Translation from IPv6 Clients to IPv4 Servers", RFC 6147, 491 April 2011. 493 10.2. Informative References 495 [RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for 496 IPv4/IPv6 Translation", RFC 6144, April 2011. 498 [RFC6418] Blanchet, M. and P. Seite, "Multiple Interfaces and 499 Provisioning Domains Problem Statement", RFC 6418, 500 November 2011. 502 Appendix A. Example of DNS Record Configuration 504 The following BIND-style examples illustrate how A and AAAA records 505 could be configured by NAT64 operator. 507 The examples use Pref64::/n of 2001:db8::/96 and example.com domain. 509 The PTR record for reverse queries (Section 3.1.1 bullet 3): 511 $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. 512 @ IN SOA ns1.example.com. hostmaster.example.com. ( 513 2003080800 12h 15m 3w 2h) 514 IN NS ns.example.com. 516 IN PTR nat64.example.com. 518 If the example.com does not use DNSSEC, the following configuration 519 file could be used. Please note the nat64.example.com has both AAAA 520 record with the Pref64::/n and A record for the connectivity check 521 (Section 3.1.1 bullet 2). 523 example.com. IN SOA ns.example.com. hostmaster.example.com. ( 524 2002050501 ; serial 525 100 ; refresh (1 minute 40 seconds) 526 200 ; retry (3 minutes 20 seconds) 527 604800 ; expire (1 week) 528 100 ; minimum (1 minute 40 seconds) 529 ) 531 example.com. IN NS ns.example.com. 533 nat64.example.com. 534 IN AAAA 2001:db8:0:0:0:0:0 nat64.example.com. 535 IN A 192.0.2.1 537 If the example.com does use DNSSEC, the following configuration file 538 could be used for A and AAAA records: 540 example.com. IN SOA ns.example.com. hostmaster.example.com. ( 541 2002050501 ; serial 542 100 ; refresh (1 minute 40 seconds) 543 200 ; retry (3 minutes 20 seconds) 544 604800 ; expire (1 week) 545 100 ; minimum (1 minute 40 seconds) 546 ) 548 example.com. IN RRSIG SOA 5 2 100 20090803071330 ( 549 20090704071330 17000 example.com. 550 TVgWsNQvsFmeNHAeccGi7+UI7KwcE9TXPuSvmV9yyJwo 551 4FvHkxVC1H+98EtrmbR4c/XcdUzdfgn+q+lBqNsnbAit 552 xFERwPxzxbX0+yeCdHbBjHe7OuOc2Gc+CH6SbT2lKwVi 553 iEx3ySqqNoVScoUyhRdnPV2A1LV0yd9GtG9mI4w= ) 555 example.com. IN NS ns.example.com. 556 example.com. IN RRSIG NS 5 2 100 20090803071330 ( 557 20090704071330 17000 example.com. 558 Xuw7saDDi6+5Z7SmtC7FC2npPOiE8F9qMR87eA0egG0I 559 B+xFx7pIogoVIDpOd1h3jqYivhblpCoDSBQb2oMbVy3B 560 SX5cF0r7Iu/xKP8XrV4DjNiugpa+NnhEIaRqG5uoPFbX 561 4cYT51yNq70I5mJvvajJu7UjmdHl26ZlnK33xps= ) 563 nat64.example.com. 564 IN AAAA 2001:db8:0:0:0:0:0 nat64.example.com. 565 IN RRSIG SOA 5 2 100 20090803071330 ( 566 20090704071330 17000 example.net. 567 TVgWsNQvsFmeNHAeccGi7+UI7KwcE9TXPuSvmV9yyJwo 568 4FvHkxVC1H+98EtrmbR4c/XcdUzdfgn+q+lBqNsnbAit 569 xFERwPxzxbX0+yeCdHbBjHe7OuOc2Gc+CH6SbT2lKwVi 570 iEx3ySqqNoVScoUyhRdnPV2A1LV0yd9GtG9mI4w= ) 572 nat64.example.com. 573 IN A 192.0.2.1 575 Authors' Addresses 577 Teemu Savolainen 578 Nokia 579 Hermiankatu 12 D 580 FI-33720 Tampere 581 Finland 583 Email: teemu.savolainen@nokia.com 584 Jouni Korhonen 585 Nokia Siemens Networks 586 Linnoitustie 6 587 FI-02600 Espoo 588 Finland 590 Email: jouni.nospam@gmail.com 592 Dan Wing 593 Cisco Systems 594 170 West Tasman Drive 595 San Jose, California 95134 596 USA 598 Email: dwing@cisco.com