idnits 2.17.1 draft-ietf-pcp-nat64-prefix64-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 21, 2014) is 3717 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-08) exists of draft-ietf-mmusic-latching-04 == Outdated reference: A later version (-13) exists of draft-ietf-pcp-port-set-04 == Outdated reference: A later version (-19) exists of draft-ietf-rtcweb-overview-09 -- Obsolete informational reference (is this intentional?): RFC 4566 (Obsoleted by RFC 8866) Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PCP Working Group M. Boucadair 3 Internet-Draft France Telecom 4 Intended status: Standards Track February 21, 2014 5 Expires: August 25, 2014 7 Learning NAT64 PREFIX64s using Port Control Protocol (PCP) 8 draft-ietf-pcp-nat64-prefix64-06 10 Abstract 12 This document defines a new Port Control Protocol (PCP) option to 13 learn the IPv6 prefix(es) used by a PCP-controlled NAT64 device to 14 build IPv4-converted IPv6 addresses. This option is needed for 15 successful communications when IPv4 addresses are used in referrals. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on August 25, 2014. 34 Copyright Notice 36 Copyright (c) 2014 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 53 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3 54 3.1. Issues . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3.2. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3.2.1. AAAA Synthesis by the DNS Stub-resolver . . . . . . . 3 57 3.2.2. Application Referrals . . . . . . . . . . . . . . . . 4 58 4. PREFIX64 Option . . . . . . . . . . . . . . . . . . . . . . . 5 59 4.1. Format . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 4.2. Server's Behavior . . . . . . . . . . . . . . . . . . . . 7 61 4.3. Client's Behavior . . . . . . . . . . . . . . . . . . . . 8 62 5. Flow Examples . . . . . . . . . . . . . . . . . . . . . . . . 9 63 5.1. TCP Session Initiated from an IPv6-only Host . . . . . . 9 64 5.2. SIP Flow Example . . . . . . . . . . . . . . . . . . . . 10 65 5.3. Mapping of IPv4 Address Ranges to IPv6 Prefixes . . . . . 13 66 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 67 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 68 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 69 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 70 9.1. Normative References . . . . . . . . . . . . . . . . . . 15 71 9.2. Informative References . . . . . . . . . . . . . . . . . 15 72 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 17 74 1. Introduction 76 According to [RFC6146], NAT64 uses Pref64::/n to construct 77 IPv4-Converted IPv6 addresses as defined in [RFC6052]. 79 This document defines a new PCP (Port Control Protocol) option 80 [RFC6887] to inform PCP clients about the Pref64::/n and suffix 81 [RFC6052] used by a PCP-controlled NAT64 device [RFC6146]. It does 82 so by defining a new PREFIX64 option. 84 This PCP option is a deterministic solution to help establish 85 communications between IPv6-only hosts and remote IPv4-only hosts. 86 Unlike [RFC7050], this option solves all the issues identified in 87 [RFC7051]. 89 Some illustration examples are provided in Section 5. Detailed 90 experiments conducted to assess the applicability of the PREFIX64 91 option for services, such as access to a video server behind NAT64 92 and SIP-based sessions, are available at 93 [I-D.boucadair-pcp-nat64-experiments]. 95 The use of this PCP option for NAT64 load balancing purposes is out 96 of scope. 98 2. Requirements Language 100 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 101 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 102 "OPTIONAL" in this document are to be interpreted as described in 103 [RFC2119]. 105 3. Problem Statement 107 3.1. Issues 109 This document proposes a deterministic solution to solve the 110 following issues: 112 o Learn the Pref64::/n used by an upstream NAT64 function. This is 113 needed to help: 115 * distinguish between IPv4-converted IPv6 addresses [RFC6052] and 116 native IPv6 addresses. 117 * implement IPv6 address synthesis for applications not relying 118 on DNS (where DNS64 [RFC6147] would provide the synthesis). 119 o Avoid stale Pref64::/n. 120 o Discover multiple Pref64::/n when multiple prefixes exist in a 121 network. 122 o Use DNSSEC ([RFC4033], [RFC4034], [RFC4035]) in the presence of 123 NAT64. 124 o Discover the suffix used by an NAT64 function when non-null 125 suffixes are in use (e.g., checksum neutral suffix). 126 o Support destination-based Pref64::/n (e.g., Section 5.1 of 127 [RFC7050]). 128 o Associate a Pref64::/n with a given NAT64 when distinct prefixes 129 are configured for each NAT64 enabled in a network. 131 A more elaborated discussion can be found at [RFC7051]. 133 3.2. Use Cases 135 This section provides some use cases to illustrate the problem space. 136 More details can be found at Section 4 of [RFC7051]. 138 3.2.1. AAAA Synthesis by the DNS Stub-resolver 140 The option defined in this document can be used for hosts with DNS64 141 capability [RFC6147] added to the host's stub-resolver. 143 The stub resolver on the host will try to obtain (native) AAAA 144 records and if they are not found, the DNS64 function on the host 145 will query for A records and then synthesize AAAA records. Using the 146 PREFIX64 PCP extension, the host's stub-resolver can learn the prefix 147 used for IPv6/IPv4 translation and synthesize AAAA records 148 accordingly. 150 Because synthetic AAAA records cannot be successfully validated in a 151 host, learning the Pref64::/n used to construct IPv4-converted IPv6 152 addresses allows the use of DNSSEC. As discussed in section 5.5 of 153 [RFC6147], a security-aware and validating host has to perform the 154 DNS64 function locally. 156 3.2.2. Application Referrals 158 As discussed in [I-D.carpenter-behave-referral-object], a frequently 159 occurring situation is that one entity A connected to a network needs 160 to inform another entity B how to reach either A itself or some 161 third-party entity C. This is known as address referral. 163 In the particular context of NAT64 [RFC6146], applications relying on 164 address referral will fail because an IPv6-only client won't be able 165 to make use of an IPv4 address received in a referral. A non- 166 exhaustive list of such applications is provided below: 168 o In SIP environments [RFC3261], the SDP part ([RFC4566]) of 169 exchanged SIP messages includes information required for 170 establishing RTP sessions (namely, IP address and port number). 171 When a NAT64 is involved in the path, an IPv6-only SIP User Agent 172 (UA) that receives an SDP offer/answer containing an IPv4 address, 173 cannot send media streams to the remote endpoint. 174 o An IPv6-only WebRTC (Web Real-Time Communication, 175 [I-D.ietf-rtcweb-overview]) agent cannot make use of an IPv4 176 address received in referrals to establish a successful session 177 with a remote IPv4-only WebRTC agent. 178 o BitTorrent is a distributed file sharing infrastructure that is 179 based on P2P techniques for exchanging files between connected 180 users. To download a given file, a BitTorrent client needs to 181 obtain the corresponding torrent file. Then, it connects to a 182 tracker to retrieve a list of leechers (clients that are currently 183 downloading the file but do not yet possess all portions of the 184 file) and seeders (clients that possess all portions of the file 185 and are uploading them to other requesting clients). The client 186 connects to those machines and downloads the available portions of 187 the requested file. In the presence of an address sharing 188 function (see Appendix A of [RFC6269]), some encountered issues 189 are solved if PCP is enabled (see [I-D.boucadair-pcp-bittorrent]). 190 Nevertheless, an IPv6-only client cannot connect to a remote 191 IPv4-only machine even if the base PCP protocol is used. 193 Learning the Pref64::/n solves the issues listed above. 195 4. PREFIX64 Option 197 4.1. Format 199 The format of the PREFIX64 option is depicted in Figure 1. This 200 option follows the guidelines specified in Section 7.3 of [RFC6887]. 202 This option allows to map specific IPv4 address ranges (called IPv4 203 Prefix List) to separate Pref64::/n prefixes as discussed in 204 [RFC6147]. 206 0 1 2 3 207 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 209 |Option Code=TBA| Reserved | Option Length | 210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 211 | Prefix64 Length | | 212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 213 : Prefix64 (Variable) : 214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 215 | | 216 : Suffix (Variable) : 217 | | 218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 219 | (optional) | 220 : IPv4 Prefix List (Variable) : 221 | (See Figure 2) | 222 | | 223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 225 Figure 1: Prefix64 PCP Option 227 The description of the fields is as follows: 229 o Option Code: To be assigned by IANA. 230 o Reserved: This field is initialized as specified in section 7.3 of 231 [RFC6887]. 232 o Option Length: Indicates in octets the length of the enclosed 233 data. 234 o Prefix64 Length: Indicates in octets the length of the Pref64::/n. 235 The allowed values are specified in [RFC6052] (i.e., 4, 5, 6, 7, 236 8, or 12). 237 o Prefix64: This field identifies the IPv6 unicast prefix to be used 238 for constructing an IPv4-converted IPv6 address from an IPv4 239 address as specified in Section 2.2 of [RFC6052]. This prefix can 240 be the Well-Known Prefix (i.e., 64:ff9b::/96) or a Network- 241 Specific Prefix. The address synthesis MUST follow the guidelines 242 documented in [RFC6052]. 243 o Suffix: The length of this field is (12 - Prefix64 Length) octets. 244 This field identifies the suffix to be used for constructing an 245 IPv4-converted IPv6 address from an IPv4 address as specified in 246 Section 2.2 of [RFC6052]. No suffix is included if a /96 Prefix64 247 is conveyed in the option. 248 o IPv4 Prefix List: This is an optional field. The format of the 249 IPv4 Prefix List field is shown in Figure 2. This field may be 250 included by a PCP server to solve the destination-dependent 251 Pref64::/n discovery problem discussed in Section 5.1 of 252 [RFC7050]. 254 * IPv4 Prefix Count: indicates the number of IPv4 prefixes 255 included in the option. "IPv4 Prefix Count" field MUST be set 256 to 0 in a request and MUST be set to the number of included 257 IPv4 subnets in a response. 258 * An IPv4 prefix is represented as "IPv4 Address/IPv4 Prefix 259 Length" [RFC4632]. For example, to encode 192.0.2.0/24, "IPv4 260 Prefix Length" field is set to 24 and "IPv4 Address" field is 261 set to 192.0.2.0. If a Pref64::/n is configured for all IPv4 262 addresses, a wildcard IPv4 prefix (i.e., 0.0.0.0/0) may be 263 returned in the response together with the configured Pref64::/ 264 n. If no IPv4 Prefix List is returned in a PREFIX64 option, the 265 PCP client assumes the prefix is valid for any destination IPv4 266 address. Valid IPv4 prefixes are listed in Section 3.1 of 267 [RFC4632]. 269 0 1 2 3 270 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 | IPv4 Prefix Count | IPv4 Prefix Length | 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 | IPv4 Address (32 bits) | 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 . .... . 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 | IPv4 Prefix Length | IPv4 Address (32 bits)... | 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 280 | ... IPv4 Address (continued) | 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 283 Figure 2: Format of IPv4 Prefix List field 285 Option Name: PREFIX64 286 Number: 287 Purpose: Learn the prefix used by the NAT64 to build 288 IPv4-converted IPv6 addresses. This is used by a host 289 is for local address synthesis (e.g., when an IPv4 address 290 is present in referrals). 291 Valid for Opcodes: MAP, ANNOUNCE 292 Length: Variable 293 May appear in: request, response. 294 Maximum occurrences: 1 for a request. As many as fit within 295 the maximum PCP message size for a response. 297 4.2. Server's Behavior 299 The PCP server controlling a NAT64 SHOULD be configured to return to 300 requesting PCP clients the value of the Pref64::/n and suffix used to 301 build IPv4-converted IPv6 addresses. When enabled, the PREFIX64 302 option conveys the value of Pref64::/n and configured suffix. If no 303 suffix is explicitly configured to the PCP server, the null suffix is 304 used as the default value (see Section 2.2 of [RFC6052]). 306 If the PCP server is configured to honor the PREFIX64 option but no 307 Pref64::/n is explicitly configured, the PCP server MUST NOT include 308 any PREFIX64 option in its PCP messages. 310 The PCP server controlling a NAT64 MAY be configured to include a 311 PREFIX64 option in all MAP responses even if the PREFIX64 option is 312 not listed in the associated request. The PCP server controlling a 313 NAT64 MAY be configured to include a PREFIX64 option in its ANNOUNCE 314 messages. 316 The PCP server MAY be configured with a list of destination IPv4 317 prefixes associated with a Pref64::/n. This list is then included by 318 the PCP server in a PREFIX64 option sent to PCP clients. 320 The PCP server MAY be configured to return multiple PREFIX64 options 321 in the same message to the PCP client. In such case, the server does 322 the following: 324 o If no destination IPv4 prefix list is configured, the PCP server 325 includes in the first PREFIX64 option, which appears in the PCP 326 message it sends to the PCP client, the prefix and suffix to 327 perform local IPv6 address synthesis [RFC6052]. Additional 328 PREFIX64 options convey any other Pref64::/n values configured. 329 Returning these prefixes allows an end host to identify all 330 synthesized IPv6 addresses in a network; the host can prefer IPv4 331 or another network interface instead in order to avoid any NAT64 332 deployed in the network. The PCP server is required to 333 disambiguate prefixes used for IPv6 address synthesis and other 334 prefixes used to avoid any NAT64 deployed in the network. The PCP 335 server can be configured with a customized IPv6 prefix list (i.e., 336 specific to a PCP client or a group of PCP clients) or system-wide 337 IPv6 prefix list (i.e., the same list is returned for any PCP 338 client). Note, it is NOT RECOMMENDED to include PREFIX64 options 339 in ANNOUNCE messages if a customized IPv6 prefix list is 340 configured to the PCP server. 341 o If IPv4 prefix lists are configured, the PCP server includes in 342 the first PREFIX64 options the Pref64::/n and suffix that are 343 associated with an IPv4 prefix list (i.e., each of these PREFIX64 344 options conveys a distinct Pref64::/n together with an IPv4 prefix 345 list). Additional PREFIX64 options convey any other Pref64::/n 346 values configured (i.e., remaining Pref64::/n not mapped to any 347 IPv4 prefix list). 349 If a distinct Pref64::/n or suffix is configured to the PCP- 350 controlled NAT64 device, the PCP server SHOULD issue an unsolicited 351 PCP ANNOUNCE message to inform the PCP client about the new Pref64::/ 352 n and/or suffix. 354 4.3. Client's Behavior 356 The PCP client includes a PREFIX64 option in a MAP or ANNOUNCE 357 request to learn the IPv6 prefix and suffix used by an upstream PCP- 358 controlled NAT64 device. When enclosed in a PCP request, the 359 Prefix64 MUST be set to ::/96. The PREFIX64 option can be inserted 360 in a MAP request used to learn the external IP address as detailed in 361 Section 11.6 of [RFC6887]. 363 The PCP client MUST be prepared to receive multiple prefix(es) (e.g., 364 if several PCP servers are deployed and each of them is configured 365 with a distinct Pref64::/n). The PCP client MUST associate each 366 received Pref64::/n and suffix with the PCP server from which the 367 Pref64::/n and suffix information was retrieved. 369 If the PCP client fails to contact a given PCP server, the PCP client 370 SHOULD clear the prefix(es) and suffix(es) it learned from that PCP 371 server. For example, a PCP client may fail to contact a PCP server 372 if the host embedding the PCP client moves to a new network, or if 373 that PCP server is out of service. The use of these stale prefixes 374 is not recommended to build IPv4-converted IPv6 address because 375 failures are likely to be encountered (see [RFC7051], Section3, 376 Issue#4). 378 If the PCP client receives a PREFIX64 option that includes an invalid 379 IPv4 prefix, the PCP client ignores that IPv4 prefix. Any other 380 valid IPv4 prefix, IPv6 prefix and suffix are not ignored by the PCP 381 client. 383 Upon receipt of the message from the PCP server, the PCP client 384 replaces any old prefix(es)/suffix(es) received from the same PCP 385 server with the new one(s) included in the PREFIX64 option(s). If no 386 PREFIX64 option includes a destination IPv4 prefix list, the host 387 embedding the PCP client uses the prefix/suffix included in the first 388 PREFIX64 option for local address synthesis. Other prefixes learned 389 can be used by the host to avoid any NAT64 deployed in the network. 390 If one or multiple received PREFIX64 options contain a destination 391 IPv4 prefix list, the PCP client MUST associate the included IPv4 392 prefixes with the Pref64::/n and the suffix indicated in the same 393 PREFIX64 option. In such case, the host embedding the PCP client 394 MUST enforce a destination-based prefix Pref64::/n selection for 395 local address synthesis purposes. How the content of the PREFIX64 396 option(s) is passed to the OS is implementation-specific. 398 Upon receipt of an unsolicited PCP ANNOUNCE message, the PCP client 399 replaces the old prefix/suffix received from the same PCP server with 400 the new Pref64::/n and suffix included in the PREFIX64 option. 402 5. Flow Examples 404 This section provides a non-normative description of use cases 405 relying on the PREFIX64 option. 407 5.1. TCP Session Initiated from an IPv6-only Host 409 The usage shown in Figure 3 depicts a typical usage of the PREFIX64 410 option when a DNS64 capability is embedded in the host. 412 In the example shown in Figure 3, once the IPv6-only client discovers 413 the IPv4 address of the remote IPv4-only server (e.g., using DNS), it 414 retrieves the Pref64::/n (i.e., 2001:db8:122:300::/56) to be used to 415 build an IPv4-converted IPv6 address for that server. This retrieval 416 is achieved using the PREFIX64 option (Steps (a) and (b)). The 417 client then uses 2001:db8:122:300::/56 to construct an IPv6 address 418 and then initiates a TCP connection (Steps (1) to (4)). 420 +---------+ +-----+ +---------+ 421 |IPv6-only| |NAT64| |IPv4-only| 422 | Client | | | | Server | 423 +---------+ +-----+ +---------+ 424 | | | 425 | (a) PCP MAP Request | | 426 | PREFIX64 | | 427 |======================>| | 428 | (b) PCP MAP Response | | 429 | PREFIX64 = | | 430 | 2001:db8:122:300::/56 | | 431 |<======================| | 432 | (1) TCP SYN | (2) TCP SYN | 433 |======================>|====================>| 434 | (4) TCP SYN/ACK | (3) TCP SYN/ACK | 435 |<======================|<====================| 436 | (5) TCP ACK | (6) TCP ACK | 437 |======================>|====================>| 438 | | | 440 Note: DNS exchange to retrieve the IPv4 address of 441 the IPv4-only Server is not shown in the figure. 443 Figure 3: Example of a TCP session initiated from an IPv6-only host 445 5.2. SIP Flow Example 447 Figure 4 shows an example of the use of the option defined in 448 Section 4 in a SIP context. In order for RTP/RTCP flows to be 449 exchanged between an IPv6-only SIP UA and an IPv4-only UA without 450 requiring any ALG (Application Level Gateway) at the NAT64 nor any 451 particular function at the IPv4-only SIP Proxy Server (e.g., Hosted 452 NAT traversal [I-D.ietf-mmusic-latching]), the PORT_SET option 453 [I-D.ietf-pcp-port-set] is used in addition to the PREFIX64 option. 455 In steps (a) and (b), the IPv6-only SIP UA retrieves a pair of ports 456 to be used for RTP/RTCP sessions, the external IPv4 address and the 457 Pref64::/n to build IPv4-embedded IPv6 addresses. This is achieved 458 by issuing a MAP request that includes a PREFIX64 option and a 459 PORT_SET option. A pair of ports (i.e., port_X/port_X+1) and an 460 external IPv4 address are then returned by the PCP server to the 461 requesting PCP client together with a Pref64::/n (i.e., 462 2001:db8:122::/48). 464 The returned external IPv4 address and external port numbers are used 465 by the IPv6-only SIP UA to build its SDP offer which contains 466 exclusively IPv4 addresses (especially in the "c=" line, the port 467 indicated for media port is the external port assigned by the PCP 468 server). The INVITE request including the SDP offer is then 469 forwarded by the NAT64 to the Proxy Server which will relay it to the 470 called party (i.e., the IPv4-only SIP UA) (Steps (1) to (3)). 472 The remote IPv4-only SIP UA accepts the offer and sends back its SDP 473 answer in a "200 OK" message which is relayed by the SIP Proxy Server 474 and NAT64 until being delivered to the IPv6-only SIP UA (Steps (4) to 475 (6)). 477 The Pref64::/n (2001:db8:122::/48) is used by the IPv6-only SIP UA to 478 construct a corresponding IPv6 address of the IPv4 address enclosed 479 in the SDP answer made by the IPv4-only SIP UA (Step 6). 481 The IPv6-only SIP UA and IPv4-only SIP UA are then able to exchange 482 RTP/RTCP flows without requiring any ALG at the NAT64 nor any special 483 function at the IPv4-only SIP Proxy Server. 485 +---------+ +-----+ +------------+ +---------+ 486 |IPv6-only| |NAT64| | IPv4 SIP | |IPv4-only| 487 | SIP UA | | | |Proxy Server| | SIP UA | 488 +---------+ +-----+ +------------+ +---------+ 489 | (a) PCP MAP Request | | | 490 | PORT_SET | | | 491 | PREFIX64 | | | 492 |======================>| | | 493 | (b) PCP MAP Response | | | 494 | PORT_SET | | | 495 | PREFIX64: | | | 496 | 2001:db8:122::/48 | | | 497 |<======================| | | 498 | (1) SIP INVITE | (2) SIP INVITE | (3) SIP INVITE | 499 |======================>|===============>|================>| 500 | (6) SIP 200 OK | (5) SIP 200 OK | (4) SIP 200 OK | 501 |<======================|<===============|<================| 502 | (7) SIP ACK | (8) SIP ACK | (9) SIP ACK | 503 |======================>|===============>|================>| 504 | | | | 505 |src port: dst port:|src port: dst port:| 506 |port_A port_B|port_X port_B| 507 |<======IPv6 RTP=======>|<============IPv4 RTP============>| 508 |<===== IPv6 RTCP======>|<============IPv4 RTCP===========>| 509 |src port: dst port:|src port: dst port:| 510 |port_A+1 port_B+1|port_X+1 port_B+1| 511 | | | 513 Figure 4: Example of IPv6 to IPv4 SIP initiated Session 515 When the session is initiated from the IPv4-only SIP UA (see 516 Figure 5), the IPv6-only SIP UA retrieves a pair of ports to be used 517 for the RTP /RTCP session, the external IPv4 address and the Pref64:: 518 /n to build IPv4-converted IPv6 addresses (Steps (a) and (b)). These 519 two steps could instead be delayed until the INVITE message is 520 received (Step 3). 522 The retrieved IPv4 address and port numbers are used to build the SDP 523 answer in Step (4) while the Pref64::/n is used to construct a IPv6 524 address corresponding to the IPv4 address enclosed in the SDP offer 525 made by the IPv4-only SIP UA (Step 3). RTP/RTCP flows are then 526 exchanged between the IPv6-only SIP UA and the IPv4-only UA without 527 requiring any ALG at the NAT64 nor any special function at the 528 IPv4-only SIP Proxy Server. 530 +---------+ +-----+ +------------+ +---------+ 531 |IPv6-only| |NAT64| | IPv4 SIP | |IPv4-only| 532 | SIP UA | | | |Proxy Server| | SIP UA | 533 +---------+ +-----+ +------------+ +---------+ 534 | (a) PCP MAP Request | | | 535 | PORT_SET | | | 536 | PREFIX64 | | | 537 |======================>| | | 538 | (b) PCP MAP Response | | | 539 | PORT_SET | | | 540 | PREFIX64: | | | 541 | 2001:db8:122::/48 | | | 542 |<======================| | | 543 | (3) SIP INVITE | (2) SIP INVITE | (1) SIP INVITE | 544 |<======================|<===============|<================| 545 | (4) SIP 200 OK | (5) SIP 200 OK | (6) SIP 200 OK | 546 |======================>|===============>|================>| 547 | (9) SIP ACK | (8) SIP ACK | (7) SIP ACK | 548 |<======================|<===============|<================| 549 | | | | 550 |src port: dst port:|src port: dst port:| 551 |port_a port_b|port_Y port_b| 552 |<======IPv6 RTP=======>|<============IPv4 RTP============>| 553 |<===== IPv6 RTCP======>|<============IPv4 RTCP===========>| 554 |src port: dst port:|src port: dst port:| 555 |port_a+1 port_b+1|port_Y+1 port_b+1| 556 | | | 558 Figure 5: Example of IPv4 to IPv6 SIP initiated Session 560 5.3. Mapping of IPv4 Address Ranges to IPv6 Prefixes 562 Figure 6 shows an example of a NAT64 configured with two Pref64::/n; 563 each of these Pref64::/n is associated with a distinct IPv4 address 564 range: 566 o 192.0.2.0/24 is mapped to 2001:db8:122:300::/56. 567 o 198.51.100.0/24 is mapped to 2001:db8:122::/48. 569 Once the IPv6-only client discovers the IPv4 address of the remote 570 IPv4-only server (i.e., 198.51.100.1), it retrieves two IPv6 prefixes 571 to be used to build an IPv4-converted IPv6 addresses. This retrieval 572 is achieved using two PREFIX64 options (Step (b)). 574 Because 198.51.100.1 matches the destination prefix 198.51.100.0/24, 575 the client uses the associated Pref64::/n (i.e., 2001:db8:122::/48) 576 to construct an IPv6 address for that IPv4-only server, and then 577 initiates a TCP connection (Steps (1) to (4)). 579 +---------+ +-----+ +---------+ 580 |IPv6-only| |NAT64| |IPv4-only| 581 | Client | | | | Server | 582 +---------+ +-----+ +---------+ 583 | | 198.51.100.1 584 | (a) PCP MAP Request | | 585 | PREFIX64 | | 586 |=================================>| | 587 | (b) PCP MAP Response | | 588 |PREFIX64{ | | 589 | Pref64::/n =2001:db8:122:300::/56| | 590 | IPv4 Prefix=192.0.2.0/24} | | 591 |PREFIX64{ | | 592 | Pref64::/n =2001:db8:122::/48 | | 593 | IPv4 Prefix=198.51.100.0/24} | | 594 |<=================================| | 595 | (1) TCP SYN | (2) TCP SYN | 596 |=================================>|====================>| 597 | (4) TCP SYN/ACK | (3) TCP SYN/ACK | 598 |<=================================|<====================| 599 | (5) TCP ACK | (6) TCP ACK | 600 |=================================>|====================>| 601 | | | 603 Note: DNS exchange to retrieve the IPv4 address of 604 the IPv4-only Server is not shown in the figure. 606 Figure 6: Mapping of IPv4 Address Ranges to IPv6 Prefixes 608 A similar behavior is to be experienced if these Pref64::/n and 609 associated IPv4 prefix lists are configured to distinct NAT64 610 devices. 612 6. IANA Considerations 614 The following PCP Option Code is to be allocated in the optional-to- 615 process range (the registry is maintained in http://www.iana.org/ 616 assignments/pcp-parameters): 618 PREFIX64 set to TBA (see Section 4.1) 620 7. Security Considerations 622 PCP-related security considerations are discussed in [RFC6887]. 624 As discussed in [RFC6147], if an attacker can manage to change the 625 Pref64::/n used by the DNS64 function, the traffic generated by the 626 host that receives the synthetic reply will be delivered to the 627 altered Pref64. This can result in either a denial-of-service (DoS) 628 attack, a flooding attack, or a MITM (Man In The Middle) attack. 629 This attack could be achieved either by altering PCP messages issued 630 by a legitimate PCP server or by using a fake PCP server. 632 Means to defend against attackers who can modify packets between the 633 PCP server and the PCP client, or who can inject spoofed packets that 634 appear to come from a legitimate PCP server SHOULD be enabled. In 635 some deployments, access control lists (ACLs) can be installed on the 636 PCP client, PCP server, and the network between them, so those ACLs 637 allow only communications from a trusted PCP server to the PCP 638 client. 640 PCP server discovery is out of scope of this document. It is the 641 responsibility of PCP server discovery document(s) to elaborate on 642 the security considerations to discover a legitimate PCP server. 644 Learning a Pref64::/n via PCP allows using DNSSEC in the presence of 645 NAT64. As such, NAT64 with DNSSEC and PCP is better than no DNSSEC 646 at all, but it is less safe than DNSSEC without DNS64/NAT64 and PCP. 647 The best mitigation action against Pref64::/n discovery attacks is 648 thus to add IPv6 support in all endpoints and hence reduce the need 649 to perform IPv6 address synthesis. 651 8. Acknowledgements 653 Many thanks to S. Perreault , R. Tirumaleswar, T. Tsou, D. Wing, J. 654 Zhao, R. Penno, I. van Beijnum, T. Savolainen, S. Savikumar, D. 656 Thaler, T. Lemon, S. Hanna, P. Resnick, R. Sparks, S. Farrell, and W. 657 Cui for the comments and suggestions. 659 9. References 661 9.1. Normative References 663 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 664 Requirement Levels", BCP 14, RFC 2119, March 1997. 666 [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing 667 (CIDR): The Internet Address Assignment and Aggregation 668 Plan", BCP 122, RFC 4632, August 2006. 670 [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 671 Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, 672 October 2010. 674 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 675 NAT64: Network Address and Protocol Translation from IPv6 676 Clients to IPv4 Servers", RFC 6146, April 2011. 678 [RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van 679 Beijnum, "DNS64: DNS Extensions for Network Address 680 Translation from IPv6 Clients to IPv4 Servers", RFC 6147, 681 April 2011. 683 [RFC6887] Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. 684 Selkirk, "Port Control Protocol (PCP)", RFC 6887, April 685 2013. 687 9.2. Informative References 689 [I-D.boucadair-pcp-bittorrent] 690 Boucadair, M., Zheng, T., Deng, X., and J. Queiroz, 691 "Behavior of BitTorrent service in PCP-enabled networks 692 with Address Sharing", draft-boucadair-pcp-bittorrent-00 693 (work in progress), May 2012. 695 [I-D.boucadair-pcp-nat64-experiments] 696 Abdesselam, M., Boucadair, M., Hasnaoui, A., and J. 697 Queiroz, "PCP NAT64 Experiments", draft-boucadair-pcp- 698 nat64-experiments-00 (work in progress), September 2012. 700 [I-D.carpenter-behave-referral-object] 701 Carpenter, B., Boucadair, M., Halpern, J., Jiang, S., and 702 K. Moore, "A Generic Referral Object for Internet 703 Entities", draft-carpenter-behave-referral-object-01 (work 704 in progress), October 2009. 706 [I-D.ietf-mmusic-latching] 707 Ivov, E., Kaplan, H., and D. Wing, "Latching: Hosted NAT 708 Traversal (HNT) for Media in Real-Time Communication", 709 draft-ietf-mmusic-latching-04 (work in progress), October 710 2013. 712 [I-D.ietf-pcp-port-set] 713 Qiong, Q., Boucadair, M., Sivakumar, S., Zhou, C., Tsou, 714 T., and S. Perreault, "Port Control Protocol (PCP) 715 Extension for Port Set Allocation", draft-ietf-pcp-port- 716 set-04 (work in progress), November 2013. 718 [I-D.ietf-rtcweb-overview] 719 Alvestrand, H., "Overview: Real Time Protocols for Brower- 720 based Applications", draft-ietf-rtcweb-overview-09 (work 721 in progress), February 2014. 723 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 724 A., Peterson, J., Sparks, R., Handley, M., and E. 725 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 726 June 2002. 728 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 729 Rose, "DNS Security Introduction and Requirements", RFC 730 4033, March 2005. 732 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 733 Rose, "Resource Records for the DNS Security Extensions", 734 RFC 4034, March 2005. 736 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 737 Rose, "Protocol Modifications for the DNS Security 738 Extensions", RFC 4035, March 2005. 740 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 741 Description Protocol", RFC 4566, July 2006. 743 [RFC6269] Ford, M., Boucadair, M., Durand, A., Levis, P., and P. 744 Roberts, "Issues with IP Address Sharing", RFC 6269, June 745 2011. 747 [RFC7050] Savolainen, T., Korhonen, J., and D. Wing, "Discovery of 748 the IPv6 Prefix Used for IPv6 Address Synthesis", RFC 749 7050, November 2013. 751 [RFC7051] Korhonen, J. and T. Savolainen, "Analysis of Solution 752 Proposals for Hosts to Learn NAT64 Prefix", RFC 7051, 753 November 2013. 755 Author's Address 757 Mohamed Boucadair 758 France Telecom 759 Rennes 35000 760 France 762 Email: mohamed.boucadair@orange.com