idnits 2.17.1 draft-ietf-pcp-third-party-id-option-08.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 : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC6887, but the abstract doesn't seem to directly say this. It does mention RFC6887 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 9, 2016) is 2970 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force A. Ripke 3 Internet-Draft R. Winter 4 Updates: 6887 (if approved) T. Dietz 5 Intended status: Standards Track J. Quittek 6 Expires: September 10, 2016 NEC 7 R. da Silva 8 Telefonica I+D 9 March 9, 2016 11 PCP Third Party ID Option 12 draft-ietf-pcp-third-party-id-option-08 14 Abstract 16 This document describes a new Port Control Protocol (PCP) option 17 called THIRD_PARTY_ID option. It is designed to be used together 18 with the THIRD_PARTY option specified in RFC 6887. 20 The THIRD_PARTY_ID option serves to identify a third party in 21 situations where a third party's IP address contained in the 22 THIRD_PARTY option does not provide sufficient information to create 23 requested mappings in a PCP-controlled device. 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 September 10, 2016. 42 Copyright Notice 44 Copyright (c) 2016 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 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 3. Target Scenarios . . . . . . . . . . . . . . . . . . . . . . 3 62 3.1. Carrier-hosted UPnP IGD-PCP IWF . . . . . . . . . . . . . 5 63 3.2. Carrier Web Portal . . . . . . . . . . . . . . . . . . . 7 64 4. Format . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 65 4.1. Result Codes . . . . . . . . . . . . . . . . . . . . . . 10 66 5. Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . 10 67 5.1. Generating a Request . . . . . . . . . . . . . . . . . . 10 68 5.2. Processing a Request . . . . . . . . . . . . . . . . . . 11 69 5.3. Processing a Response . . . . . . . . . . . . . . . . . . 11 70 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 71 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 72 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 73 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 74 9.1. Normative References . . . . . . . . . . . . . . . . . . 12 75 9.2. Informative References . . . . . . . . . . . . . . . . . 13 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 78 1. Introduction 80 The IETF has specified the Port Control Protocol (PCP) [RFC6887] to 81 control how packets are translated and/or forwarded by a PCP- 82 controlled device such as a network address translator (NAT) or 83 firewall. 85 This document focuses on scenarios where the PCP client sends 86 requests that concern internal addresses other than the address of 87 the PCP client itself. 89 There is already an option defined for this purpose in [RFC6887] 90 called the THIRD_PARTY option. The THIRD_PARTY option carries the IP 91 address of a host for which a PCP client requests an action at the 92 PCP server. The THIRD_PARTY option can, for example, be used if port 93 mapping requests for a carrier-grade NAT (CGN) are not sent from PCP 94 clients at subscriber terminals, but, for example, from a PCP 95 Interworking Function which requests port mappings. 97 In some cases, the THIRD_PARTY option alone is not sufficient and 98 further means are needed for identifying the third party. Such cases 99 are addressed by the THIRD_PARTY_ID option, that is specified in this 100 document. 102 The primary issue addressed by the THIRD_PARTY_ID option is that 103 there are CGN deployments that do not distinguish internal hosts by 104 their IP address alone, but use further identifiers (IDs) for unique 105 subscriber identification. This is, for example, the case if a CGN 106 supports overlapping private or shared IP address spaces 107 [RFC1918][RFC6598] for internal hosts of different subscribers. In 108 such cases, different internal hosts are identified and mapped at the 109 CGN by their IP address and/or another ID, for example, the ID of a 110 tunnel between the CGN and the subscriber. In these scenarios (and 111 similar ones), the internal IP address contained in the THIRD_PARTY 112 option is not sufficient to de-multiplex connections from internal 113 hosts. An additional identifier needs to be present in the PCP 114 message in order to uniquely identify an internal host. The 115 THIRD_PARTY_ID option is used to carry this ID. 117 This applies to some of the PCP deployment scenarios that are listed 118 in Section 2.1 of [RFC6887], in particular to a Layer-2 aware NAT 119 which is described in more detail in Section 3, as well as in other 120 scenarios where overlapping address spaces occur like in [RFC6674] or 121 [RFC6619]. 123 The THIRD_PARTY_ID option is defined for the PCP opcodes MAP and PEER 124 to be used together with the THIRD_PARTY option which is specified in 125 [RFC6887]. 127 2. Terminology 129 The terminology defined in the specification of PCP [RFC6887] 130 applies. 132 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 133 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 134 "OPTIONAL" in this document are to be interpreted as described in RFC 135 2119 [RFC2119]. 137 3. Target Scenarios 139 This section describes two scenarios that illustrate the use of the 140 THIRD_PARTY_ID option: 142 1. a UPnP IGD-PCP IWF (Universal Plug and Play Internet Gateway 143 Device - Port Control Protocol Interworking Function [RFC6970]), 145 2. a carrier web portal for port mapping. 147 These are merely two examples that illustrate the use and 148 applicability of the THIRD_PARTY_ID option. While these are just two 149 examples, there might be other conceivable use cases. However, the 150 use of the THIRD_PARTY_ID option as specified in this document is 151 restricted to scenarios where the option is needed for the purpose of 152 uniquely identifying an internal host in addition to the information 153 found in the THIRD_PARTY option. 155 Both scenarios elaborated in this document are refinements of the 156 same basic scenario shown in Figure 1 which is considered as a PCP 157 deployment scenario employing Layer-2 aware NATs as listed in 158 Section 2.1 of [RFC6887]. It has a carrier operating a CGN and a 159 Port Control Protocol Interworking Function (PCP IWF) [RFC6970] for 160 subscribers to request port mappings at the CGN. The PCP IWF 161 communicates with the CGN using PCP. For this purpose the PCP IWF 162 contains a PCP client serving multiple subscribers and the CGN is co- 163 located with a PCP server. The way subscribers interact with the PCP 164 IWF for requesting port mappings for their internal hosts is not 165 specified in this basic scenario, but it is elaborated on more in the 166 specific scenarios in Section 3.1 and Section 3.2. 168 The CGN operates as a Layer-2 aware NAT. Unlike a standard NAT, it 169 includes a subscriber identifier in addition to the source IP address 170 in entries of the NAT mapping table. 172 +--------------+ +------------------+ 173 | Subscriber | | Carrier | ==== L2 connection(s) 174 | | | +--------------+ | between subscriber 175 | +......+ PCP | | and CGN 176 | +----------+ | | | Interworking | | #### PCP communication 177 | | Internal | | | | Function | | .... Subscriber - IWF 178 | | Host | | | +-----#--------+ | interaction 179 | +----+-----+ | | # | (elaborated 180 | | | | +-----#--------+ | in specific 181 | +----+-----+ | | | PCP Server | | scenarios below) 182 | | CPE | | | | | | 183 | | +-+======+ CGN L2NAT +--------- Public Internet 184 | +----------+ | | +--------------+ | 185 +--------------+ +------------------+ 187 Figure 1: Carrier hosted PCP IWF for port mapping requests 189 Internal hosts in the subscriber's network use private IP addresses 190 ([RFC1918]). There is no NAT between the internal host and the CGN, 191 and there is an overlap of addresses used by internal hosts at 192 different subscribers. That is why the CGN needs more than just the 193 internal host's IP address to distinguish internal hosts at different 194 subscribers. A commonly deployed method for solving this issue is 195 using an additional identifier for this purpose. A natural candidate 196 for this additional identifier at the CGN is the ID of the tunnel 197 that connects the CGN to the subscriber's network. The subscriber's 198 CPE operates as a Layer-2 bridge. 200 Requests for port mappings from the PCP IWF to the CGN need to 201 uniquely identify the internal host for which a port mapping is to be 202 established or modified. Already existing for this purpose is the 203 THIRD_PARTY option that can be used to specify the internal host's IP 204 address. The THIRD_PARTY_ID option is introduced for carrying the 205 additional third party information needed to identify the internal 206 host in this scenario. 208 The additional identifier for internal hosts needs to be included in 209 MAP requests from the PCP IWF in order to uniquely identify the 210 internal host that should have its address mapped. This is the 211 purpose that the new THIRD_PARTY_ID option serves in this scenario. 212 It carries the additional identifier, that is the tunnel ID, that 213 serves for identifying an internal host in combination with the 214 internal host's (private) IP address. The IP address of the internal 215 host is included in the PCP IWF's mapping requests by using the 216 THIRD_PARTY option. 218 The information carried by the THIRD_PARTY_ID option is not just 219 needed to identify an internal host in a PCP request. The CGN needs 220 this information in its internal mapping tables for translating 221 packet addresses and for forwarding packets to subscriber-specific 222 tunnels. 224 How the carrier PCP IWF is managing port mappings, such as, for 225 example, automatically extending the lifetime of a mapping, is beyond 226 the scope of this document. 228 3.1. Carrier-hosted UPnP IGD-PCP IWF 230 This scenario further elaborates the basic one above by choosing 231 UPnP-IGD as the communication protocol between the subscriber and the 232 carrier's PCP IWF. Then obviously, the PCP IWF is realized as a UPnP 233 IGD-PCP IWF as specified in [RFC6970]. 235 As shown in Figure 2 it is assumed here that the UPnP IGD-PCP IWF is 236 not embedded in the subscriber premises router, but offered as a 237 service to the subscriber. Further, it is assumed that the UPnP IGD- 238 PCP IWF is not providing NAT functionality. 240 This requires that the subscriber is able to connect to the UPnP IGD- 241 PCP IWF to request port mappings at the CGN using UPnP-IGD as 242 specified in [RFC6970]. In this scenario the connection is provided 243 via (one of the) tunnel(s) connecting the subscriber's network to the 244 Broadband Remote Access Server (BRAS) and an extension of this tunnel 245 from the BRAS to the UPnP IGD-PCP IWF. Note that there are other 246 alternatives that can be used for providing the connection to the 247 UPnP IGD-PCP IWF. The tunnel extension used in this scenario can, 248 for example, be realized by a forwarding function for UPnP messages 249 at the BRAS that forwards such messages through per-subscriber 250 tunnels to the UPnP IGD-PCP IWF. Depending on an actual 251 implementation, the UPnP IGD-PCP IWF can then either use the ID of 252 the tunnel in which the UPnP message arrived directly as 253 THIRD_PARTY_ID option for PCP requests to the CGN or it uses the ID 254 of the tunnel to retrieve the THIRD_PARTY_ID option from the AAA 255 server. 257 To support the latter option, the BRAS needs to register the 258 subscriber's tunnel IDs at the AAA Server at the time it contacts the 259 AAA server for authentication and/or authorization of the subscriber. 260 The tunnel IDs to be registered per subscriber at the AAA server may 261 include the tunnel between CPE and BRAS, between BRAS and UPnP IGD- 262 PCP IWF, and between BRAS and CGN. The UPnP IGD-PCP IWF queries the 263 AAA Server for the ID of the tunnel between BRAS and CGN, because 264 this is the identifier to be used as the THIRD_PARTY_ID option in the 265 subsequent port mapping request. 267 +--------------+ +------------------------------------+ 268 | Subscriber | | Carrier | 269 | | | +----------------------------+ | 270 | | | | AAA Server | | 271 | | | +-----+---------------+------+ | 272 | | | | | | 273 | +----------+ | | +-----+---+ +-----+------+ | 274 | | Internal | | | | +=====+ | | 275 | | Host | | | | ...........| UPnP IGD | | 276 | +----+-----+ | | | . +=====+ PCP IWF | | 277 | | . | | | . | +-----#------+ | 278 | +----+--.--| | | | . | # | 279 | | | . +========+ . | +-----#------+ | 280 | | | .................. +=====+ PCP Server | | 281 | | +------------------------------| | | 282 | | CPE +========+ BRAS +=====+ CGN L2NAT +------- Public 283 | +----------+ | | +---------+ +------------+ | Internet 284 +--------------+ +------------------------------------+ 285 ==== L2 tunnel borders between subscriber, BRAS, IWF, and CGN 286 .... UPnP communication 287 #### PCP communication 289 Figure 2: UPnP IGD-PCP IWF 291 A potential extension to [RFC6970] regarding an additional state 292 variable for the THIRD_PARTY_ID option and regarding an additional 293 error code for a mismatched THIRD_PARTY_ID option and its processing 294 might be a logical next step. However, this is not in the scope of 295 this document. 297 3.2. Carrier Web Portal 299 This scenario shown in Figure 3 is different from the previous one 300 concerning the protocol used between the subscriber and the IWF. 301 Here, HTTP(S) is the protocol that the subscriber uses for port 302 mapping requests. The subscriber may make requests manually using a 303 web browser or automatically - as in the previous scenario - with 304 applications in the subscriber's network issuing port mapping 305 requests on demand. The Web Portal queries the AAA Server for the 306 subscriber's ID of the tunnel(BRAS, CGN) which was reported by the 307 BRAS. The returned ID of the tunnel(BRAS, CGN) is used as the 308 THIRD_PARTY_ID option in the subsequent port mapping request. 310 +--------------+ +------------------------------------+ 311 | Subscriber | | Carrier | 312 | | | +------------+ | 313 | | | +------------+ | Web Portal | | 314 | +----------+ | | | AAA Server +--+ +--+ | 315 | | Internal | | | +-----+------+ | PCP Client | | | 316 | | Host | | | | +-----#------+ | | 317 | +----+-----+ | | | # | | 318 | | | | +-----+---+ +-----#------+ | | 319 | +----+-----+ | | | | | PCP Server | | | 320 | | CPE | | | | BRAS | | | | | 321 | | +-+======+ +=====+ CGN L2NAT +--+---- Public 322 | +----------+ | | +---------+ +------------+ | Internet 323 +--------------+ +------------------------------------+ 324 ==== L2 tunnel(s) between subscriber, BRAS, and CGN 325 #### PCP communication 327 Figure 3: Carrier Web Portal 329 The PCP IWF is realized as a combination of a web server and a PCP 330 Client. 332 4. Format 334 The THIRD_PARTY_ID option as shown in Figure 4 uses the format of PCP 335 options as specified in [RFC6887]: 337 0 1 2 3 338 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 339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 340 |Option Code=TBD| Reserved | Option Length | 341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 342 | | 343 | THIRD_PARTY_ID | 344 | | 345 | | 346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 348 Option Name: THIRD_PARTY_ID 349 Option Code: TBD 350 Purpose: Together with the THIRD_PARTY option, the 351 THIRD_PARTY_ID option identifies a third party 352 for which a request for an external IP address 353 and port is made. 354 Valid for Opcodes: MAP, PEER 355 Length: Variable, maximum 1016 octets. 356 May appear in: Request. May appear in response only if it 357 appeared in the associated request. 358 Maximum occurrences: 1 360 RFC EDITOR NOTE: Replace TBD with the value assigned by IANA. 362 Figure 4: THIRD_PARTY_ID Option 364 The "Reserved" field and the "Option length" field are to be set as 365 specified in Section 7.3 of [RFC6887]. 367 The "THIRD_PARTY_ID" field contains a deployment specific identifier 368 that identifies a realm of a NAT map entry. Together with a 369 THIRD_PARTY option it can be used to identify a subscriber's session 370 on a PCP- controlled device. It has no other semantics. 372 The "THIRD_PARTY_ID" is not bound to any specific identifier. It can 373 contain any deployment specific value the PCP client and the PCP 374 server agree on. How this agreement is reached if both PCP server 375 and client are not administered by the same entity is beyond the 376 scope of this document. Also, the client does not need to have an 377 understanding of how the ID is being used at the PCP server. 379 If an identifier is used that is based on an existing standard, then 380 the encoding rules of that standard must be followed. As an example, 381 in case an L2TPv3 [RFC3931] session ID is being used, then that 382 identifier has to be encoded the same way it would be encoded in the 383 L2TPv3 session header. This allows for a simple octet-by-octet 384 comparison at the PCP-controlled device. 386 [RFC6887] expects option data to always come in multiples of an 387 octet. An ID however might not fulfill this criterion. As an 388 example, an MPLS label is 20 bits wide. In these cases padding is 389 done by appending 0 bits until the byte boundary is reached. After 390 that the padding rules of [RFC6887] apply. 392 The option number is in the mandatory-to-process range (0-127), 393 meaning that a request with a THIRD_PARTY_ID option is processed by 394 the PCP server if and only if the THIRD_PARTY_ID option is supported 395 by the PCP server. Therefore, it should not be included unless the 396 PCP client is certain that a mapping without the THIRD_PARTY_ID is 397 impossible. 399 4.1. Result Codes 401 The following PCP Result Codes are new: 403 TBD-2: THIRD_PARTY_ID_UNKNOWN: The provided identifier in a 404 THIRD_PARTY_ID option is unknown/unavailable to the PCP server. 405 This is a long lifetime error. 407 TBD-3: THIRD_PARTY_MISSING_OPTION: This error occurs if both 408 THIRD_PARTY and THIRD_PARTY_ID options are expected in a request 409 but one option is missing. This is a long lifetime error. 411 TBD-4: UNSUPP_THIRD_PARTY_ID_LENGTH: The received option length is 412 not supported. This is a long lifetime error. 414 5. Behavior 416 The following sections describe the operations of a PCP client and a 417 PCP server when generating the request and processing the request and 418 response. 420 5.1. Generating a Request 422 In addition to generating a PCP request that is described in 423 [RFC6887] the following has to be applied. The THIRD_PARTY_ID option 424 MAY be included either in a PCP MAP or PEER opcode. It MUST be used 425 in combination with the THIRD_PARTY option which provides an IP 426 address. The THIRD_PARTY_ID option holds an identifier to allow the 427 PCP-controlled device to uniquely identify the internal host 428 (specified in the THIRD_PARTY option) for which the port mapping is 429 to be established or modified. The padding rules described in 430 Section 4 apply. 432 5.2. Processing a Request 434 The THIRD_PARTY_ID option is in the mandatory-to-process range and if 435 the PCP server does not support this option it MUST return an 436 UNSUPP_OPTION response. If the provided identifier in a 437 THIRD_PARTY_ID option is unknown/unavailable, the PCP server MUST 438 return a THIRD_PARTY_ID_UNKNOWN response. If the PCP server receives 439 a request with an unsupported THIRD_PARTY_ID option length, it MUST 440 return an UNSUPP_THIRD_PARTY_ID_LENGTH response. If the PCP server 441 receives a THIRD_PARTY_ID option without a THIRD_PARTY option it MUST 442 return a THIRD_PARTY_MISSING_OPTION response. 444 Upon receiving a valid request with a legal THIRD_PARTY_ID option 445 identifier, the message is processed as specified in [RFC6887], 446 except that the identifier contained in the THIRD_PARTY_ID is used in 447 addition when accessing a mapping table. Instead of just using the 448 value contained in the THIRD_PARTY option when accessing the internal 449 Internet address of a mapping table, now the combination of the two 450 values contained in the THIRD_PARTY option and in the THIRD_PARTY_ID 451 option is used to access the combination of internal Internet address 452 and internal realm of a NAT map entry. 454 In case two or more different tunnel technologies are being used, 455 precautions need to be taken to handle potential overlap of the ID 456 spaces of these technologies. For example, different PCP client/PCP 457 server pairs can be used per tunnel technology. 459 5.3. Processing a Response 461 In addition to the response processing described in [RFC6887] if the 462 PCP client receives a THIRD_PARTY_ID_UNKNOWN or a 463 UNSUPP_THIRD_PARTY_ID_LENGTH or a THIRD_PARTY_MISSING_OPTION response 464 back for its previous request it SHOULD report an error. To where to 465 report an error is based on policy. 467 6. IANA Considerations 469 The following PCP Option Code is to be allocated in the mandatory-to- 470 process range: 472 TBD: THIRD_PARTY_ID 474 [NOTE for IANA: Please allocate a PCP Option Code at 475 http://www.iana.org/assignments/pcp-parameters/pcp- 476 parameters.xml#options] 478 The following PCP Result Codes are to be allocated: 480 TBD-2: THIRD_PARTY_ID_UNKNOWN 482 TBD-3: THIRD_PARTY_MISSING_OPTION 484 TBD-4: UNSUPP_THIRD_PARTY_ID_LENGTH 486 [NOTE for IANA: Please allocate PCP Result Codes at 487 http://www.iana.org/assignments/pcp-parameters/pcp- 488 parameters.xml#result-codes] 490 7. Security Considerations 492 This option is to be used in combination with the THIRD_PARTY option. 493 Consequently, all corresponding security considerations in 494 Section 18.1.1 of [RFC6887] apply. Especially, the network on which 495 the PCP messages are sent must be sufficiently protected. Further, 496 it is RECOMMENDED to use PCP authentication [RFC7652] unless the 497 network has already appropriate authentication means in place. 499 The THIRD_PARTY_ID option carries a context identifier which type and 500 length is deployment and implementation dependent. This identifier 501 might carry privacy sensitive information. It is therefore 502 RECOMMENDED to utilize identifiers that do not have such privacy 503 concerns. Means to protect unauthorized access to this information 504 MUST be put in place. In the scenarios described in this document 505 e.g., access to the web portal or UPnP IGD-PCP IWF MUST be 506 authenticated. Generally speaking, the identifier itself MUST only 507 be accessible by the network operator and MUST only be handled on 508 operator equipment. E.g. creation of a PCP message on the web portal 509 or the UPnP IGD PCP IWF is triggered by the subscriber but the actual 510 option filling is done by an operator-controlled entity. 512 8. Acknowledgments 514 Thanks to Mohamed Boucadair for many valuable suggestions, in 515 particular for suggesting a variable length for the THIRD_PARTY_ID 516 option. Thanks to Dave Thaler, Tom Taylor, and Dan Wing for their 517 comments and review. 519 9. References 521 9.1. Normative References 523 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., 524 and E. Lear, "Address Allocation for Private Internets", 525 BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, 526 . 528 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 529 Requirement Levels", BCP 14, RFC 2119, 530 DOI 10.17487/RFC2119, March 1997, 531 . 533 [RFC6598] Weil, J., Kuarsingh, V., Donley, C., Liljenstolpe, C., and 534 M. Azinger, "IANA-Reserved IPv4 Prefix for Shared Address 535 Space", BCP 153, RFC 6598, DOI 10.17487/RFC6598, April 536 2012, . 538 [RFC6887] Wing, D., Ed., Cheshire, S., Boucadair, M., Penno, R., and 539 P. Selkirk, "Port Control Protocol (PCP)", RFC 6887, 540 DOI 10.17487/RFC6887, April 2013, 541 . 543 9.2. Informative References 545 [RFC3931] Lau, J., Ed., Townsley, M., Ed., and I. Goyret, Ed., 546 "Layer Two Tunneling Protocol - Version 3 (L2TPv3)", 547 RFC 3931, DOI 10.17487/RFC3931, March 2005, 548 . 550 [RFC6619] Arkko, J., Eggert, L., and M. Townsley, "Scalable 551 Operation of Address Translators with Per-Interface 552 Bindings", RFC 6619, DOI 10.17487/RFC6619, June 2012, 553 . 555 [RFC6674] Brockners, F., Gundavelli, S., Speicher, S., and D. Ward, 556 "Gateway-Initiated Dual-Stack Lite Deployment", RFC 6674, 557 DOI 10.17487/RFC6674, July 2012, 558 . 560 [RFC6970] Boucadair, M., Penno, R., and D. Wing, "Universal Plug and 561 Play (UPnP) Internet Gateway Device - Port Control 562 Protocol Interworking Function (IGD-PCP IWF)", RFC 6970, 563 DOI 10.17487/RFC6970, July 2013, 564 . 566 [RFC7652] Cullen, M., Hartman, S., Zhang, D., and T. Reddy, "Port 567 Control Protocol (PCP) Authentication Mechanism", 568 RFC 7652, DOI 10.17487/RFC7652, September 2015, 569 . 571 Authors' Addresses 572 Andreas Ripke 573 NEC 574 Heidelberg 575 Germany 577 Email: ripke@neclab.eu 579 Rolf Winter 580 NEC 581 Heidelberg 582 Germany 584 Email: winter@neclab.eu 586 Thomas Dietz 587 NEC 588 Heidelberg 589 Germany 591 Email: dietz@neclab.eu 593 Juergen Quittek 594 NEC 595 Heidelberg 596 Germany 598 Email: quittek@neclab.eu 600 Rafael Lopez da Silva 601 Telefonica I+D 602 Madrid 603 Spain 605 Email: rafaelalejandro.lopezdasilva@telefonica.com