idnits 2.17.1 draft-ietf-behave-nat64-learn-analysis-03.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 7, 2012) is 4430 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-17) exists of draft-ietf-behave-nat64-discovery-heuristic-05 ** Obsolete normative reference: RFC 2326 (Obsoleted by RFC 7826) ** Obsolete normative reference: RFC 2671 (Obsoleted by RFC 6891) ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3484 (Obsoleted by RFC 6724) ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) ** Obsolete normative reference: RFC 5389 (Obsoleted by RFC 8489) Summary: 6 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Behavior Engineering for Hindrance J. Korhonen, Ed. 3 Avoidance (BEHAVE) Nokia Siemens Networks 4 Internet-Draft T. Savolainen, Ed. 5 Intended status: Informational Nokia 6 Expires: September 8, 2012 March 7, 2012 8 Analysis of solution proposals for hosts to learn NAT64 prefix 9 draft-ietf-behave-nat64-learn-analysis-03.txt 11 Abstract 13 Hosts and applications may benefit from the knowledge if an IPv6 14 address is synthesized, which would mean a NAT64 is used to reach the 15 IPv4 network or Internet. This document analyses a number of 16 proposed solutions for communicating whether the synthesis is taking 17 place, used address format, and the IPv6 prefix used by the NAT64 and 18 DNS64. The solutions enable both NAT64 avoidance and intentional 19 utilization by allowing local IPv6 address synthesis. The document 20 concludes by recommending selection of heuristic discovery based 21 solution. 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 8, 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 3. Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 4. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 6 61 5. Proposed solutions to learn about synthesis and 62 Network-Specific Prefix . . . . . . . . . . . . . . . . . . . 8 63 5.1. DNS Query for a Well-Known Name . . . . . . . . . . . . . 8 64 5.1.1. Solution description . . . . . . . . . . . . . . . . . 8 65 5.1.2. Analysis and discussion . . . . . . . . . . . . . . . 8 66 5.1.3. Summary . . . . . . . . . . . . . . . . . . . . . . . 9 67 5.2. EDNS0 option indicating AAAA Record synthesis and 68 format . . . . . . . . . . . . . . . . . . . . . . . . . . 9 69 5.2.1. Solution description . . . . . . . . . . . . . . . . . 9 70 5.2.2. Analysis and discussion . . . . . . . . . . . . . . . 9 71 5.2.3. Summary . . . . . . . . . . . . . . . . . . . . . . . 10 72 5.3. EDNS0 flags indicating AAAA Record synthesis and format . 11 73 5.3.1. Solution description . . . . . . . . . . . . . . . . . 11 74 5.3.2. Analysis and discussion . . . . . . . . . . . . . . . 11 75 5.3.3. Summary . . . . . . . . . . . . . . . . . . . . . . . 12 76 5.4. DNS Resource Record for IPv4-Embedded IPv6 address . . . . 12 77 5.4.1. Solution description . . . . . . . . . . . . . . . . . 12 78 5.4.2. Analysis and discussion . . . . . . . . . . . . . . . 12 79 5.4.3. Summary . . . . . . . . . . . . . . . . . . . . . . . 13 80 5.5. Learning the IPv6 Prefix of a Network's NAT64 using DNS . 13 81 5.5.1. Solution description . . . . . . . . . . . . . . . . . 13 82 5.5.2. Analysis and discussion . . . . . . . . . . . . . . . 14 83 5.5.3. Summary . . . . . . . . . . . . . . . . . . . . . . . 15 84 5.6. Learning the IPv6 Prefix of a Network's NAT64 using 85 DHCPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . 15 86 5.6.1. Solution description . . . . . . . . . . . . . . . . . 15 87 5.6.2. Analysis and discussion . . . . . . . . . . . . . . . 16 88 5.6.3. Summary . . . . . . . . . . . . . . . . . . . . . . . 16 89 5.7. Learning the IPv6 Prefix of a Network's NAT64 using 90 Router Advertisements . . . . . . . . . . . . . . . . . . 17 91 5.7.1. Solution description . . . . . . . . . . . . . . . . . 17 92 5.7.2. Analysis and discussion . . . . . . . . . . . . . . . 17 93 5.7.3. Summary . . . . . . . . . . . . . . . . . . . . . . . 18 94 5.8. Using application layer protocols such as STUN . . . . . . 18 95 5.8.1. Solution description . . . . . . . . . . . . . . . . . 18 96 5.8.2. Analysis and discussion . . . . . . . . . . . . . . . 18 97 5.8.3. Summary . . . . . . . . . . . . . . . . . . . . . . . 20 98 5.9. Learning the IPv6 Prefix of a Network's NAT64 using 99 Access Technology Specific Methods . . . . . . . . . . . . 20 100 5.9.1. Solution description . . . . . . . . . . . . . . . . . 20 101 5.9.2. Analysis and discussion . . . . . . . . . . . . . . . 20 102 5.9.3. Summary . . . . . . . . . . . . . . . . . . . . . . . 21 103 6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 21 104 7. Security Considerations . . . . . . . . . . . . . . . . . . . 22 105 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 106 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 23 107 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23 108 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 109 11.1. Normative References . . . . . . . . . . . . . . . . . . . 23 110 11.2. Informative References . . . . . . . . . . . . . . . . . . 24 111 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 113 1. Introduction 115 Hosts and applications may benefit from the knowledge of whether an 116 IPv6 address is synthesized, which would mean a NAT64 is used to 117 reach the IPv4 network or Internet. There are two issues that can be 118 addressed with solutions that allow hosts and applications to learn 119 the Network Specific Prefix (NSP) [RFC6052] used by the NAT64 120 [RFC6146] and the DNS64 [RFC6147] devices. 122 Firstly, finding out whether a particular address is synthetic and 123 therefore learning the presence of a NAT64. For example, a Dual- 124 Stack (DS) host with IPv4 connectivity could use this information to 125 bypass NAT64 and use native IPv4 transport for destinations that are 126 reachable through IPv4. We will refer this as 'Issue #1' throughout 127 the document. 129 Secondly, to find out how to construct from an IPv4 address an IPv6 130 address that will be routable to/by the NAT64. This is useful when 131 IPv4 literals can be found in the payload of some protocol or 132 applications do not use DNS to resolve names to addresses but know 133 the IPv4 address of the destination by some other means. We will 134 refer this as 'Issue #2' throughout the document. 136 Additionally, three other issues have to be considered by a solution 137 addressing the first two issues: whether DNS is required 'Issue #3', 138 whether a solution supports changing NSP 'Issue #4', and whether 139 multiple NSPs are supported (either of the same or different length) 140 for load-balancing purposes 'Issue #5'. 142 This document analyses all known solution proposals known at the time 143 of writing for communicating if the synthesis is taking place, used 144 address format, and the IPv6 prefix used by the NAT64 and DNS64. 145 Based on the analysis we conclude whether the issue of learning the 146 Network-Specific Prefix is worth solving and what would be the 147 recommended solution(s) in that case. 149 2. Terminology 151 Address Synthesis 153 Address synthesis is a mechanism, in the context of this document, 154 where an IPv4 address is represented as an IPv6 address understood 155 by a NAT64 device. The synthesized IPv6 address is formed by 156 embedding an IPv4 address as-is into an IPv6 address prefixed with 157 a NSP/WKP. It is assumed that the 'unused' suffix bits of the 158 synthesized address are set to zero as described in Section 2.2 of 159 [RFC6052]. 161 DNS64 163 DNS extensions for network address translation from IPv6 clients 164 to IPv4 servers: A network entity that synthesizes IPv6 addresses 165 and AAAA records out of IPv4 addresses and A records, hence making 166 IPv4 namespaces visible into IPv6 namespace. DNS64 uses NSP 167 and/or WKP in the synthesis process. 169 NAT64 171 Network Address and protocol Translation mechanism for translating 172 IPv6 packets to IPv4 packets and vice-versa: A network entity that 173 a host or an application may want to either avoid or utilize. 174 IPv6 packets hosts send to addresses in the NSP and/or WKP are 175 routed to NAT64. 177 NSP 179 Network-Specific Prefix: A prefix chosen by network administrator 180 for NAT64/DNS64 to present IPv4 addresses in IPv6 namespace. 182 WKP 184 Well-Known Prefix: A prefix (64:ff9b::/96) chosen by IETF and 185 configured by a network administrator for NAT64/DNS64 to present 186 IPv4 addresses in IPv6 namespace. 188 3. Issues 190 This document analyses different solutions with a focus to following 191 five issues: 193 Issue #1 195 The problem of distinguishing between a synthesized and a real 196 IPv6 addresses, which allows a host to learn the presence of a 197 NAT64 in the network. 199 Issue #2 201 The problem of learning the NSP used by the access network and 202 needed for local IPv6 address synthesis. 204 Issue #3 206 The problem of learning the NSP or WKP used by the access network 207 by a host not implementing DNS (hence applications are unable to 208 use DNS to learn prefix). 210 Issue #4 212 The problem of supporting changing NSP. The NSP learned by the 213 host may become stale for multiple reasons. For example, the host 214 might move to a new network that uses different NSP, thus making 215 the previously learned NSP stale. Also, the NSP used in the 216 network may be changed due administrative reasons, thus again 217 making previously learned NSP stale. 219 Issue #5 221 The problem of supporting multiple NSPs. A network may be 222 configured with multiple NSPs for address synthesis. For example, 223 for load-balancing purposes each NAT64 device in the same network 224 could be assigned with their own NSP. It should be noted that 225 learning a single NSP is enough for an end host to successfully 226 perform local IPv6 address synthesis but to avoid NAT64 the end 227 host needs to learn all NSPs used by the access network. 229 4. Background 231 Certain applications, operating in protocol translation scenarios, 232 can benefit from knowing the IPv6 prefix used by a local NAT64 of the 233 attached access network. This applies to the Framework document 234 [RFC6144] Scenario 1 ("IPv6 network to IPv4 Internet"), Scenario 5 235 ("An IPv6 network to an IPv4 network"), and Scenario 7 ("The IPv6 236 Internet to the IPv4 Internet"). Scenario 3("The IPv6 Internet to an 237 IPv4 network") is not considered applicable herein as in that case a 238 NAT64 is located at the front of remote IPv4 network and host in IPv6 239 Internet can benefit very little of learning NSP IPv6 prefix used by 240 the remote NAT64. The NAT64 prefix can be either a Network Specific 241 Prefix (NSP) or the Well-known Prefix (WKP). Below is (an 242 incomplete) list of various use cases where it is beneficial for a 243 host or an application to know the presence of a NAT64 and the NSP/ 244 WKP: 246 o Host-based DNSSEC validation: as is documented in DNS64 [RFC6147] 247 section 5.5. point 3, synthetic AAAA records cannot be 248 successfully validated in a host. In order to utilize NAT64 a 249 security-aware and validating host has to perform DNS64 function 250 locally and hence it has to be able to learn WKP or proper NSP. 252 o Protocols that use IPv4 literals: in IPv6-only access native IPv4 253 connections cannot be created. If a network has NAT64 it is 254 possible to synthesize IPv6 address by combining the IPv4 literal 255 and the IPv6 prefix used by NAT64. The synthesized IPv6 address 256 can then be used to create an IPv6 connection. 258 o Multicast translation, as described on Internet Drafts contributed 259 to behave WG called "An IPv4 - IPv6 multicast translator" by Stig 260 Venaas, Hitoshi Asaeda, Shinsuke Suzuki, and Tomohiro Fujisaki at 261 December 2010 and "Framework for IPv4/IPv6 Multicast Translation" 262 by Stig Venaas, Xing Li, and Congxiao Bao at June 2011. 264 o URI schemes with host IPv4 address literals rather than domain 265 names (e.g., http://192.0.2.1, ftp://192.0.2.1, imap://192.0.2.1, 266 ipp://192.0.2.1)): a host can synthesize IPv6 address out of the 267 literal in URI and use IPv6 to create connection through NAT64. 269 o Updating host's [RFC3484] preference table to prefer native 270 prefixes over translated prefixes: this is useful as applications 271 are more likely able to traverse through NAT44 than NAT64. 273 DNS64 cannot serve applications that are not using DNS or that obtain 274 referral as an IPv4 literal address. One example application is the 275 Session Description Protocol (SDP) [RFC4566], as used by Real Time 276 Streaming Protocol (RTSP) [RFC2326] and Session Initiation Protocol 277 (SIP) [RFC3261]. Other example applications include web browsers, as 278 IPv4 address literals are still encountered in web pages and URLs. 279 Some of these applications could still work through NAT64, provided 280 they were able to create locally valid IPv6 presentations of peers' 281 IPv4 addresses. 283 It is a known issue that passing IP address referrals, often fails in 284 today's Internet, as described in "Problem Statement for Referral" 285 draft submitted to the IETF by Brian Carpenter in February 2011. 286 Synthesizing IPv6 addresses does not necessarily make the situation 287 any better as the synthesized addresses utilizing NSP are not 288 distinguishable from public IPv6 addresses for the referral receiver. 289 However, the situation is not really any different from the current 290 Internet as using public addresses does not really guarantee 291 reachability (for example due firewalls). A node 'A' behind NAT64 292 may detect it is talking to a node 'B' through NAT64, in which case 293 the node 'A' may want to avoid passing its IPv6 address as a referral 294 to the node 'B'. The node 'B' on the IPv4 side of the NAT64 should 295 not see the IPv6 address of a node 'A' from the IPv6 side of NAT64, 296 and hence the node 'B' should not be able to pass IPv6 address 297 referral to a node 'C'. Passing IPv4 presentation of the IPv6 298 address of the host 'A' to the node 'C' is bound to similar problems 299 as passing a public IPv4 address of a host behind NAT44 as a 300 referral. This analysis focuses on detecting NAT64 presence from the 301 IPv6 side of NAT64. 303 5. Proposed solutions to learn about synthesis and Network-Specific 304 Prefix 306 5.1. DNS Query for a Well-Known Name 308 5.1.1. Solution description 310 Section 3 of [I-D.ietf-behave-nat64-discovery-heuristic] describes a 311 host behavior for discovering the presence of a DNS64 server and a 312 NAT64 device, and heuristics for discovering the used NSP. A host 313 requiring information for local IPv6 address synthesis or for NAT64 314 avoidance sends a DNS query for an AAAA record of a Well-Known IPv4- 315 only Fully Qualified Domain Name (FQDN). If a host receives a 316 negative reply, it knows there are no DNS64 and NAT64 in the network. 318 If a host receives AAAA reply, it knows the network must be utilizing 319 IPv6 address synthesis. After receiving a synthesized AAAA Resource 320 Record, the host may examine the received IPv6 address and use 321 heuristics, such as "subtracting" the known IPv4 address out of 322 synthesized IPv6 address, to find out the NSP. 324 The Well-Known Name may be assigned by IANA or provided some third 325 party, including application or operating system vendor. The IPv4 326 address corresponding to the Well-Known Name may be resolved via A 327 query to Well-Known Name, assigned by IANA, or hard-coded. 329 5.1.2. Analysis and discussion 331 The PROs of the proposal are listed below: 333 + Can be used to solve Issue #1 and Issue #2. 335 + Solves issue #4 via DNS record lifetime. 337 + Can partially solve issue #5 if multiple synthetic AAAA records 338 are included in the response. Can find multiple address formats. 340 + Does not necessarily require any standards effort. 342 + Does not require host stack or resolver changes. All required 343 logic and heuristics can be implemented in applications that are 344 interested in learning about address synthesis taking place. 346 + The solution is backward compatible from 'legacy' hosts and 347 servers point of view. 349 + Hosts or applications interested in learning about synthesis and 350 the used NSP can do the "discovery" proactively at any time, for 351 example every time the host attaches to a new network. 353 + Does not require explicit support from the network using NAT64 355 The CONs of the proposal are listed below: 357 - Requires hosting of a DNS resource record for the Well-Known Name. 359 - Does not provide solution for issue #3. 361 - This method is only able to find one NSP even if a network is 362 utilizing multiple NSPs (issue #5) (unless DNS64 includes multiple 363 synthetic AAAA records in response). 365 5.1.3. Summary 367 This is the only approach that can be deployed without explicit 368 support from the network or the host. This approach could also 369 complement explicit methods and be used as a fallback approach when 370 explicit methods are not supported by an access network. 372 5.2. EDNS0 option indicating AAAA Record synthesis and format 374 5.2.1. Solution description 376 The third revision of "EDNS0 Option for Indicating AAAA Record 377 Synthesis and Format", a draft document submitted to the behave WG in 378 February 2011 by Jouni Korhonen and Teemu Savolainen, defined a new 379 EDNS0 option [RFC2671], which contained 3 flag bits (called SY-bits). 380 The EDNS0 option served as an implicit indication of the presence of 381 DNS64 server and the NAT64 device. The EDNS0 option SY-bit values 382 other than '000' and '111' explicitly told the NSP prefix length. 383 Only the DNS64 server could insert the EDNS0 option and the required 384 SY-bits combination into the synthesized AAAA Resource Record. 386 5.2.2. Analysis and discussion 388 The PROs of the proposal are listed below: 390 + Can be used to solve Issue #1 and is designed to explicitly solve 391 Issue #2. 393 + Solves issue #4 via DNS record lifetime. 395 + Can partially solve issue #5 if multiple synthetic AAAA records 396 are included in the response and all use same format. 398 + The solution is backward compatible from 'legacy' hosts and 399 servers point of view. 401 + Even if the solution is bundled with DNS queries and responses, a 402 standardization of a new DNS record type is not required, rather 403 just defining a new EDNS0 option. 405 + EDNS0 option implementation requires changes only to DNS64 406 servers. 408 + Does not require additional provisioning or management as the 409 EDNS0 option is added automatically by the DNS64 server to the 410 responses. 412 + Does not involve additional queries towards the global DNS 413 infrastructure as EDNS0 logic can be handled within the DNS64 414 server. 416 The CONs of the proposal are listed below: 418 - Requires end hosts to support [RFC2671] EDSN0 extension mechanism. 420 - Requires host resolver changes and a mechanism/additions to the 421 host resolver API (or flags, hints etc) to deliver a note to the 422 querying application that the address is synthesized and what is 423 the NSP prefix length. 425 - Requires a modification to DNS64 servers to include the EDNS0 426 option to the synthesized responses. 428 - Does not provide solution for issue #3. 430 5.2.3. Summary 432 The EDNS0 option based solution works by extending the existing EDNS0 433 Resource Record. Although the solution has host resolver and DNS64 434 server impacts, the changes are limited to those entities (end host, 435 applications) that are interested in learning the presence of NAT64 436 and the used NAT64 prefix. The provisioning and management overhead 437 is minimal if not non-existent as the EDNS0 options are synthesized 438 in a DNS64 server in a same manner as the synthesized AAAA Resource 439 Records. Moreover, EDNS0 does not induce any load to DNS servers 440 because no new RRType query is defined. 442 5.3. EDNS0 flags indicating AAAA Record synthesis and format 444 5.3.1. Solution description 446 The first revision of "EDNS0 Flags Indicating AAAA Record Synthesis 447 and Format", a draft document submitted to the behave WG in July 2010 448 by Jouni Korhonen and Teemu Savolainen, defined 3 new flag bits 449 (called SY-bits) into EDNS0 OPT [RFC2671] header, which served as an 450 implicit indication of the presence of DNS64 server and a NAT64 451 device. SY-bit values other than '000' or '111' explicitly told the 452 NSP prefix length. Only the DNS64 server could insert the EDNS0 453 option and the required SY-bits combination into the synthesized AAAA 454 Resource Record. 456 5.3.2. Analysis and discussion 458 The PROs of the proposal are listed below: 460 + Can be used to solve Issue #1 and is designed to explicitly solve 461 Issue #2. 463 + Solves issue #4 via DNS record lifetime. 465 + Can partially solve issue #5 if multiple synthetic AAAA records 466 are included in the response and all use same format. 468 + The solution is backward compatible from 'legacy' hosts and 469 servers point of view. 471 + EDNS0 option implementation requires changes only to DNS64 472 servers. 474 + Does not require additional provisioning or management as the 475 EDNS0 option is added automatically by the DNS64 server to the 476 responses. 478 + Does not involve additional queries towards the global DNS 479 infrastructure as EDNS0 logic can be handled within the DNS64 480 server. 482 The CONs of the proposal are listed below: 484 - Requires end hosts to support [RFC2671] EDSN0 extension mechanism. 486 - Consumes scarce flag bits from EDNS0 OPT header. 488 - Requires a host resolver changes and a mechanism/additions to the 489 host resolver API (or flags, hints etc) to deliver a note to the 490 querying application that the address is synthesized and what is 491 the NSP prefix length. 493 - Requires a modification to DNS64 servers to include the EDNS0 494 option to the synthesized responses. 496 - Does not provide solution for issue #3. 498 5.3.3. Summary 500 This option is included here for the sake of completeness. The 501 consumption of three bits of the limited EDNS0 OPT space can be 502 considered unfavorable and hence is unlikely to be accepted. 504 5.4. DNS Resource Record for IPv4-Embedded IPv6 address 506 5.4.1. Solution description 508 An Internet Draft titled "A64: DNS Resource Record for IPv4-Embedded 509 IPv6 Address" by Mohamed Boucadair and Eric Burgey that was 510 contributed to behave WG at September 2010 proposed a new DNS 511 Resource Record (A64) that would be a record dedicated to storing a 512 single IPv4-Embedded IPv6 address [RFC6052]. Use of a dedicated 513 Resource Record would allow a host to distinguish between real IPv6 514 addresses and synthesized IPv6 addresses. The solution requires host 515 to send a query for an A64 record. Positive answer with A64 record 516 informs the requesting host that the resolved address is not a native 517 address but an IPv4-Embedded IPv6 address. This would ease the local 518 policies to prefer direct communications (i.e., avoid using IPv4- 519 Embedded IPv6 addresses when a native IPv6 address or a native IPv4 520 address is available). Applications may be notified via new or 521 modified API. 523 5.4.2. Analysis and discussion 525 The PROs of the proposal are listed below: 527 + Can be used to solve Issue #1 and #5. 529 + Solves issue #4 via DNS record lifetime. 531 + The solution is backward compatible from 'legacy' hosts and 532 servers point of view. 534 + Synthesized addresses can be used in authoritative DNS servers. 536 + Maintains the reliability of the DNS model (i.e., a synthesised 537 IPv6 address is presented as such and not as native IPv6 address). 539 + When both IPv4-Converted and native IPv6 addresses are configured 540 for the same QNAME, native addresses are preferred. 542 The CONs of the proposal are listed below: 544 - Does not address Issue #2 or #3 in any way. 546 - Requires a host resolver changes and a mechanism/additions to the 547 host resolver API (or flags, hints etc) to deliver a note to the 548 querying application that the address is synthesized. 550 - Requires a standardization of a new DNS Resource Record type 551 (A64), and the implementation of it in both resolvers and servers. 553 - Requires a coordinated deployment between different flavors of DNS 554 servers within the provider to work deterministically. 556 - Additional load the DNS servers (3 Queries, A64, AAAA and A, may 557 be issued by a dual-stack host). 559 - Does not help to identify synthesized IPv6 addresses if the 560 session does not involve any DNS queries. 562 5.4.3. Summary 564 While the proposed solution delivers explicit information about 565 address synthesis taking place solving the Issue #1, a 566 standardization of a new DNS record type might turn out a too 567 overwhelming task for a solution for a temporary transition phase. 568 Defining a new record type increases load towards DNS server as the 569 host issues parallel A64, AAAA and A queries. 571 5.5. Learning the IPv6 Prefix of a Network's NAT64 using DNS 573 5.5.1. Solution description 575 Revision four of "Learning the IPv6 Prefix of a Network's IPv6/IPv4 576 Translator", a draft document submitted to the behave WG in October 577 2009 by Dan Wing, proposed two DNS-based methods for discovering the 578 presence of a DNS64 server and a NAT64 device, and then a mechanism 579 for discovering the used NSP. 581 Firstly, the document proposed that a host may learn the presence of 582 a DNS64 server and a NAT64 device, by receiving a TXT Resource Record 583 with a well-known string (that document proposes to be reserved by 584 IANA) followed by the NAT64 unicast IPv6 address and the prefix 585 length. The DNS64 server would add the TXT Resource Record into the 586 DNS response. 588 Secondly, the document proposed specifying a new U-NAPTR [RFC4848] 589 application to discover the NAT64's IPv6 prefix and length. The 590 input domain name is exactly the same as would be used for a reverse 591 DNS lookup, derived from the host's IPv6 in the ".ip6.arpa." tree. 592 The host doing the U-NAPTR queries may need multiple queries until 593 the host finds the provisioned domain name with the correct prefix 594 length. The response to a successful U-NATPR query contains the 595 unicast IPv6 address and the prefix length of the NAT64 device. 597 5.5.2. Analysis and discussion 599 The PROs of the proposal are listed below: 601 + Can be used to solve Issue #1 and Issue #2. 603 + Solves issue #4 via DNS record lifetime. 605 + Does not require host stack or resolver changes if the required 606 logic and heuristics is implemented in applications that are 607 interested in learning about address synthesis taking place. 609 The CONs of the proposal are listed below: 611 - Requires standardization of a well-known name by IANA for TXT 612 Resource Record and/or a standardization of a new U-NAPTR 613 application. 615 - Requires a host resolver changes and a mechanism/additions to the 616 host resolver API (or flags, hints etc) to deliver a note to the 617 querying application that the address is synthesized and what is 618 the NSP prefix length. However, it is possible that the U-NAPTR 619 application logic is completely implemented by the application 620 itself as noted in PROs list. 622 - U-NAPTR prefix learning method may entail multiple queries. 624 - U-NAPTR prefix learning method requires provisioning of NSPs in 625 ".ip6.arpa." tree. 627 - RFC5507 [RFC5507] specifically recommends against reusing TXT 628 Resource Records to expand DNS. 630 - Requires configuration on the access network's DNS servers. 632 - Does not provide solution for issue #3. 634 If TXT record would include multiple NSPs issue #5 could be solved as 635 well, but only if nodes as a group would select different NSPs hence 636 supporting load-balancing. As this is not clear this item is not yet 637 listed under PRO or CON. 639 5.5.3. Summary 641 The implementation of this solution requires some changes to the 642 applications and resolvers in a similar fashion as in solutions in 643 Section 5.2, Section 5.3 and Section 5.4. Unlike the other DNS-based 644 approaches, the U-NAPTR-based solution also requires provisioning 645 information into the '.ip6.arpa.' tree which is not any more entirely 646 internal to the provider hosting the NAT64/DNS64 service. 648 The iterative approach of learning the NAT64 prefix in U-NAPTR-based 649 solution may result in multiple DNS queries, which can be considered 650 more complex and inefficient compared to other DNS-based solutions. 652 5.6. Learning the IPv6 Prefix of a Network's NAT64 using DHCPv6 654 5.6.1. Solution description 656 Two individual IETF Internet-Draft contributions specified DHCPv6 657 based approaches. 659 "Learning the IPv6 Prefix of a Network's IPv6/IPv4 Translator", a 660 draft document submitted to the behave WG in October 2009 by Dan 661 Wing, described a new DHCPv6 [RFC3315] option 662 (OPTION_AFT_PREFIX_DHCP) that would contain the IPv6 unicast prefix, 663 IPv6 ASM prefix, and IPv6 SSM prefix (and their lengths) for the 664 NAT64. 666 "Dynamic Host Configuration Protocol (DHCPv6) Options for Shared IP 667 Addresses Solutions", a draft document submitted to the behave WG in 668 December 2009 by Mohamed Boucadair, Pierre Levis, Jean-Luc Grimault, 669 Teemu Savolainen, and Gabor Bajko, proposed a DHCPv6 option that 670 could be used to communicate to a requesting host the prefix used for 671 building IPv4-Converted IPv6 addresses together with the format type 672 and therefore also the used address synthesis algorithm. 673 Provisioning the format type is required so as to be correctly 674 handled by the NAT64-enabled devices deployed in a given domain. 676 5.6.2. Analysis and discussion 678 The PROs of the proposal are listed below: 680 + Can be used to solve Issue #1, Issue #2, Issue #3 and Issue #4 via 681 DHCPv6 information lifetime. 683 + Does not involve DNS system. Therefore, applications that would 684 not normally initiate any DNS queries can still learn the NAT64 685 prefix. 687 + DHCPv6 is designed to provide various kinds of configuration 688 information in a centrally managed fashion. 690 The CONs of the proposal are listed below: 692 - Change of NSP requires change to DHCPv6 configuration. 694 - Requires at least Stateless DHCPv6 client on hosts. 696 - Requires support on DHCPv6 clients, which is not trivial in all 697 operating systems. 699 - The DHCPv6-based solution involves changes and management on 700 network side nodes that are not really part of the NAT64/DNS64 701 deployment (or issues caused by their existence). 703 - A new DHCPv6 option is required and the corresponding changes to 704 both DHCPv6 clients and servers. 706 If DHCPv6 would include multiple NSPs issue #5 could be solved as 707 well, but only if nodes as a group would select different NSPs hence 708 supporting load-balancing. As this is not clear this item is not yet 709 listed under PRO or CON. 711 5.6.3. Summary 713 The DHCPv6-based solution would be a good solution in a sense it 714 hooks into general IP configuration phase, allows easy updates when 715 configuration information changes and does not involve DNS in 716 general. Use of DHCPv6 requires configuration changes on DHCPv6 717 clients and servers and in some cases may also require implementation 718 changes. Furthermore, it is not obvious that all devices that need 719 translation services would implement stateless DHCPv6. For example, 720 cellular 3GPP networks do not mandate hosts or network to implement 721 or deploy DHCPv6. 723 5.7. Learning the IPv6 Prefix of a Network's NAT64 using Router 724 Advertisements 726 5.7.1. Solution description 728 Revision three of "Learning the IPv6 Prefixes of an IPv6/IPv4 729 Translator", a draft document submitted to the behave WG in July 2009 730 by Dan Wing, Xuewei Wang, and Xiaohu Xu, described a new Router 731 Advertisement (RA) [RFC4861] option (OPTION_AFT_PREFIX_RA) that would 732 contain the IPv6 unicast prefix, IPv6 ASM prefix, and IPv6 SSM prefix 733 (and their lengths) for the NAT64. The RA option is essentially the 734 same as for DHCPv6 discussed in Section 5.6. 736 5.7.2. Analysis and discussion 738 The PROs of the proposal are listed below: 740 + Can be used to solve Issue #1, Issue #2, and Issue #3. 742 + Can solve Issue #4 if lifetime information can be communicated. 744 The CONs of the proposal are listed below: 746 - Requires configuration and managements of all access routers to 747 emit correct information in RA. This could, for example, be 748 accomplished somehow by piggybacking on top of routing protocols 749 (which would then require enhancements to routing protocols) 751 - In some operating systems it may not be trivial to transfer 752 information obtained in RA to upper layers 754 - Requires changes to host operating system's IP stack 756 - NSP change requires changes to access router configuration 758 - Requires standardization of a new option to Router Advertisement 759 that is generally unfavored approach 761 - The RA-based solution involves changes and management on network 762 side nodes that are not really part of the NAT64/DNS64 deployment 763 (or issues caused by their existence). 765 If RA would include multiple NSPs issue #5 could be solved as well, 766 but only if nodes as a group would select different NSPs hence 767 supporting load-balancing. As this is not clear this item is not yet 768 listed under PRO or CON. 770 5.7.3. Summary 772 The RA-based solution would be a good solution in a sense it hooks 773 into general IP configuration phase, allows easy updates when 774 configuration information changes and does not involve DNS in 775 general. However, generally introducing any changes to the Neighbor 776 Discovery Protocol that are not absolutely necessary are unfavored 777 due to the impact on both network node side and end host IP stack 778 implementations. 780 Compared to the DHCPv6 equivalent solution in Section 5.6 the 781 management overhead is greater with RA-based solution. In case of 782 DHCPv6-based solution the management can be centralized to few DHCPv6 783 servers compared to RA-based solution where each access router is 784 supposed to be configured with the same information. 786 5.8. Using application layer protocols such as STUN 788 5.8.1. Solution description 790 Application layer protocols, such as Session Traversal Utilities for 791 NAT (STUN) [RFC5389], which define methods for endpoints to learn 792 their external IP addresses could be used for NAT64 and NSP 793 discovery. This document focuses on STUN, but the protocol could be 794 something else as well. 796 A host must first use DNS to discover IPv6 representation(s) of STUN 797 server(s) IPv4 address(es), because the host has no way to directly 798 use IPv4 addresses to contact to STUN server(s). 800 After learning the IPv6 address of a STUN server the STUN client 801 sends a request to the STUN server containing new 'SENDING-TO' 802 attribute that tells to the server the IPv6 address the client sent 803 the request to. In a reply the server includes another new attribute 804 called 'RECEIVED-AS', which contains server's IP address the request 805 arrived on. After receiving the reply the client compares 806 'SENDING-TO' and 'RECEIVED-AS' attributes to find out an NSP 807 candidate. 809 5.8.2. Analysis and discussion 811 This solution is relatively similar as described in Section 5.1, but 812 instead of using DNS uses STUN to get input for heuristic algorithms. 814 The PROs of the proposal are listed below: 816 + Can be used to solve Issue #1 and Issue #2. 818 + Does not require host changes or supportive protocols such as DNS 819 or DHCPv6. All required logic and heuristics can be implemented 820 in applications that are interested in learning about address 821 synthesis taking place. 823 + The solution is backward compatible from 'legacy' hosts and 824 servers point of view. 826 + Hosts or applications interested in learning about synthesis and 827 the used NSP can do the "discovery" proactively at any time, for 828 example every time the host attaches to a new network. 830 + Does not require explicit support from the network using NAT64. 832 + Can possibly be bundled to existing STUN message exchanges as new 833 attributes and hence client can learn its external IPv4 address 834 and a NSP/WKP with the same exchange 836 + Can be used to confirm the heuristics by synthesizing IPv6 address 837 of another STUN server or by synthesizing IPv6 address of first 838 STUN server after host has heuristically determined NSP using 839 method from Section 5.1. I.e. the connectivity test could be done 840 with STUN. 842 + True IPv4 destination address is used in NSP determination instead 843 of IPv4 address received from DNS. This may increase reliability. 845 + The same STUN improvement could also be used to reveal NAT66 on 846 the data path, if the 'RECEIVED-AS' would contain different IPv6 847 address than 'SENDING-TO'. 849 The CONs of the proposal are listed below: 851 - Requires a server on the network to respond the queries. 853 - Requires standardization if done as extension to STUN. 855 - The solution involves changes and management on network side nodes 856 that are not really part of the NAT64/DNS64 deployment (or issues 857 caused by their existence). 859 - Does not solve issue #3 if STUN server's synthetic IPv6 address is 860 provisioned via DNS. 862 - Does not solve issue #4 as the STUN server would not be aware of 863 learned NSP's validity time. 865 - Does not solve issue #5 as the STUN server would not be aware of 866 multiple NSP prefixes. 868 - Heavyweight solution especially if an application does not 869 otherwise support STUN. 871 5.8.3. Summary 873 The STUN, or similar, protocol based approach is a second way to 874 solve the problem without explicit access network support. The 875 heuristics for NSP discovery would still be in the client, however, 876 the result may be more reliable as actual IPv4 destination address is 877 compared to IPv6 address used in sending. The additional benefit of 878 STUN is that the client learns its public IPv4 address with the same 879 message exchange. STUN could also be used as the connectivity test 880 tool if the client would first heuristically determine NSP out of DNS 881 as described in Section 5.1, synthesize IPv6 representation of STUN 882 server's IPv4 address, and then tests connectivity to the STUN 883 server. 885 As an additional benefit the STUN improvement could be used for NAT66 886 discovery. 888 5.9. Learning the IPv6 Prefix of a Network's NAT64 using Access 889 Technology Specific Methods 891 5.9.1. Solution description 893 Several link layers on different access systems have attachment time 894 signaling protocols for negotiating various parameters that are used 895 later on with the established link layer connection. Examples of 896 such include 3GPP Non-Access-Stratum (NAS) signaling protocol 897 [NAS.24.301] among other link layers and tunneling solutions. There, 898 using NAS signaling it could be possible to list all NSPs with their 899 respective prefix lengths in generic protocol configuration option 900 containers during the network access establishment. The lack of NSPs 901 in protocol configuration option containers would be an implicit 902 indication that there is no NAT64 present in the network. 904 5.9.2. Analysis and discussion 906 The PROs of the proposal are listed below: 908 + Can be used to solve Issue #1, Issue #2, Issue #3 and Issue #5. 910 + Can solve Issue #4 if lifetime information is also communicated. 912 The CONs of the proposal are listed below: 914 - Requires configuration and managements of all access routers/ 915 gateway to emit correct information in "link/lower layer" 916 signaling. In a case the NAT64 functionality is implemented into 917 the access router/gateway itself that terminates the generic 918 protocol configuration exchange, then the configuration management 919 can be automated. 921 - In some operating systems it may not be trivial to transfer 922 information obtained in "link/lower layers" to upper layers. 924 - NSP change may require changes to access router/gateway 925 configuration. 927 - Requires standardization of a new configuration parameter 928 exchange/container for each access system of interest. The 929 proposed solution is indeed specific to each access technology. 931 5.9.3. Summary 933 The Access Technology-based solution would be a good solution in a 934 sense it hooks into general network access establishment phase, 935 allows easy updates when configuration information changes and does 936 not involve DNS in general. However, generally introducing any 937 changes to the link/lower layers is a long and slow process, and 938 changes would need to be done for all access technologies/systems 939 that are used with NAT64. 941 Compared to the RA equivalent solution in Section 5.7 the management 942 overhead is equivalent or even less than RA-based solution. 944 6. Conclusion 946 Our conclusion is to recommend publishing the Well-Known DNS Name 947 heuristic discovery-based method as a standards track IETF document 948 for applications and host implementors to implement as-is. 950 As a general principle we prefer to have as minimal solution as 951 possible, avoid impacts to entities not otherwise involved in the 952 protocol translation scheme, minimize host impact, and that requires 953 minimal to no operational effort on the network side. 955 Of the different issues we give most weight for issues #1 and #2. We 956 are not giving much weight for the Issue #3 'DNS should not be 957 required', as cases where hosts need to synthesize IPv6 addresses but 958 do not have DNS available seem rare for us. Even if application does 959 not otherwise utilize DNS, it ought to be able to trigger simple DNS 960 query to find out WKP/NSP. Issue #4 is handled by majority of 961 solutions and Issue #5 is considered to be mostly insignificant as 962 even if individual hosts would use only one NSP at a time, different 963 hosts would be using different NSPs, hence supporting load-balancing 964 targets. Only one of the discussed solutions, see Section 5.6, 965 support learning of possible new or indicating support for multiple 966 algorithms for address synthesis other than the one described in 967 [RFC6052]. 969 The DNS64 entity has to be configured with WKP/NSP in order for it to 970 do synthesis and hence using DNS also for delivering the synthesis 971 information sounds logical. The fact that the synthesis information 972 fate-shares the information received in the DNS response is a 973 valuable attribute and reduces the possible distribution of stale 974 prefix information. However, having all DNS64 servers to support 975 explicit WKP/NSP discovery (ENDS0, A64, and DNS SRV record 976 approaches) is difficult to arrange. The U-NAPTR-based approach 977 would require provisioning information into the '.ip6.arpa' tree 978 which would not be entirely internal for the provider. Use of DHCPv6 979 would require additional trouble configuring DHCPv6 servers and 980 ensuring DHCPv6 clients are in place, and furthermore that the NAT64, 981 DHCPv6 (and possible even some DNS64) servers are all in sync. RA- 982 based mechanisms are operationally expensive as configuration would 983 have to be placed and maintained in the access routers. Furthermore, 984 both DHCPv6 and RA based mechanisms involve entities that do not 985 otherwise need to be aware of protocol translation (only need to know 986 DNS server addresses). Finally, regarding the use of STUN. A host 987 does not need to implement STUN where as DNS is in practice required 988 anyway. Also, STUN protocol would need to be changed on both host 989 and network side to support the discovery of NAT64 and WKP/NSP. 991 7. Security Considerations 993 The security considerations are essentially similar to what is 994 described in DNS64 [RFC6147]. Forgery of information required for 995 IPv6 address synthesis may allow an attacker to insert itself as 996 middle man or to perform denial-of-service attack. The DHCPv6 and RA 997 based approaches are vulnerable for the forgery as the attacker may 998 send forged RAs or act as a rogue DHCPv6 server (unless DHCPv6 999 authentication or SEND are used). If the attacker is already able to 1000 modify and forge DNS responses (flags, addresses of know IPv4-only 1001 servers, records, etc), ability to influence local address synthesis 1002 is likely of low additional value. Also, a DNS-based mechanism is 1003 only as secure as the method used to configure the DNS server's IP 1004 addresses on the host. Therefore, if the host cannot trust e.g. 1005 DHCPv6 it cannot trust the DNS server learned via DHCPv6 either, 1006 unless the host has a way to authenticate all DNS responses. 1008 8. IANA Considerations 1010 This document is informative and has no actions to IANA. 1012 9. Contributors 1014 The following people have contributed text to this document. 1016 Mohamed Boucadair 1017 France Telecom 1018 Rennes, 35000 1019 France 1021 Email: mohamed.boucadair@orange-ftgroup.com 1023 10. Acknowledgements 1025 Authors would like to thank Dan Wing and Christian Huitema especially 1026 for the STUN idea and for their valuable comments and discussions. 1028 11. References 1030 11.1. Normative References 1032 [I-D.ietf-behave-nat64-discovery-heuristic] 1033 Savolainen, T., Korhonen, J., and D. Wing, "Discovery of a 1034 Network-Specific NAT64 Prefix using a Well-Known Name", 1035 draft-ietf-behave-nat64-discovery-heuristic-05 (work in 1036 progress), January 2012. 1038 [RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time 1039 Streaming Protocol (RTSP)", RFC 2326, April 1998. 1041 [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", 1042 RFC 2671, August 1999. 1044 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1045 A., Peterson, J., Sparks, R., Handley, M., and E. 1047 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1048 June 2002. 1050 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 1051 and M. Carney, "Dynamic Host Configuration Protocol for 1052 IPv6 (DHCPv6)", RFC 3315, July 2003. 1054 [RFC3484] Draves, R., "Default Address Selection for Internet 1055 Protocol version 6 (IPv6)", RFC 3484, February 2003. 1057 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1058 Description Protocol", RFC 4566, July 2006. 1060 [RFC4848] Daigle, L., "Domain-Based Application Service Location 1061 Using URIs and the Dynamic Delegation Discovery Service 1062 (DDDS)", RFC 4848, April 2007. 1064 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 1065 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 1066 September 2007. 1068 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 1069 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 1070 October 2008. 1072 [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 1073 Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, 1074 October 2010. 1076 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 1077 NAT64: Network Address and Protocol Translation from IPv6 1078 Clients to IPv4 Servers", RFC 6146, April 2011. 1080 [RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van 1081 Beijnum, "DNS64: DNS Extensions for Network Address 1082 Translation from IPv6 Clients to IPv4 Servers", RFC 6147, 1083 April 2011. 1085 11.2. Informative References 1087 [NAS.24.301] 1088 3GPP, "Non-Access-Stratum (NAS) protocol for Evolved 1089 Packet System (EPS)", 3GPP TS 24.301 8.8.0, December 2010. 1091 [RFC5507] IAB, Faltstrom, P., Austein, R., and P. Koch, "Design 1092 Choices When Expanding the DNS", RFC 5507, April 2009. 1094 [RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for 1095 IPv4/IPv6 Translation", RFC 6144, April 2011. 1097 Authors' Addresses 1099 Jouni Korhonen (editor) 1100 Nokia Siemens Networks 1101 Linnoitustie 6 1102 FI-02600 Espoo 1103 Finland 1105 Email: jouni.nospam@gmail.com 1107 Teemu Savolainen (editor) 1108 Nokia 1109 Hermiankatu 12 D 1110 FI-33720 Tampere 1111 Finland 1113 Email: teemu.savolainen@nokia.com