idnits 2.17.1 draft-korhonen-behave-nat64-learn-analysis-02.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 (February 22, 2011) is 4810 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-02) exists of draft-korhonen-edns0-synthesis-flag-00 == Outdated reference: A later version (-02) exists of draft-carpenter-referral-ps-01 -- Duplicate reference: draft-korhonen-edns0-synthesis-flag, mentioned in 'I-D.korhonen-edns0-synthesis-flag', was also mentioned in 'EDNS0-Flag'. == Outdated reference: A later version (-03) exists of draft-venaas-behave-v4v6mc-framework-02 == Outdated reference: A later version (-04) exists of draft-wing-behave-learn-prefix-03 -- Duplicate reference: draft-wing-behave-learn-prefix, mentioned in 'RA-Learn-Prefix', was also mentioned in 'I-D.wing-behave-learn-prefix'. -- Obsolete informational reference (is this intentional?): RFC 2326 (Obsoleted by RFC 7826) -- Obsolete informational reference (is this intentional?): RFC 2671 (Obsoleted by RFC 6891) -- Obsolete informational reference (is this intentional?): RFC 3315 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 3484 (Obsoleted by RFC 6724) -- Obsolete informational reference (is this intentional?): RFC 4566 (Obsoleted by RFC 8866) -- Obsolete informational reference (is this intentional?): RFC 5389 (Obsoleted by RFC 8489) Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 9 comments (--). 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: August 26, 2011 February 22, 2011 8 Analysis of solution proposals for hosts to learn NAT64 prefix 9 draft-korhonen-behave-nat64-learn-analysis-02.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. This enables both NAT64 avoidance and intentional utilization 19 by allowing local IPv6 address synthesis. 21 Status of this Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on August 26, 2011. 38 Copyright Notice 40 Copyright (c) 2011 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 2. Terminology and Assumptions . . . . . . . . . . . . . . . . . 4 57 3. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 6 58 4. Proposed solutions to learn about synthesis and 59 Network-Specific Prefix . . . . . . . . . . . . . . . . . . . 7 60 4.1. EDNS0 option indicating AAAA Record synthesis and 61 format . . . . . . . . . . . . . . . . . . . . . . . . . . 7 62 4.1.1. Solution description . . . . . . . . . . . . . . . . . 7 63 4.1.2. Analysis and discussion . . . . . . . . . . . . . . . 8 64 4.1.3. Summary . . . . . . . . . . . . . . . . . . . . . . . 9 65 4.2. EDNS0 flags indicating AAAA Record synthesis and format . 9 66 4.2.1. Solution description . . . . . . . . . . . . . . . . . 9 67 4.2.2. Analysis and discussion . . . . . . . . . . . . . . . 9 68 4.2.3. Summary . . . . . . . . . . . . . . . . . . . . . . . 10 69 4.3. DNS Query for a Well-Known Name . . . . . . . . . . . . . 10 70 4.3.1. Solution description . . . . . . . . . . . . . . . . . 10 71 4.3.2. Analysis and discussion . . . . . . . . . . . . . . . 11 72 4.3.3. Summary . . . . . . . . . . . . . . . . . . . . . . . 11 73 4.4. DNS Resource Record for IPv4-Embedded IPv6 address . . . . 11 74 4.4.1. Solution description . . . . . . . . . . . . . . . . . 12 75 4.4.2. Analysis and discussion . . . . . . . . . . . . . . . 12 76 4.4.3. Summary . . . . . . . . . . . . . . . . . . . . . . . 13 77 4.5. Learning the IPv6 Prefix of a Network's NAT64 using DNS . 13 78 4.5.1. Solution description . . . . . . . . . . . . . . . . . 13 79 4.5.2. Analysis and discussion . . . . . . . . . . . . . . . 13 80 4.5.3. Summary . . . . . . . . . . . . . . . . . . . . . . . 14 81 4.6. Learning the IPv6 Prefix of a Network's NAT64 using 82 DHCPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . 15 83 4.6.1. Solution description . . . . . . . . . . . . . . . . . 15 84 4.6.2. Analysis and discussion . . . . . . . . . . . . . . . 15 85 4.6.3. Summary . . . . . . . . . . . . . . . . . . . . . . . 16 86 4.7. Learning the IPv6 Prefix of a Network's NAT64 using 87 Router Advertisements . . . . . . . . . . . . . . . . . . 16 88 4.7.1. Solution description . . . . . . . . . . . . . . . . . 16 89 4.7.2. Analysis and discussion . . . . . . . . . . . . . . . 16 90 4.7.3. Summary . . . . . . . . . . . . . . . . . . . . . . . 17 91 4.8. Using application layer protocols such as STUN . . . . . . 17 92 4.8.1. Solution description . . . . . . . . . . . . . . . . . 17 93 4.8.2. Analysis and discussion . . . . . . . . . . . . . . . 18 94 4.8.3. Summary . . . . . . . . . . . . . . . . . . . . . . . 19 95 4.9. Learning the IPv6 Prefix of a Network's NAT64 using 96 Access Technology Specific Methods . . . . . . . . . . . . 19 97 4.9.1. Solution description . . . . . . . . . . . . . . . . . 20 98 4.9.2. Analysis and discussion . . . . . . . . . . . . . . . 20 99 4.9.3. Summary . . . . . . . . . . . . . . . . . . . . . . . 20 100 5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 21 101 6. Security Considerations . . . . . . . . . . . . . . . . . . . 22 102 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 103 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 22 104 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22 105 10. Informative References . . . . . . . . . . . . . . . . . . . . 23 106 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 108 1. Introduction 110 Hosts and applications may benefit from the knowledge of whether an 111 IPv6 address is synthesized, which would mean a NAT64 is used to 112 reach the IPv4 network or Internet. There are two issues that can be 113 addressed with solutions that allow hosts and applications to learn 114 the Network Specific Prefix (NSP) [RFC6052] used by the NAT64 115 [I-D.ietf-behave-v6v4-xlate-stateful] and the DNS64 116 [I-D.ietf-behave-dns64] devices. 118 Firstly, finding out whether a particular address is synthetic and 119 therefore learning the presence of a NAT64. For example, a Dual- 120 Stack (DS) host with IPv4 connectivity could use this information to 121 bypass NAT64 and use native IPv4 transport for destinations that are 122 reachable through IPv4. We will refer this as 'Issue #1' throughout 123 the document. 125 Secondly, finding out how to construct from an IPv4 address an IPv6 126 address that will be routable to/by the NAT64. This is useful when 127 IPv4 literals can be found in the payload of some protocol or 128 applications do not use DNS to resolve names to addresses but know 129 the IPv4 address of the destination by some other means. We will 130 refer this as 'Issue #2' throughout the document. 132 Additionally three other issues have to be considered by a solution 133 addressing the first two issues: whether DNS is required 'Issue #3', 134 whether a solution supports changing NSP 'Issue #4', and whether 135 multiple NSPs are supported (either of the same or different length) 136 for load-balancing purposes 'Issue #5'. 138 This document analyses all known solution proposals known at the time 139 of writing for communicating if the synthesis is taking place, used 140 address format, and the IPv6 prefix used by the NAT64 and DNS64. 141 Based on the analysis we conclude whether the issue of learning the 142 Network-Specific Prefix is worth solving and what would be the 143 recommended solution(s) in that case. 145 2. Terminology and Assumptions 147 NSP 149 Network-Specific Prefix: A prefix chosen by network administrator 150 for NAT64/DNS64 to present IPv4 addresses in IPv6 namespace. 152 WKP 154 Well-Known Prefix: A prefix (64:ff9b::/96) chosen by IETF and 155 configured by a network administrator for NAT64/DNS64 to present 156 IPv4 addresses in IPv6 namespace. 158 NAT64 160 Network Address and protocol Translation mechanism for translating 161 IPv6 packets to IPv4 packets and vice-versa: A network entity that 162 a host or an application may want to either avoid or utilize. 163 IPv6 packets hosts send to addresses in the NSP and/or WKP are 164 routed to NAT64. 166 DNS64 168 DNS extensions for network address translation from IPv6 clients 169 to IPv4 servers: A network entity that synthesizes IPv6 addresses 170 and AAAA records out of IPv4 addresses and A records, hence making 171 IPv4 namespaces visible into IPv6 namespace. DNS64 uses NSP 172 and/or WKP in the synthesis process. 174 Address Synthesis 176 A mechanism, in the context of this document, where an IPv4 177 address is represented as an IPv6 address understood by a NAT64 178 device. The synthesized IPv6 address is formed by embedding an 179 IPv4 address as-is into an IPv6 address prefixed with a NSP/WKP. 180 It is assumed that the 'unused' suffix bits of the synthesized 181 address are set to zero as described in Section 2.2 of [RFC6052]. 183 Issue #1 185 The problem of distinguishing between a synthesized and a real 186 IPv6 addresses, which allows a host to learn the presence of a 187 NAT64 in the network. 189 Issue #2 191 The problem of learning the NSP used by the access network and 192 needed for local IPv6 address synthesis. 194 Issue #3 196 The problem of learning the NSP or WKP used by the access network 197 by a host not implementing DNS (hence applications are unable to 198 use DNS to learn prefix). 200 Issue #4 202 The problem of supporting changing NSP. The NSP learned by the 203 host may become stale for multiple reasons. For example, the host 204 might move to a new network that uses different NSP, thus making 205 the previously learned NSP stale. Also, the NSP used in the 206 network may be changed due administrative reasons, thus again 207 making previously learned NSP stale. 209 Issue #5 211 The problem of supporting multiple NSPs. A network may be 212 configured with multiple NSPs for address synthesis. For example, 213 for load-balancing purposes each NAT64 device in the same network 214 could be assigned with their own NSP. It should be noted that 215 learning a single NSP is enough for an end host to successfully 216 perform local IPv6 address synthesis but to avoid NAT64 the end 217 host needs to learn all NSPs used by the access network. 219 3. Background 221 Certain applications, operating in protocol translation scenarios, 222 can benefit from knowing the IPv6 prefix used by a local NAT64 of the 223 attached access network. This applies to the Framework document 224 [I-D.ietf-behave-v6v4-framework] Scenario 1 ("IPv6 network to IPv4 225 Internet"), Scenario 5 ("An IPv6 network to an IPv4 network"), and 226 Scenario 7 ("The IPv6 Internet to the IPv4 Internet"). Scenario 227 3("The IPv6 Internet to an IPv4 network") is not considered 228 applicable herein as in that case a NAT64 is located at the front of 229 remote IPv4 network and host in IPv6 Internet can benefit very little 230 of learning NSP IPv6 prefix used by the remote NAT64. The NAT64 231 prefix can be either a Network Specific Prefix (NSP) or the Well- 232 known Prefix (WKP). Below is (an incomplete) list of various use 233 cases where it is beneficial for a host or an application to know the 234 presence of a NAT64 and the NSP/WKP: 236 o Host-based DNSSEC validation: as is documented in DNS64 237 [I-D.ietf-behave-dns64] section 5.5. point 3, synthetic AAAA 238 records cannot be successfully validated in a host. In order to 239 utilize NAT64 a security-aware and validating host has to perform 240 DNS64 function locally and hence it has to be able to learn WKP or 241 proper NSP. 243 o Protocols that use IPv4 literals: in IPv6-only access native IPv4 244 connections cannot be created. If a network has NAT64 it is 245 possible to synthesize IPv6 address by combining the IPv4 literal 246 and the IPv6 prefix used by NAT64. The synthesized IPv6 address 247 can then be used to create an IPv6 connection. 249 o Multicast translations 250 [I-D.venaas-behave-mcast46][I-D.venaas-behave-v4v6mc-framework]. 252 o URI schemes with host IPv4 address literals rather than domain 253 names (e.g., http://192.0.2.1, ftp://192.0.2.1, imap://192.0.2.1, 254 ipp://192.0.2.1)): a host can synthesize IPv6 address out of the 255 literal in URI and use IPv6 to create connection through NAT64. 257 o Updating host's [RFC3484] preference table to prefer native 258 prefixes over translated prefixes: this is useful as applications 259 are more likely able to traverse through NAT44 than NAT64. 261 DNS64 cannot serve applications that are not using DNS or that obtain 262 referral as an IPv4 literal address. One example application is the 263 Session Description Protocol (SDP) [RFC4566], as used by Real Time 264 Streaming Protocol (RTSP) [RFC2326] and Session Initiation Protocol 265 (SIP) [RFC3261]. Other example applications include web browsers, as 266 IPv4 address literals are still encountered in web pages and URLs. 267 Some of these applications could still work through NAT64, provided 268 they were able to create locally valid IPv6 presentations of peers' 269 IPv4 addresses. 271 It is a known issue that passing IP address referrals, often fails in 272 today's Internet [I-D.carpenter-referral-ps]. Synthesizing IPv6 273 addresses does not necessarily make the situation any better as the 274 synthesized addresses are not distinguishable from public IPv6 275 addresses for the referral receiver. However, the situation is not 276 really any different from the current Internet as using public 277 addresses does not really guarantee reachability (for example due 278 firewalls). Therefore, we think that it is up to the referral 279 originating host to somehow identify that the IPv6 address is 280 made-up. 282 4. Proposed solutions to learn about synthesis and Network-Specific 283 Prefix 285 4.1. EDNS0 option indicating AAAA Record synthesis and format 287 4.1.1. Solution description 289 Section 3 of [I-D.korhonen-edns0-synthesis-flag] defines a new EDNS0 290 option [RFC2671], which contain 3 flag bits (called SY-bits). The 291 EDNS0 option serves as an implicit indication of the presence of 292 DNS64 server and the NAT64 device. The EDNS0 option SY-bit values 293 other than '000' and '111' explicitly tell the NSP prefix length. 295 Only the DNS64 server can insert the EDNS0 option and the required 296 SY-bits combination into the synthesized AAAA Resource Record. 298 4.1.2. Analysis and discussion 300 The PROs of the proposal are listed below: 302 + Can be used to solve Issue #1 and is designed to explicitly solve 303 Issue #2. 305 + Solves issue #4 via DNS record lifetime. 307 + Can partially solve issue #5 if multiple synthetic AAAA records 308 are included in the response and all use same format. 310 + The solution is backward compatible from 'legacy' hosts and 311 servers point of view. 313 + Even if the solution is bundled with DNS queries and responses, a 314 standardization of a new DNS record type is not required, rather 315 just defining a new EDNS0 option. 317 + EDNS0 option implementation requires changes only to DNS64 318 servers. 320 + Does not require additional provisioning or management as the 321 EDNS0 option is added automatically by the DNS64 server to the 322 responses. 324 + Does not involve additional queries towards the global DNS 325 infrastructure as EDNS0 logic can be handled within the DNS64 326 server. 328 The CONs of the proposal are listed below: 330 - Requires end hosts to support [RFC2671] EDSN0 extension mechanism. 332 - Requires host resolver changes and a mechanism/additions to the 333 host resolver API (or flags, hints etc) to deliver a note to the 334 querying application that the address is synthesized and what is 335 the NSP prefix length. 337 - Requires a modification to DNS64 servers to include the EDNS0 338 option to the synthesized responses. 340 - Does not provide solution for issue #3. 342 4.1.3. Summary 344 The EDNS0 option based solution works by extending the existing EDNS0 345 Resource Record. Although the solution has host resolver and DNS64 346 server impacts, the changes are limited to those entities (end host, 347 applications) that are interested in learning the presence of NAT64 348 and the used NAT64 prefix. The provisioning and management overhead 349 is minimal if not non-existent as the EDNS0 options are synthesized 350 in a DNS64 server in a same manner as the synthesized AAAA Resource 351 Records. Moreover, EDNS0 does not induce any load to DNS servers 352 because no new RRType query is defined. 354 4.2. EDNS0 flags indicating AAAA Record synthesis and format 356 4.2.1. Solution description 358 Section 3 of [EDNS0-Flag] defines 3 new flag bits (called SY-bits) 359 into EDNS0 OPT [RFC2671] header, which serve as an implicit 360 indication of the presence of DNS64 server and a NAT64 device. SY- 361 bit values other than '000' or '111' explicitly tell the NSP prefix 362 length. Only the DNS64 server can insert the EDNS0 option and the 363 required SY-bits combination into the synthesized AAAA Resource 364 Record. 366 4.2.2. Analysis and discussion 368 The PROs of the proposal are listed below: 370 + Can be used to solve Issue #1 and is designed to explicitly solve 371 Issue #2. 373 + Solves issue #4 via DNS record lifetime. 375 + Can partially solve issue #5 if multiple synthetic AAAA records 376 are included in the response and all use same format. 378 + The solution is backward compatible from 'legacy' hosts and 379 servers point of view. 381 + EDNS0 option implementation requires changes only to DNS64 382 servers. 384 + Does not require additional provisioning or management as the 385 EDNS0 option is added automatically by the DNS64 server to the 386 responses. 388 + Does not involve additional queries towards the global DNS 389 infrastructure as EDNS0 logic can be handled within the DNS64 390 server. 392 The CONs of the proposal are listed below: 394 - Requires end hosts to support [RFC2671] EDSN0 extension mechanism. 396 - Consumes scarce flag bits from EDNS0 OPT header. 398 - Requires a host resolver changes and a mechanism/additions to the 399 host resolver API (or flags, hints etc) to deliver a note to the 400 querying application that the address is synthesized and what is 401 the NSP prefix length. 403 - Requires a modification to DNS64 servers to include the EDNS0 404 option to the synthesized responses. 406 - Does not provide solution for issue #3. 408 4.2.3. Summary 410 This option is included here for the sake of completeness. The 411 consumption of three bits of the limited EDNS0 OPT space can be 412 considered unfavorable and hence is unlikely to be accepted. 414 4.3. DNS Query for a Well-Known Name 416 4.3.1. Solution description 418 Section 3 of [I-D.savolainen-heuristic-nat64-discovery] describes a 419 host behavior for discovering the presence of a DNS64 server and a 420 NAT64 device, and heuristics for discovering the used NSP. A host 421 requiring information for local IPv6 address synthesis or for NAT64 422 avoidance sends a DNS query for an AAAA record of a Well-Known IPv4- 423 only Fully Qualified Domain Name (FQDN). If a host receives a 424 negative reply, it knows there are no DNS64 and NAT64 in the network. 426 If a host receives AAAA reply, it knows the network must be utilizing 427 IPv6 address synthesis. After receiving a synthesized AAAA Resource 428 Record, the host may examine the received IPv6 address and use 429 heuristics, such as "subtracting" the known IPv4 address out of 430 synthesized IPv6 address, to find out the NSP. 432 The Well-Known Name may be assigned by IANA or provided some third 433 party, including application or operating system vendor. The IPv4 434 address corresponding to the Well-Known Name may be resolved via A 435 query to Well-Known Name, assigned by IANA, or hard-coded. 437 4.3.2. Analysis and discussion 439 The PROs of the proposal are listed below: 441 + Can be used to solve Issue #1 and Issue #2. 443 + Solves issue #4 via DNS record lifetime. 445 + Can partially solve issue #5 if multiple synthetic AAAA records 446 are included in the response. Can find multiple address formats. 448 + Does not necessarily require any standards effort. 450 + Does not require host stack or resolver changes. All required 451 logic and heuristics can be implemented in applications that are 452 interested in learning about address synthesis taking place. 454 + The solution is backward compatible from 'legacy' hosts and 455 servers point of view. 457 + Hosts or applications interested in learning about synthesis and 458 the used NSP can do the "discovery" proactively at any time, for 459 example every time the host attaches to a new network. 461 + Does not require explicit support from the network using NAT64 463 The CONs of the proposal are listed below: 465 - Requires hosting of a DNS resource record for the Well-Known Name. 467 - Does not provide solution for issue #3. 469 - This method is only able to find one NSP even if a network is 470 utilizing multiple NSPs (issue #5) (unless DNS64 includes multiple 471 synthetic AAAA records in response). 473 4.3.3. Summary 475 This is the only approach that can be deployed without explicit 476 support from the network or the host. This approach could also 477 complement explicit methods and be used as a fallback approach when 478 explicit methods are not supported by an access network. 480 4.4. DNS Resource Record for IPv4-Embedded IPv6 address 481 4.4.1. Solution description 483 Section 4 of [I-D.boucadair-behave-dns-a64] defines a new DNS 484 Resource Record (A64) that is a record specific to store a single 485 IPv4-Embedded IPv6 address [RFC6052]. Using a dedicated Resource 486 Record allows a host to distinguish between real IPv6 addresses and 487 synthesized IPv6 addresses. The solution requires host to send a 488 query for an A64 record. Positive answer with A64 record informs the 489 requesting host that the resolved address is not a native address but 490 an IPv4-Embedded IPv6 address. This would ease the local policies to 491 prefer direct communications (i.e., avoid using IPv4-Embedded IPv6 492 addresses when a native IPv6 address or a native IPv4 address is 493 available). Applications may be notified via new or modified API. 495 4.4.2. Analysis and discussion 497 The PROs of the proposal are listed below: 499 + Can be used to solve Issue #1 and #5. 501 + Solves issue #4 via DNS record lifetime. 503 + The solution is backward compatible from 'legacy' hosts and 504 servers point of view. 506 + Synthesized addresses can be used in authoritative DNS servers. 508 + Maintains the reliability of the DNS model (i.e., a synthesised 509 IPv6 address is presented as such and not as native IPv6 address). 511 + When both IPv4-Converted and native IPv6 addresses are configured 512 for the same QNAME, native addresses are preferred. 514 The CONs of the proposal are listed below: 516 - Does not address Issue #2 or #3 in any way. 518 - Requires a host resolver changes and a mechanism/additions to the 519 host resolver API (or flags, hints etc) to deliver a note to the 520 querying application that the address is synthesized. 522 - Requires a standardization of a new DNS Resource Record type 523 (A64), and the implementation of it in both resolvers and servers. 525 - Requires a coordinated deployment between different flavors of DNS 526 servers within the provider to work deterministically. 528 - Additional load the DNS servers (3 Queries, A64, AAAA and A, may 529 be issued by a dual-stack host). 531 - Does not help to identify synthesized IPv6 addresses if the 532 session does not involve any DNS queries. 534 4.4.3. Summary 536 While the proposed solution delivers explicit information about 537 address synthesis taking place solving the Issue #1, a 538 standardization of a new DNS record type might turn out a too 539 overwhelming task for a solution for a temporary transition phase. 540 Defining a new record type increases load towards DNS server as the 541 host issues parallel A64, AAAA and A queries. 543 4.5. Learning the IPv6 Prefix of a Network's NAT64 using DNS 545 4.5.1. Solution description 547 Section 4.1 of [I-D.wing-behave-learn-prefix] actually proposes two 548 DNS-based method for discovering the presence of a DNS64 server and a 549 NAT64 device, and then a mechanism for discovering the used NSP. 550 First, a host may learn the presence of a DNS64 server and a NAT64 551 device, by receiving a TXT Resource Record with a well-known (TBD 552 IANA registered?) string followed by the NAT64 unicast IPv6 address 553 and the prefix length. The DNS64 server would add the TXT Resource 554 Record into the DNS response. 556 Second, Section 4.1 of [I-D.wing-behave-learn-prefix] also proposes 557 specifying a new U-NAPTR [RFC4848] application to discover the 558 NAT64's IPv6 prefix and length. The input domain name is exactly the 559 same as would be used for a reverse DNS lookup, derived from the 560 host's IPv6 in the ".ip6.arpa." tree. The host doing the U-NAPTR 561 queries may need multiple queries until finds the provisioned domain 562 name with the correct prefix length. The response to a successful 563 U-NATPR query contains the unicast IPv6 address and the prefix length 564 of the NAT64 device. 566 4.5.2. Analysis and discussion 568 [Editor' note: can this be made to solve issue #5 by having multiple 569 NSPs in TXT record?] 571 The PROs of the proposal are listed below: 573 + Can be used to solve Issue #1 and Issue #2. 575 + Solves issue #4 via DNS record lifetime. 577 + Does not require host stack or resolver changes if the required 578 logic and heuristics is implemented in applications that are 579 interested in learning about address synthesis taking place. 581 The CONs of the proposal are listed below: 583 - Requires standardization of a well-known names from IANA for TXT 584 Resource Record and/or a standardization of a new U-NAPTR 585 application. 587 - Requires a host resolver changes and a mechanism/additions to the 588 host resolver API (or flags, hints etc) to deliver a note to the 589 querying application that the address is synthesized and what is 590 the NSP prefix length. However, it is possible that the U-NAPTR 591 application logic is completely implemented by the application 592 itself as noted in PROs list. 594 - U-NAPTR prefix learning method may entail multiple queries. 596 - U-NAPTR prefix learning method requires provisioning of NSPs in 597 ".ip6.arpa." tree. 599 - RFC5507 [RFC5507] specifically recommends against reusing TXT 600 Resource Records to expand DNS. 602 - Requires configuration on the access network's DNS servers. 604 - Does not provide solution for issue #3. 606 4.5.3. Summary 608 The implementation of this solution requires some changes to the 609 applications and resolvers in a similar fashion as in solutions in 610 Section 4.1, Section 4.2 and Section 4.4. Unlike the other DNS-based 611 approaches, the U-NAPTR-based solution also requires provisioning 612 information into the '.ip6.arpa.' tree which is not any more entirely 613 internal to the provider hosting the NAT64/DNS64 service. 615 The iterative approach of learning the NAT64 prefix in U-NAPTR-based 616 solution may result in multiple DNS queries, which can be considered 617 more complex and inefficient compared to other DNS-based solutions. 619 4.6. Learning the IPv6 Prefix of a Network's NAT64 using DHCPv6 621 4.6.1. Solution description 623 Two individual drafts specify DHCPv6 based approaches. 625 Section 4.2 of [I-D.wing-behave-learn-prefix] describes a new DHCPv6 626 [RFC3315] option (OPTION_AFT_PREFIX_DHCP) that contains the IPv6 627 unicast prefix, IPv6 ASM prefix, and IPv6 SSM prefix (and their 628 lengths) for the NAT64. 630 Section 4 of [I-D.boucadair-dhcpv6-shared-address-option] defines a 631 DHCPv6 option that can be used to communicate to a requesting host 632 the prefix used for building IPv4-Converted IPv6 addresses together 633 with the format type. Provisioning the format type is required so as 634 to be correctly handled by the NAT64-enabled devices deployed in a 635 given domain. 637 4.6.2. Analysis and discussion 639 The PROs of the proposal are listed below: 641 + Can be used to solve Issue #1, Issue #2, Issue #3 and Issue #4 via 642 DHCPv6 information lifetime. 644 + Does not involve DNS system. Therefore, applications that would 645 not normally initiate any DNS queries can still learn the NAT64 646 prefix. 648 + DHCPv6 is designed to provide various kinds of configuration 649 information in a centrally managed fashion. 651 The CONs of the proposal are listed below: 653 - Change of NSP requires change to DHCPv6 configuration. 655 - Requires at least Stateless DHCPv6 client on hosts. 657 - Requires support on DHCPv6 clients, which is not trivial in all 658 operating systems. 660 - The DHCPv6-based solution involves changes and management on 661 network side nodes that are not really part of the NAT64/DNS64 662 deployment (or issues caused by their existence). 664 - A new DHCPv6 option is required and the corresponding changes to 665 both DHCPv6 clients and servers. 667 If DHCPv6 would include multiple NSPs issue #5 could be solved as 668 well, but only if nodes as a group would select different NSPs hence 669 supporting load-balancing. As this is not clear this item is not yet 670 listed under PRO nor CON. 672 4.6.3. Summary 674 The DHCPv6-based solution would be a good solution in a sense it 675 hooks into general IP configuration phase, allows easy updates when 676 configuration information changes and does not involve DNS in 677 general. Use of DHCPv6 requires configuration changes on DHCPv6 678 clients and servers and in some cases may also require implementation 679 changes. Furthermore, it is not obvious that all devices that need 680 translation services would implement stateless DHCPv6. For example, 681 cellular 3GPP networks do not mandate hosts or network to implement 682 or deploy DHCPv6. 684 4.7. Learning the IPv6 Prefix of a Network's NAT64 using Router 685 Advertisements 687 4.7.1. Solution description 689 Section 3.3 of [RA-Learn-Prefix] describes a new Router Advertisement 690 (RA) [RFC4861] option (OPTION_AFT_PREFIX_RA) that contains the IPv6 691 unicast prefix, IPv6 ASM prefix, and IPv6 SSM prefix (and their 692 lengths) for the NAT64. The RA option is essentially the same as for 693 DHCPv6 discussed in Section 4.6. 695 4.7.2. Analysis and discussion 697 The PROs of the proposal are listed below: 699 + Can be used to solve Issue #1, Issue #2, and Issue #3. 701 + Can solve Issue #4 if lifetime information can be communicated. 703 The CONs of the proposal are listed below: 705 - Requires configuration and managements of all access routers to 706 emit correct information in RA. This could, for example, be 707 accomplished somehow by piggybacking on top of routing protocols 708 (which would then require enhancements to routing protocols) 710 - In some operating systems it may not be trivial to transfer 711 information obtained in RA to upper layers 713 - Requires changes to host operating system's IP stack 715 - NSP change requires changes to access router configuration 717 - Requires standardization of a new option to Router Advertisement 718 that is generally unfavored approach 720 - The RA-based solution involves changes and management on network 721 side nodes that are not really part of the NAT64/DNS64 deployment 722 (or issues caused by their existence). 724 If RA would include multiple NSPs issue #5 could be solved as well, 725 but only if nodes as a group would select different NSPs hence 726 supporting load-balancing. As this is not clear this item is not yet 727 listed under PRO nor CON. 729 4.7.3. Summary 731 The RA-based solution would be a good solution in a sense it hooks 732 into general IP configuration phase, allows easy updates when 733 configuration information changes and does not involve DNS in 734 general. However, generally introducing any changes to the Neighbor 735 Discovery Protocol that are not absolutely necessary are unfavored 736 due the impact on both network node side and end host IP stack 737 implementations. 739 Compared to the DHCPv6 equivalent solution in Section 4.6 the 740 management overhead is greater with RA-based solution. In case of 741 DHCPv6-based solution the management can be centralized to few DHCPv6 742 servers compared to RA-based solution where each access router is 743 supposed to be configured with the same information. 745 4.8. Using application layer protocols such as STUN 747 4.8.1. Solution description 749 Application layer protocols, such as Session Traversal Utilities for 750 NAT (STUN) [RFC5389], which define methods for endpoints to learn 751 their external IP addresses could be used for NAT64 and NSP 752 discovery. This document focuses on STUN, but the protocol could be 753 something else as well. 755 A host must first use DNS to discover IPv6 representation(s) of STUN 756 server(s) IPv4 address(es), because the host has no way to directly 757 use IPv4 addresses to contact to STUN server(s). 759 After learning the IPv6 address of a STUN server the STUN client 760 sends a request to the STUN server containing new 'SENDING-TO' 761 attribute that tells to the server the IPv6 address the client sent 762 the request to. In a reply the server includes another new attribute 763 called 'RECEIVED-AS', which contains server's IP address the request 764 arrived on. After receiving the reply the client compares 765 'SENDING-TO' and 'RECEIVED-AS' attributes to find out an NSP 766 candidate. 768 4.8.2. Analysis and discussion 770 This solution is relatively similar as described in section 4.3, but 771 instead of using DNS uses STUN to get input for heuristic algorithms. 773 The PROs of the proposal are listed below: 775 + Can be used to solve Issue #1 and Issue #2. 777 + Does not require host changes or supportive protocols such as DNS 778 or DHCPv6. All required logic and heuristics can be implemented 779 in applications that are interested in learning about address 780 synthesis taking place. 782 + The solution is backward compatible from 'legacy' hosts and 783 servers point of view. 785 + Hosts or applications interested in learning about synthesis and 786 the used NSP can do the "discovery" proactively at any time, for 787 example every time the host attaches to a new network. 789 + Does not require explicit support from the network using NAT64. 791 + Can possibly be bundled to existing STUN message exchanges as new 792 attributes and hence client can learn its external IPv4 address 793 and a NSP/WKP with the same exchange 795 + Can be used to confirm the heuristics by synthesizing IPv6 address 796 of another STUN server or by synthesizing IPv6 address of first 797 STUN server after host has heuristically determined NSP using 798 method from section 4.3. I.e. the connectivity test could be done 799 with STUN. 801 + True IPv4 destination address is used in NSP determination instead 802 of IPv4 address received from DNS. This may increase reliability. 804 + The same STUN improvement could also be used to reveal NAT66 on 805 the data path, if the 'RECEIVED-AS' would contain different IPv6 806 address than 'SENDING-TO'. 808 The CONs of the proposal are listed below: 810 - Requires a server on the network to respond the queries. 812 - Requires standardization if done as extension to STUN. 814 - The solution involves changes and management on network side nodes 815 that are not really part of the NAT64/DNS64 deployment (or issues 816 caused by their existence). 818 - Does not solve issue #3 if STUN server's synthetic IPv6 address is 819 provisioned via DNS. 821 - Does not solve issue #4 as the STUN server would not be aware of 822 learned NSP's validity time. 824 - Does not solve issue #5 as the STUN server would not be aware of 825 multiple NSP prefixes. 827 - Heavyweight solution especially if an application does not 828 otherwise support STUN. 830 4.8.3. Summary 832 The STUN, or similar, protocol based approach is a second way to 833 solve the problem without explicit access network support. The 834 heuristics for NSP discovery would still be in the client, however, 835 the result may be more reliable as actual IPv4 destination address is 836 compared to IPv6 address used in sending. The additional benefit of 837 STUN is that the client learns its public IPv4 address with the same 838 message exchange. STUN could also be used as the connectivity test 839 tool if the client would first heuristically determine NSP out of DNS 840 as described in section 4.3, synthesize IPv6 representation of STUN 841 server's IPv4 address, and then tests connectivity to the STUN 842 server. 844 As an additional benefit the STUN improvement could be used for NAT66 845 discovery. 847 4.9. Learning the IPv6 Prefix of a Network's NAT64 using Access 848 Technology Specific Methods 850 4.9.1. Solution description 852 Several link layers on different access systems have an attachment 853 time signaling protocols to negotiate various parameter used later on 854 the established link layer connection. Examples of such include 3GPP 855 Non-Access-Stratum (NAS) signaling protocol [3GPP.24.301] among other 856 link layers and tunneling solutions. There, using NAS signaling it 857 could be possible to list all NSPs with their respective prefix 858 lengths in generic protocol configuration option containers during 859 the network access establishment. The lack of NSPs in protocol 860 configuration option containers would be an implicit indication that 861 there is no NAT64 present in the network. 863 4.9.2. Analysis and discussion 865 The PROs of the proposal are listed below: 867 + Can be used to solve Issue #1, Issue #2, Issue #3 and Issue #5. 869 + Can solve Issue #4 if lifetime information is also communicated. 871 The CONs of the proposal are listed below: 873 - Requires configuration and managements of all access routers/ 874 gateway to emit correct information in "link/lower layer" 875 signaling. In a case the NAT64 functionality is implemented into 876 the access router/gateway itself that terminates the generic 877 protocol configuration exchange, then the configuration management 878 can be automated. 880 - In some operating systems it may not be trivial to transfer 881 information obtained in "link/lower layers" to upper layers. 883 - NSP change may require changes to access router/gateway 884 configuration. 886 - Requires standardization of a new configuration parameter 887 exchange/container for each access system of interest. The 888 proposed solution is indeed specific to each access technology. 890 4.9.3. Summary 892 The Access Technology-based solution would be a good solution in a 893 sense it hooks into general network access establishment phase, 894 allows easy updates when configuration information changes and does 895 not involve DNS in general. However, generally introducing any 896 changes to the link/lower layers is a long and slow router, and yet 897 is access technology/system specific. 899 Compared to the RA equivalent solution in Section 4.7 the management 900 overhead is equivalent or even less than RA-based solution. 902 5. Conclusion 904 Our conclusion is to recommend publishing the Well-Known DNS Name 905 heuristic-based method (see Section 4.3) as an Informational IETF 906 document for applications and host implementors to implement as-is. 907 If Standards Track work is seen beneficial, then our recommendation 908 is the standardization of ENDS0 option. The reasoning for our 909 conclusion is discussed in the following paragraphs. 911 Of the different issues we give most weight for issues #1 and #2. We 912 are not giving much weight for the Issue #3 'DNS should not be 913 required', as cases where hosts need to synthesize IPv6 addresses but 914 do does not have DNS available seem rare for us. Even if application 915 does not otherwise utilize DNS, it ought to be able to trigger simple 916 DNS query to find out WKP/NSP. Issue #4 is handled by majority of 917 solutions. Issue #5 is considered to be mostly insignificant from an 918 individual hosts point of view as it would use only one NSP at a 919 time, while different hosts could be using different NSPs, hence 920 supporting load-balancing targets. None of the discussed solutions 921 support learning of possible new or indicating support for multiple 922 algorithms for address synthesis other than the one described in 923 [RFC6052]. 925 The DNS64 entity has to be configured with WKP/NSP in order for it to 926 do synthetization and hence using DNS also for delivering the 927 synthetization information sounds logical. The fact that the 928 synthetization information fate-shares the information received in 929 the DNS response is a valuable attribute and reduces the possible 930 distribution of stale prefix information. On the contrary, use of 931 DHCPv6 would require additional trouble configuring DHCPv6 servers 932 and ensuring DHCPv6 clients are in place, and furthermore that the 933 NAT64, DHCPv6 (and possible even some DNS64) servers are all in sync. 934 RA-based mechanisms are operationally expensive as configuration 935 would have to be placed and maintained in the access routers. 936 Furthermore, both DHCPv6 and RA based mechanisms involve entities 937 that do not otherwise need to be aware of protocol translation (only 938 need to know DNS server addresses). 940 Of the DNS-based mechanisms we favor EDNS0 option due to its 941 lightweight nature. All the A64, DNS SRV, and ENDS0 approaches would 942 require standardization and deployment efforts that may be excessive 943 compared to the size of the problem. The U-NAPTR-based approach 944 would require provisioning information into the '.ip6.arpa' tree 945 which would not be entirely internal for the provider. 947 The two heuristic-based approaches could be taken into use at once 948 and would provide benefits in networks utilizing protocol 949 translation, but on the long run their usefulness depends how well 950 networks will deploy explicit methods. 952 6. Security Considerations 954 The security considerations are essentially similar to what is 955 described in DNS64 [I-D.ietf-behave-dns64]. Forgery of information 956 required for IPv6 address synthesis may allow an attacker to insert 957 itself as middle man or to perform denial-of-service attack. The 958 DHCPv6 and RA based approaches are vulnerable for the forgery as the 959 attacker may send forged RAs or act as a rogue DHCPv6 server (unless 960 DHCPv6 authentication or SEND are used). If the attacker is already 961 able to modify and forge DNS responses (flags, addresses of know 962 IPv4-only servers, records, etc), ability to influence local address 963 synthesis is likely of low additional value. Also, a DNS-based 964 mechanism is only as secure as the method used to configure the DNS 965 server's IP addresses on the host. Therefore, if the host cannot 966 trust e.g. DHCPv6 it cannot trust the DNS server learned via DHCPv6 967 either, unless the host has a way to authenticate all DNS responses. 969 7. IANA Considerations 971 This document is informative and has no actions to IANA. 973 8. Contributors 975 The following people have contributed text to this document. 977 Mohamed Boucadair 978 France Telecom 979 Rennes, 35000 980 France 982 Email: mohamed.boucadair@orange-ftgroup.com 984 9. Acknowledgements 986 Authors would like to thank Dan Wing and Christian Huitema especially 987 for the STUN idea for their valuable comments and discussions. 989 10. Informative References 991 [3GPP.24.301] 992 3GPP, "Non-Access-Stratum (NAS) protocol for Evolved 993 Packet System (EPS)", 3GPP TS 24.301 8.8.0, December 2010. 995 [EDNS0-Flag] 996 Korhonen, J. and T. Savolainen, "EDNS0 Flags Indicating 997 AAAA Record Synthesis and Format", 998 draft-korhonen-edns0-synthesis-flag-00 (work in progress), 999 June 2010. 1001 [I-D.boucadair-behave-dns-a64] 1002 Boucadair, M. and E. Burgey, "A64: DNS Resource Record for 1003 IPv4-Embedded IPv6 Address", 1004 draft-boucadair-behave-dns-a64-02 (work in progress), 1005 September 2010. 1007 [I-D.boucadair-dhcpv6-shared-address-option] 1008 Boucadair, M., Levis, P., Grimault, J., Savolainen, T., 1009 and G. Bajko, "Dynamic Host Configuration Protocol 1010 (DHCPv6) Options for Shared IP Addresses Solutions", 1011 draft-boucadair-dhcpv6-shared-address-option-01 (work in 1012 progress), December 2009. 1014 [I-D.carpenter-referral-ps] 1015 Carpenter, B., Jiang, S., and B. Zhou, "Problem Statement 1016 for Referral", draft-carpenter-referral-ps-01 (work in 1017 progress), August 2010. 1019 [I-D.ietf-behave-dns64] 1020 Bagnulo, M., Sullivan, A., Matthews, P., and I. Beijnum, 1021 "DNS64: DNS extensions for Network Address Translation 1022 from IPv6 Clients to IPv4 Servers", 1023 draft-ietf-behave-dns64-11 (work in progress), 1024 October 2010. 1026 [I-D.ietf-behave-v6v4-framework] 1027 Baker, F., Li, X., Bao, C., and K. Yin, "Framework for 1028 IPv4/IPv6 Translation", 1029 draft-ietf-behave-v6v4-framework-10 (work in progress), 1030 August 2010. 1032 [I-D.ietf-behave-v6v4-xlate-stateful] 1033 Bagnulo, M., Matthews, P., and I. Beijnum, "Stateful 1034 NAT64: Network Address and Protocol Translation from IPv6 1035 Clients to IPv4 Servers", 1036 draft-ietf-behave-v6v4-xlate-stateful-12 (work in 1037 progress), July 2010. 1039 [I-D.korhonen-edns0-synthesis-flag] 1040 Korhonen, J. and T. Savolainen, "EDNS0 Option for 1041 Indicating AAAA Record Synthesis and Format", 1042 draft-korhonen-edns0-synthesis-flag-02 (work in progress), 1043 February 2011. 1045 [I-D.savolainen-heuristic-nat64-discovery] 1046 Savolainen, T. and J. Korhonen, "Discovery of a Network- 1047 Specific NAT64 Prefix using a Well-Known Name", 1048 draft-savolainen-heuristic-nat64-discovery-01 (work in 1049 progress), February 2011. 1051 [I-D.venaas-behave-mcast46] 1052 Venaas, S., Asaeda, H., SUZUKI, S., and T. Fujisaki, "An 1053 IPv4 - IPv6 multicast translator", 1054 draft-venaas-behave-mcast46-02 (work in progress), 1055 December 2010. 1057 [I-D.venaas-behave-v4v6mc-framework] 1058 Venaas, S., Li, X., and C. Bao, "Framework for IPv4/IPv6 1059 Multicast Translation", 1060 draft-venaas-behave-v4v6mc-framework-02 (work in 1061 progress), December 2010. 1063 [I-D.wing-behave-learn-prefix] 1064 Wing, D., "Learning the IPv6 Prefix of a Network's IPv6/ 1065 IPv4 Translator", draft-wing-behave-learn-prefix-04 (work 1066 in progress), October 2009. 1068 [RA-Learn-Prefix] 1069 Wing, D., Wang, X., and X. Xu, "Learning the IPv6 Prefixes 1070 of an IPv6/IPv4 Translator", 1071 draft-wing-behave-learn-prefix-03 (work in progress), 1072 July 2009. 1074 [RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time 1075 Streaming Protocol (RTSP)", RFC 2326, April 1998. 1077 [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", 1078 RFC 2671, August 1999. 1080 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1081 A., Peterson, J., Sparks, R., Handley, M., and E. 1082 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1083 June 2002. 1085 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 1086 and M. Carney, "Dynamic Host Configuration Protocol for 1087 IPv6 (DHCPv6)", RFC 3315, July 2003. 1089 [RFC3484] Draves, R., "Default Address Selection for Internet 1090 Protocol version 6 (IPv6)", RFC 3484, February 2003. 1092 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1093 Description Protocol", RFC 4566, July 2006. 1095 [RFC4848] Daigle, L., "Domain-Based Application Service Location 1096 Using URIs and the Dynamic Delegation Discovery Service 1097 (DDDS)", RFC 4848, April 2007. 1099 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 1100 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 1101 September 2007. 1103 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 1104 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 1105 October 2008. 1107 [RFC5507] IAB, Faltstrom, P., Austein, R., and P. Koch, "Design 1108 Choices When Expanding the DNS", RFC 5507, April 2009. 1110 [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 1111 Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, 1112 October 2010. 1114 Authors' Addresses 1116 Jouni Korhonen (editor) 1117 Nokia Siemens Networks 1118 Linnoitustie 6 1119 FI-02600 Espoo 1120 Finland 1122 Email: jouni.nospam@gmail.com 1123 Teemu Savolainen (editor) 1124 Nokia 1125 Hermiankatu 12 D 1126 FI-33720 Tampere 1127 Finland 1129 Email: teemu.savolainen@nokia.com