idnits 2.17.1 draft-ietf-behave-nat64-discovery-heuristic-09.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 1 instance of lines with non-RFC6890-compliant IPv4 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 (May 24, 2012) is 4355 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 (~~), 2 warnings (==), 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 25, 2012 Nokia Siemens Networks 6 D. Wing 7 Cisco Systems 8 May 24, 2012 10 Discovery of IPv6 Prefix Used for IPv6 Address Synthesis 11 draft-ietf-behave-nat64-discovery-heuristic-09.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 25, 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 . . . . . . . . . . . . . . . . . . . 10 73 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 74 8.1. About the IPv4 Address for the Well-Known Name . . . . . . 11 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 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 addresses of the 167 well-known name inside of the received IPv6 addresses to determine 168 the used address format. 170 An IPv4 address of the well-known name should be found inside of a 171 synthetic IPv6 address at some of the locations described in 172 [RFC6052]. If the searched IPv4 addresses are not found on any of 173 the standard locations the network must be using different 174 formatting. Developers may over time learn on IPv6 translated 175 address formats that are extensions or alternatives to the standard 176 formats. Developers MAY at that point add additional steps to the 177 described discovery procedures. The additional steps are outside the 178 scope of 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 vendor specific connectivity check server and a 311 protocol of vendor's choice, but if that is not possible a node MAY 312 do a PTR query of the Pref64::/n that may return a hostname. The 313 node then does an A query of that hostname, which may return zero, 314 one or more A resource records pointing to connectivity check servers 315 used by the network operator. Negative response to PTR or A query 316 means there are no connectivity check servers available. A network 317 operator that provides NAT64 services for nodes with and without 318 vendor specific connectivity check servers SHOULD assist nodes in 319 their connectivity checks by mapping each NAT64 FQDN to one or more 320 DNS A resource records with IPv4 address(es) pointing to connectivity 321 check server(s). 323 In case of one or more connectivity check servers being available for 324 use, the node chooses the first one preferring vendor specific 325 servers, if multiple are available. 327 The connectivity check protocol used with vendor specific 328 connectivity check servers is implementation specific. 330 The connectivity check protocol used with connectivity check servers 331 pointed by NAT64 FQDN's A records is ICMPv6 [RFC4443]. The node 332 performing connectivity check against these servers SHALL send an 333 ICMPv6 Echo Request to an IPv6 address synthesized by combining 334 discovered Pref64::/n with an IPv4 address of the server. This will 335 test the IPv6 path to the NAT64, the NAT64's operation, and the IPv4 336 path all the way to the connectivity check server. If no response is 337 received for the ICMPv6 Echo Request, the node SHALL send another 338 ICMPv6 Echo Request, a second later. If still no response is 339 received, the node SHALL send a third ICMPv6 Echo Request 3 seconds 340 later. If an ICMPv6 Echo Response is received, the node knows the 341 IPv6 path to the connectivity check server is functioning normally. 342 If, after the three transmissions of the ICMPv6 Echo Request, no 343 response is received, the node learns this Pref64::/n may not be 344 functioning, and the node MAY choose a different NAT64 (if a 345 different NAT64 is available), choose to alert the user, or proceed 346 anyway hoping the problem is temporal or only with the connectivity 347 check itself. 349 If no separate connectivity check is performed before local IPv6 350 address synthesis, a node may monitor success of connection attempts 351 performed with locally synthesized IPv6 addresses. Based on success 352 of these connections, and based on possible ICMPv6 error messages 353 received (such as Destination Unreachable Message), the mode MAY 354 cease to perform local address synthesis and MAY restart Pref64::/n 355 discovery procedures. 357 3.2.1. No Connectivity Checks Against ipv4only.arpa 359 Clients MUST NOT send a connectivity check to the address returned in 360 the ipv4only.arpa query. This is because, by design, no server will 361 be operated on the Internet at that address as such. Similarly, 362 network operators MUST NOT operate a server on that address. The 363 reason this address isn't used for connectivity checks is that 364 operators who neglect to operate a connectivity check server will 365 allow that traffic towards the Internet where it will be dropped and 366 cause a false negative connectivity check with the client (that is, 367 the NAT64 is working fine, but the connectivity check fails because a 368 server is not operating at ipv4-only.arpa on the Internet and a 369 server is not operated by the NAT64 operator). Instead, for the 370 connectivity check, an additional DNS resource record is looked up 371 and used for the connectivity check. This ensures that packets don't 372 unnecessarily leak to the Internet and reduces the chance of a false 373 negative connectivity check. 375 3.3. Alternative Domain Names 377 Some applications, operating systems, devices, or networks may find 378 it advantageous to operate their own DNS infrastructure to perform a 379 function similar to ipv4-only.arpa, but using a different resource 380 record. The primary advantage is to ensure availability of the DNS 381 infrastructure and ensure the proper configuration of the DNS record 382 itself. DNS For example, a company named Example might have their 383 application query ipv4-only.example.com. Other than the different 384 DNS resource record being queried, the rest of the operations are 385 anticipated to be identical to the steps described in this document. 387 4. Operational Considerations for Hosting the IPv4-Only Well-Known Name 389 The authoritative name server for the well-known name shall have DNS 390 record Time-To-Live (TTL) set to a long value in order to improve 391 effectiveness of DNS caching. The exact TTL value depends on 392 availability time for the used public IPv4 address. 394 The domain serving the well-known name must be signed with DNSSEC. 395 See also Security Considerations section. 397 5. DNS(64) Entity Considerations 399 DNS(64) servers MUST NOT interfere or perform special procedures for 400 the queries related to the well-known name until the time has arrived 401 for the exit strategy to be defined and deployed. 403 6. Exit Strategy 405 A day will come when this tool is no longer needed. At that point 406 best suited techniques for implementing exit strategy will be 407 documented. 409 A node SHOULD implement configuration knob for disabling the 410 Pref64::/n discovery feature. 412 7. Security Considerations 414 The security considerations follow closely those of RFC6147 415 [RFC6147]. If an attacker manages to change the Pref64::/n node 416 discovers, the traffic generated by the node will be delivered to 417 altered destination. This can result in either a denial-of-service 418 (DoS) attack (if the resulting IPv6 addresses are not assigned to any 419 device), a flooding attack (if the resulting IPv6 addresses are 420 assigned to devices that do not wish to receive the traffic), or an 421 eavesdropping attack (in case the altered NSP is routed through the 422 attacker). 424 The zone serving the well-known name has to be protected with DNSSEC, 425 as otherwise it will be too attractive target for attackers who wish 426 to alter nodes' Pref64::/n discovery procedures. 428 A node SHOULD implement validating DNSSEC resolver for validating the 429 A response of the well-known name query. A node without validating 430 DNSSEC resolver SHOULD request validation to be performed by the used 431 recursive DNS server and use secure channel when communicating with 432 the DNS64. 434 For the secure Pref64::/n discovery the access network SHOULD sign 435 the NAT64 translator's fully qualified domain name. A node SHOULD 436 use the algorithm described in Section 3.1 in order to securely learn 437 the Pref64::/n. 439 Lastly, best mitigation action against Pref64::/n discovery attacks 440 is to add IPv6 support for nodes' destinations and hence reduce need 441 to perform local IPv6 address synthesis. 443 8. IANA Considerations 445 According to procedures described in RFC3172 this document requests 446 IANA and IAB to reserve a second level domain from the .ARPA zone for 447 the well-known domain name. The well-known domain name could be, for 448 example, "ipv4only.arpa". 450 The well-known name needs to map to at least two different global 451 IPv4 addresses. The addresses are to be taken from 192.0.0.0/24 452 address block. The addresses are documented to be of global scope, 453 but they do not need to be routable in local or global scopes. 455 8.1. About the IPv4 Address for the Well-Known Name 457 The IPv4 addresses for the well-known name must not be non-global 458 IPv4 addresses as listed in the Section 3 of [RFC5735]. Otherwise 459 DNS64 entities may not perform AAAA record synthesis when well-known 460 prefix is used, as stated in Section 3.1 of [RFC6052]. However, the 461 addresses do not have to be routable or allocated to any real node, 462 as no communications will be initiated to these IPv4 address. 464 Allocation of at least two IPv4 addresses improves the heuristics in 465 cases where the bit pattern of the primary IPv4 address appears more 466 than once in the synthetic IPv6 address (NSP prefix contains the same 467 bit pattern as the IPv4 address). 469 If no well-known IPv4 addresses would be statically allocated for 470 this method, the heuristic would require sending of an additional A 471 query to learn the IPv4 addresses that would be then searched from 472 inside of the received IPv6 address. 474 9. Acknowledgements 476 Authors would like to thank Cameron Byrne, Christian Huitema, Washam 477 Fan, Peter Koch, Stephan Lagerholm, Zhenqiang Li, Andrew Sullivan, 478 and Dave Thaler, for significant improvement ideas and comments. 480 10. References 482 10.1. Normative References 484 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 485 Requirement Levels", BCP 14, RFC 2119, March 1997. 487 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 488 Message Protocol (ICMPv6) for the Internet Protocol 489 Version 6 (IPv6) Specification", RFC 4443, March 2006. 491 [RFC5735] Cotton, M. and L. Vegoda, "Special Use IPv4 Addresses", 492 BCP 153, RFC 5735, January 2010. 494 [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 495 Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, 496 October 2010. 498 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 499 NAT64: Network Address and Protocol Translation from IPv6 500 Clients to IPv4 Servers", RFC 6146, April 2011. 502 [RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van 503 Beijnum, "DNS64: DNS Extensions for Network Address 504 Translation from IPv6 Clients to IPv4 Servers", RFC 6147, 505 April 2011. 507 10.2. Informative References 509 [RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for 510 IPv4/IPv6 Translation", RFC 6144, April 2011. 512 [RFC6418] Blanchet, M. and P. Seite, "Multiple Interfaces and 513 Provisioning Domains Problem Statement", RFC 6418, 514 November 2011. 516 Appendix A. Example of DNS Record Configuration 518 The following BIND-style examples illustrate how A and AAAA records 519 could be configured by NAT64 operator. 521 The examples use Pref64::/n of 2001:db8::/96 and example.com domain. 523 The PTR record for reverse queries (Section 3.1.1 bullet 3): 525 $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. 526 @ IN SOA ns1.example.com. hostmaster.example.com. ( 527 2003080800 12h 15m 3w 2h) 528 IN NS ns.example.com. 530 IN PTR nat64.example.com. 532 If the example.com does not use DNSSEC, the following configuration 533 file could be used. Please note the nat64.example.com has both AAAA 534 record with the Pref64::/n and A record for the connectivity check 535 (Section 3.1.1 bullet 2). 537 example.com. IN SOA ns.example.com. hostmaster.example.com. ( 538 2002050501 ; serial 539 100 ; refresh (1 minute 40 seconds) 540 200 ; retry (3 minutes 20 seconds) 541 604800 ; expire (1 week) 542 100 ; minimum (1 minute 40 seconds) 543 ) 545 example.com. IN NS ns.example.com. 547 nat64.example.com. 548 IN AAAA 2001:db8:0:0:0:0:0 nat64.example.com. 550 IN A 192.0.2.1 552 If the example.com does use DNSSEC, the following configuration file 553 could be used for A and AAAA records: 555 example.com. IN SOA ns.example.com. hostmaster.example.com. ( 556 2002050501 ; serial 557 100 ; refresh (1 minute 40 seconds) 558 200 ; retry (3 minutes 20 seconds) 559 604800 ; expire (1 week) 560 100 ; minimum (1 minute 40 seconds) 561 ) 563 example.com. IN RRSIG SOA 5 2 100 20090803071330 ( 564 20090704071330 17000 example.com. 565 TVgWsNQvsFmeNHAeccGi7+UI7KwcE9TXPuSvmV9yyJwo 566 4FvHkxVC1H+98EtrmbR4c/XcdUzdfgn+q+lBqNsnbAit 567 xFERwPxzxbX0+yeCdHbBjHe7OuOc2Gc+CH6SbT2lKwVi 568 iEx3ySqqNoVScoUyhRdnPV2A1LV0yd9GtG9mI4w= ) 570 example.com. IN NS ns.example.com. 571 example.com. IN RRSIG NS 5 2 100 20090803071330 ( 572 20090704071330 17000 example.com. 573 Xuw7saDDi6+5Z7SmtC7FC2npPOiE8F9qMR87eA0egG0I 574 B+xFx7pIogoVIDpOd1h3jqYivhblpCoDSBQb2oMbVy3B 575 SX5cF0r7Iu/xKP8XrV4DjNiugpa+NnhEIaRqG5uoPFbX 576 4cYT51yNq70I5mJvvajJu7UjmdHl26ZlnK33xps= ) 578 nat64.example.com. 579 IN AAAA 2001:db8:0:0:0:0:0 nat64.example.com. 580 IN RRSIG SOA 5 2 100 20090803071330 ( 581 20090704071330 17000 example.net. 582 TVgWsNQvsFmeNHAeccGi7+UI7KwcE9TXPuSvmV9yyJwo 583 4FvHkxVC1H+98EtrmbR4c/XcdUzdfgn+q+lBqNsnbAit 584 xFERwPxzxbX0+yeCdHbBjHe7OuOc2Gc+CH6SbT2lKwVi 585 iEx3ySqqNoVScoUyhRdnPV2A1LV0yd9GtG9mI4w= ) 587 nat64.example.com. 588 IN A 192.0.2.1 590 Authors' Addresses 592 Teemu Savolainen 593 Nokia 594 Hermiankatu 12 D 595 FI-33720 Tampere 596 Finland 598 Email: teemu.savolainen@nokia.com 600 Jouni Korhonen 601 Nokia Siemens Networks 602 Linnoitustie 6 603 FI-02600 Espoo 604 Finland 606 Email: jouni.nospam@gmail.com 608 Dan Wing 609 Cisco Systems 610 170 West Tasman Drive 611 San Jose, California 95134 612 USA 614 Email: dwing@cisco.com