idnits 2.17.1 draft-ietf-behave-nat64-discovery-heuristic-05.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 (January 25, 2012) is 4465 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: July 28, 2012 Nokia Siemens Networks 6 D. Wing 7 Cisco Systems 8 January 25, 2012 10 Discovery of a Network-Specific NAT64 Prefix using a Well-Known Name 11 draft-ietf-behave-nat64-discovery-heuristic-05.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 without explicit support from the access network. The method 18 depends on existence of a well-known IPv4-only domain name 19 "ipv4only.arpa". The information learned enables applications and 20 hosts to perform local IPv6 address synthesis and on dual-stack 21 accesses avoid traversal through NAT64. 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 July 28, 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 . . . . . . . . . . . . . . . . . . . . . . . 3 60 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 61 3. Host behavior . . . . . . . . . . . . . . . . . . . . . . . . 4 62 3.1. Learning NAT64 prefix securely by using DNSSEC . . . . . . 5 63 3.1.1. Requirements for the network . . . . . . . . . . . . . 6 64 3.1.2. Host 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 . . . . . . . . . . . . . . . . . . . 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. Normative References . . . . . . . . . . . . . . . . . . . . . 11 77 Appendix A. Example of DNS record configuration . . . . . . . . . 11 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 80 1. Introduction 82 As part of the transition to IPv6 NAT64 [RFC6146] and DNS64 [RFC6147] 83 technologies will be utilized by some access networks to provide IPv4 84 connectivity for IPv6-only hosts. The DNS64 utilizes IPv6 address 85 synthesis to create local IPv6 presentations of peers having only 86 IPv4 addresses, hence allowing DNS-using IPv6-only hosts to 87 communicate with IPv4-only peers. 89 However, DNS64 cannot serve applications not using DNS, such as those 90 receiving IPv4 address literals as referrals. Such applications 91 could nevertheless be able to work through NAT64, provided they are 92 able to create locally valid IPv6 presentations of peers' IPv4 93 addresses. 95 Additionally, DNS64 is not able to do IPv6 address synthesis for 96 hosts running validating DNSSEC enabled resolvers, but instead the 97 synthesis must be done by the hosts themselves. In order to perform 98 IPv6 synthesis hosts have to learn the IPv6 prefix(es) used on the 99 access network for protocol translation. 101 This document describes a best effort method for applications and 102 hosts to learn the information required to perform local IPv6 address 103 synthesis. An example application is a browser encountering IPv4 104 address literals in an IPv6-only access network. Another example is 105 a host running validating security aware DNS resolver in an IPv6-only 106 access network. 108 The knowledge of IPv6 address synthesis taking place may also be 109 useful if DNS64 and NAT64 are present in dual-stack enabled access 110 networks. In such cases hosts may choose to prefer IPv4 in order to 111 avoid traversal through protocol translators. 113 It is important to notice that use of this approach will not result 114 in as robust and good behaving system as an all-IPv6 system would be. 115 Hence it is highly RECOMMENDED to upgrade to IPv6 and utilize the 116 described method only as a short-term solution. 118 2. Requirements and Terminology 120 2.1. Requirements 122 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 123 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 124 document are to be interpreted as described in [RFC2119]. 126 2.2. Terminology 128 Well-Known IPv4-only Name (WKN): a fully qualified domain name, 129 "ipv4only.arpa", well-known to have only A record. 131 Well-Known IPv4 Address: an IPv4 address that is well-known and 132 mapped to the well-known name. 134 3. Host behavior 136 A host requiring information about presence of NAT64 and the IPv6 137 prefix used for protocol translation SHALL send a DNS query for AAAA 138 records of a well-known IPv4-only fully qualified domain name: 139 "ipv4only.arpa". The host MAY also need to perform DNS query for the 140 A record of the well-known name in order to learn what is the IPv4 141 address of the well-known name. The host may perform this check in 142 both IPv6-only and dual-stack access networks. 144 When sending AAAA query for the well-known name a host MUST set 145 "Checking Disabled (CD)" bit to zero, as otherwise the DNS64 will not 146 perform IPv6 address synthesis hence does not reveal the IPv6 147 prefix(es) used for protocol translation. 149 A DNS reply with one or more non-empty AAAA records indicates that 150 the access network is utilizing IPv6 address synthesis. A host MUST 151 look through all of the received AAAA records to collect all 152 available prefixes. The prefixes may include Well-Known Prefix 64: 153 ff9b::/96 [RFC6052] or one or more Network-Specific Prefixes. In the 154 case of NSPs the host SHALL search for the IPv4 address of the well- 155 known name inside of the received IPv6 addresses to determine the 156 used address format. 158 An IPv4 address of the well-known name should be found inside 159 synthetic IPv6 address at some of the locations described in 160 [RFC6052]. If the searched IPv4 address is not found on any of the 161 standard locations the network must be using different formatting. 162 Developers may over time learn on IPv6 translated address formats 163 that are extensions or alternatives to the standard formats. 164 Developers MAY at that point add additional steps to the described 165 discovery procedures. The additional steps are outside the scope of 166 the present document. 168 The host should ensure a 32-bit IPv4 address value is present only 169 once in an IPv6 address. In case another instance of the value is 170 found inside the IPv6, the host shall repeat the search with another 171 IPv4 address, if possible. 173 In the case only one IPv6 prefix was present in the DNS response: a 174 host shall use that IPv6 prefix for both local synthesis and for 175 detecting synthesis done by the DNS64 entity on the network. 177 In the case multiple IPv6 prefixes were present in the DNS response: 178 a host SHOULD use all received prefixes when determining whether 179 other received IPv6 addresses are synthetic. However, for selecting 180 prefix for the local IPv6 address synthesis host MUST use the 181 following prioritization order, of which purpose is to avoid use of 182 prefixes containing suffixes reserved for the future [RFC6052]: 184 1. Use NSP having /96 prefix 186 2. Use WKP prefix 188 3. Use longest available NSP prefix 190 In the case of NXDOMAIN response or an empty AAAA reply: the DNS64 is 191 not available on the access network, network filtered the well-known 192 query on purpose, or something went wrong in the DNS resolution. All 193 unsuccessful cases result in unavailability of a host to perform 194 local IPv6 address synthesis. The host MAY periodically resend AAAA 195 query to check if DNS64 has become available or possibly temporary 196 problem cleared. The host MAY perform A query for the well-known 197 name to learn whether the NAT64 prefix discovery framework is 198 available at all (see section 6 about Exit Strategy). The host MAY 199 also continue monitoring DNS replies with IPv6 addresses constructed 200 from WKP, in which case the host MAY use the WKP as if it were 201 learned during the query for well-known name. 203 To save Internet's resources, if possible, a host should perform 204 NAT64 discovery only when needed (e.g. when local synthesis is 205 required, cached reply timeouts, new network interface is started, 206 and so forth. Furthermore, the host SHOULD cache the replies it 207 receives and honor TTLs. 209 3.1. Learning NAT64 prefix securely by using DNSSEC 211 If a node is using untrusted channel between itself and DNS64, or 212 DNS64 entity itself is untrusted, it is possible for an attacker to 213 influence node's NAT64 prefix detection procedures. This may result 214 in denial-of-service, redirection, man-in-the-middle, or other 215 attacks. To protect against these attacks the node may use DNSSEC, 216 or communicate with trusted DNS64 over trusted channel. 217 Significantly, DNSSEC must be configured by the NAT64 operator for 218 the DNSSEC approach to work. 220 3.1.1. Requirements for the network 222 To support DNSSEC capable nodes to perform NAT64 prefix learning 223 securely, the operator of the NAT64 device MUST perform the following 224 configurations. In the case of multiple IPv6 prefixes being used in 225 a network, e.g. for load-balancing purposes, it is for network 226 administrators to decide whether a single NAT64's fully qualified 227 domain name maps to multiple prefixes, or whether there will be 228 dedicated FQDN per IPv6 prefix. 230 1. Have one or more fully qualified domain names for the NAT64 231 translators (NAT64 FQDN). 233 2. Each NAT64 FQDN MUST have one or more DNS AAAA resource records 234 with each IPv6 address consisting of NAT64 prefix and 0's for the 235 elements after the actual NAT64 prefix. Also, for the 236 connectivity test each NAT64 FQDN MUST have one or more DNS A 237 resource records with IPv4 address(es) of NAT64 Internet facing 238 interfaces. 240 3. Each NAT64 prefix MUST HAVE PTR record that points to 241 corresponding NAT64 FQDN. 243 4. Sign the NAT64 FQDNs' AAAA and A records with DNSSEC. 245 5. Have access network's authoritative nameservers to respond to DNS 246 queries for the NAT64 FQDNs only when the queries have been 247 originated from the network domain the NAT64 is serving. If the 248 NAT64's AAAA records are made resolvable throughout the Internet, 249 a possible misuse vector of the NAT64 prefixes and NAT64 FQDNs in 250 other networks is enabled: an attacker in other access network 251 may lure a host on that network to think it is configuring NAT64 252 prefix in secure manner, while in reality it is not as the node 253 would be configuring NAT64 prefix in a network where the NAT64 254 prefix should not be used. 256 3.1.2. Host behavior 258 A DNSSEC capable node MUST use the following procedure to confirm the 259 learned NAT64 prefix is legitimate: 261 1. Heuristically find out a NAT64 prefix 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 host wishes to use 265 securely, the host performs the following steps. 267 2. Send DNS PTR query for the IPv6 address of the translator (for 268 "ipv6.arpa"), using the prefix from the step 1 and 0 for the 269 elements after the prefix length. This will return the NAT64 270 FQDN. 272 3. Send DNS AAAA query for the NAT64 FQDN. 274 4. Verify the DNS AAAA response matches the address obtained in step 275 1. It is possible that the NAT64 FQDN maps to multiple AAAA 276 records, in which case the node has to check if any of the 277 responses matches to the address obtained in step 1. The node 278 must ignore other responses and not to use those for local IPv6 279 address synthesis. 281 5. Perform DNSSEC validation of the DNS AAAA response. 283 After the node has successfully performed the above five steps, the 284 node can consider NAT64 prefix securely learned. 286 3.2. Connectivity check 288 After learning a NAT64 prefix, it can be useful to determine if that 289 learned prefix is functional. It could be non-functional for a 290 variety of reasons -- the heuristic failed to work as expected, the 291 IPv6 path to the NAT64 is down, the NAT64 is down, or the IPv4 path 292 beyond the NAT64 is down. 294 There are two general approaches to determine if the learned prefix 295 is functional. The first approach is to perform a separate 296 connectivity check. The second approach is to attempt to use the 297 learned prefix for normal traffic. Each approach has some trade-offs 298 (e.g., additional network traffic or possible user-noticable delay), 299 and implementations should carefully weigh which approach is 300 appropriate for their application and the network. 302 The host MAY perform separate connectivity check by sending an ICMPv6 303 Echo Request to IPv6 address synthesized by combining discovered 304 NAT64 prefix with an IPv4 address of the server used for the 305 connectivity check. This will test the IPv6 path to the NAT64 and 306 the NAT64's operation. It will not test the IPv4 path beyond the 307 NAT64. 309 To perform connectivity check, the host does a PTR query of the 310 NAT64's IPv6 prefix which returns a hostname. The host then does an 311 A query of that hostname, which returns one or more A resource 312 records, which are the IPv4-facing IP addresses of that NAT64. The 313 host chooses the first one of these addresses and sends an ICMPv6 314 Echo Request to that address. If no response is received, the host 315 sends another ICMPv6 Echo Request, a second later. If still no 316 response is received, it sends a third ICMPv6 Echo Request 3 seconds 317 later. As the NAT64 will respond to ICMP Echo Requests sent to any 318 of its IPv4 addresses, there is no purpose in attempting to send ICMP 319 Echo Requests to the other IPv4 addresses. If an ICMPv6 Echo 320 Response is received, the host knows the IPv6 path to the NAT64 and 321 the NAT64 is functioning normally. If, after the three transmissions 322 of the ICMPv6 Echo Request, no response is received, the host knows 323 this NAT64 prefix is not functioning, and MAY choose a different 324 NAT64 (if a different NAT64 is available) or choose to alert the 325 user. 327 Alternatively, or additionally, the host MAY use implementation 328 specific server other than the NAT64 for the connectivity check. 329 This implementation specific server can be used as fallback server if 330 the NAT64 does not respond or does not have A record. 332 To help hosts' connectivity checks NAT64 operators are RECOMMENDED to 333 maintain DNS AAAA and A records for the NAT64 FQDN as is described in 334 Section 3.1.1 step 1, independently of possible DNSSEC support. 336 3.2.1. No connectivity checks against ipv4only.arpa 338 Clients MUST NOT send a connectivity check to the address returned in 339 the ipv4only.arpa query. This is because, by design, no server will 340 be operated on the Internet at that address as such. Similarly, 341 network operators MUST NOT operate a server on that address. The 342 reason this address isn't used for connectivity checks is that 343 operators who neglect to operate a connectivity check server will 344 allow that traffic towards the Internet where it will be dropped and 345 cause a false negative connectivity check with the client (that is, 346 the NAT64 is working fine, but the connectivity check fails because a 347 server is not operating at ipv4-only.arpa on the Internet and a 348 server is not operated by the NAT64 operator). Instead, for the 349 connectivity check, an additional DNS resource record is looked up 350 (specifically, the A record associated with the NAT64's hostname) and 351 used for the connectivity check. This ensures that packets don't 352 unnecessarily leak to the Internet and reduces the chance of a false 353 negative connectivity check. 355 3.3. Alternative domain names 357 Some applications, operating systems, devices, or networks may find 358 it advantageous to operate their own DNS infrastructure to perform a 359 function similar to ipv4-only.arpa, but using a different resource 360 record. The primary advantage is to ensure availability of the DNS 361 infrastructure and ensure the proper configuration of the DNS record 362 itself. DNS For example, a company named Example might have their 363 application query ipv4-only.example.com. Other than the different 364 DNS resource record being queried, the rest of the operations are 365 anticipated to be identical to the steps described in this document. 367 4. Operational considerations for hosting the IPv4-only well-known name 369 The authoritative name server for the well-known name shall have DNS 370 record TTL set to a long value in order to improve effectiveness of 371 DNS caching and robustness of the discovery procedure in general. 372 The exact value depends on availability time for the used public IPv4 373 address, but should not be longer than one year. 375 The domain serving the well-known name must be signed with DNSSEC. 376 See also Security Considerations section. 378 It is expected that volumes for well-known name related queries are 379 roughly SOMETHING, TBD. The infrastructure required to serve well- 380 known name is SOMETHING, TBD. 382 5. DNS(64) entity considerations 384 DNS(64) servers MUST NOT interfere or perform special procedures for 385 the queries related to the well-known name until the time has arrived 386 for the exit strategy to be deployed. 388 6. Exit strategy 390 A day will come when this tool is no longer needed. At that point 391 best suited techniques for implementing exit strategy will be 392 documented. In the global scope the exit strategy may include 393 sending NXDOMAIN replies by the authoritative name server of the 394 well-known name with a very long TTL. 396 A client implementation receiving NXDOMAIN response for the A query 397 of the well-known name means SHOULD consider this tool as temporarily 398 disabled. 400 7. Security Considerations 402 The security considerations follow closely those of RFC6147 403 [RFC6147]. If an attacker manages to change the NAT64 prefix host 404 discovers, the traffic generated by the host will be delivered to 405 altered destination. This can result in either a denial-of-service 406 (DoS) attack (if the resulting IPv6 addresses are not assigned to any 407 device), a flooding attack (if the resulting IPv6 addresses are 408 assigned to devices that do not wish to receive the traffic), or an 409 eavesdropping attack (in case the altered NSP is routed through the 410 attacker). 412 The zone serving the well-known name has to be protected with DNSSEC, 413 as otherwise it will be too attractive target for attackers who wish 414 to alter hosts' NSP prefix discovery procedures. 416 A host SHOULD implement validating DNSSEC resolver for validating the 417 A response of the well-known name query. A host without validating 418 DNSSEC resolver SHOULD request validation to be performed by the used 419 recursive DNS server. 421 For the secure NAT64 prefix discovery the access network SHOULD sign 422 the NAT64 translator's fully qualified domain name, and make that DNS 423 resolvable only from the network domain NAT64 is serving. Otherwise 424 the NAT64 prefix may be used for attacks in other access networks. A 425 host SHOULD use the algorithm described in Section 3.1 in order to 426 securely learn the NAT64 prefix. 428 8. IANA Considerations 430 According to procedures described in RFC3172 this document requests 431 IANA and IAB to reserve a second level domain from the .ARPA zone for 432 the well-known domain name. The well-known domain name could be, for 433 example, "ipv4only.arpa". 435 The well-known name also needs to map to one but preferably to two 436 different public IPv4 addresses. 438 8.1. About the IPv4 address for the well-known name 440 The IPv4 address for the well-known name, if possible, should be 441 chosen so that it is unlikely to appear more than once within an IPv6 442 address and also as easy as possible to find from within the 443 synthetic IPv6 address. An address not listed in the Section 3 of 444 [RFC5735] is required as otherwise DNS64 entity may not perform AAAA 445 record synthesis. The address does not have to be routable or 446 allocated to any node, as no communications are initiated to the IPv4 447 address. 449 Allocating two IPv4 addresses would improve the heuristics in cases 450 where the primary IPv4 address' bit pattern appears more than once in 451 the synthetic IPv6 address (NSP prefix contains the same bit pattern 452 as the IPv4 address). 454 If no well-known IPv4 address is statically allocated for this 455 method, the heuristic requires sending additional A query to learn 456 the IPv4 address that is sought inside the received IPv6 address. 457 Without knowing IPv4 address it is impossible to determine address 458 format used by DNS64. 460 9. Acknowledgements 462 Authors would like to thank Andrew Sullivan, Washam Fan, Cameron 463 Byrne, Zhenqiang Li, Dave Thaler, Peter Koch, and Christian Huitema 464 for significant improvement ideas and comments. 466 10. Normative References 468 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 469 Requirement Levels", BCP 14, RFC 2119, March 1997. 471 [RFC5735] Cotton, M. and L. Vegoda, "Special Use IPv4 Addresses", 472 BCP 153, RFC 5735, January 2010. 474 [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 475 Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, 476 October 2010. 478 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 479 NAT64: Network Address and Protocol Translation from IPv6 480 Clients to IPv4 Servers", RFC 6146, April 2011. 482 [RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van 483 Beijnum, "DNS64: DNS Extensions for Network Address 484 Translation from IPv6 Clients to IPv4 Servers", RFC 6147, 485 April 2011. 487 Appendix A. Example of DNS record configuration 489 The following BIND-style examples illustrate how A and AAAA records 490 could be configured by NAT64 operator. 492 The examples use NAT64 prefix of 2001:db8::/96 and example.com 493 domain. 495 The PTR record for reverse queries (Section 3.1.1 bullet 3): 497 $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. 498 @ IN SOA ns1.example.com. hostmaster.example.com. ( 499 2003080800 12h 15m 3w 2h) 500 IN NS ns.example.com. 502 IN PTR nat64.example.com. 504 If the example.com does not use DNSSEC, the following configuration 505 file could be used. Please note the nat64.example.com has both AAAA 506 record with the NAT64 prefix and A record for the connectivity check 507 (Section 3.1.1 bullet 2). 509 example.com. IN SOA ns.example.com. hostmaster.example.com. ( 510 2002050501 ; serial 511 100 ; refresh (1 minute 40 seconds) 512 200 ; retry (3 minutes 20 seconds) 513 604800 ; expire (1 week) 514 100 ; minimum (1 minute 40 seconds) 515 ) 517 example.com. IN NS ns.example.com. 519 nat64.example.com. 520 IN AAAA 2001:db8:0:0:0:0:0 nat64.example.com. 521 IN A 192.0.2.1 523 If the example.com does use DNSSEC, the following configuration file 524 could be used for A and AAAA records: 526 example.com. IN SOA ns.example.com. hostmaster.example.com. ( 527 2002050501 ; serial 528 100 ; refresh (1 minute 40 seconds) 529 200 ; retry (3 minutes 20 seconds) 530 604800 ; expire (1 week) 531 100 ; minimum (1 minute 40 seconds) 532 ) 534 example.com. IN RRSIG SOA 5 2 100 20090803071330 ( 535 20090704071330 17000 example.com. 536 TVgWsNQvsFmeNHAeccGi7+UI7KwcE9TXPuSvmV9yyJwo 537 4FvHkxVC1H+98EtrmbR4c/XcdUzdfgn+q+lBqNsnbAit 538 xFERwPxzxbX0+yeCdHbBjHe7OuOc2Gc+CH6SbT2lKwVi 539 iEx3ySqqNoVScoUyhRdnPV2A1LV0yd9GtG9mI4w= ) 541 example.com. IN NS ns.example.com. 542 example.com. IN RRSIG NS 5 2 100 20090803071330 ( 543 20090704071330 17000 example.com. 544 Xuw7saDDi6+5Z7SmtC7FC2npPOiE8F9qMR87eA0egG0I 545 B+xFx7pIogoVIDpOd1h3jqYivhblpCoDSBQb2oMbVy3B 546 SX5cF0r7Iu/xKP8XrV4DjNiugpa+NnhEIaRqG5uoPFbX 547 4cYT51yNq70I5mJvvajJu7UjmdHl26ZlnK33xps= ) 549 nat64.example.com. 550 IN AAAA 2001:db8:0:0:0:0:0 nat64.example.com. 551 IN RRSIG SOA 5 2 100 20090803071330 ( 552 20090704071330 17000 example.net. 553 TVgWsNQvsFmeNHAeccGi7+UI7KwcE9TXPuSvmV9yyJwo 554 4FvHkxVC1H+98EtrmbR4c/XcdUzdfgn+q+lBqNsnbAit 555 xFERwPxzxbX0+yeCdHbBjHe7OuOc2Gc+CH6SbT2lKwVi 556 iEx3ySqqNoVScoUyhRdnPV2A1LV0yd9GtG9mI4w= ) 558 nat64.example.com. 559 IN A 192.0.2.1 561 Authors' Addresses 563 Teemu Savolainen 564 Nokia 565 Hermiankatu 12 D 566 FI-33720 Tampere 567 Finland 569 Email: teemu.savolainen@nokia.com 570 Jouni Korhonen 571 Nokia Siemens Networks 572 Linnoitustie 6 573 FI-02600 Espoo 574 Finland 576 Email: jouni.nospam@gmail.com 578 Dan Wing 579 Cisco Systems 580 170 West Tasman Drive 581 San Jose, California 95134 582 USA 584 Email: dwing@cisco.com