idnits 2.17.1 draft-ietf-pcp-nat64-prefix64-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == 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 04, 2014) is 3733 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-08 -- 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 04, 2014 5 Expires: August 8, 2014 7 Learning NAT64 PREFIX64s using Port Control Protocol (PCP) 8 draft-ietf-pcp-nat64-prefix64-05 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 8, 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 Learning the Pref64::/n used to construct IPv4-converted IPv6 151 addresses allows the use of DNSSEC. 153 3.2.2. Application Referrals 155 As discussed in [I-D.carpenter-behave-referral-object], a frequently 156 occurring situation is that one entity A connected to a network needs 157 to inform another entity B how to reach either A itself or some 158 third-party entity C. This is known as address referral. 160 In the particular context of NAT64 [RFC6146], applications relying on 161 address referral will fail because an IPv6-only client won't be able 162 to make use of an IPv4 address received in a referral. A non- 163 exhaustive list of such applications is provided below: 165 o In SIP environments [RFC3261], the SDP part ([RFC4566]) of 166 exchanged SIP messages includes information required for 167 establishing RTP sessions (namely, IP address and port number). 168 When a NAT64 is involved in the path, an IPv6-only SIP User Agent 169 (UA) that receives an SDP offer/answer containing an IPv4 address, 170 cannot send media streams to the remote endpoint. 171 o An IPv6-only WebRTC (Web Real-Time Communication, 172 [I-D.ietf-rtcweb-overview]) agent cannot make use of an IPv4 173 address received in referrals to establish a successful session 174 with a remote IPv4-only WebRTC agent. 175 o BitTorrent is a distributed file sharing infrastructure that is 176 based on P2P techniques for exchanging files between connected 177 users. To download a given file, a BitTorrent client needs to 178 obtain the corresponding torrent file. Then, it connects to a 179 tracker to retrieve a list of leechers (clients that are currently 180 downloading the file but do not yet possess all portions of the 181 file) and seeders (clients that possess all portions of the file 182 and are uploading them to other requesting clients). The client 183 connects to those machines and downloads the available portions of 184 the requested file. In the presence of an address sharing 185 function (see Appendix A of [RFC6269]), some encountered issues 186 are solved if PCP is enabled (see [I-D.boucadair-pcp-bittorrent]). 187 Nevertheless, an IPv6-only client cannot connect to a remote 188 IPv4-only machine even if the base PCP protocol is used. 190 Learning the Pref64::/n solves the issues listed above. 192 4. PREFIX64 Option 194 4.1. Format 196 The format of the PREFIX64 option is depicted in Figure 1. This 197 option follows the guidelines specified in Section 7.3 of [RFC6887]. 199 This option allows to map specific IPv4 address ranges (called IPv4 200 Prefix List) to separate Pref64::/n prefixes as discussed in 201 [RFC6147]. 203 0 1 2 3 204 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 205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 206 |Option Code=TBA| Reserved | Option Length | 207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 208 | Prefix64 Length | | 209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 210 : Prefix64 (Variable) : 211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 212 | | 213 : Suffix (Variable) : 214 | | 215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 216 | (optional) | 217 : IPv4 Prefix List (Variable) : 218 | | 219 | | 220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 222 Figure 1: Prefix64 PCP Option 224 The description of the fields is as follows: 226 o Option Code: To be assigned by IANA. 227 o Option Length: Indicates in octets the length of the enclosed 228 data. 229 o Prefix64 Length: Indicates in octets the length of the Pref64::/n. 230 The allowed values are specified in [RFC6052] (i.e., 4, 5, 6, 7, 231 8, or 12). 232 o Prefix64: This field identifies the IPv6 unicast prefix to be used 233 for constructing an IPv4-converted IPv6 address from an IPv4 234 address as specified in Section 2.2 of [RFC6052]. This prefix can 235 be the Well-Known Prefix (i.e., 64:ff9b::/96) or a Network- 236 Specific Prefix. The address synthesis MUST follow the guidelines 237 documented in [RFC6052]. 239 o Suffix: The length of this field is (12 - Prefix64 Length) octets. 240 This field identifies the suffix to be used for constructing an 241 IPv4-converted IPv6 address from an IPv4 address as specified in 242 Section 2.2 of [RFC6052]. No suffix is included if a /96 Prefix64 243 is conveyed in the option. 244 o IPv4 Prefix List: This is an optional field. The format of the 245 IPv4 Prefix List field is shown in Figure 2. This field may be 246 included by a PCP server to solve the destination-dependent 247 Pref64::/n discovery problem discussed in Section 5.1 of 248 [RFC7050]. 250 * IPv4 Prefix Count: indicates the number of IPv4 prefixes 251 included in the option. "IPv4 Prefix Count" field MUST be set 252 to 0 in a request and MUST be set to the number of included 253 IPv4 subnets in a response. 254 * An IPv4 prefix is represented as "IPv4 Address/IPv4 Prefix 255 Length" [RFC4632]. For example, to encode 192.0.2.0/24, "IPv4 256 Prefix Length" field is set to 24 and "IPv4 Address" field is 257 set to 192.0.2.0. If a Pref64::/n is configured for all IPv4 258 addresses, a wildcard IPv4 prefix (i.e., 0.0.0.0/0) may be 259 returned in the response together with the configured Pref64::/ 260 n. If no IPv4 Prefix List is returned in a PREFIX64 option, the 261 PCP client assumes the prefix is valid for any destination IPv4 262 address. Valid IPv4 prefixes are listed in Section 3.1 of 263 [RFC4632]. 265 0 1 2 3 266 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 267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 268 | IPv4 Prefix Count | IPv4 Prefix Length | 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 | IPv4 Address (32 bits) | 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 .... 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 | IPv4 Prefix Length | IPv4 Address (32 bits)... | 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 | ... IPv4 Address (continued) | 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 Figure 2: Format of IPv4 Prefix List field 281 Option Name: PREFIX64 282 Number: 283 Purpose: Learn the prefix used by the NAT64 to build 284 IPv4-converted IPv6 addresses. This is used by a host 285 is for local address synthesis (e.g., when an IPv4 address 286 is present in referrals). 287 Valid for Opcodes: MAP, ANNOUNCE 288 Length: Variable 289 May appear in: request, response. 290 Maximum occurrences: 1 for a request. As many as fit within 291 the maximum PCP message size for a response. 293 4.2. Server's Behavior 295 The PCP server controlling a NAT64 SHOULD be configured to return to 296 requesting PCP clients the value of the Pref64::/n and suffix used to 297 build IPv4-converted IPv6 addresses. When enabled, the PREFIX64 298 option conveys the value of Pref64::/n and configured suffix. If no 299 suffix is explicitly configured to the PCP server, the null suffix is 300 used as the default value (see Section 2.2 of [RFC6052]). 302 If the PCP server is configured to honor the PREFIX64 option but no 303 Pref64::/n is explicitly configured, the PCP server MUST NOT include 304 any PREFIX64 option in its PCP messages. 306 The PCP server controlling a NAT64 MAY be configured to include a 307 PREFIX64 option in all MAP responses even if the PREFIX64 option is 308 not listed in the associated request. The PCP server controlling a 309 NAT64 MAY be configured to include a PREFIX64 option in its ANNOUNCE 310 messages. 312 The PCP server MAY be configured with a list of destination IPv4 313 prefixes associated with a Pref64::/n. This list is then included by 314 the PCP server in a PREFIX64 option sent to PCP clients. 316 The PCP server MAY be configured to return multiple PREFIX64 options 317 in the same message to the PCP client. In such case, the server does 318 the following: 320 o If no destination IPv4 prefix list is configured, the PCP server 321 includes in the first PREFIX64 option, which appears in the PCP 322 message it sends to the PCP client, the prefix and suffix to 323 perform local IPv6 address synthesis [RFC6052]. Additional 324 PREFIX64 options convey any other Pref64::/n values configured. 325 Returning these prefixes allows an end host to identify them as 326 translated addresses, and instead prefer IPv4 or an alternative 327 network interface in order to avoid any NAT64 deployed in the 328 network. The PCP server is required to disambiguate prefixes used 329 for IPv6 address synthesis and other prefixes used to avoid any 330 NAT64 deployed in the network. The PCP server can be configured 331 with a customized IPv6 prefix list (i.e., specific to a PCP client 332 or a group of PCP clients) or system-wide IPv6 prefix list (i.e., 333 the same list is returned for any PCP client). Note, it is NOT 334 RECOMMENDED to include PREFIX64 options in ANNOUNCE messages if a 335 customized IPv6 prefix list is configured to the PCP server. 336 o If IPv4 prefix lists are configured, the PCP server includes in 337 the first PREFIX64 options the Pref64::/n and suffix that are 338 associated with an IPv4 prefix list (i.e., each of these PREFIX64 339 options conveys a distinct Pref64::/n together with an IPv4 prefix 340 list). Additional PREFIX64 options convey any other Pref64::/n 341 values configured (i.e., remaining Pref64::/n not mapped to any 342 IPv4 prefix list). 344 If a distinct Pref64::/n or suffix is configured to the PCP- 345 controlled NAT64 device, the PCP server SHOULD issue an unsolicited 346 PCP ANNOUNCE message to inform the PCP client about the new Pref64::/ 347 n and/or suffix. 349 4.3. Client's Behavior 351 The PCP client includes a PREFIX64 option in a MAP or ANNOUNCE 352 request to learn the IPv6 prefix and suffix used by an upstream PCP- 353 controlled NAT64 device. When enclosed in a PCP request, the 354 Prefix64 MUST be set to ::/96. The PREFIX64 option can be inserted 355 in a MAP request used to learn the external IP address as detailed in 356 Section 11.6 of [RFC6887]. 358 The PCP client MUST be prepared to receive multiple prefix(es) (e.g., 359 if several PCP servers are deployed and each of them is configured 360 with a distinct Pref64::/n). The PCP client MUST associate each 361 received Pref64::/n and suffix with the PCP server from which the 362 Pref64::/n and suffix information was retrieved. If the PCP client 363 fails to contact a given PCP server, the PCP client SHOULD clear the 364 prefix(es) and suffix(es) it learned from that PCP server. 366 If the PCP client receives a PREFIX64 option that includes an invalid 367 IPv4 prefix, the PCP client ignores that IPv4 prefix. Any other 368 valid IPv4 prefix, IPv6 prefix and suffix are not ignored by the PCP 369 client. 371 Upon receipt of the message from the PCP server, the PCP client 372 replaces any old prefix(es)/suffix(es) received from the same PCP 373 server with the new one(s) included in the PREFIX64 option(s). If no 374 PREFIX64 option includes a destination IPv4 prefix list, the host 375 embedding the PCP client uses the prefix/suffix included in the first 376 PREFIX64 option for local address synthesis. Other prefixes learned 377 can be used by the host to avoid any NAT64 deployed in the network. 378 If one or multiple received PREFIX64 options contain a destination 379 IPv4 prefix list, the PCP client MUST associate the included IPv4 380 prefixes with the Pref64::/n and the suffix indicated in the same 381 PREFIX64 option. In such case, the host embedding the PCP client 382 MUST enforce a destination-based prefix Pref64::/n selection for 383 local address synthesis purposes. How the content of the PREFIX64 384 option(s) is passed to the OS is implementation-specific. 386 Upon receipt of an unsolicited PCP ANNOUNCE message, the PCP client 387 replaces the old prefix/suffix received from the same PCP server with 388 the new Pref64::/n and suffix included in the PREFIX64 option. 390 5. Flow Examples 392 This section provides a non-normative description of use cases 393 relying on the PREFIX64 option. 395 5.1. TCP Session Initiated from an IPv6-only Host 397 The usage shown in Figure 3 depicts a typical usage of the PREFIX64 398 option when a DNS64 capability is embedded in the host. 400 In the example shown in Figure 3, once the IPv6-only client discovers 401 the IPv4 address of the remote IPv4-only server (e.g., using DNS), it 402 retrieves the Pref64::/n (i.e., 2001:db8:122:300::/56) to be used to 403 build an IPv4-converted IPv6 address for that server. This retrieval 404 is achieved using the PREFIX64 option (Steps (a) and (b)). The 405 client then uses 2001:db8:122:300::/56 to construct an IPv6 address 406 and then initiates a TCP connection (Steps (1) to (4)). 408 +---------+ +-----+ +---------+ 409 |IPv6-only| |NAT64| |IPv4-only| 410 | Client | | | | Server | 411 +---------+ +-----+ +---------+ 412 | | | 413 | (a) PCP MAP Request | | 414 | PREFIX64 | | 415 |======================>| | 416 | (b) PCP MAP Response | | 417 | PREFIX64 = | | 418 | 2001:db8:122:300::/56 | | 419 |<======================| | 420 | (1) TCP SYN | (2) TCP SYN | 421 |======================>|====================>| 422 | (4) TCP SYN/ACK | (3) TCP SYN/ACK | 423 |<======================|<====================| 424 | (5) TCP ACK | (6) TCP ACK | 425 |======================>|====================>| 426 | | | 428 Note: DNS exchange to retrieve the IPv4 address of 429 the IPv4-only Server is not shown in the figure. 431 Figure 3: Example of a TCP session initiated from an IPv6-only host 433 5.2. SIP Flow Example 435 Figure 4 shows an example of the use of the option defined in 436 Section 4 in a SIP context. In order for RTP/RTCP flows to be 437 exchanged between an IPv6-only SIP UA and an IPv4-only UA without 438 requiring any ALG (Application Level Gateway) at the NAT64 nor any 439 particular function at the IPv4-only SIP Proxy Server (e.g., Hosted 440 NAT traversal [I-D.ietf-mmusic-latching]), the PORT_SET option 441 [I-D.ietf-pcp-port-set] is used in addition to the PREFIX64 option. 443 In steps (a) and (b), the IPv6-only SIP UA retrieves a pair of ports 444 to be used for RTP/RTCP sessions, the external IPv4 address and the 445 Pref64::/n to build IPv4-embedded IPv6 addresses. This is achieved 446 by issuing a MAP request that includes a PREFIX64 option and a 447 PORT_SET option. A pair of ports (i.e., port_X/port_X+1) and an 448 external IPv4 address are then returned by the PCP server to the 449 requesting PCP client together with a Pref64::/n (i.e., 450 2001:db8:122::/48). 452 The returned external IPv4 address and external port numbers are used 453 by the IPv6-only SIP UA to build its SDP offer which contains 454 exclusively IPv4 addresses (especially in the "c=" line, the port 455 indicated for media port is the external port assigned by the PCP 456 server). The INVITE request including the SDP offer is then 457 forwarded by the NAT64 to the Proxy Server which will relay it to the 458 called party (i.e., the IPv4-only SIP UA) (Steps (1) to (3)). 460 The remote IPv4-only SIP UA accepts the offer and sends back its SDP 461 answer in a "200 OK" message which is relayed by the SIP Proxy Server 462 and NAT64 until being delivered to the IPv6-only SIP UA (Steps (4) to 463 (6)). 465 The Pref64::/n (2001:db8:122::/48) is used by the IPv6-only SIP UA to 466 construct a corresponding IPv6 address of the IPv4 address enclosed 467 in the SDP answer made by the IPv4-only SIP UA (Step 6). 469 The IPv6-only SIP UA and IPv4-only SIP UA are then able to exchange 470 RTP/RTCP flows without requiring any ALG at the NAT64 nor any special 471 function at the IPv4-only SIP Proxy Server. 473 +---------+ +-----+ +------------+ +---------+ 474 |IPv6-only| |NAT64| | IPv4 SIP | |IPv4-only| 475 | SIP UA | | | |Proxy Server| | SIP UA | 476 +---------+ +-----+ +------------+ +---------+ 477 | (a) PCP MAP Request | | | 478 | PORT_SET | | | 479 | PREFIX64 | | | 480 |======================>| | | 481 | (b) PCP MAP Response | | | 482 | PORT_SET | | | 483 | PREFIX64: | | | 484 | 2001:db8:122::/48 | | | 485 |<======================| | | 486 | (1) SIP INVITE | (2) SIP INVITE | (3) SIP INVITE | 487 |======================>|===============>|================>| 488 | (6) SIP 200 OK | (5) SIP 200 OK | (4) SIP 200 OK | 489 |<======================|<===============|<================| 490 | (7) SIP ACK | (8) SIP ACK | (9) SIP ACK | 491 |======================>|===============>|================>| 492 | | | | 493 |src port: dst port:|src port: dst port:| 494 |port_A port_B|port_X port_B| 495 |<======IPv6 RTP=======>|<============IPv4 RTP============>| 496 |<===== IPv6 RTCP======>|<============IPv4 RTCP===========>| 497 |src port: dst port:|src port: dst port:| 498 |port_A+1 port_B+1|port_X+1 port_B+1| 499 | | | 501 Figure 4: Example of IPv6 to IPv4 SIP initiated Session 503 When the session is initiated from the IPv4-only SIP UA (see 504 Figure 5), the IPv6-only SIP UA retrieves a pair of ports to be used 505 for the RTP /RTCP session, the external IPv4 address and the Pref64:: 506 /n to build IPv4-converted IPv6 addresses (Steps (a) and (b)). These 507 two steps could instead be delayed until the INVITE message is 508 received (Step 3). 510 The retrieved IPv4 address and port numbers are used to build the SDP 511 answer in Step (4) while the Pref64::/n is used to construct a IPv6 512 address corresponding to the IPv4 address enclosed in the SDP offer 513 made by the IPv4-only SIP UA (Step 3). RTP/RTCP flows are then 514 exchanged between the IPv6-only SIP UA and the IPv4-only UA without 515 requiring any ALG at the NAT64 nor any special function at the 516 IPv4-only SIP Proxy Server. 518 +---------+ +-----+ +------------+ +---------+ 519 |IPv6-only| |NAT64| | IPv4 SIP | |IPv4-only| 520 | SIP UA | | | |Proxy Server| | SIP UA | 521 +---------+ +-----+ +------------+ +---------+ 522 | (a) PCP MAP Request | | | 523 | PORT_SET | | | 524 | PREFIX64 | | | 525 |======================>| | | 526 | (b) PCP MAP Response | | | 527 | PORT_SET | | | 528 | PREFIX64: | | | 529 | 2001:db8:122::/48 | | | 530 |<======================| | | 531 | (3) SIP INVITE | (2) SIP INVITE | (1) SIP INVITE | 532 |<======================|<===============|<================| 533 | (4) SIP 200 OK | (5) SIP 200 OK | (6) SIP 200 OK | 534 |======================>|===============>|================>| 535 | (9) SIP ACK | (8) SIP ACK | (7) SIP ACK | 536 |<======================|<===============|<================| 537 | | | | 538 |src port: dst port:|src port: dst port:| 539 |port_a port_b|port_Y port_b| 540 |<======IPv6 RTP=======>|<============IPv4 RTP============>| 541 |<===== IPv6 RTCP======>|<============IPv4 RTCP===========>| 542 |src port: dst port:|src port: dst port:| 543 |port_a+1 port_b+1|port_Y+1 port_b+1| 544 | | | 546 Figure 5: Example of IPv4 to IPv6 SIP initiated Session 548 5.3. Mapping of IPv4 Address Ranges to IPv6 Prefixes 550 Figure 6 shows an example of a NAT64 configured with two Pref64::/n; 551 each of these Pref64::/n is associated with a distinct IPv4 address 552 range: 554 o 192.0.2.0/24 is mapped to 2001:db8:122:300::/56. 555 o 198.51.100.0/24 is mapped to 2001:db8:122::/48. 557 Once the IPv6-only client discovers the IPv4 address of the remote 558 IPv4-only server (i.e., 198.51.100.1), it retrieves two IPv6 prefixes 559 to be used to build an IPv4-converted IPv6 addresses. This retrieval 560 is achieved using two PREFIX64 options (Step (b)). 562 Because 198.51.100.1 matches the destination prefix 198.51.100.0/24, 563 the client uses the associated Pref64::/n (i.e., 2001:db8:122::/48) 564 to construct an IPv6 address for that IPv4-only server, and then 565 initiates a TCP connection (Steps (1) to (4)). 567 +---------+ +-----+ +---------+ 568 |IPv6-only| |NAT64| |IPv4-only| 569 | Client | | | | Server | 570 +---------+ +-----+ +---------+ 571 | | 198.51.100.1 572 | (a) PCP MAP Request | | 573 | PREFIX64 | | 574 |=================================>| | 575 | (b) PCP MAP Response | | 576 |PREFIX64{ | | 577 | Pref64::/n =2001:db8:122:300::/56| | 578 | IPv4 Prefix=192.0.2.0/24} | | 579 |PREFIX64{ | | 580 | Pref64::/n =2001:db8:122::/48 | | 581 | IPv4 Prefix=198.51.100.0/24} | | 582 |<=================================| | 583 | (1) TCP SYN | (2) TCP SYN | 584 |=================================>|====================>| 585 | (4) TCP SYN/ACK | (3) TCP SYN/ACK | 586 |<=================================|<====================| 587 | (5) TCP ACK | (6) TCP ACK | 588 |=================================>|====================>| 589 | | | 591 Note: DNS exchange to retrieve the IPv4 address of 592 the IPv4-only Server is not shown in the figure. 594 Figure 6: Mapping of IPv4 Address Ranges to IPv6 Prefixes 596 A similar behavior is to be experienced if these Pref64::/n and 597 associated IPv4 prefix lists are configured to distinct NAT64 598 devices. 600 6. IANA Considerations 602 The following PCP Option Code is to be allocated in the optional-to- 603 process range (the registry is maintained in http://www.iana.org/ 604 assignments/pcp-parameters/pcp-parameters.xml#option-rules): 606 PREFIX64 set to TBA (see Section 4.1) 608 7. Security Considerations 610 PCP-related security considerations are discussed in [RFC6887]. 612 As discussed in [RFC6147], if an attacker can manage to change the 613 Pref64::/n used by the DNS64 function, the traffic generated by the 614 host that receives the synthetic reply will be delivered to the 615 altered Pref64. This can result in either a denial-of-service (DoS) 616 attack, a flooding attack, or a MITM (Man In The Middle) attack. 617 This attack could be achieved either by altering PCP messages issued 618 by a legitimate PCP server or by using a fake PCP server. 620 Means to defend against attackers who can modify packets between the 621 PCP server and the PCP client, or who can inject spoofed packets that 622 appear to come from a legitimate PCP server SHOULD be enabled. In 623 some deployments, access control lists (ACLs) can be installed on the 624 PCP client, PCP server, and the network between them, so those ACLs 625 allow only communications from a trusted PCP server to the PCP 626 client. 628 PCP server discovery is out of scope of this document. It is the 629 responsibility of PCP server discovery document(s) to elaborate on 630 the security considerations to discover a legitimate PCP server. 632 Learning a Pref64::/n via PCP allows using DNSSEC in the presence of 633 NAT64. As such, NAT64 with DNSSEC and PCP is better than no DNSSEC 634 at all, but it is less safe than DNSSEC without DNS64/NAT64 and PCP. 635 The best mitigation action against Pref64::/n discovery attacks is 636 thus to add IPv6 support in all endpoints and hence reduce the need 637 to perform IPv6 address synthesis. 639 8. Acknowledgements 641 Many thanks to S. Perreault , R. Tirumaleswar, T. Tsou, D. Wing, J. 642 Zhao, R. Penno, I. van Beijnum, T. Savolainen, S. Savikumar, D. 643 Thaler, S. Hanna, and R. Sparks for the comments and suggestions. 645 9. References 647 9.1. Normative References 649 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 650 Requirement Levels", BCP 14, RFC 2119, March 1997. 652 [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing 653 (CIDR): The Internet Address Assignment and Aggregation 654 Plan", BCP 122, RFC 4632, August 2006. 656 [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 657 Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, 658 October 2010. 660 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 661 NAT64: Network Address and Protocol Translation from IPv6 662 Clients to IPv4 Servers", RFC 6146, April 2011. 664 [RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van 665 Beijnum, "DNS64: DNS Extensions for Network Address 666 Translation from IPv6 Clients to IPv4 Servers", RFC 6147, 667 April 2011. 669 [RFC6887] Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. 670 Selkirk, "Port Control Protocol (PCP)", RFC 6887, April 671 2013. 673 9.2. Informative References 675 [I-D.boucadair-pcp-bittorrent] 676 Boucadair, M., Zheng, T., Deng, X., and J. Queiroz, 677 "Behavior of BitTorrent service in PCP-enabled networks 678 with Address Sharing", draft-boucadair-pcp-bittorrent-00 679 (work in progress), May 2012. 681 [I-D.boucadair-pcp-nat64-experiments] 682 Abdesselam, M., Boucadair, M., Hasnaoui, A., and J. 683 Queiroz, "PCP NAT64 Experiments", draft-boucadair-pcp- 684 nat64-experiments-00 (work in progress), September 2012. 686 [I-D.carpenter-behave-referral-object] 687 Carpenter, B., Boucadair, M., Halpern, J., Jiang, S., and 688 K. Moore, "A Generic Referral Object for Internet 689 Entities", draft-carpenter-behave-referral-object-01 (work 690 in progress), October 2009. 692 [I-D.ietf-mmusic-latching] 693 Ivov, E., Kaplan, H., and D. Wing, "Latching: Hosted NAT 694 Traversal (HNT) for Media in Real-Time Communication", 695 draft-ietf-mmusic-latching-04 (work in progress), October 696 2013. 698 [I-D.ietf-pcp-port-set] 699 Qiong, Q., Boucadair, M., Sivakumar, S., Zhou, C., Tsou, 700 T., and S. Perreault, "Port Control Protocol (PCP) 701 Extension for Port Set Allocation", draft-ietf-pcp-port- 702 set-04 (work in progress), November 2013. 704 [I-D.ietf-rtcweb-overview] 705 Alvestrand, H., "Overview: Real Time Protocols for Brower- 706 based Applications", draft-ietf-rtcweb-overview-08 (work 707 in progress), September 2013. 709 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 710 A., Peterson, J., Sparks, R., Handley, M., and E. 711 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 712 June 2002. 714 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 715 Rose, "DNS Security Introduction and Requirements", RFC 716 4033, March 2005. 718 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 719 Rose, "Resource Records for the DNS Security Extensions", 720 RFC 4034, March 2005. 722 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 723 Rose, "Protocol Modifications for the DNS Security 724 Extensions", RFC 4035, March 2005. 726 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 727 Description Protocol", RFC 4566, July 2006. 729 [RFC6269] Ford, M., Boucadair, M., Durand, A., Levis, P., and P. 730 Roberts, "Issues with IP Address Sharing", RFC 6269, June 731 2011. 733 [RFC7050] Savolainen, T., Korhonen, J., and D. Wing, "Discovery of 734 the IPv6 Prefix Used for IPv6 Address Synthesis", RFC 735 7050, November 2013. 737 [RFC7051] Korhonen, J. and T. Savolainen, "Analysis of Solution 738 Proposals for Hosts to Learn NAT64 Prefix", RFC 7051, 739 November 2013. 741 Author's Address 743 Mohamed Boucadair 744 France Telecom 745 Rennes 35000 746 France 748 Email: mohamed.boucadair@orange.com