idnits 2.17.1 draft-boucadair-hops-capability-discovery-00.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 (June 30, 2015) is 3194 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-14) exists of draft-ietf-pcp-authentication-12 == Outdated reference: A later version (-13) exists of draft-ietf-pcp-port-set-09 -- Obsolete informational reference (is this intentional?): RFC 793 (Obsoleted by RFC 9293) -- Obsolete informational reference (is this intentional?): RFC 4960 (Obsoleted by RFC 9260) -- Obsolete informational reference (is this intentional?): RFC 6145 (Obsoleted by RFC 7915) -- Obsolete informational reference (is this intentional?): RFC 6824 (Obsoleted by RFC 8684) Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Boucadair 3 Internet-Draft C. Jacquenet 4 Intended status: Experimental France Telecom 5 Expires: January 1, 2016 June 30, 2015 7 Discovering the Capabilities of Flow-Aware Service Functions (a.k.a. 8 Middleboxes): A PCP-based Approach 9 draft-boucadair-hops-capability-discovery-00 11 Abstract 13 This document specifies a solution to discover the capabilities of a 14 flow-aware service function. The solution relies upon the use of the 15 Port Control Protocol (PCP). 17 This solution allows for applications to anticipate connectivity 18 failures and to proceed with countermeasures (e.g., create a mapping 19 for incoming connections, discover a mapping lifetime, discover an 20 external IP address, avoid injecting some options in the outgoing 21 packets, etc.). The propsoed approach allows, for example, to 22 discover whether an upstream flow-aware service function is MPTCP- 23 friendly (that is, it does not strip MPTCP signals) or SCTP- 24 compliant, whether it embeds a firewall function, etc. or a 25 combination thereof. 27 Requirements Language 29 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 30 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 31 document are to be interpreted as described in RFC 2119 [RFC2119]. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at http://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on January 1, 2016. 50 Copyright Notice 52 Copyright (c) 2015 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 68 2. PCP CAPABILITY Option . . . . . . . . . . . . . . . . . . . . 4 69 3. PCP Client & Host Behavior . . . . . . . . . . . . . . . . . 5 70 4. PCP Server Behavior . . . . . . . . . . . . . . . . . . . . . 6 71 5. Sample Use Cases . . . . . . . . . . . . . . . . . . . . . . 6 72 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 73 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 74 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 75 8.1. Normative References . . . . . . . . . . . . . . . . . . 10 76 8.2. Informative References . . . . . . . . . . . . . . . . . 10 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 79 1. Introduction 81 Advanced service functions (e.g., Performance Enhancement Proxies 82 ([RFC3135]), NATs [RFC3022][RFC6333][RFC6146], firewalls 83 [I-D.ietf-opsawg-firewalls], etc.) are required to achieve various 84 objectives such as IP address sharing, firewalling, to avoid covert 85 channels, to detect and protect against DDoS attacks, etc. 87 Removing those functions is not an option because they are used to 88 address constraints that are often typical of the current yet protean 89 Internet situation (global IPv4 address depletion comes to mind, but 90 also the plethora of services with different QoS/security/robustness 91 requirements, etc.), and this is even exacerbated by environment- 92 specific designs (e.g., the nature and the number of service 93 functions that need to be invoked at the Gi interface of a mobile 94 infrastructure). 96 Moreover, these sophisticated service functions are located in the 97 network but also in service platforms, or other structures like 98 Content Delivery Networks. Some of these service functions can be 99 controlled by hosts (e.g., NAT) to avoid connectivity complications 100 ([RFC6269]) while others are hidden to customers. 102 This document proposes a solution that can be used by hosts to 103 discover the capabilities of flow-aware service functions that are 104 visible to them but it can also be used by an administrator 105 responsible for the management of such (hidden) service functions, 106 e.g., to inform an SFC controller ([I-D.ww-sfc-control-plane]) about 107 the nature and the status of these service functions. Obviously, 108 exposing this information to hosts/applications is deployment- 109 specific. 111 Customer-facing flow-aware service functions can announce their 112 capabilities to hosts. This information can be used by a host to 113 select a service function instance (e.g., include the external 114 address of that service function in a referral will involve that 115 service function in the communication path). For example, a host 116 that discovers that the Residential Gateway it is connected to does 117 not support Stream Control Transmission Protocol (SCTP, [RFC4960]), 118 won't even try to use SCTP as a transport protocol; TCP/SCTP happy 119 eyeball proposals are useless in such case. 121 This document extends the base PCP [RFC6887] with a new option, 122 called CAPABILITY (Section 2), to discover the capabilities of one or 123 several service functions typically embedded in middleboxes. 124 Retrieving the capabilities of these middleboxes is meant to 125 facilitate fault management (e.g., provide a hint about why some 126 applications fail, help select the required actions to instruct the 127 middlebox to handle incoming connections, etc.). This option, when 128 received from a PCP server, is used by a host (and the PCP client) to 129 better adapt the traffic it may send according to the perceived 130 network conditions as exposed in the PCP option (including tweaking 131 PCP requests to instruct mappings). 133 This specification can also be used to help the introduction of new 134 transport protocols. For example, CPE devices managed by a service 135 provider can include this feature. Also, a service provider that 136 Introduces additional service nodes that support new features (e.g., 137 SCTP-aware CGN) in the network can select the set of CPEs that will 138 be serviced by these nodes. It can do so by setting the SCTP bit 139 when sending the capability information to the selected CPEs. 140 Additional sample use cases are discussed in Section 5. 142 2. PCP CAPABILITY Option 144 The CAPABILITY option (Code: TBA, Figure 1) is used by a flow-aware 145 service function to explicitly inform a host about the capabilities 146 that pertain to the said flow-aware service function, especially as 147 far as IP forwarding operations are concerned. 149 One single CAPABILITY option is conveyed in the same PCP message even 150 if several functions are co-located in the same device (e.g., NAT44 151 and NAT64, NAT44 and port set assignment capability, etc.). 153 0 1 2 3 154 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 155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 156 | CAPABILITY | Reserved | Length=16 | 157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 158 |A| Capability | 159 +-+ | 160 : : 161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 163 This Option: 165 Option Name: PCP Capabilities option (CAPABILITY) 166 Number: TBA (IANA) 167 Purpose: Retrieve the capabilities of a PCP-controlled device 168 Valid for Opcodes: ANNOUNCE, MAP, PEER 169 Length: 16 170 May appear in: both request and response 171 Maximum occurrences: 1 173 Figure 1: Capability option 175 When set, the A bit indicates the PCP server supports authentication 176 ([I-D.ietf-pcp-authentication]). If this bit is unset, it indicates 177 that plain PCP is supported. 179 The Capability Field is encoded in 127 bits. Each bit in the 180 Capability bit mask is used to represent a PCP-controlled device 181 capability. Whenever a bit of the Capability Field is set, this 182 means that the corresponding capability is enabled/supported. 183 Several bits can be set simultaneously if several functions are co- 184 located. The default value for each capability bit is '0'. The 185 meaning associated with the following Capability bits is (other 186 values can be added to the list): 188 Bit #: Description 189 1: NAT44 [RFC3022] 190 2: Stateless NAT64 [RFC6145]. 191 4: Stateful NAT64 [RFC6146]. 192 5 : Dual-Stack Lite (DS-Lite) AFTR [RFC6333] 193 6: Dual-Stack Extra Lite [RFC6619] 194 8: A+P Port Range Router (PRR) [RFC6346] 195 9: Supports PORT_SET option [I-D.ietf-pcp-port-set]. 196 16: IPv4 firewall. 197 32: IPv6 Firewall [RFC6092]. 198 64: IPv6-to-IPv6 Network Prefix Translation (NPTv6) [RFC6296]. 199 119: TCP [RFC0793]. 200 120: User Datagram Protocol (UDP) [RFC0768]. 201 121: UDP-Lite compliant [RFC3828] 202 122: Datagram Congestion Control Protocol (DCCP) [RFC4340] 203 123: SCTP [RFC4960] 204 124: Multipath TCP (MPTCP) [RFC6824]. 205 125: DSCP re-marking function. 206 126: FLOWDATA-aware function ([I-D.wing-pcp-flowdata]). 207 127: ILNP Translator [RFC6740]. 209 3. PCP Client & Host Behavior 211 The PCP client includes a CAPABILITY option in a MAP or ANNOUNCE 212 request to learn the capabilities of an upstream PCP-controlled 213 device. When conveyed in a PCP request, the Capability field MUST be 214 set to 0. The CAPABILITY option can be inserted in a MAP request 215 that is used to learn the external IP address, as detailed in 216 Section 11.6 of [RFC6887]. 218 The PCP client MUST be prepared to receive multiple CAPABILITY 219 options (e.g., if several PCP servers are deployed and each of them 220 is configured with a distinct set of capabilities). The PCP client 221 MUST associate each received set of capabilities and suffix with the 222 PCP server from which the information was retrieved. 224 Upon receipt of an unsolicited PCP ANNOUNCE message, the PCP client 225 replaces the former set of capabilities as received from the same PCP 226 server with the new set of capabilities, as indicated in the 227 CAPABILITY option. 229 Based on the received capabilities, the host/application/PCP client 230 may decide to tune its requests (e.g., Section 5). For example, a 231 PCP client can use the returned information to decide whether all PCP 232 servers need to be contacted in parallel or only a subset of them , 233 or which service function to solicit in order to establish some 234 sessions (e.g., SCTP). 236 4. PCP Server Behavior 238 Activating this feature on the PCP server is subject to 239 administrative authorization procedures. 241 The PCP server that controls a flow-aware service function SHOULD be 242 configured to provide requesting PCP clients with the supported 243 capabilities whose corresponding bit in the CAPABILITY option will 244 therefore be set. When enabled, the CAPABILITY option conveys the 245 set of capabilities supported by the PCP-controlled device. 247 If the PCP server is configured to honor the CAPABILITY option but 248 has no means to determine the set of capabilities supported by the 249 local device, the PCP server MUST NOT include any CAPABILITY option 250 in its PCP messages. 252 The PCP server MAY be configured to include a CAPABILITY option in 253 all MAP responses, even if the CAPABILITY option is not listed in the 254 associated request. The PCP server MAY be configured to include a 255 CAPABILITY option in its ANNOUNCE messages. 257 In the event of any change of the capabilities supported by the PCP- 258 controlled device (e.g., the activation of a new service function), 259 the PCP server SHOULD issue an unsolicited PCP ANNOUNCE message to 260 inform the PCP client about the updated set of capabilities. 262 Upon receipt of a PCP request from a PCP client that requires the PCP 263 server to proceed with an operation that is beyond its capabilities, 264 the PCP server MAY return an error code together with the CAPABILITY 265 option. 267 When a new PCP server joins the network, it MAY then send an ANNOUNCE 268 Opcode with its capabilities (i.e., CAPABILITY option). 270 5. Sample Use Cases 272 Below is provided a non-exhaustive list of use cases to illustrate 273 the benefits of the proposed solution: 275 o A middlebox may be configured to strip MPTCP options or to let 276 them pass without any modification. Explicitly advertising such 277 capability to the hosts will avoid extra delays to establish 278 successful TCP sessions. In reference to Figure 2, the host won't 279 use MPTCP because the firewall it is connected to does not support 280 MPTCP. This information is useful for the application since it 281 can use the TCP option space more efficiently, so as to insert 282 options that couldn't be inserted if MPTCP options were included. 284 __________ 285 +-----------+ +-----------------+ / \ +-----------+ 286 | HOST |___|MPTCP-disabled FW|____| Internet |___| Server | 287 +-----------+ +-----------------+ \__________/ +-----------+ 289 Figure 2: MPTCP Example 291 o A host that supports both TCP and SCTP can decide which transport 292 to use when establishing transport sessions. For example, an 293 application that is designed to be transported over TCP or SCTP 294 can avoid sending SCTP packets if an upstream device in the path 295 announces that it is not compliant with SCTP. SCTP can be used if 296 that upstream device announces it supports SCTP. Furthermore, if 297 that upstream device is also a NAT, appropriate (SCTP) explicit 298 dynamic mappings can be instantiated by the application so that 299 incoming connections can be forwarded appropriately. Figure 3 300 shows an example of two NAT devices; one of them supports SCTP. 301 Owing to the CAPABILITY option, SCTP sessions can be forced by the 302 host to cross the SCTP-enabled NAT by including for instance the 303 external IP address (@IP_Ext2) in a referral). 305 ______________________ 306 / \ 307 | | 308 | +--------+ 309 | | SCTP- |@IP_Ext1 310 | |disabled|-----+ 311 | | NAT | 312 +------+ | Network +--------+ 313 | Host |______| | 314 +------+ | +-------+ 315 | | SCTP- |@IP_Ext2 316 | |Enabled|------- 317 | | NAT | 318 | +-------+ 319 \_________________________/ 321 Figure 3: SCTP Example 323 o In an IPv6 network that runs NPTv6 [RFC6296] functions, firewalls 324 controlled by a PCP server are embedded in different devices: the 325 PCP client learns about the available PCP servers by means of DHCP 326 [RFC7291] or any other PCP server discovery technique. The PCP 327 client learns about the PCP server capabilities by using the 328 CAPABILITY option. The PCP client sends MAP PCP request to a PCP- 329 controlled NPTv6 device with Internal Port=0 and Protocol=0 (which 330 means 'all ports for all protocols') to find the external IP 331 address. This PCP request has to be sent only once since NPTv6 is 332 stateless and provides a 1:1 relationship between addresses that 333 belong to the "inside" and "outside" prefixes, respectively. The 334 PCP client will send PCP requests only to the PCP server that 335 controls the NPTv6 device before the Assigned Lifetime of the MAP 336 response expires or when the host that embeds the PCP client 337 acquires a new IPv6 address that belongs to the "inside" prefix. 338 However, the PCP client will send MAP/PEER requests to the PCP 339 server that controls the firewall device to create/delete dynamic 340 outbound mappings, or use PCP instead of its default application 341 keep-alives to maintain the firewall-maintained states alive. 343 PCP 344 Client __________ 345 +-----------+ +------+ +------+ / \ +-----------+ 346 |Application|___| NPTv6|___| FW |____| Internet |___|Application| 347 | Client | | | | | | | | Server | 348 +-----------+ +------+ +------+ \__________/ +-----------+ 350 Figure 4: NPTv6 and Firewall not collocated with PCP server 351 Capability 353 o In a network that embeds NAT64 [RFC6146] devices, the PCP- 354 controlled firewall service functions are embedded in different 355 devices: The IPv6-only PCP client can send the PREFIX64 PCP option 356 [RFC7225] only to the PCP-controlled NAT64 device to learn the 357 Prefix64(s) used to build IPv4-embedded IPv6 addresses. 359 o Multiple PCP-controlled devices: See Figure 5 the example of a 360 network deploying several techniques to connect with the IPv4 361 Internet, to provide IPv6-only connectivity, etc. The discovered 362 capabilities can be used to trigger the selection of the 363 appropriate PCP server [RFC7488]. 365 +-----+ 366 ______|NPTv6|___________ 367 / +-----+ \ 368 | | 369 | +-----+ 370 +-----------+ +------+ | | PRR | 371 |Application|___| IPv6 |______| Network +-----+ 372 |PCP Client| | FW | | | 373 +-----------+ +------+ | +------+ 374 | | NAT64| 375 +-----------+ +-------+ | | + | 376 |PCP client |___|A+P NAT|_____| | FW | 377 +-----------+ +-------+ | +-----+ +------+ 378 \______|NPTv6|___________/ 379 +-----+ 381 Figure 5: Multiple PCP-controlled devices 383 o In a IPv6 network that supports a PCP-controlled ILNP translator 384 [RFC6740], the PCP-controlled firewall service functions are 385 embedded in different devices. The PCP client needs to send PCP 386 requests only to the PCP-controlled ILNP translator to find Global 387 Locators associated with Internal Locators. 389 o When the PCP-controlled device is a Port Range Router (PRR, see 390 Section 3.2 of [RFC6346]), the PCP client should use the PORT_SET 391 [I-D.ietf-pcp-port-set] option. 393 6. Security Considerations 395 PCP-related security considerations are discussed in [RFC6887]. 397 An attacker may generate a PCP message with a fake CAPABILITY option 398 to switch off some features that would have been used by a host. 399 Means to authenticate the PCP server SHOULD be supported. 401 7. IANA Considerations 403 The following PCP option Code is to be allocated in the optional-to- 404 process range (the registry is maintained in 405 http://www.iana.org/assignments/pcp-parameters/pcp- 406 parameters.xml#options): 408 CAPABILITY 410 A sub-registry is required to track the set of capabilities of PCP- 411 controlled devices. 413 8. References 415 8.1. Normative References 417 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 418 Requirement Levels", BCP 14, RFC 2119, March 1997. 420 [RFC6887] Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. 421 Selkirk, "Port Control Protocol (PCP)", RFC 6887, April 422 2013. 424 8.2. Informative References 426 [I-D.ietf-opsawg-firewalls] 427 Baker, F. and P. Hoffman, "On Firewalls in Internet 428 Security", draft-ietf-opsawg-firewalls-01 (work in 429 progress), October 2012. 431 [I-D.ietf-pcp-authentication] 432 Wasserman, M., Hartman, S., Zhang, D., and T. Reddy, "Port 433 Control Protocol (PCP) Authentication Mechanism", draft- 434 ietf-pcp-authentication-12 (work in progress), June 2015. 436 [I-D.ietf-pcp-port-set] 437 Qiong, Q., Boucadair, M., Sivakumar, S., Zhou, C., Tsou, 438 T., and S. Perreault, "Port Control Protocol (PCP) 439 Extension for Port Set Allocation", draft-ietf-pcp-port- 440 set-09 (work in progress), May 2015. 442 [I-D.wing-pcp-flowdata] 443 Wing, D., Penno, R., and T. Reddy, "PCP Flowdata Option", 444 draft-wing-pcp-flowdata-00 (work in progress), July 2013. 446 [I-D.ww-sfc-control-plane] 447 Li, H., Wu, Q., Boucadair, M., Jacquenet, C., Haeffner, 448 W., Lee, S., Parker, R., Dunbar, L., Malis, A., Halpern, 449 J., Reddy, T., and P. Patil, "Service Function Chaining 450 (SFC) Control Plane Components & Requirements", draft-ww- 451 sfc-control-plane-06 (work in progress), June 2015. 453 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 454 August 1980. 456 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 457 793, September 1981. 459 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 460 Address Translator (Traditional NAT)", RFC 3022, January 461 2001. 463 [RFC3135] Border, J., Kojo, M., Griner, J., Montenegro, G., and Z. 464 Shelby, "Performance Enhancing Proxies Intended to 465 Mitigate Link-Related Degradations", RFC 3135, June 2001. 467 [RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and 468 G. Fairhurst, "The Lightweight User Datagram Protocol 469 (UDP-Lite)", RFC 3828, July 2004. 471 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 472 Congestion Control Protocol (DCCP)", RFC 4340, March 2006. 474 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 475 4960, September 2007. 477 [RFC6092] Woodyatt, J., "Recommended Simple Security Capabilities in 478 Customer Premises Equipment (CPE) for Providing 479 Residential IPv6 Internet Service", RFC 6092, January 480 2011. 482 [RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation 483 Algorithm", RFC 6145, April 2011. 485 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 486 NAT64: Network Address and Protocol Translation from IPv6 487 Clients to IPv4 Servers", RFC 6146, April 2011. 489 [RFC6269] Ford, M., Boucadair, M., Durand, A., Levis, P., and P. 490 Roberts, "Issues with IP Address Sharing", RFC 6269, June 491 2011. 493 [RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix 494 Translation", RFC 6296, June 2011. 496 [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 497 Stack Lite Broadband Deployments Following IPv4 498 Exhaustion", RFC 6333, August 2011. 500 [RFC6346] Bush, R., "The Address plus Port (A+P) Approach to the 501 IPv4 Address Shortage", RFC 6346, August 2011. 503 [RFC6619] Arkko, J., Eggert, L., and M. Townsley, "Scalable 504 Operation of Address Translators with Per-Interface 505 Bindings", RFC 6619, June 2012. 507 [RFC6740] Atkinson,, RJ., "Identifier-Locator Network Protocol 508 (ILNP) Architectural Description", RFC 6740, November 509 2012. 511 [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, 512 "TCP Extensions for Multipath Operation with Multiple 513 Addresses", RFC 6824, January 2013. 515 [RFC7225] Boucadair, M., "Discovering NAT64 IPv6 Prefixes Using the 516 Port Control Protocol (PCP)", RFC 7225, May 2014. 518 [RFC7291] Boucadair, M., Penno, R., and D. Wing, "DHCP Options for 519 the Port Control Protocol (PCP)", RFC 7291, July 2014. 521 [RFC7488] Boucadair, M., Penno, R., Wing, D., Patil, P., and T. 522 Reddy, "Port Control Protocol (PCP) Server Selection", RFC 523 7488, March 2015. 525 Authors' Addresses 527 Mohamed Boucadair 528 France Telecom 529 Rennes 35000 530 France 532 Email: mohamed.boucadair@orange.com 534 Christian Jacquenet 535 France Telecom 536 Rennes 537 France 539 Email: christian.jacquenet@orange.com