idnits 2.17.1 draft-boucadair-pcp-failure-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 21 instances of too long lines in the document, the longest one being 1 character in excess of 72. -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (May 16, 2013) is 3997 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 368, but no explicit reference was found in the text == Outdated reference: A later version (-09) exists of draft-ietf-pcp-proxy-02 == Outdated reference: A later version (-04) exists of draft-boucadair-pcp-flow-examples-00 Summary: 1 error (**), 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: Informational R. Penno 5 Expires: November 17, 2013 Cisco 6 May 16, 2013 8 Analysis of Port Control Protocol (PCP) Failure Scenarios 9 draft-boucadair-pcp-failure-06 11 Abstract 13 This document identifies and analyzes several PCP failure scenarios. 14 Identifying these failure scenarios is useful to assess the 15 efficiency of the protocol and also to decide whether new PCP 16 extensions are needed. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on November 17, 2013. 35 Copyright Notice 37 Copyright (c) 2013 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. PCP Client Failure Scenarios . . . . . . . . . . . . . . . . 2 54 2.1. Change of the IP Address of The PCP Server . . . . . . . 2 55 2.2. Application Crash . . . . . . . . . . . . . . . . . . . . 3 56 2.3. PCP Client Crash . . . . . . . . . . . . . . . . . . . . 4 57 2.4. Change of the Internal IP Address . . . . . . . . . . . . 4 58 2.5. Change of the CPE WAN IP Address . . . . . . . . . . . . 5 59 2.6. UPnP IGD/PCP IWF . . . . . . . . . . . . . . . . . . . . 6 60 3. Restart or Failure of the PCP Server . . . . . . . . . . . . 6 61 3.1. Basic Rule . . . . . . . . . . . . . . . . . . . . . . . 6 62 3.2. Clear PCP Mappings . . . . . . . . . . . . . . . . . . . 7 63 3.3. State Redundancy is Enabled . . . . . . . . . . . . . . . 7 64 3.4. Cold-Standby without State Redundancy . . . . . . . . . . 7 65 3.5. Anycast Redundancy Mode . . . . . . . . . . . . . . . . . 7 66 4. Security Considerations . . . . . . . . . . . . . . . . . . . 8 67 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 68 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 69 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 70 7.1. Normative References . . . . . . . . . . . . . . . . . . 8 71 7.2. Informative References . . . . . . . . . . . . . . . . . 8 72 Appendix A. PCP State Synchronization: Overview . . . . . . . . 9 73 Appendix B. GET/NEXT Operation . . . . . . . . . . . . . . . . . 9 74 B.1. OpCode Format . . . . . . . . . . . . . . . . . . . . . . 9 75 B.2. OpCode-Specific Result Code . . . . . . . . . . . . . . . 11 76 B.3. Ordering and Equality . . . . . . . . . . . . . . . . . . 11 77 B.4. NEXT Option . . . . . . . . . . . . . . . . . . . . . . . 11 78 B.5. GET/NEXT PCP Client Theory of Operation . . . . . . . . . 14 79 B.6. GET/NEXT PCP Server Theory of Operation . . . . . . . . . 14 80 B.7. Flow Examples . . . . . . . . . . . . . . . . . . . . . . 15 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 83 1. Introduction 85 This document discusses several failure scenarios that may occur when 86 deploying PCP [RFC6887]. 88 2. PCP Client Failure Scenarios 90 2.1. Change of the IP Address of The PCP Server 92 When a new IP address is used to reach its PCP Server, the PCP Client 93 must re-create all of its explicit dynamic mappings using the newly 94 discovered IP address. 96 The PCP Client must undertake the same process as per refreshing an 97 existing explicit dynamic mapping (see [RFC6887]); the only 98 difference is the PCP requests are sent to a distinct IP address. No 99 specific behavior is required from the PCP Server for handling these 100 requests. 102 Proposed Action: No particular extension is required to be added 103 to the base specification to mitigate this failure scenario. 105 2.2. Application Crash 107 When a fatal error is encountered by an application relying on PCP to 108 open explicit dynamic mappings on an upstream device, and upon the 109 restart of that application, the PCP Client should issue appropriate 110 requests to refresh the explicit dynamic mappings of that application 111 (e.g., clear old mappings and install new ones using the new port 112 number used by the application). 114 If the same port number is used but a distinct Mapping Nonce is 115 generated, the request will be rejected with a NOT_AUTHORIZED error 116 with the Lifetime of the error indicating duration of that existing 117 mapping (see Section 2.7 of [I-D.boucadair-pcp-flow-examples]). 119 Proposed Action: A solution to recover the Mapping Nonce used when 120 instantiating the mapping may be envisaged; this solution may not 121 be viable if PCP authentication is not in use. Mapping Nonce 122 recovery in the simple PCP threat model (especially when Mapping 123 Check validation is enabled) induces the same security threated as 124 those discussed in [RFC6887]. 126 If a distinct port number is used by the application to bound its 127 service (i.e., a new internal port number is to be signaled in PCP), 128 the PCP Server may honor the refresh requests if the per-subscriber 129 quota is not exceeded. A distinct external port number would be 130 assigned by the PCP Server due to the presence of "stale" explicit 131 dynamic mapping(s) associated with the "old" port number. 133 Proposed Action: To avoid this inconvenience induced by stale 134 explicit dynamic mappings, the PCP Client may clear the "old" 135 mappings before issuing the refresh requests; but this would 136 require the PCP Client to store the information about the "old" 137 port number. This can be easy to solve if the PCP Client is 138 embedded in the application. In some scenarios, this is not so 139 easy because the PCP Client may handle PCP requests on behalf of 140 several applications and no means to identify the requesting 141 application may be supported. Means to identify the application 142 may be envisaged. 144 [RFC6887] does not allow a PCP Client to issue a request to delete 145 all the explicit dynamic mappings associated with an internal IP 146 address. If a PCP Client is allowed to clear all mappings bound 147 to the same IP address, this would have negative impact on other 148 applications and PCP Client(s) which may use the same internal IP 149 address to instruct their explicit dynamic mappings in the PCP 150 Server. 152 2.3. PCP Client Crash 154 The PCP Client may encounter a fatal error leading to its restart. 155 In such case, the internal IP address and port numbers used by 156 requesting applications are not impacted. Therefore, the explicit 157 dynamic mappings as maintained by the PCP Server are accurate and 158 there is no need to refresh them. 160 On the PCP Client side, a new UDP port should be assigned to issue 161 PCP requests. As a consequence, if outstanding requests have been 162 sent to the PCP Server, the responses are likely to be lost. 164 If the PCP Client stores its explicit dynamic mappings in a 165 persistent memory, there is no need to retrieve the list of active 166 mappings from the PCP Server. 168 Proposed Action: If several PCP Clients are co-located on the same 169 host, related PCP mapping tables should be uniquely distinguished 170 (e.g., a PCP Client does not delete explicit dynamic mappings 171 instructed by another PCP Client). 173 If the PCP Client does not store the explicit dynamic mappings and 174 new Mapping Nonces are assigned, the PCP Server will reject to 175 refresh these mappings. 177 Proposed Action: This issue can be solved if the PCP Client uses 178 GET OpCode (Appendix B) to recover the mapping nonces used when 179 instantiating the mappings if PCP authentication is used or 180 Mapping Nonce validation check is disabled. 182 2.4. Change of the Internal IP Address 184 When a new IP address is assigned to a host embedding a PCP Client, 185 the PCP Client must install on the PCP Server all the explicit 186 dynamic mappings it manages, using the new assigned IP address as the 187 internal IP address. The hinted external port number won't be 188 assigned by the PCP Server since a "stale" mapping is already 189 instantiated by the PCP Server (but it is associated with a distinct 190 internal IP address). 192 For a host configured with several addresses, the PCP Client must 193 maintain a record about the target IP address it used when issuing 194 its PCP requests. If no record is maintained and upon a change of 195 the IP address or de-activation of an interface, the PCP-instructed 196 explicit dynamic mappings are broken and inbound communications will 197 fail to be delivered. 199 Depending on the configured policies, the PCP Server may honor all or 200 part of the requests received from the PCP Client. Upon receipt of 201 the response from the PCP Server, the PCP Client must update its 202 local PCP state with the new assigned port numbers and external IP 203 address. 205 Proposed Action: Because of the possible negative impact if the 206 quota is exceed due to the presence of stale mappings (see the 207 example in Section 2.14 of [I-D.boucadair-pcp-flow-examples]), a 208 procedure to clear stale mappings may have some benefits. 210 A PCP Client may be used to manage explicit dynamic mappings on 211 behalf of a third party (i.e., the PCP Client and the third party are 212 not co-located on the same host). If a new internal IP address is 213 assigned to that third party (e.g., webcam), the PCP Client should be 214 instructed to delete the old mapping(s) and create new one(s) using 215 the new assigned internal IP address. When the PCP Client is co- 216 located with the DHCP server (e.g., PCP Proxy [I-D.ietf-pcp-proxy], 217 IWF in the CP router [I-D.ietf-pcp-upnp-igd-interworking]), the state 218 can be updated using the state of the local DHCP server. Otherwise, 219 it is safe to recommend the use of static internal IP addresses if 220 PCP is used to configure third-party explicit dynamic mappings. 222 Proposed Action: No particular extension is required to be added 223 to the base specification to mitigate this failure scenario. 225 2.5. Change of the CPE WAN IP Address 227 The change of the IP address of the WAN interface of the CPE would 228 have an impact on the accuracy of the explicit dynamic mappings 229 instantiated in the PCP Server: 231 o For the DS-Lite case [RFC6333]: if a new IPv6 address is used by 232 the B4 element when encapsulating IPv4 packets in IPv6 ones, the 233 explicit dynamic mappings should be refreshed: If the PCP Client 234 is embedded in the B4, the refresh operation is triggered by the 235 change of the B4 IPv6 address. This would be more complicated 236 when the PCP Client is located in a device behind the B4. If a 237 PCP Proxy is embedded in the CPE, the proxy can use ANNOUNCE 238 OpCode towards internal IPv4 hosts behind the DS-Lite CPE. 240 o For the NAT64 case [RFC6146], any change of the assigned IPv6 241 prefix delegated to the CPE will be detected by the PCP Client 242 (because this leads to the allocation of a new IPv6 address). The 243 PCP Client has to undertake the operation described in 244 Section 2.4. 246 o For the NAT444 case, similar problems are encountered because the 247 PCP Client has no reasonable way to detect the CPE's WAN address 248 changed. 250 Proposed Action: Means to help detecting the CPE's WAN address 251 change would help in mitigating this failure scenario. 253 2.6. UPnP IGD/PCP IWF 255 In the event an UPnP IGD/PCP IWF [I-D.ietf-pcp-upnp-igd-interworking] 256 fails to renew a mapping, there is no mechanism to inform the UPnP 257 Control Point about this failure. 259 Proposed Action: This issue can not be solved. 261 On the reboot of the IWF, if no mapping table is maintained in a 262 permanent storage, "stale" mappings will be maintained by the PCP 263 Server and per-user quota will be consumed. This is even exacerbated 264 if new mapping nonces are assigned by the IWF. 266 Proposed Action: This issue can be soften by synchronizing the 267 mapping table owing to the invocation of the GET OpCode defined in 268 Appendix B. This procedure is supported only if Mapping Nonce 269 validation checks are disabled. 271 3. Restart or Failure of the PCP Server 273 This section covers failure scenarios encountered by the PCP Server. 275 3.1. Basic Rule 277 In any situation the PCP Server loses all or part of its PCP state, 278 the Epoch value must be reset when replying to received requests. 279 Doing so would allow PCP Client to audit its explicit dynamic mapping 280 table. 282 If the state is not lost, the PCP Server must not reset the Epoch 283 value returned to requesting PCP Clients. 285 Proposed Action: No action is required to update the base PCP 286 specification for this failure scenario. 288 3.2. Clear PCP Mappings 290 When a command line or a configuration change is enforced to clear 291 all or a subset of PCP explicit dynamic mappings maintained by the 292 PCP Server, the PCP Server must reset its Epoch to zero value. 294 In order to avoid all PCP Clients to update their explicit dynamic 295 mappings, the PCP Server should reset the Epoch to zero value only 296 for impacted users. 298 Proposed Action: No action is required to update the base PCP 299 specification for this failure scenario. 301 3.3. State Redundancy is Enabled 303 When state redundancy is enabled, the state is not lost during 304 failure events. Failures are therefore transparent to requesting PCP 305 Clients. When a backup device takes over, Epoch must not be reset to 306 zero. 308 Proposed Action: No action is required to update the base PCP 309 specification for this failure scenario. 311 3.4. Cold-Standby without State Redundancy 313 In this section we assume that a redundancy mechanisms is configured 314 between a primary PCP-controlled device and a backup one but without 315 activating any state synchronization for the PCP-instructed explicit 316 dynamic mappings between the backup and the primary devices. 318 If the primary PCP-controlled device fails and the backup one takes 319 over, the PCP Server must reset the Epoch to zero value. Doing so 320 would allow PCP Clients to detect the loss of states in the PCP 321 Server and proceed to state synchronization. 323 Proposed Action: No action is required to update the base PCP 324 specification for this failure scenario. 326 3.5. Anycast Redundancy Mode 328 When an anycast-based mode is deployed (i.e., the same IP address is 329 used to reach several PCP Servers) for redundancy reasons, the change 330 of the PCP Server which handles the requests of a given PCP Client 331 won't be detected by that PCP Client. 333 Tweaking the Epoch (Section 8.5 of [RFC6887]) may help to detect the 334 loss of state and therefore to re-create missing explicit dynamic 335 mappings. 337 Proposed Action: No action is required to update the base PCP 338 specification for this failure scenario. 340 4. Security Considerations 342 PCP-related security consideratiosn are discussed in [RFC6887]. 344 5. IANA Considerations 346 No action is required from IANA. 348 6. Acknowledgements 350 Francis Dupont contributed text to this document. Many thanks to 351 him. 353 7. References 355 7.1. Normative References 357 [I-D.ietf-pcp-proxy] 358 Boucadair, M., Penno, R., and D. Wing, "Port Control 359 Protocol (PCP) Proxy Function", draft-ietf-pcp-proxy-02 360 (work in progress), February 2013. 362 [I-D.ietf-pcp-upnp-igd-interworking] 363 Boucadair, M., Penno, R., and D. Wing, "Universal Plug and 364 Play (UPnP) Internet Gateway Device (IGD)-Port Control 365 Protocol (PCP) Interworking Function", draft-ietf-pcp- 366 upnp-igd-interworking-10 (work in progress), April 2013. 368 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 369 Requirement Levels", BCP 14, RFC 2119, March 1997. 371 [RFC6887] Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. 372 Selkirk, "Port Control Protocol (PCP)", RFC 6887, April 373 2013. 375 7.2. Informative References 377 [I-D.boucadair-pcp-flow-examples] 378 Boucadair, M., "PCP Flow Examples", draft-boucadair-pcp- 379 flow-examples-00 (work in progress), February 2013. 381 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 382 NAT64: Network Address and Protocol Translation from IPv6 383 Clients to IPv4 Servers", RFC 6146, April 2011. 385 [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 386 Stack Lite Broadband Deployments Following IPv4 387 Exhaustion", RFC 6333, August 2011. 389 Appendix A. PCP State Synchronization: Overview 391 The following sketches the state synchronization logic: 393 o One element (i.e., PCP Client/host/application, PCP Server, PCP 394 Proxy, PCP IWF) of the chain is REQUIRED to use stable storage 396 o If the PCP Client (resp., the PCP Server) crashes and restarts it 397 just have to synchronize with the PCP Server (resp., the PCP 398 Client); 400 o If both crash then one has to use stable storage and we fall back 401 in the previous case as soon as we know which one (the Epoch value 402 gives this information); 404 o PCP Server -> PCP Client not-disruptive synchronization requires a 405 GET/NEXT mechanism to retrieve the state from the PCP Server; 406 without this mechanism the only way to put the PCP Server in a 407 known state is for the PCP Client to send a delete all request, a 408 clearly disruptive operation. 410 o PCP Client -> PCP Server synchronization is done by a re-create or 411 refresh of the state. The PCP Client MAY retrieve the PCP Server 412 state in order to prevent stale explicit dynamic mappings. 414 Appendix B. GET/NEXT Operation 416 This section defines a new PCP OpCode called GET and its associated 417 Option NEXT. 419 These PCP Opcode and Option are used by the PCP Client to retrieve an 420 explicit mapping or to walk through the explicit dynamic mapping 421 table maintained by the PCP Server for this subscriber and retrieves 422 a list of explicit dynamic mapping entries it instantiated. 424 GET can also be used by a NoC to retrieve the list of mappings for a 425 given subscriber. 427 B.1. OpCode Format 429 The GET OpCode payload contains a Filter used for explicit dynamic 430 mapping matching: only the explicit dynamic mappings of the 431 subscriber which match the Filter in a request are considered so 432 could be returned in response. 434 Implementation Note: Some existing implementations use 98 (0x62) 435 codepoint for GET OpCode, 131 for AMBIGUOUS error code, and 131 436 (0x83) for NEXT Option. 438 The layout of GET OpCode is shown in Figure 1. 440 0 1 2 3 441 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 442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 443 | Protocol | Reserved | 444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 445 | | 446 : Filter internal IP address (always 128 bits) : 447 | | 448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 449 | | 450 : Filter external IP address (always 128 bits) : 451 | | 452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 453 | Filter internal port | Filter external port | 454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 456 Figure 1: GET: OpCode format 458 For all fields, the value 0 in a request means wildcard filter/any 459 value matches. Of course this has to be sound: no defined port with 460 protocol set to any. 462 These fields are described below: 464 Protocol: Same than for MAP [RFC6887]. 466 Reserved: MUST be sent as 0 and MUST be ignored when received. 468 Filter internal IP address: Conveys the internal IP address 469 (including an unspecified IPv4IPv6 address). The encoding of this 470 field follows Section 5 of [RFC6887]. 472 Filter external IP address: Conveys the external IP address 473 (including an unspecified IPv4IPv6 address). The encoding of this 474 field follows Section 5 of [RFC6887]. 476 Filter internal port: The internal port (including 0). 478 Filter external port: The external port (including 0). 480 Responses include a bit-to-bit copy of the OpCode found in the 481 request. 483 B.2. OpCode-Specific Result Code 485 This OpCode defines two new specific Result Code 487 TBD: NONEXIST_MAP, e.g., no explicit dynamic mapping matching the 488 Filter was found. 490 TBD: AMBIGUOUS. This code is returned when the PCP Server is not 491 able to decide which mapping to return. Existing implementations 492 use 131 as codepoint. 494 B.3. Ordering and Equality 496 The PCP server is required to implement an order between matching 497 explicit dynamic mappings. The only property of this order is to be 498 stable: it doesn't change (*) between two GET requests with the same 499 Filter. 501 (*) "change" means two mappings are not gratuitously swapped: 502 expiration, renewal or creation are authorized to change the order 503 but they are at least expected by the PCP client. 505 [Ed. Note: We have two proposals for the order: lexicographical 506 order and lifetime order. Both work, this should be left to the 507 implementor.] 509 Equality is defined by: 511 o same protocol and; 512 o same internal address and; 513 o same external address and; 514 o same internal port and; 515 o same external port. 517 B.4. NEXT Option 519 Formal definition: 521 Name: NEXT 523 Number: at most one in requests, any in responses. 525 Purpose: carries a Locator in requests, matching explicit dynamic 526 mappings greater than the Locator in responses. 528 Is valid for OpCodes: GET OpCode. 530 Length: variable, the minimum is 11. 532 May appear in: both requests and responses. 534 Maximum occurrences: one for requests, bounded by maximum message 535 size for PCP responses [RFC6887]. 537 The layout of the NEXT Option is shown in Figure 2. 539 Version=1 540 0 1 2 3 541 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 542 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 543 | Protocol | Reserved | MORE/END | 544 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 545 | | 546 : Mapping internal IP address (always 128 bits) : 547 | | 548 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 549 | | 550 : Mapping external IP address (always 128 bits) : 551 | | 552 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 553 | Mapping remaining lifetime | 554 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 555 | Mapping internal port | Mapping external port | 556 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 557 | | 558 | Mapping Options : 559 | | 560 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 562 Version=2 564 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 565 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 566 : Mapping Nonce (96 bits) : 567 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 568 | Protocol | Reserved | MORE/END | 569 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 570 | | 571 : Mapping internal IP address (always 128 bits) : 572 | | 573 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 574 | | 575 : Mapping external IP address (always 128 bits) : 577 | | 578 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 579 | Mapping remaining lifetime | 580 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 581 | Mapping internal port | Mapping external port | 582 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 583 | | 584 | Mapping Options : 585 | | 586 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 588 Figure 2: NEXT: Option format 590 In requests the NEXT Option carries a Locator: a position in the list 591 of explicit dynamic mappings which match the Filter. The following 592 two useful forms of Locators are considered: 594 o the "Undefined" form where the Protocol, Addresses, Ports fields 595 are set to zero. 597 o the "Defined" form where none of the Protocol, Addresses and Ports 598 is set to zero. 600 The new fields in a Locator (a.k.a., the NEXT Option in a GET 601 request) are described below: 603 MORE/END: The value 0 denotes "MORE" and means the response MAY 604 include multiple NEXT Options; a value other than 0 (1 is 605 RECOMMENDED) denotes "END" and means the response SHALL include at 606 most one NEXT Option. 608 Mapping remaining lifetime: MUST be sent as 0 and MUST be ignored 609 when received. 611 Mapping Options: The Option Codes of the PCP Client wants to get in 612 the response (e.g., THIRD_PARTY). The format is the same than for 613 the UNPROCESSED Option (see rev 17 of[RFC6887]). 615 In responses the NEXT Options carry the returned explicit dynamic 616 mappings, one per NEXT Option. The fields are described below: 618 Protocol: The protocol of the returned mapping. 620 MORE/END: The value 0 when there are explicit dynamic mapping 621 matching the Filter and greater than this returned mapping; a 622 value other than 0 (1 is RECOMMENDED) when the return mapping is 623 the greatest explicit dynamic mapping matching the Filter. 625 Mapping internal IP address: the internal address of the returned 626 mapping. The encoding of this field follows Section 5 of 627 [RFC6887]. 629 Mapping external IP address: the external address of the returned 630 mapping. The encoding of this field follows Section 5 of 631 [RFC6887]. 633 Mapping remaining lifetime: The remaining lifetime in seconds of the 634 returned mapping. 636 Mapping internal port: the internal port of the returned mapping. 638 Mapping external port: the external port of the returned mapping. 640 Mapping Options: An embedded list of option values. Each 641 corresponding Option Code MUST be present in the request NEXT 642 Option, each option MUST be related to the returned mapping or not 643 related to any mapping. 645 B.5. GET/NEXT PCP Client Theory of Operation 647 GET requests without a NEXT Option have low usage but with a full 648 wildcard Filter they ask the PCP Server to know if it has at least 649 one explicit dynamic mapping for this subscriber. 651 GET requests with an END NEXT Option are "pure" GET: they asks for 652 the status and/or the remaining lifetime or options of a specific 653 explicit dynamic mapping. It is recommended to use an Undefined 654 Locator and to use the Filter to identify the mapping. 656 GET requests with a MORE NEXT Option are for the whole explicit 657 dynamic mapping table retrieval from the PCP Server. The initial 658 request contains an Undefined Locator, other requests a Defined 659 Locator filled by a copy of the last returned mapping with the 660 Lifetime and Option fields reseted to the original values. An END 661 NEXT Option marks the end of the retrieval. 663 B.6. GET/NEXT PCP Server Theory of Operation 665 The PCP Server behavior is described below: 667 o on the reception of a valid GET request the ordered list of 668 explicit dynamic mapping of the subscriber matching the given 669 Filter is (conceptually) built. 671 o if the list is empty a NONEXIST_MAP error response is returned. 672 It includes no NEXT Option. 674 o the list is scanned to find the Locator using the Equality defined 675 in Appendix B.3. If it is found the mappings less than the 676 Locator are removed from the list, so the result is a list which 677 begins by the mapping equals to the Locator followed by greater 678 mappings. 680 o if the NEXT Option in the request is an END one, the first mapping 681 of the list is returned in an only NEXT option, marked END if the 682 list contains only this mapping, marked MORE otherwise. 684 o if the NEXT option in the request is a MORE one, as many as can 685 fit mappings are returned in order in the response, marked as MORE 686 but if the whole list can be returned the last is marked END. 688 "Returned" means to include required options when they are defined 689 for a mapping: if the mapping M has 3 REMOTE_PEER_FILTERs and the 690 REMOTE_PEER_FILTER code was in the request NEXT, the NEXT carrying M 691 will get the 3 REMOTE_PEER_FILTER options embedded. 693 B.7. Flow Examples 695 As an illustration example, let's consider the following explicit 696 dynamic mapping table is maintained by the PCP Server: 698 +------+--------------+----------+-----------+----------+-----------+ 699 | Pro | Internal IP | Internal | External | External | Remaining | 700 | | Address | Port | IP | Port | Lifetime | 701 | | | | Address | | | 702 +------+--------------+----------+-----------+----------+-----------+ 703 | UDP | 198.51.100.1 | 25655 | 192.0.2.1 | 15659 | 1659 | 704 | TCP | 198.51.100.2 | 12354 | 192.0.2.1 | 32654 | 3600 | 705 | TCP | 198.51.100.2 | 8596 | 192.0.2.1 | 25659 | 6000 | 706 | UDP | 198.51.100.1 | 19856 | 192.0.2.1 | 42654 | 7200 | 707 | TCP | 198.51.100.1 | 15775 | 192.0.2.1 | 32652 | 9000 | 708 +------+--------------+----------+-----------+----------+-----------+ 710 Table 1: Excerpt of a mapping table 712 As shown in Table 1, the PCP Server sorts the explicit dynamic 713 mapping table using the internal IP address and the remaining 714 lifetime. 716 Figure 3 illustrates the exchange that occurs when a PCP Client tries 717 to retrieve the information related to a non-existing explicit 718 dynamic mapping. 720 +------+ +------+ 721 | PCP | | PCP | 722 |Client| |Server| 723 +------+ +------+ 724 | (1) PCP GET Request | 725 | protocol= TCP | 726 | internal-ip-address= 198.51.100.1 | 727 | internal-port= 59864 | 728 | Undefined Locator | 729 |---------------------------------->| 730 | | 731 | (2) PCP GET Response | 732 | error= NONEXIST_MAP | 733 |<----------------------------------| 734 | | 736 Figure 3: Example of a failed GET operation 738 Figure 4 shows an example of a PCP Client which retrieves 739 successfully an existing mapping from the PCP Server. 741 +------+ +------+ 742 | PCP | | PCP | 743 |Client| |Server| 744 +------+ +------+ 745 | (1) PCP GET Request | 746 | protocol= TCP | 747 | internal-ip-address= 198.51.100.1 | 748 | internal-port= 25655 | 749 | Undefined Locator | 750 |---------------------------------->| 751 | | 752 | (2) PCP GET Response | 753 | END | 754 | protocol= TCP | 755 | internal-ip-address= 198.51.100.1 | 756 | internal-port= 25655 | 757 | external-ip-address= 192.0.2.1 | 758 | external-port= 15659 | 759 | remaining-lifetime= 1659 | 760 |<----------------------------------| 761 | | 762 | (3) PCP MAP4 Request | 763 | protocol= TCP | 764 | internal-ip-address= 198.51.100.1 | 765 | internal-port= 25655 | 766 | external-ip-address= 192.0.2.1 | 767 | external-port= 15659 | 768 | requested-lifetime= 0 | 769 |---------------------------------->| 770 | | 772 Figure 4: Example of a successful GET operation 774 In reference to Figure 5, the PCP Server returns the explicit dynamic 775 mappings having the internal address equal to 192.0.2.1 ordered by 776 increasing remaining lifetime. 778 +------+ +------+ 779 | PCP | | PCP | 780 |Client| |Server| 781 +------+ +------+ 782 | (1) PCP GET Request | 783 | internal-ip-address= 198.51.100.2 | 784 | Undefined Locator | 785 |---------------------------------->| 786 | | 787 | (2) PCP GET Response | 788 | MORE | 789 | protocol= TCP | 790 | internal-ip-address= 198.51.100.2 | 791 | internal-port= 12354 | 792 | external-ip-address= 192.0.2.1 | 793 | external-port= 32654 | 794 | remaining-lifetime= 3600 | 795 | END | 796 | protocol= TCP | 797 | internal-ip-address= 198.51.100.2 | 798 | internal-port= 8596 | 799 | external-ip-address= 192.0.2.1 | 800 | external-port= 25659 | 801 | remaining-lifetime= 6000 | 802 |<----------------------------------| 803 | | 805 Figure 5: Flow example of GET/NEXT 807 In reference to Figure 6, the PCP Server returns the explicit dynamic 808 mappings having the internal address equal to 192.0.2.2 ordered by 809 increasing remaining lifetime. In this example, the same internal 810 port is used for TCP and UDP. 812 +------+ +------+ 813 | PCP | | PCP | 814 |Client| |Server| 815 +------+ +------+ 816 | (1) PCP GET Request | 817 | internal-ip-address= 198.51.100.1 | 818 | internal-port= 25655 | 819 | Undefined Locator | 820 |---------------------------------->| 821 | | 822 | (2) PCP GET Response | 823 | MORE | 824 | protocol= UDP | 825 | internal-ip-address= 198.51.100.1 | 826 | internal-port= 25655 | 827 | external-ip-address= 192.0.2.1 | 828 | external-port= 15659 | 829 | remaining-lifetime= 1659 | 830 | END | 831 | protocol= TCP | 832 | internal-ip-address= 198.51.100.1 | 833 | internal-port= 25655 | 834 | external-ip-address= 192.0.2.1 | 835 | external-port= 32652 | 836 | remaining-lifetime= 9000 | 837 |<----------------------------------| 838 | | 840 Figure 6: Flow example of GET/NEXT: same internal port number 842 Authors' Addresses 844 Mohamed Boucadair 845 France Telecom 846 Rennes 35000 847 France 849 Email: mohamed.boucadair@orange.com 851 Reinaldo Penno 852 Cisco 853 USA 855 Email: repenno@cisco.com