idnits 2.17.1 draft-ietf-behave-nat64-learn-analysis-01.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 (October 6, 2011) is 4585 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** 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 (~~), 1 warning (==), 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: April 8, 2012 October 6, 2011 8 Analysis of solution proposals for hosts to learn NAT64 prefix 9 draft-ietf-behave-nat64-learn-analysis-01.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 April 8, 2012. 40 Copyright Notice 42 Copyright (c) 2011 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 and Assumptions . . . . . . . . . . . . . . . . . 4 59 3. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 6 60 4. Proposed solutions to learn about synthesis and 61 Network-Specific Prefix . . . . . . . . . . . . . . . . . . . 7 62 4.1. DNS Query for a Well-Known Name . . . . . . . . . . . . . 7 63 4.1.1. Solution description . . . . . . . . . . . . . . . . . 7 64 4.1.2. Analysis and discussion . . . . . . . . . . . . . . . 8 65 4.1.3. Summary . . . . . . . . . . . . . . . . . . . . . . . 9 66 4.2. EDNS0 option indicating AAAA Record synthesis and 67 format . . . . . . . . . . . . . . . . . . . . . . . . . . 9 68 4.2.1. Solution description . . . . . . . . . . . . . . . . . 9 69 4.2.2. Analysis and discussion . . . . . . . . . . . . . . . 9 70 4.2.3. Summary . . . . . . . . . . . . . . . . . . . . . . . 10 71 4.3. EDNS0 flags indicating AAAA Record synthesis and format . 10 72 4.3.1. Solution description . . . . . . . . . . . . . . . . . 10 73 4.3.2. Analysis and discussion . . . . . . . . . . . . . . . 11 74 4.3.3. Summary . . . . . . . . . . . . . . . . . . . . . . . 11 75 4.4. DNS Resource Record for IPv4-Embedded IPv6 address . . . . 12 76 4.4.1. Solution description . . . . . . . . . . . . . . . . . 12 77 4.4.2. Analysis and discussion . . . . . . . . . . . . . . . 12 78 4.4.3. Summary . . . . . . . . . . . . . . . . . . . . . . . 13 79 4.5. Learning the IPv6 Prefix of a Network's NAT64 using DNS . 13 80 4.5.1. Solution description . . . . . . . . . . . . . . . . . 13 81 4.5.2. Analysis and discussion . . . . . . . . . . . . . . . 13 82 4.5.3. Summary . . . . . . . . . . . . . . . . . . . . . . . 14 83 4.6. Learning the IPv6 Prefix of a Network's NAT64 using 84 DHCPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . 15 85 4.6.1. Solution description . . . . . . . . . . . . . . . . . 15 86 4.6.2. Analysis and discussion . . . . . . . . . . . . . . . 15 87 4.6.3. Summary . . . . . . . . . . . . . . . . . . . . . . . 16 88 4.7. Learning the IPv6 Prefix of a Network's NAT64 using 89 Router Advertisements . . . . . . . . . . . . . . . . . . 16 90 4.7.1. Solution description . . . . . . . . . . . . . . . . . 16 91 4.7.2. Analysis and discussion . . . . . . . . . . . . . . . 16 92 4.7.3. Summary . . . . . . . . . . . . . . . . . . . . . . . 17 93 4.8. Using application layer protocols such as STUN . . . . . . 17 94 4.8.1. Solution description . . . . . . . . . . . . . . . . . 17 95 4.8.2. Analysis and discussion . . . . . . . . . . . . . . . 18 96 4.8.3. Summary . . . . . . . . . . . . . . . . . . . . . . . 19 97 4.9. Learning the IPv6 Prefix of a Network's NAT64 using 98 Access Technology Specific Methods . . . . . . . . . . . . 19 99 4.9.1. Solution description . . . . . . . . . . . . . . . . . 20 100 4.9.2. Analysis and discussion . . . . . . . . . . . . . . . 20 101 4.9.3. Summary . . . . . . . . . . . . . . . . . . . . . . . 20 102 5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 21 103 6. Security Considerations . . . . . . . . . . . . . . . . . . . 22 104 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 105 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 22 106 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22 107 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 108 10.1. Normative References . . . . . . . . . . . . . . . . . . . 22 109 10.2. Informative References . . . . . . . . . . . . . . . . . . 23 110 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 112 1. Introduction 114 Hosts and applications may benefit from the knowledge of whether an 115 IPv6 address is synthesized, which would mean a NAT64 is used to 116 reach the IPv4 network or Internet. There are two issues that can be 117 addressed with solutions that allow hosts and applications to learn 118 the Network Specific Prefix (NSP) [RFC6052] used by the NAT64 119 [RFC6146] and the DNS64 [RFC6147] devices. 121 Firstly, finding out whether a particular address is synthetic and 122 therefore learning the presence of a NAT64. For example, a Dual- 123 Stack (DS) host with IPv4 connectivity could use this information to 124 bypass NAT64 and use native IPv4 transport for destinations that are 125 reachable through IPv4. We will refer this as 'Issue #1' throughout 126 the document. 128 Secondly, finding out how to construct from an IPv4 address an IPv6 129 address that will be routable to/by the NAT64. This is useful when 130 IPv4 literals can be found in the payload of some protocol or 131 applications do not use DNS to resolve names to addresses but know 132 the IPv4 address of the destination by some other means. We will 133 refer this as 'Issue #2' throughout the document. 135 Additionally three other issues have to be considered by a solution 136 addressing the first two issues: whether DNS is required 'Issue #3', 137 whether a solution supports changing NSP 'Issue #4', and whether 138 multiple NSPs are supported (either of the same or different length) 139 for load-balancing purposes 'Issue #5'. 141 This document analyses all known solution proposals known at the time 142 of writing for communicating if the synthesis is taking place, used 143 address format, and the IPv6 prefix used by the NAT64 and DNS64. 144 Based on the analysis we conclude whether the issue of learning the 145 Network-Specific Prefix is worth solving and what would be the 146 recommended solution(s) in that case. 148 2. Terminology and Assumptions 150 NSP 152 Network-Specific Prefix: A prefix chosen by network administrator 153 for NAT64/DNS64 to present IPv4 addresses in IPv6 namespace. 155 WKP 157 Well-Known Prefix: A prefix (64:ff9b::/96) chosen by IETF and 158 configured by a network administrator for NAT64/DNS64 to present 159 IPv4 addresses in IPv6 namespace. 161 NAT64 163 Network Address and protocol Translation mechanism for translating 164 IPv6 packets to IPv4 packets and vice-versa: A network entity that 165 a host or an application may want to either avoid or utilize. 166 IPv6 packets hosts send to addresses in the NSP and/or WKP are 167 routed to NAT64. 169 DNS64 171 DNS extensions for network address translation from IPv6 clients 172 to IPv4 servers: A network entity that synthesizes IPv6 addresses 173 and AAAA records out of IPv4 addresses and A records, hence making 174 IPv4 namespaces visible into IPv6 namespace. DNS64 uses NSP 175 and/or WKP in the synthesis process. 177 Address Synthesis 179 A mechanism, in the context of this document, where an IPv4 180 address is represented as an IPv6 address understood by a NAT64 181 device. The synthesized IPv6 address is formed by embedding an 182 IPv4 address as-is into an IPv6 address prefixed with a NSP/WKP. 183 It is assumed that the 'unused' suffix bits of the synthesized 184 address are set to zero as described in Section 2.2 of [RFC6052]. 186 Issue #1 188 The problem of distinguishing between a synthesized and a real 189 IPv6 addresses, which allows a host to learn the presence of a 190 NAT64 in the network. 192 Issue #2 194 The problem of learning the NSP used by the access network and 195 needed for local IPv6 address synthesis. 197 Issue #3 199 The problem of learning the NSP or WKP used by the access network 200 by a host not implementing DNS (hence applications are unable to 201 use DNS to learn prefix). 203 Issue #4 205 The problem of supporting changing NSP. The NSP learned by the 206 host may become stale for multiple reasons. For example, the host 207 might move to a new network that uses different NSP, thus making 208 the previously learned NSP stale. Also, the NSP used in the 209 network may be changed due administrative reasons, thus again 210 making previously learned NSP stale. 212 Issue #5 214 The problem of supporting multiple NSPs. A network may be 215 configured with multiple NSPs for address synthesis. For example, 216 for load-balancing purposes each NAT64 device in the same network 217 could be assigned with their own NSP. It should be noted that 218 learning a single NSP is enough for an end host to successfully 219 perform local IPv6 address synthesis but to avoid NAT64 the end 220 host needs to learn all NSPs used by the access network. 222 3. Background 224 Certain applications, operating in protocol translation scenarios, 225 can benefit from knowing the IPv6 prefix used by a local NAT64 of the 226 attached access network. This applies to the Framework document 227 [RFC6144] Scenario 1 ("IPv6 network to IPv4 Internet"), Scenario 5 228 ("An IPv6 network to an IPv4 network"), and Scenario 7 ("The IPv6 229 Internet to the IPv4 Internet"). Scenario 3("The IPv6 Internet to an 230 IPv4 network") is not considered applicable herein as in that case a 231 NAT64 is located at the front of remote IPv4 network and host in IPv6 232 Internet can benefit very little of learning NSP IPv6 prefix used by 233 the remote NAT64. The NAT64 prefix can be either a Network Specific 234 Prefix (NSP) or the Well-known Prefix (WKP). Below is (an 235 incomplete) list of various use cases where it is beneficial for a 236 host or an application to know the presence of a NAT64 and the NSP/ 237 WKP: 239 o Host-based DNSSEC validation: as is documented in DNS64 [RFC6147] 240 section 5.5. point 3, synthetic AAAA records cannot be 241 successfully validated in a host. In order to utilize NAT64 a 242 security-aware and validating host has to perform DNS64 function 243 locally and hence it has to be able to learn WKP or proper NSP. 245 o Protocols that use IPv4 literals: in IPv6-only access native IPv4 246 connections cannot be created. If a network has NAT64 it is 247 possible to synthesize IPv6 address by combining the IPv4 literal 248 and the IPv6 prefix used by NAT64. The synthesized IPv6 address 249 can then be used to create an IPv6 connection. 251 o Multicast translations 252 [I-D.venaas-behave-mcast46][I-D.venaas-behave-v4v6mc-framework]. 254 o URI schemes with host IPv4 address literals rather than domain 255 names (e.g., http://192.0.2.1, ftp://192.0.2.1, imap://192.0.2.1, 256 ipp://192.0.2.1)): a host can synthesize IPv6 address out of the 257 literal in URI and use IPv6 to create connection through NAT64. 259 o Updating host's [RFC3484] preference table to prefer native 260 prefixes over translated prefixes: this is useful as applications 261 are more likely able to traverse through NAT44 than NAT64. 263 DNS64 cannot serve applications that are not using DNS or that obtain 264 referral as an IPv4 literal address. One example application is the 265 Session Description Protocol (SDP) [RFC4566], as used by Real Time 266 Streaming Protocol (RTSP) [RFC2326] and Session Initiation Protocol 267 (SIP) [RFC3261]. Other example applications include web browsers, as 268 IPv4 address literals are still encountered in web pages and URLs. 269 Some of these applications could still work through NAT64, provided 270 they were able to create locally valid IPv6 presentations of peers' 271 IPv4 addresses. 273 It is a known issue that passing IP address referrals, often fails in 274 today's Internet [I-D.carpenter-referral-ps]. Synthesizing IPv6 275 addresses does not necessarily make the situation any better as the 276 synthesized addresses utilizing NSP are not distinguishable from 277 public IPv6 addresses for the referral receiver. However, the 278 situation is not really any different from the current Internet as 279 using public addresses does not really guarantee reachability (for 280 example due firewalls). A node 'A' behind NAT64 may detect it is 281 talking to a node 'B' through NAT64, in which case the node 'A' may 282 want to avoid passing its IPv6 address as a referral to the node 'B'. 283 The node 'B' on the IPv4 side of the NAT64 should not see the IPv6 284 address of a node 'A' from the IPv6 side of NAT64, and hence the node 285 'B' should not be able to pass IPv6 address referral to a node 'C'. 286 Passing IPv4 presentation of the IPv6 address of the host 'A' to the 287 node 'C' is bound to similar problems as passing a public IPv4 288 address of a host behind NAT44 as a referral. This analysis focuses 289 on detecting NAT64 presence from the IPv6 side of NAT64. 291 4. Proposed solutions to learn about synthesis and Network-Specific 292 Prefix 294 4.1. DNS Query for a Well-Known Name 296 4.1.1. Solution description 298 Section 3 of [I-D.savolainen-heuristic-nat64-discovery] describes a 299 host behavior for discovering the presence of a DNS64 server and a 300 NAT64 device, and heuristics for discovering the used NSP. A host 301 requiring information for local IPv6 address synthesis or for NAT64 302 avoidance sends a DNS query for an AAAA record of a Well-Known IPv4- 303 only Fully Qualified Domain Name (FQDN). If a host receives a 304 negative reply, it knows there are no DNS64 and NAT64 in the network. 306 If a host receives AAAA reply, it knows the network must be utilizing 307 IPv6 address synthesis. After receiving a synthesized AAAA Resource 308 Record, the host may examine the received IPv6 address and use 309 heuristics, such as "subtracting" the known IPv4 address out of 310 synthesized IPv6 address, to find out the NSP. 312 The Well-Known Name may be assigned by IANA or provided some third 313 party, including application or operating system vendor. The IPv4 314 address corresponding to the Well-Known Name may be resolved via A 315 query to Well-Known Name, assigned by IANA, or hard-coded. 317 4.1.2. Analysis and discussion 319 The PROs of the proposal are listed below: 321 + Can be used to solve Issue #1 and Issue #2. 323 + Solves issue #4 via DNS record lifetime. 325 + Can partially solve issue #5 if multiple synthetic AAAA records 326 are included in the response. Can find multiple address formats. 328 + Does not necessarily require any standards effort. 330 + Does not require host stack or resolver changes. All required 331 logic and heuristics can be implemented in applications that are 332 interested in learning about address synthesis taking place. 334 + The solution is backward compatible from 'legacy' hosts and 335 servers point of view. 337 + Hosts or applications interested in learning about synthesis and 338 the used NSP can do the "discovery" proactively at any time, for 339 example every time the host attaches to a new network. 341 + Does not require explicit support from the network using NAT64 343 The CONs of the proposal are listed below: 345 - Requires hosting of a DNS resource record for the Well-Known Name. 347 - Does not provide solution for issue #3. 349 - This method is only able to find one NSP even if a network is 350 utilizing multiple NSPs (issue #5) (unless DNS64 includes multiple 351 synthetic AAAA records in response). 353 4.1.3. Summary 355 This is the only approach that can be deployed without explicit 356 support from the network or the host. This approach could also 357 complement explicit methods and be used as a fallback approach when 358 explicit methods are not supported by an access network. 360 4.2. EDNS0 option indicating AAAA Record synthesis and format 362 4.2.1. Solution description 364 Section 3 of [I-D.korhonen-edns0-synthesis-flag] defines a new EDNS0 365 option [RFC2671], which contain 3 flag bits (called SY-bits). The 366 EDNS0 option serves as an implicit indication of the presence of 367 DNS64 server and the NAT64 device. The EDNS0 option SY-bit values 368 other than '000' and '111' explicitly tell the NSP prefix length. 369 Only the DNS64 server can insert the EDNS0 option and the required 370 SY-bits combination into the synthesized AAAA Resource Record. 372 4.2.2. Analysis and discussion 374 The PROs of the proposal are listed below: 376 + Can be used to solve Issue #1 and is designed to explicitly solve 377 Issue #2. 379 + Solves issue #4 via DNS record lifetime. 381 + Can partially solve issue #5 if multiple synthetic AAAA records 382 are included in the response and all use same format. 384 + The solution is backward compatible from 'legacy' hosts and 385 servers point of view. 387 + Even if the solution is bundled with DNS queries and responses, a 388 standardization of a new DNS record type is not required, rather 389 just defining a new EDNS0 option. 391 + EDNS0 option implementation requires changes only to DNS64 392 servers. 394 + Does not require additional provisioning or management as the 395 EDNS0 option is added automatically by the DNS64 server to the 396 responses. 398 + Does not involve additional queries towards the global DNS 399 infrastructure as EDNS0 logic can be handled within the DNS64 400 server. 402 The CONs of the proposal are listed below: 404 - Requires end hosts to support [RFC2671] EDSN0 extension mechanism. 406 - Requires host resolver changes and a mechanism/additions to the 407 host resolver API (or flags, hints etc) to deliver a note to the 408 querying application that the address is synthesized and what is 409 the NSP prefix length. 411 - Requires a modification to DNS64 servers to include the EDNS0 412 option to the synthesized responses. 414 - Does not provide solution for issue #3. 416 4.2.3. Summary 418 The EDNS0 option based solution works by extending the existing EDNS0 419 Resource Record. Although the solution has host resolver and DNS64 420 server impacts, the changes are limited to those entities (end host, 421 applications) that are interested in learning the presence of NAT64 422 and the used NAT64 prefix. The provisioning and management overhead 423 is minimal if not non-existent as the EDNS0 options are synthesized 424 in a DNS64 server in a same manner as the synthesized AAAA Resource 425 Records. Moreover, EDNS0 does not induce any load to DNS servers 426 because no new RRType query is defined. 428 4.3. EDNS0 flags indicating AAAA Record synthesis and format 430 4.3.1. Solution description 432 Section 3 of the version -00 of [I-D.korhonen-edns0-synthesis-flag] 433 defines 3 new flag bits (called SY-bits) into EDNS0 OPT [RFC2671] 434 header, which serve as an implicit indication of the presence of 435 DNS64 server and a NAT64 device. SY-bit values other than '000' or 436 '111' explicitly tell the NSP prefix length. Only the DNS64 server 437 can insert the EDNS0 option and the required SY-bits combination into 438 the synthesized AAAA Resource Record. 440 4.3.2. Analysis and discussion 442 The PROs of the proposal are listed below: 444 + Can be used to solve Issue #1 and is designed to explicitly solve 445 Issue #2. 447 + Solves issue #4 via DNS record lifetime. 449 + Can partially solve issue #5 if multiple synthetic AAAA records 450 are included in the response and all use same format. 452 + The solution is backward compatible from 'legacy' hosts and 453 servers point of view. 455 + EDNS0 option implementation requires changes only to DNS64 456 servers. 458 + Does not require additional provisioning or management as the 459 EDNS0 option is added automatically by the DNS64 server to the 460 responses. 462 + Does not involve additional queries towards the global DNS 463 infrastructure as EDNS0 logic can be handled within the DNS64 464 server. 466 The CONs of the proposal are listed below: 468 - Requires end hosts to support [RFC2671] EDSN0 extension mechanism. 470 - Consumes scarce flag bits from EDNS0 OPT header. 472 - Requires a host resolver changes and a mechanism/additions to the 473 host resolver API (or flags, hints etc) to deliver a note to the 474 querying application that the address is synthesized and what is 475 the NSP prefix length. 477 - Requires a modification to DNS64 servers to include the EDNS0 478 option to the synthesized responses. 480 - Does not provide solution for issue #3. 482 4.3.3. Summary 484 This option is included here for the sake of completeness. The 485 consumption of three bits of the limited EDNS0 OPT space can be 486 considered unfavorable and hence is unlikely to be accepted. 488 4.4. DNS Resource Record for IPv4-Embedded IPv6 address 490 4.4.1. Solution description 492 Section 4 of [I-D.boucadair-behave-dns-a64] defines a new DNS 493 Resource Record (A64) that is a record specific to store a single 494 IPv4-Embedded IPv6 address [RFC6052]. Using a dedicated Resource 495 Record allows a host to distinguish between real IPv6 addresses and 496 synthesized IPv6 addresses. The solution requires host to send a 497 query for an A64 record. Positive answer with A64 record informs the 498 requesting host that the resolved address is not a native address but 499 an IPv4-Embedded IPv6 address. This would ease the local policies to 500 prefer direct communications (i.e., avoid using IPv4-Embedded IPv6 501 addresses when a native IPv6 address or a native IPv4 address is 502 available). Applications may be notified via new or modified API. 504 4.4.2. Analysis and discussion 506 The PROs of the proposal are listed below: 508 + Can be used to solve Issue #1 and #5. 510 + Solves issue #4 via DNS record lifetime. 512 + The solution is backward compatible from 'legacy' hosts and 513 servers point of view. 515 + Synthesized addresses can be used in authoritative DNS servers. 517 + Maintains the reliability of the DNS model (i.e., a synthesised 518 IPv6 address is presented as such and not as native IPv6 address). 520 + When both IPv4-Converted and native IPv6 addresses are configured 521 for the same QNAME, native addresses are preferred. 523 The CONs of the proposal are listed below: 525 - Does not address Issue #2 or #3 in any way. 527 - Requires a host resolver changes and a mechanism/additions to the 528 host resolver API (or flags, hints etc) to deliver a note to the 529 querying application that the address is synthesized. 531 - Requires a standardization of a new DNS Resource Record type 532 (A64), and the implementation of it in both resolvers and servers. 534 - Requires a coordinated deployment between different flavors of DNS 535 servers within the provider to work deterministically. 537 - Additional load the DNS servers (3 Queries, A64, AAAA and A, may 538 be issued by a dual-stack host). 540 - Does not help to identify synthesized IPv6 addresses if the 541 session does not involve any DNS queries. 543 4.4.3. Summary 545 While the proposed solution delivers explicit information about 546 address synthesis taking place solving the Issue #1, a 547 standardization of a new DNS record type might turn out a too 548 overwhelming task for a solution for a temporary transition phase. 549 Defining a new record type increases load towards DNS server as the 550 host issues parallel A64, AAAA and A queries. 552 4.5. Learning the IPv6 Prefix of a Network's NAT64 using DNS 554 4.5.1. Solution description 556 Section 4.1 of the version -04 of [I-D.wing-behave-learn-prefix] 557 actually proposes two DNS-based method for discovering the presence 558 of a DNS64 server and a NAT64 device, and then a mechanism for 559 discovering the used NSP. First, a host may learn the presence of a 560 DNS64 server and a NAT64 device, by receiving a TXT Resource Record 561 with a well-known (TBD IANA registered?) string followed by the NAT64 562 unicast IPv6 address and the prefix length. The DNS64 server would 563 add the TXT Resource Record into the DNS response. 565 Second, Section 4.1 of the version -04 of 566 [I-D.wing-behave-learn-prefix] also proposes specifying a new U-NAPTR 567 [RFC4848] application to discover the NAT64's IPv6 prefix and length. 568 The input domain name is exactly the same as would be used for a 569 reverse DNS lookup, derived from the host's IPv6 in the ".ip6.arpa." 570 tree. The host doing the U-NAPTR queries may need multiple queries 571 until finds the provisioned domain name with the correct prefix 572 length. The response to a successful U-NATPR query contains the 573 unicast IPv6 address and the prefix length of the NAT64 device. 575 4.5.2. Analysis and discussion 577 [Editor' note: can this be made to solve issue #5 by having multiple 578 NSPs in TXT record?] 580 The PROs of the proposal are listed below: 582 + Can be used to solve Issue #1 and Issue #2. 584 + Solves issue #4 via DNS record lifetime. 586 + Does not require host stack or resolver changes if the required 587 logic and heuristics is implemented in applications that are 588 interested in learning about address synthesis taking place. 590 The CONs of the proposal are listed below: 592 - Requires standardization of a well-known names from IANA for TXT 593 Resource Record and/or a standardization of a new U-NAPTR 594 application. 596 - Requires a host resolver changes and a mechanism/additions to the 597 host resolver API (or flags, hints etc) to deliver a note to the 598 querying application that the address is synthesized and what is 599 the NSP prefix length. However, it is possible that the U-NAPTR 600 application logic is completely implemented by the application 601 itself as noted in PROs list. 603 - U-NAPTR prefix learning method may entail multiple queries. 605 - U-NAPTR prefix learning method requires provisioning of NSPs in 606 ".ip6.arpa." tree. 608 - RFC5507 [RFC5507] specifically recommends against reusing TXT 609 Resource Records to expand DNS. 611 - Requires configuration on the access network's DNS servers. 613 - Does not provide solution for issue #3. 615 4.5.3. Summary 617 The implementation of this solution requires some changes to the 618 applications and resolvers in a similar fashion as in solutions in 619 Section 4.2, Section 4.3 and Section 4.4. Unlike the other DNS-based 620 approaches, the U-NAPTR-based solution also requires provisioning 621 information into the '.ip6.arpa.' tree which is not any more entirely 622 internal to the provider hosting the NAT64/DNS64 service. 624 The iterative approach of learning the NAT64 prefix in U-NAPTR-based 625 solution may result in multiple DNS queries, which can be considered 626 more complex and inefficient compared to other DNS-based solutions. 628 4.6. Learning the IPv6 Prefix of a Network's NAT64 using DHCPv6 630 4.6.1. Solution description 632 Two individual drafts specify DHCPv6 based approaches. 634 Section 4.2 of the version -04 of [I-D.wing-behave-learn-prefix] 635 describes a new DHCPv6 [RFC3315] option (OPTION_AFT_PREFIX_DHCP) that 636 contains the IPv6 unicast prefix, IPv6 ASM prefix, and IPv6 SSM 637 prefix (and their lengths) for the NAT64. 639 Section 4 of [I-D.boucadair-dhcpv6-shared-address-option] defines a 640 DHCPv6 option that can be used to communicate to a requesting host 641 the prefix used for building IPv4-Converted IPv6 addresses together 642 with the format type and therefore also the used address synthesis 643 algorithm. Provisioning the format type is required so as to be 644 correctly handled by the NAT64-enabled devices deployed in a given 645 domain. 647 4.6.2. Analysis and discussion 649 The PROs of the proposal are listed below: 651 + Can be used to solve Issue #1, Issue #2, Issue #3 and Issue #4 via 652 DHCPv6 information lifetime. 654 + Does not involve DNS system. Therefore, applications that would 655 not normally initiate any DNS queries can still learn the NAT64 656 prefix. 658 + DHCPv6 is designed to provide various kinds of configuration 659 information in a centrally managed fashion. 661 The CONs of the proposal are listed below: 663 - Change of NSP requires change to DHCPv6 configuration. 665 - Requires at least Stateless DHCPv6 client on hosts. 667 - Requires support on DHCPv6 clients, which is not trivial in all 668 operating systems. 670 - The DHCPv6-based solution involves changes and management on 671 network side nodes that are not really part of the NAT64/DNS64 672 deployment (or issues caused by their existence). 674 - A new DHCPv6 option is required and the corresponding changes to 675 both DHCPv6 clients and servers. 677 If DHCPv6 would include multiple NSPs issue #5 could be solved as 678 well, but only if nodes as a group would select different NSPs hence 679 supporting load-balancing. As this is not clear this item is not yet 680 listed under PRO nor CON. 682 4.6.3. Summary 684 The DHCPv6-based solution would be a good solution in a sense it 685 hooks into general IP configuration phase, allows easy updates when 686 configuration information changes and does not involve DNS in 687 general. Use of DHCPv6 requires configuration changes on DHCPv6 688 clients and servers and in some cases may also require implementation 689 changes. Furthermore, it is not obvious that all devices that need 690 translation services would implement stateless DHCPv6. For example, 691 cellular 3GPP networks do not mandate hosts or network to implement 692 or deploy DHCPv6. 694 4.7. Learning the IPv6 Prefix of a Network's NAT64 using Router 695 Advertisements 697 4.7.1. Solution description 699 Section 3.3 of the version -03 of [I-D.wing-behave-learn-prefix] 700 describes a new Router Advertisement (RA) [RFC4861] option 701 (OPTION_AFT_PREFIX_RA) that contains the IPv6 unicast prefix, IPv6 702 ASM prefix, and IPv6 SSM prefix (and their lengths) for the NAT64. 703 The RA option is essentially the same as for DHCPv6 discussed in 704 Section 4.6. 706 4.7.2. Analysis and discussion 708 The PROs of the proposal are listed below: 710 + Can be used to solve Issue #1, Issue #2, and Issue #3. 712 + Can solve Issue #4 if lifetime information can be communicated. 714 The CONs of the proposal are listed below: 716 - Requires configuration and managements of all access routers to 717 emit correct information in RA. This could, for example, be 718 accomplished somehow by piggybacking on top of routing protocols 719 (which would then require enhancements to routing protocols) 721 - In some operating systems it may not be trivial to transfer 722 information obtained in RA to upper layers 724 - Requires changes to host operating system's IP stack 726 - NSP change requires changes to access router configuration 728 - Requires standardization of a new option to Router Advertisement 729 that is generally unfavored approach 731 - The RA-based solution involves changes and management on network 732 side nodes that are not really part of the NAT64/DNS64 deployment 733 (or issues caused by their existence). 735 If RA would include multiple NSPs issue #5 could be solved as well, 736 but only if nodes as a group would select different NSPs hence 737 supporting load-balancing. As this is not clear this item is not yet 738 listed under PRO nor CON. 740 4.7.3. Summary 742 The RA-based solution would be a good solution in a sense it hooks 743 into general IP configuration phase, allows easy updates when 744 configuration information changes and does not involve DNS in 745 general. However, generally introducing any changes to the Neighbor 746 Discovery Protocol that are not absolutely necessary are unfavored 747 due the impact on both network node side and end host IP stack 748 implementations. 750 Compared to the DHCPv6 equivalent solution in Section 4.6 the 751 management overhead is greater with RA-based solution. In case of 752 DHCPv6-based solution the management can be centralized to few DHCPv6 753 servers compared to RA-based solution where each access router is 754 supposed to be configured with the same information. 756 4.8. Using application layer protocols such as STUN 758 4.8.1. Solution description 760 Application layer protocols, such as Session Traversal Utilities for 761 NAT (STUN) [RFC5389], which define methods for endpoints to learn 762 their external IP addresses could be used for NAT64 and NSP 763 discovery. This document focuses on STUN, but the protocol could be 764 something else as well. 766 A host must first use DNS to discover IPv6 representation(s) of STUN 767 server(s) IPv4 address(es), because the host has no way to directly 768 use IPv4 addresses to contact to STUN server(s). 770 After learning the IPv6 address of a STUN server the STUN client 771 sends a request to the STUN server containing new 'SENDING-TO' 772 attribute that tells to the server the IPv6 address the client sent 773 the request to. In a reply the server includes another new attribute 774 called 'RECEIVED-AS', which contains server's IP address the request 775 arrived on. After receiving the reply the client compares 776 'SENDING-TO' and 'RECEIVED-AS' attributes to find out an NSP 777 candidate. 779 4.8.2. Analysis and discussion 781 This solution is relatively similar as described in section 4.3, but 782 instead of using DNS uses STUN to get input for heuristic algorithms. 784 The PROs of the proposal are listed below: 786 + Can be used to solve Issue #1 and Issue #2. 788 + Does not require host changes or supportive protocols such as DNS 789 or DHCPv6. All required logic and heuristics can be implemented 790 in applications that are interested in learning about address 791 synthesis taking place. 793 + The solution is backward compatible from 'legacy' hosts and 794 servers point of view. 796 + Hosts or applications interested in learning about synthesis and 797 the used NSP can do the "discovery" proactively at any time, for 798 example every time the host attaches to a new network. 800 + Does not require explicit support from the network using NAT64. 802 + Can possibly be bundled to existing STUN message exchanges as new 803 attributes and hence client can learn its external IPv4 address 804 and a NSP/WKP with the same exchange 806 + Can be used to confirm the heuristics by synthesizing IPv6 address 807 of another STUN server or by synthesizing IPv6 address of first 808 STUN server after host has heuristically determined NSP using 809 method from section 4.3. I.e. the connectivity test could be done 810 with STUN. 812 + True IPv4 destination address is used in NSP determination instead 813 of IPv4 address received from DNS. This may increase reliability. 815 + The same STUN improvement could also be used to reveal NAT66 on 816 the data path, if the 'RECEIVED-AS' would contain different IPv6 817 address than 'SENDING-TO'. 819 The CONs of the proposal are listed below: 821 - Requires a server on the network to respond the queries. 823 - Requires standardization if done as extension to STUN. 825 - The solution involves changes and management on network side nodes 826 that are not really part of the NAT64/DNS64 deployment (or issues 827 caused by their existence). 829 - Does not solve issue #3 if STUN server's synthetic IPv6 address is 830 provisioned via DNS. 832 - Does not solve issue #4 as the STUN server would not be aware of 833 learned NSP's validity time. 835 - Does not solve issue #5 as the STUN server would not be aware of 836 multiple NSP prefixes. 838 - Heavyweight solution especially if an application does not 839 otherwise support STUN. 841 4.8.3. Summary 843 The STUN, or similar, protocol based approach is a second way to 844 solve the problem without explicit access network support. The 845 heuristics for NSP discovery would still be in the client, however, 846 the result may be more reliable as actual IPv4 destination address is 847 compared to IPv6 address used in sending. The additional benefit of 848 STUN is that the client learns its public IPv4 address with the same 849 message exchange. STUN could also be used as the connectivity test 850 tool if the client would first heuristically determine NSP out of DNS 851 as described in section 4.3, synthesize IPv6 representation of STUN 852 server's IPv4 address, and then tests connectivity to the STUN 853 server. 855 As an additional benefit the STUN improvement could be used for NAT66 856 discovery. 858 4.9. Learning the IPv6 Prefix of a Network's NAT64 using Access 859 Technology Specific Methods 861 4.9.1. Solution description 863 Several link layers on different access systems have an attachment 864 time signaling protocols to negotiate various parameter used later on 865 the established link layer connection. Examples of such include 3GPP 866 Non-Access-Stratum (NAS) signaling protocol [NAS.24.301] among other 867 link layers and tunneling solutions. There, using NAS signaling it 868 could be possible to list all NSPs with their respective prefix 869 lengths in generic protocol configuration option containers during 870 the network access establishment. The lack of NSPs in protocol 871 configuration option containers would be an implicit indication that 872 there is no NAT64 present in the network. 874 4.9.2. Analysis and discussion 876 The PROs of the proposal are listed below: 878 + Can be used to solve Issue #1, Issue #2, Issue #3 and Issue #5. 880 + Can solve Issue #4 if lifetime information is also communicated. 882 The CONs of the proposal are listed below: 884 - Requires configuration and managements of all access routers/ 885 gateway to emit correct information in "link/lower layer" 886 signaling. In a case the NAT64 functionality is implemented into 887 the access router/gateway itself that terminates the generic 888 protocol configuration exchange, then the configuration management 889 can be automated. 891 - In some operating systems it may not be trivial to transfer 892 information obtained in "link/lower layers" to upper layers. 894 - NSP change may require changes to access router/gateway 895 configuration. 897 - Requires standardization of a new configuration parameter 898 exchange/container for each access system of interest. The 899 proposed solution is indeed specific to each access technology. 901 4.9.3. Summary 903 The Access Technology-based solution would be a good solution in a 904 sense it hooks into general network access establishment phase, 905 allows easy updates when configuration information changes and does 906 not involve DNS in general. However, generally introducing any 907 changes to the link/lower layers is a long and slow router, and yet 908 is access technology/system specific. 910 Compared to the RA equivalent solution in Section 4.7 the management 911 overhead is equivalent or even less than RA-based solution. 913 5. Conclusion 915 Our conclusion is to recommend publishing the Well-Known DNS Name 916 heuristic discovery-based method as a standards track IETF document 917 for applications and host implementors to implement as-is. 919 As a general principle we prefer to have as minimal solution as 920 possible, avoid impacts to entities not otherwise involved in the 921 protocol translation scheme, minimize host impact, and that requires 922 minimal to no operational effort on the network side. 924 Of the different issues we give most weight for issues #1 and #2. We 925 are not giving much weight for the Issue #3 'DNS should not be 926 required', as cases where hosts need to synthesize IPv6 addresses but 927 do not have DNS available seem rare for us. Even if application does 928 not otherwise utilize DNS, it ought to be able to trigger simple DNS 929 query to find out WKP/NSP. Issue #4 is handled by majority of 930 solutions and Issue #5 is considered to be mostly insignificant as 931 even if individual hosts would use only one NSP at a time, different 932 hosts would be using different NSPs, hence supporting load-balancing 933 targets. Only one of the discussed solutions, see Section 4.6, 934 support learning of possible new or indicating support for multiple 935 algorithms for address synthesis other than the one described in 936 [RFC6052]. 938 The DNS64 entity has to be configured with WKP/NSP in order for it to 939 do synthesis and hence using DNS also for delivering the synthesis 940 information sounds logical. The fact that the synthesis information 941 fate-shares the information received in the DNS response is a 942 valuable attribute and reduces the possible distribution of stale 943 prefix information. However, having all DNS64 servers to support 944 explicit WKP/NSP discovery (ENDS0, A64, and DNS SRV record 945 approaches) is difficult to arrange. The U-NAPTR-based approach 946 would require provisioning information into the '.ip6.arpa' tree 947 which would not be entirely internal for the provider. Use of DHCPv6 948 would require additional trouble configuring DHCPv6 servers and 949 ensuring DHCPv6 clients are in place, and furthermore that the NAT64, 950 DHCPv6 (and possible even some DNS64) servers are all in sync. RA- 951 based mechanisms are operationally expensive as configuration would 952 have to be placed and maintained in the access routers. Furthermore, 953 both DHCPv6 and RA based mechanisms involve entities that do not 954 otherwise need to be aware of protocol translation (only need to know 955 DNS server addresses). 957 6. Security Considerations 959 The security considerations are essentially similar to what is 960 described in DNS64 [RFC6147]. Forgery of information required for 961 IPv6 address synthesis may allow an attacker to insert itself as 962 middle man or to perform denial-of-service attack. The DHCPv6 and RA 963 based approaches are vulnerable for the forgery as the attacker may 964 send forged RAs or act as a rogue DHCPv6 server (unless DHCPv6 965 authentication or SEND are used). If the attacker is already able to 966 modify and forge DNS responses (flags, addresses of know IPv4-only 967 servers, records, etc), ability to influence local address synthesis 968 is likely of low additional value. Also, a DNS-based mechanism is 969 only as secure as the method used to configure the DNS server's IP 970 addresses on the host. Therefore, if the host cannot trust e.g. 971 DHCPv6 it cannot trust the DNS server learned via DHCPv6 either, 972 unless the host has a way to authenticate all DNS responses. 974 7. IANA Considerations 976 This document is informative and has no actions to IANA. 978 8. Contributors 980 The following people have contributed text to this document. 982 Mohamed Boucadair 983 France Telecom 984 Rennes, 35000 985 France 987 Email: mohamed.boucadair@orange-ftgroup.com 989 9. Acknowledgements 991 Authors would like to thank Dan Wing and Christian Huitema especially 992 for the STUN idea for their valuable comments and discussions. 994 10. References 996 10.1. Normative References 998 [RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time 999 Streaming Protocol (RTSP)", RFC 2326, April 1998. 1001 [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", 1002 RFC 2671, August 1999. 1004 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1005 A., Peterson, J., Sparks, R., Handley, M., and E. 1006 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1007 June 2002. 1009 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 1010 and M. Carney, "Dynamic Host Configuration Protocol for 1011 IPv6 (DHCPv6)", RFC 3315, July 2003. 1013 [RFC3484] Draves, R., "Default Address Selection for Internet 1014 Protocol version 6 (IPv6)", RFC 3484, February 2003. 1016 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1017 Description Protocol", RFC 4566, July 2006. 1019 [RFC4848] Daigle, L., "Domain-Based Application Service Location 1020 Using URIs and the Dynamic Delegation Discovery Service 1021 (DDDS)", RFC 4848, April 2007. 1023 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 1024 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 1025 September 2007. 1027 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 1028 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 1029 October 2008. 1031 [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 1032 Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, 1033 October 2010. 1035 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 1036 NAT64: Network Address and Protocol Translation from IPv6 1037 Clients to IPv4 Servers", RFC 6146, April 2011. 1039 [RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van 1040 Beijnum, "DNS64: DNS Extensions for Network Address 1041 Translation from IPv6 Clients to IPv4 Servers", RFC 6147, 1042 April 2011. 1044 10.2. Informative References 1046 [I-D.boucadair-behave-dns-a64] 1047 Boucadair, M. and E. Burgey, "A64: DNS Resource Record for 1048 IPv4-Embedded IPv6 Address", 1049 draft-boucadair-behave-dns-a64-02 (work in progress), 1050 September 2010. 1052 [I-D.boucadair-dhcpv6-shared-address-option] 1053 Boucadair, M., Levis, P., Grimault, J., Savolainen, T., 1054 and G. Bajko, "Dynamic Host Configuration Protocol 1055 (DHCPv6) Options for Shared IP Addresses Solutions", 1056 draft-boucadair-dhcpv6-shared-address-option-01 (work in 1057 progress), December 2009. 1059 [I-D.carpenter-referral-ps] 1060 Carpenter, B., Jiang, S., and Z. Cao, "Problem Statement 1061 for Referral", draft-carpenter-referral-ps-02 (work in 1062 progress), February 2011. 1064 [I-D.korhonen-edns0-synthesis-flag] 1065 Korhonen, J. and T. Savolainen, "EDNS0 Option for 1066 Indicating AAAA Record Synthesis and Format", 1067 draft-korhonen-edns0-synthesis-flag-02 (work in progress), 1068 February 2011. 1070 [I-D.savolainen-heuristic-nat64-discovery] 1071 Savolainen, T. and J. Korhonen, "Discovery of a Network- 1072 Specific NAT64 Prefix using a Well-Known Name", 1073 draft-savolainen-heuristic-nat64-discovery-01 (work in 1074 progress), February 2011. 1076 [I-D.venaas-behave-mcast46] 1077 Venaas, S., Asaeda, H., SUZUKI, S., and T. Fujisaki, "An 1078 IPv4 - IPv6 multicast translator", 1079 draft-venaas-behave-mcast46-02 (work in progress), 1080 December 2010. 1082 [I-D.venaas-behave-v4v6mc-framework] 1083 Venaas, S., Li, X., and C. Bao, "Framework for IPv4/IPv6 1084 Multicast Translation", 1085 draft-venaas-behave-v4v6mc-framework-03 (work in 1086 progress), June 2011. 1088 [I-D.wing-behave-learn-prefix] 1089 Wing, D., "Learning the IPv6 Prefix of a Network's IPv6/ 1090 IPv4 Translator", draft-wing-behave-learn-prefix-04 (work 1091 in progress), October 2009. 1093 [NAS.24.301] 1094 3GPP, "Non-Access-Stratum (NAS) protocol for Evolved 1095 Packet System (EPS)", 3GPP TS 24.301 8.8.0, December 2010. 1097 [RFC5507] IAB, Faltstrom, P., Austein, R., and P. Koch, "Design 1098 Choices When Expanding the DNS", RFC 5507, April 2009. 1100 [RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for 1101 IPv4/IPv6 Translation", RFC 6144, April 2011. 1103 Authors' Addresses 1105 Jouni Korhonen (editor) 1106 Nokia Siemens Networks 1107 Linnoitustie 6 1108 FI-02600 Espoo 1109 Finland 1111 Email: jouni.nospam@gmail.com 1113 Teemu Savolainen (editor) 1114 Nokia 1115 Hermiankatu 12 D 1116 FI-33720 Tampere 1117 Finland 1119 Email: teemu.savolainen@nokia.com