idnits 2.17.00 (12 Aug 2021) /tmp/idnits19556/draft-ietf-pcp-proxy-09.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 (July 14, 2015) is 2496 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: draft-ietf-pcp-anycast has been published as RFC 7723 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Perreault 3 Internet-Draft Jive Communications 4 Intended status: Standards Track M. Boucadair 5 Expires: January 15, 2016 France Telecom 6 R. Penno 7 D. Wing 8 Cisco 9 S. Cheshire 10 Apple 11 July 14, 2015 13 Port Control Protocol (PCP) Proxy Function 14 draft-ietf-pcp-proxy-09 16 Abstract 18 This document specifies a new PCP functional element denoted as a PCP 19 Proxy. The PCP Proxy relays PCP requests received from PCP clients 20 to upstream PCP server(s). A typical deployment usage of this 21 function is to help establish successful PCP communications for PCP 22 clients that can not be configured with the address of a PCP server 23 located more than one hop away. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on January 15, 2016. 42 Copyright Notice 44 Copyright (c) 2015 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 1.1. Use Case: the NAT Cascade . . . . . . . . . . . . . . . . 3 61 1.2. Use Case: the PCP Relay . . . . . . . . . . . . . . . . . 4 62 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 63 3. Operation of the PCP Proxy . . . . . . . . . . . . . . . . . 5 64 3.1. Optimized Hairpin Routing . . . . . . . . . . . . . . . . 8 65 3.2. Termination of Recursion . . . . . . . . . . . . . . . . 8 66 3.3. Source Address for PCP Requests Sent Upstream . . . . . . 9 67 3.4. Unknown OpCodes and Options . . . . . . . . . . . . . . . 9 68 3.4.1. No NAT is Co-located with the PCP Proxy . . . . . . . 9 69 3.4.2. PCP Proxy Co-located with a NAT Function . . . . . . 10 70 3.5. Mapping Repair . . . . . . . . . . . . . . . . . . . . . 10 71 3.6. Multiple PCP Servers . . . . . . . . . . . . . . . . . . 11 72 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 73 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 74 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 75 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 76 7.1. Normative References . . . . . . . . . . . . . . . . . . 12 77 7.2. Informative References . . . . . . . . . . . . . . . . . 12 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 80 1. Introduction 82 This document defines a new PCP [RFC6887] functional element: the PCP 83 Proxy. As shown in Figure 1, the PCP proxy is logically equivalent 84 to a PCP client back-to-back with a PCP server. The "glue" between 85 the two is what is specified in this document. Other than that 86 "glue", the server and the client behave exactly like their regular 87 counterparts. 89 The PCP Proxy is responsible for relaying PCP messages received from 90 PCP clients to upstream PCP servers and vice versa. 92 Whether the PCP Proxy is co-located with a flow-aware function (e.g., 93 NAT, firewall) is deployment-specific. 95 ................. 96 +------+ : +------+------+ : +------+ 97 |Client|-------:-|Server|Client|-:----|Server| 98 +------+ : +------+------+ : +------+ 99 : Proxy : 100 ................. 102 Figure 1: Reference Architecture 104 This document assumes a hop-by-hop PCP authentication scheme. That 105 is, in reference to Figure 1, the left-most PCP client authenticates 106 with the PCP Proxy, while the PCP Proxy authenticates with the 107 upstream server. Note that in some deployments, PCP authentication 108 may only be enabled between the PCP Proxy and an upstream PCP server 109 (e.g., a customer premises host may not authenticate with the PCP 110 Proxy but the PCP Proxy may authenticate with the PCP server). The 111 hop-by-hop authentication scheme is more suitable from a deployment 112 standpoint. Furthermore, it allows to easily support a PCP Proxy 113 that alters PCP messages (e.g., strip a PCP option, modify a PCP 114 field, etc.). 116 1.1. Use Case: the NAT Cascade 118 In today's world, with public routable IPv4 addresses becoming less 119 readily available, it is increasingly common for customers to receive 120 a private address from their Internet Service Provider (ISP), and the 121 ISP uses a NAT gateway of its own to translate those packets before 122 sending them out onto the public Internet. This means that there is 123 likely to be more than one NAT on the path between client machines 124 and the public Internet: 126 o If a residential customer receives a translated address from their 127 ISP, and then installs their own residential NAT gateway to share 128 that address between multiple client devices in their home, then 129 there are at least two NAT gateways on the path between client 130 devices and the public Internet. 132 o If a mobile phone customer receives a translated address from 133 their mobile phone carrier, and uses "Personal Hotspot" or 134 "Internet Sharing" software on their mobile phone to make Wireless 135 LAN (WLAN) Internet access available to other client devices, then 136 there are at least two NAT gateways on the path between those 137 client devices and the public Internet. 139 o If a hotel guest connects a portable WLAN gateway to their hotel 140 room Ethernet port to share their room's Internet connection 141 between their phone and their laptop computer, then packets from 142 the client devices may traverse the hotel guest's portable NAT, 143 the hotel network's NAT, and the ISP's NAT before reaching the 144 public Internet. 146 While it is possible, in theory, that client devices could somehow 147 discover all the NATs on the path, and communicate with each one 148 separately using Port Control Protocol [RFC6887], in practice it's 149 not clear how client devices would reliably learn this information. 150 Since the NAT gateways are installed and operated by different 151 individuals and organizations, no single entity has knowledge of all 152 the NATs on the path. Also, even if a client device could somehow 153 know all the NATs on the path, requiring a client device to 154 communicate separately with all of them imposes unreasonable 155 complexity on PCP clients, many of which are expected to be simple 156 low-cost devices. 158 In addition, this goes against the spirit of NAT gateways. The main 159 purpose of a NAT gateway is to make multiple downstream client 160 devices to appear, from the point of view of everything upstream of 161 the NAT gateway, to be a single client device. In the same spirit, 162 it makes sense for a PCP-capable NAT gateway to make multiple 163 downstream client devices requesting port mappings to appear, from 164 the point of view of everything upstream of the NAT gateway, to be a 165 single client device requesting port mappings. 167 1.2. Use Case: the PCP Relay 169 Another envisioned use case of the PCP Proxy is to help establish 170 successful PCP communications for PCP clients that can not be 171 configured with the address of a PCP server located more than one hop 172 away. A PCP Proxy can be for instance embedded in a CPE (Customer 173 Premises Equipment) while the PCP server is located in a network 174 operated by an ISP. This is illustrated in Figure 2. 176 | 177 +------+ | 178 |Client|--+ 179 +------+ | +-----+ +------+ 180 +--|Proxy|------------------|Server| 181 +------+ | +-----+ +------+ 182 |Client|--+ CPE 183 +------+ | 184 | 185 LAN 187 Figure 2: PCP Relay Use Case 189 This works because the proxy's server side is listening on the 190 address used as a default gateway by the clients. The clients use 191 that address as a fallback when discovering the PCP server's address. 192 The proxy picks up the requests and forwards them upstream to the 193 ISP's PCP server, with whose address it has been provisioned through 194 regular PCP client provisioning means. 196 This particular use case assumes that provisioning the server's 197 address on the CPE is feasible while doing it on the clients in the 198 LAN is not, which is what makes the PCP proxy valuable. 200 Note that [I-D.ietf-pcp-anycast] documents an alternate solution to 201 the PCP proxy. Nevertheless, as discussed in 202 [I-D.boucadair-pcp-deployment-cases], the anycast solution may be 203 problematic when multiple PCP servers are to be contacted. 205 2. Terminology 207 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 208 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 209 "OPTIONAL" in this document are to be interpreted as described in RFC 210 2119 [RFC2119]. 212 Where this document uses the terms "upstream" and "downstream", the 213 term "upstream" refers to the direction outbound packets travel 214 towards the public Internet, and the term "downstream" refers to the 215 direction inbound packets travel from the public Internet towards 216 client systems. Typically when a home user views a web site, their 217 computer sends an outbound TCP SYN packet upstream towards the public 218 Internet, and an inbound downstream TCP SYN ACK reply comes back from 219 the public Internet. 221 3. Operation of the PCP Proxy 223 Upon receipt of a PCP mapping-creation request from a downstream PCP 224 client, a PCP proxy first examines its local mapping table to see if 225 it already has a valid active mapping matching the Internal Address 226 and Internal Port (and in the case of PEER requests, remote peer) 227 given in the request. 229 If the PCP proxy does not already have a valid active mapping for 230 this mapping-creation request, then it allocates an available port on 231 its external interface. We assume for the sake of this description 232 that the address of its external interface is itself a private 233 address, subject to translation by an upstream NAT. The PCP proxy 234 then constructs an appropriate corresponding PCP request of its own 235 (described below), and sends it to its upstream NAT, and the newly- 236 created local mapping is considered temporary until a confirming 237 reply is received from the upstream PCP server. 239 If the PCP proxy does already have a valid active mapping for this 240 mapping-creation request, and the lifetime remaining on the local 241 mapping is at least 3/4 of the lifetime requested by the PCP client, 242 then the PCP proxy SHOULD send an immediate reply giving the 243 outermost External Address and Port (previously learned using PCP 244 recursively, as described below), and the actual lifetime remaining 245 for this mapping. If the lifetime remaining on the local mapping is 246 less than 3/4 of the lifetime requested by the PCP client, then the 247 PCP proxy MUST generate an upstream request as described below. 249 For mapping-deletion requests (Lifetime = 0), the local mapping, if 250 any, is deleted, and then (regardless of whether a local mapping 251 existed) a corresponding upstream request is generated. 253 The PCP proxy knows the destination IP address for its upstream PCP 254 request using the same means that are available for provisioning a 255 PCP client. In particular, the PCP proxy MUST follow the procedure 256 defined in Section 8.1 of [RFC6887] to discover its PCP server. This 257 does not preclude other means from being used in addition. 259 In the upstream PCP request: 261 o The PCP Client's IP Address and Internal Port are the PCP proxy's 262 own external address and port just allocated for this mapping. 264 o The Suggested External Address and Port in the upstream PCP 265 request SHOULD be copied from the original PCP request. 267 o The Requested Lifetime is as requested by the client if it falls 268 within the acceptable range for this PCP server; otherwise it 269 SHOULD be capped to appropriate minimum and maximum values 270 configured for this PCP server. 272 o The Mapping Nonce is copied from the original PCP request. 274 o For PEER requests, the Remote Peer IP Address and Port are copied 275 from the original PCP request. 277 Upon receipt of a PCP reply giving the outermost (i.e., publicly 278 routable) External Address, Port and Lifetime, the PCP proxy records 279 this information in its own mapping table and relays the information 280 to the requesting downstream PCP client in a PCP reply. The PCP 281 proxy therefore records, among other things, the following 282 information in its mapping table: 284 o Client's Internal Address and Port. 286 o External Address and Port allocated by this PCP proxy. 288 o Outermost External Address and Port allocated by the upstream PCP 289 server. 291 o Mapping lifetime (also dictated by the upstream PCP server). 293 o Mapping nonce. 295 In the downstream PCP reply: 297 o The Lifetime is as granted by the upstream PCP server, or less, if 298 the granted lifetime exceeds the maximum lifetime this PCP server 299 is configured to grant. If the downstream Lifetime is more than 300 the Lifetime granted by the upstream PCP server (which is NOT 301 RECOMMENDED) then this PCP proxy MUST take responsibility for 302 renewing the upstream mapping itself. 304 o The Epoch Time is this PCP proxy's Epoch Time, not the Epoch Time 305 of the upstream PCP server. Each PCP server has its own 306 independent Epoch Time. However, if the Epoch Time received from 307 the upstream PCP server indicates a loss of state in that PCP 308 server, the PCP proxy can either recreate the lost mappings 309 itself, or it can reset its own Epoch Time to cause its downstream 310 clients to perform such state repairs themselves. A PCP proxy 311 MUST NOT simply copy the upstream PCP server's Epoch Time into its 312 downstream PCP replies, since if it suffers its own state loss it 313 needs the ability to communicate that state loss to clients. Thus 314 each PCP server has its own independent Epoch Time. However, as a 315 convenience, a downstream PCP proxy may simply choose to reset its 316 own Epoch Time whenever it detects that its upstream PCP server 317 has lost state. Thus, in this case, the PCP proxy's Epoch Time 318 always resets whenever its upstream PCP server loses state; it may 319 also reset at other times too. 321 o The Mapping Nonce is copied from the reply received from the 322 upstream PCP server. 324 o The Assigned External Port and Assigned External IP Address are 325 copied from the reply received from the upstream PCP server (i.e., 326 they are the outermost External IP Address and Port, not the 327 locally-assigned external address and port.) 329 o For PEER requests, the Remote Peer IP Address and Port are copied 330 from the reply received from the upstream PCP server. 332 3.1. Optimized Hairpin Routing 334 A PCP proxy SHOULD implement Optimized Hairpin Routing. What this 335 means is the following: 337 o If a PCP proxy observes an outgoing packet arriving on its 338 internal interface that is addressed to an External Address and 339 Port appearing in the NAT gateway's own mapping table, then the 340 NAT gateway SHOULD (after creating a new outbound mapping if one 341 does not already exist) rewrite the packet appropriately and 342 deliver it to the internal client currently allocated that 343 External Address and Port. 345 o If a PCP proxy observes an outgoing packet arriving on its 346 internal interface which is addressed to an Outermost External 347 Address and Port appearing in the NAT gateway's own mapping table, 348 then the NAT gateway SHOULD do likewise: create a new outbound 349 mapping if one does not already exist, and then rewrite the packet 350 appropriately and deliver it to the internal client currently 351 allocated that Outermost External Address and Port. This is not 352 necessary for successful communication, but for efficiency. 353 Without this Optimized Hairpin Routing, the packet will be 354 delivered all the way to the outermost NAT gateway, which will 355 then perform standard hairpin translation and send it back. Using 356 knowledge of the Outermost External Address and Port, this 357 rewriting can be anticipated and performed locally, which will 358 typically offer higher throughput and lower latency than sending 359 it all the way to the outermost NAT gateway and back. 361 Note that traffic counters maintained by an upstream PCP server will 362 differ from the ones of a PCP Proxy implementing the optimized 363 hairpin routing. 365 3.2. Termination of Recursion 367 Any recursive algorithm needs a mechanism to terminate the recursion 368 at the appropriate point. This termination of recursion can be 369 achieved in a variety of ways. The following (non exhaustive) 370 examples are provided for illustration purposes: 372 o An ISP's PCP-controlled gateway (that may embed a NAT, firewall or 373 any function that can be controlled with PCP) could be configured 374 to know that it is the outermost PCP-controlled gateway, and 375 consequently does not need to relay PCP requests upstream. 377 o A PCP-controlled gateway could determine automatically that if its 378 external address is not one of the known private addresses 379 [RFC1918][RFC6598], then its external address is a public routable 380 IP address, and consequently it does not need to relay PCP 381 requests upstream. 383 o Recursion may be terminated if there is no explicit list of PCP 384 servers configured to the PCP Proxy (e.g., [RFC7291]) or if its 385 default router is not responsive to PCP requests. 387 o Recursion may also be terminated if the upstream PCP-controlled 388 device does not embed a PCP Proxy. 390 3.3. Source Address for PCP Requests Sent Upstream 392 As with a regular PCP server, the PCP-controlled device can be a NAT, 393 a firewall, or even some sort of hybrid. In particular, a PCP proxy 394 that simply relays all requests upstream can be thought of as the 395 degenerate case of a PCP server controlling a wide-open firewall 396 back-to-back with a regular PCP client. 398 One important property of the PCP-controlled device will affect the 399 PCP proxy's behaviour: when the proxy's server part instructs the 400 device to create a mapping, that mapping's external address may or 401 may not be one that belongs to the proxy node. 403 o When the mapping's external address belongs to the proxy node, as 404 would presumably be the case for a NAT, then the proxy's client 405 side sends out an upstream PCP request using the mapping's 406 external IP address as source. 408 o When the mapping's external address does not belong to the proxy 409 node, as would presumably be the case for a firewall, then the 410 proxy's client side needs to install upstream mappings on behalf 411 of its downstream clients. To do this, it MUST insert a 412 THIRD_PARTY Option in its upstream PCP request carrying the 413 mapping's external address. 415 Note that hybrid PCP-controlled devices may create NAT-like mappings 416 in some circumstances and firewall-like mappings in others. A proxy 417 controlling such a device would adjust its behavior dynamically 418 depending on the kind of mapping created. 420 3.4. Unknown OpCodes and Options 422 3.4.1. No NAT is Co-located with the PCP Proxy 424 When no NAT is co-located with the PCP Proxy, the port numbers 425 included in received PCP messages (from the PCP server or PCP 426 client(s)) are not altered by the PCP Proxy. The PCP Proxy relays to 427 the PCP server unknown Options and OpCodes because there is no 428 reachability failure risk. 430 3.4.2. PCP Proxy Co-located with a NAT Function 432 By default, the proxy MUST relay unknown OpCodes and mandatory-to- 433 process unknown Options. Rejecting unknown Options and OpCodes has 434 the drawback of preventing a PCP client to make use of new 435 capabilities offered by the PCP server but not supported by the PCP 436 Proxy even if no IP address and/or port is included in the Option/ 437 OpCode. 439 Because PCP messages with an unknown OpCode or mandatory-to-process 440 unknown Options can carry a hidden internal address or internal port 441 that will not be translated, a PCP Proxy MUST be configurable to 442 disable relaying unknown OpCodes and mandatory-to-process unknown 443 Options. If the PCP Proxy is configured to disable relaying unknown 444 OpCodes and mandatory-to-process unknown Options, the PCP Proxy MUST 445 behave as follows: 447 o a PCP Proxy co-located with a NAT MUST reject by an UNSUPP_OPCODE 448 error response a received request with an unknown OpCode. 450 o a PCP Proxy co-located with a NAT MUST reject by an UNSUPP_OPTION 451 error response a received request with a mandatory-to-process 452 unknown Option. 454 3.5. Mapping Repair 456 ANNOUNCE requests received from PCP clients are handled locally; as 457 such these requests MUST NOT be relayed to the provisioned PCP 458 server. 460 Upon receipt of an unsolicited ANNOUNCE response from a PCP server, 461 the PCP Proxy proceeds to renew the mappings and checks whether there 462 are changes compared to a local cache if it is maintained by the PCP 463 Proxy. If no change is detected, no unsolicited ANNOUNCE is 464 generated towards PCP clients. If a change is detected, the PCP 465 Proxy MUST generate unsolicited ANNOUNCE message(s) to appropriate 466 PCP clients. If the PCP Proxy does not maintain a local cache for 467 the mappings, unsolicited multicast ANNOUNCE messages are sent to PCP 468 clients. 470 Upon change of its external IP address, the PCP Proxy SHOULD renew 471 the mappings it maintained. If the PCP server assigns a different 472 external port, the PCP Proxy SHOULD follow the mapping repair 473 procedure defined in [RFC6887]. This can be achieved only if a full 474 state table is maintained by the PCP Proxy. 476 3.6. Multiple PCP Servers 478 A PCP Proxy MAY handle multiple PCP servers at the same time. Each 479 PCP server is associated with its own epoch value. PCP clients are 480 not aware of the presence of multiple PCP servers. 482 According to [RFC7488], if several PCP Names are configured to the 483 PCP Proxy, it will contact in parallel all these PCP servers. 485 In some contexts (e.g., PCP-controlled CGNs), the PCP Proxy MAY load 486 balance the PCP clients among available PCP servers. The PCP Proxy 487 MUST ensure requests of a given PCP client are relayed to the same 488 PCP server. 490 The PCP Proxy MAY rely on some fields (e.g., Zone ID 491 [I-D.penno-pcp-zones]) in the PCP request to redirect the request to 492 a given PCP server. 494 4. IANA Considerations 496 This document makes no request of IANA. 498 5. Security Considerations 500 The PCP Proxy MUST follow the security considerations elaborated in 501 [RFC6887] for both the client and server side. 503 Section 3.3 specifies the cases where a THIRD_PARTY option is 504 inserted by the PCP Proxy. In those cases, means to prevent a 505 malicious user from creating mappings on behalf of a third party must 506 be enabled as discussed in Section 13.1 of [RFC6887]. In particular, 507 THIRD_PARTY options MUST NOT be enabled unless the network on which 508 the PCP messages are to be sent is fully trusted. For example if 509 access control lists (ACLs) are installed on the PCP Proxy, PCP 510 server, and the network between them, so those ACLs allow only 511 communications from a trusted PCP Proxy to the PCP server. 513 A received request carrying an unknown OpCode or Option SHOULD be 514 dropped (or in the case of an unknown Option which is not mandatory- 515 to-process the Option SHOULD be removed) if it is not compatible with 516 security controls provisioned to the PCP Proxy. 518 The device embedding the PCP Proxy MAY block PCP requests directly 519 sent to the PCP server. This can be enforced using access control 520 lists. 522 6. Acknowledgements 524 Many thanks to C. Zhou, T. Reddy, and D. Thaler for their review 525 and comments. 527 Special thanks to F. Dupont who contributed to this document. 529 7. References 531 7.1. Normative References 533 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 534 Requirement Levels", BCP 14, RFC 2119, March 1997. 536 [RFC6887] Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. 537 Selkirk, "Port Control Protocol (PCP)", RFC 6887, April 538 2013. 540 7.2. Informative References 542 [I-D.boucadair-pcp-deployment-cases] 543 Boucadair, M., "Port Control Protocol (PCP) Deployment 544 Models", draft-boucadair-pcp-deployment-cases-03 (work in 545 progress), July 2014. 547 [I-D.ietf-pcp-anycast] 548 Kiesel, S., Penno, R., and S. Cheshire, "Port Control 549 Protocol (PCP) Anycast Addresses", draft-ietf-pcp- 550 anycast-06 (work in progress), May 2015. 552 [I-D.penno-pcp-zones] 553 Penno, R., "PCP Support for Multi-Zone Environments", 554 draft-penno-pcp-zones-01 (work in progress), October 2011. 556 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 557 E. Lear, "Address Allocation for Private Internets", BCP 558 5, RFC 1918, February 1996. 560 [RFC6598] Weil, J., Kuarsingh, V., Donley, C., Liljenstolpe, C., and 561 M. Azinger, "IANA-Reserved IPv4 Prefix for Shared Address 562 Space", BCP 153, RFC 6598, April 2012. 564 [RFC7291] Boucadair, M., Penno, R., and D. Wing, "DHCP Options for 565 the Port Control Protocol (PCP)", RFC 7291, July 2014. 567 [RFC7488] Boucadair, M., Penno, R., Wing, D., Patil, P., and T. 568 Reddy, "Port Control Protocol (PCP) Server Selection", RFC 569 7488, March 2015. 571 Authors' Addresses 573 Simon Perreault 574 Jive Communications 575 Quebec, QC 576 Canada 578 Email: sperreault@jive.com 580 Mohamed Boucadair 581 France Telecom 582 Rennes 35000 583 France 585 Email: mohamed.boucadair@orange.com 587 Reinaldo Penno 588 Cisco 589 USA 591 Email: repenno@cisco.com 593 Dan Wing 594 Cisco Systems, Inc. 595 170 West Tasman Drive 596 San Jose, California 95134 597 USA 599 Email: dwing@cisco.com 601 Stuart Cheshire 602 Apple Inc. 603 1 Infinite Loop 604 Cupertino, California 95014 605 USA 607 Phone: +1 408 974 3207 608 Email: cheshire@apple.com