idnits 2.17.1 draft-boucadair-pcp-deployment-cases-03.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 03, 2014) is 3584 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 527, but no explicit reference was found in the text == Outdated reference: A later version (-08) exists of draft-ietf-pcp-anycast-01 == Outdated reference: A later version (-09) exists of draft-ietf-pcp-proxy-05 == Outdated reference: A later version (-10) exists of draft-ietf-pcp-server-selection-03 Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). 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 July 03, 2014 5 Expires: January 4, 2015 7 Port Control Protocol (PCP) Deployment Models 8 draft-boucadair-pcp-deployment-cases-03 10 Abstract 12 This document lists a set of Port Control Protocol (PCP) deployment 13 models. 15 Status of This Memo 17 This Internet-Draft is submitted in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF). Note that other groups may also distribute 22 working documents as Internet-Drafts. The list of current Internet- 23 Drafts is at http://datatracker.ietf.org/drafts/current/. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 This Internet-Draft will expire on January 4, 2015. 32 Copyright Notice 34 Copyright (c) 2014 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents 39 (http://trustee.ietf.org/license-info) in effect on the date of 40 publication of this document. Please review these documents 41 carefully, as they describe your rights and restrictions with respect 42 to this document. Code Components extracted from this document must 43 include Simplified BSD License text as described in Section 4.e of 44 the Trust Legal Provisions and are provided without warranty as 45 described in the Simplified BSD License. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 50 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 51 3. CPE Models . . . . . . . . . . . . . . . . . . . . . . . . . 2 52 3.1. Single Homed CPE Model: Local PCP Server . . . . . . . . 3 53 3.2. Single Homed CPE Model: Multiple PCP Servers . . . . . . 3 54 3.3. Multi-Homed CPE Model: One Single PCP Server . . . . . . 4 55 3.4. Multi-Homed CPE Model: Multiple PCP Servers . . . . . . . 5 56 3.5. PCP Proxy Model . . . . . . . . . . . . . . . . . . . . . 6 57 3.6. UPnP IGD-PCP Interworking Model . . . . . . . . . . . . . 7 58 3.7. HTTP-based User Interface . . . . . . . . . . . . . . . . 8 59 3.8. Cascaded PCP-controlled Nodes Model . . . . . . . . . . . 8 60 4. Hide PCP Servers Model . . . . . . . . . . . . . . . . . . . 10 61 4.1. PCP Proxy Model . . . . . . . . . . . . . . . . . . . . . 10 62 4.2. HTTP-Triggered PCP Client Model . . . . . . . . . . . . . 11 63 5. Separated PCP Server & PCP-controlled Device Model . . . . . 12 64 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 65 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 66 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 67 8.1. Normative References . . . . . . . . . . . . . . . . . . 13 68 8.2. Informative References . . . . . . . . . . . . . . . . . 13 69 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14 71 1. Introduction 73 This document lists a set of PCP [RFC6887] deployment models. 75 2. Terminology 77 This document makes use of the following terms: 79 o PCP client denotes a functional element responsible for issuing 80 PCP requests to a PCP server. Refer to [RFC6887]. 81 o PCP server denotes a functional element that receives and 82 processes PCP requests from a PCP client. A PCP server can be co- 83 located with or be separated from the function (e.g., NAT, 84 Firewall) it controls. Refer to [RFC6887]. 85 o PCP proxy refers to a functional elements that is responsible for 86 relaying PCP requests received from PCP client to upstream PCP 87 servers. 89 3. CPE Models 90 3.1. Single Homed CPE Model: Local PCP Server 92 This model assumes PCP is enabled in the LAN side to control 93 functions located in the CPE. The PCP server is reachable with the 94 IP address of the private-faced interface of the CPE. Typical 95 functions that can be controlled by PCP in this model are NAT and 96 firewall. 98 +-------------+ 99 | PCP | 100 | Client |----+ ,-----------. 101 +-------------+ | +------------+ ,' `--. 102 +---| CPE | / : 103 | PCP server |_______; ISP | 104 +---| NAT+FW+.. | : | 105 +-------------+ | +------------+ \ | 106 | PCP |----+ -------------------. 107 | Client | 108 +-------------+ 110 PCP client can be configured with their PCP server using DHCP for 111 instance [I-D.ietf-pcp-dhcp]. If no PCP server is configured, PCP 112 clients assume their default gateway is the PCP server. 114 This model applies for both residential or corporate markets. 116 3.2. Single Homed CPE Model: Multiple PCP Servers 118 This model assumes a customer site is connected to the same ISP's 119 network. One or multiple PCP servers are deployed in the ISP's 120 domain; each of them manage distinct set of functions. In the 121 example shown in the following figure: 123 o NAT64 device [RFC6146] are used to interwork with IPv4-only 124 devices. 126 o NPTv6 function [RFC6296] is used for engineering motivation 127 internal to the ISP. 129 +-------------+ 130 | PCP | 131 | Client |----+ ,-----------. 132 +-------------+ | +------------+ ,' ISP `--. 133 +---| CPE | / : 134 | |________; NAT64 | 135 +---| | : | 136 +-------------+ | +------------+ \ NPTv6 | 137 | PCP |----+ ----------------. 138 | Client | 139 +-------------+ 141 The use of NAT64 and NPTv6 functions is for illustration purposes; 142 other functions can be enabled in the ISP's network side. 144 PCP clients located behind the CPE, must discover both the external 145 IPv4 address and port numbers assigned by the NAT64 and the external 146 IPv6 address assigned by the NPTv6. These external addresses are 147 used for example in referrals to indicate to remote peers both the 148 IPv4 address and IPv6 address to reach an internal server deployed in 149 an IPv6-only domain. 151 The use of a PCP anycast address ([I-D.ietf-pcp-anycast]) is not 152 recommended for this deployment case because two state entries must 153 be created in both NAT64 and NPTv6. Explicit means such as 154 [I-D.ietf-pcp-dhcp] must be used instead to provision IP addresses of 155 available PCP servers. 157 [I-D.ietf-pcp-dhcp] may be used to provision the IP addresses of 158 these PCP servers, or the CPE must embed a PCP proxy function that 159 must follow [I-D.ietf-pcp-server-selection] to contact all PCP 160 servers. 162 3.3. Multi-Homed CPE Model: One Single PCP Server 164 A typical example of this model is shown in the following figure: 166 ==================== 167 | Internet | 168 ===================== 169 | | 170 | | 171 +----+--------+ +-+------------+ 172 | ISP1 | | ISP2 | 173 | | | | 174 +----+--------+ +-+------------+ 175 | | 176 | | 177 .............................................................. 178 | | 179 | Port1 | Port2 Subscriber Network 180 | | 181 +----------------------+ 182 | NAT & PCP servers | 183 | GW Router | 184 +----+-----------------+ 185 | 186 | 187 | 188 -----+-------------- 189 | 190 +-+-----+ 191 | Hosts | (private address space) 192 +-------+ 194 Internal PCP clients can interact with one single PCP server. 196 3.4. Multi-Homed CPE Model: Multiple PCP Servers 198 A typical example of this model is shown in the following figure: 200 ================== 201 | Internet | 202 ================== 203 | | 204 | | 205 +----+-+ +-+----+ 206 | ISP1 | | ISP2 | 207 +----+-+ +-+----+ 208 | | 209 ......................................................... 210 | | 211 | | Subscriber Network 212 +-------+---+ +----+------+ 213 | rtr1 with | | rtr2 with | 214 | FW1 | | FW2 | 215 +-------+---+ +----+------+ 216 | | 217 | | 218 | | 219 -------+----------+------ 220 | 221 +-+-----+ 222 | Hosts | 223 +-------+ 225 The PCP client must interact with all PCP servers; otherwise 226 complications arise to communicate with remote peers. The procedure 227 defined in [I-D.ietf-pcp-server-selection] is used to contact those 228 servers. 230 The use of anycast-based model ([I-D.ietf-pcp-anycast]) might induce 231 failures when communicating with external peers (e.g., incoming 232 packets will be dropped by one of the firewalls). 234 3.5. PCP Proxy Model 236 This model assumes no PCP-controlled function is located in the CPE 237 (e.g., DS-Lite case). The upstream PCP server is located in the 238 ISP's network. The PCP server can be deduced from other provisioning 239 parameters (e.g., use the IP address of the AFTR as PCP server); 240 otherwise the IP address (s) must be discovered by other means. 242 The use of an anycast-based model may not be convenient in some cases 243 (e.g., multiple PCP-controlled devices are deployed; each of them 244 manage a subset of services and state). 246 +-------------+ 247 | Host | 248 | |----+ ,-----------. 249 +-------------+ | +------------+ ,' `--. 250 +---| CPE | / ISP : 251 | PCP proxy |_____; PCP server 1 | 252 +---| PCP client | : PCP server i | 253 +-------------+ | +------------+ \ | 254 | PCP |----+ -------------------. 255 | Client | 256 +-------------+ 258 3.6. UPnP IGD-PCP Interworking Model 260 This model is specified in [RFC6970]. The interworking function must 261 be provisioned with the IP address(es) of remote PCP server(s). 263 (a) 264 +-------------+ 265 | IGD Control | 266 | Point |----+ 267 +-------------+ | +-----+ +--------+ +------+ 268 +---| IGD-| |Provider| |Remote| 269 | PCP |--| NAT |-----| Host | 270 +---| IWF | | | | | 271 +-------------+ | +-----+ +--------+ +------+ 272 | Local Host |----+ 273 +-------------+ 274 LAN Side External Side 275 <======UPnP IGD==============><=====PCP=====> 277 (b) 278 +-------------+ 279 | IGD Control | 280 | Point |----+ 281 +-------------+ | +-----+ +--------+ +------+ 282 +---| IGD-| |Provider| |Remote| 283 | PCP |--| NAT |-----| Host | 284 +---| IWF | | | | | 285 +-------------+ | +-----+ +--------+ +------+ 286 | Local Host |----+ NAT1 NAT2 287 +-------------+ 289 3.7. HTTP-based User Interface 291 This deployment model relies on the following: 293 o An HTTP administration based interface (e.g. GUI) is provided to 294 the user to manage its flow-based forwarding rules. This 295 interface is part of the CPE management interface. 297 o The CPE embeds a PCP client. 299 o HTTP requests are translated into appropriate PCP requests in 300 order to install the requested state. 302 o The PCP client uses THIRD_PARTY option. 304 o The PCP client should be configured with the PCP server that 305 controls the on-path PCP-controlled device for that user. 307 o One or multiple PCP servers can be deployed. The logic of 308 contacting these PCP servers may be explicitly configured to the 309 PCP client. If not, the procedure defined in 310 [I-D.ietf-pcp-server-selection] is used to contact those PCP 311 servers. 313 o The use of a well-known address ([I-D.ietf-pcp-anycast]) to reach 314 internal PCP servers might not be convenient if all PCP servers do 315 not manage the same set of mapping entries (e.g., NAT64, NPTv6, 316 IPv6 firewall, etc.). 318 +-------------+ 319 | Host 1 |----+ ,-----------. 320 +-------------+ | +------------+ ,' `--. 321 +---| CPE | / ISP : 322 | HTTP Server|_____; | 323 +---| PCP client | : PCP server i | 324 +-------------+ | +------------+ \ | 325 | Host 2 |----+ -------------------. 326 +-------------+ 328 This model can co-exist with the models discussed in Section 3.5 and 329 Section 3.6. 331 3.8. Cascaded PCP-controlled Nodes Model 333 This model assumes cascaded PCP-controlled devices are deployed. A 334 typical example is provided below. 336 ,-----------. 337 PCP server ,' `--. 338 +-------+ +------+ +----------+ / : 339 |PCP |____|Home |______|ISP CPE |________; Public | 340 |Client | |Router| |NAT Router| : Internet | 341 +-------+ +------+ +----------+ \ | 342 \ ; 343 `------. ,-' 344 `-----' 345 ,-----------. 346 PCP server ,' `--. 347 +-------+ +------+ +-------+ / : 348 |PCP |____|CPE |______|CGN/FW |___________; Public | 349 |Client | | | | | : Internet | 350 +-------+ +------+ +-------+ \ | 351 \ ; 352 `------. ,-' 353 `-----' 354 ,-----------. 355 PCP proxy PCP server ,' `--. 356 +-------+ +------+ +-------+ / : 357 |PCP |____|CPE |_______________|CGN/FW |__; Public | 358 |Client | | | | | : Internet | 359 +-------+ +------+ +-------+ \ | 360 \ ; 361 `------. ,-' 362 `-----' 363 ,-----------. 364 PCP server PCP server ,' `--. 365 +-------+ +------+ +-------+ / : 366 |PCP |____|CPE |_______________|CGN/FW |__; Public | 367 |Client | | | | | : Internet | 368 +-------+ +------+ +-------+ \ | 369 \ ; 370 `------. ,-' 371 `-----' 373 This model requires a PCP proxy function [I-D.ietf-pcp-proxy] be 374 deployed in intermediate PCP-controlled devices: 376 o The PCP client is not aware of the presence of more than one level 377 of PCP servers. 379 o Each intermediate PCP proxy must contact the appropriate next hop 380 PCP server(s). 382 o The use of PCP anaycast address may not be appropriate when the 383 PCP server is co-located with the PCP-controlled device. 385 4. Hide PCP Servers Model 387 4.1. PCP Proxy Model 389 In order to hide PCP servers deployed within an administrative 390 domain, an administrative entity may decide to deploy one or more PCP 391 proxies [I-D.ietf-pcp-proxy] in front of PCP clients. A PCP proxy is 392 responsible for relaying PCP requests to the appropriate PCP 393 server(s): 395 o In order to prevent single failure scenarios, multiple PCP proxies 396 can be hosted within an administrative domain. 398 o A PCP proxy can be configured with one or multiple PCP servers. 400 o A PCP proxy can be configured with the logic indicating how it 401 should proceed to contact upstream PCP servers. The PCP proxy 402 will then follow the procedure defined in 403 [I-D.ietf-pcp-server-selection] to contact those PCP servers. 405 o Internal PCP clients may be configured with the IP address(es) of 406 the appropriate PCP proxy (e.g., [I-D.ietf-pcp-dhcp]). 408 * If all PCP proxies interact with the same PCP server(s), the 409 same IP address can be provisioned to PCP clients. 411 * If PCP proxies do not interact with the same set of PCP 412 server(s), appropriate IP address(es) are to be returned to 413 each requesting PCP client. 415 +------------------------------------+ 416 | Administrative Domain | 417 +----------+ | +-------------------+ | 418 |PCP client|---|----| PCP proxy | | 419 +----------+ | +-------------------+ | 420 | | | | 421 | | | | 422 | +------+------+ +-+------------+ | 423 | | PCP server | | PCP server | | 424 | +-------------+ +--------------+ | 425 +------------------------------------+ 427 The PCP proxy should not use the PCP anycast address 428 ([I-D.ietf-pcp-anycast]) if available PCP servers do not manage the 429 same PCP-controlled device. Deterministic means should be used 430 instead. 432 PCP client should not use the PCP anycast address to reach a PCP 433 proxy if deployed PCP proxies do not interact with the same PCP 434 servers. Explicit provisioning means should be preferred. 436 If the PCP proxy is reachable using the PCP anycast address, 437 available PCP servers must not be reachable using the same PCP 438 anycast address. 440 4.2. HTTP-Triggered PCP Client Model 442 Another deployment model to hide the identity of back-end PCP servers 443 is to rely on HTTP to invoke the PCP service. This model can be used 444 by operators to accommodate cases where a PCP client implementation 445 is not available at the customer side (e.g., unmanaged CPE model). 447 The deployment model relies on the following: 449 o An HTTP administration based interface (e.g. GUI) is provided to 450 the user to manage its flow-based forwarding rules. 452 o The HTTP user interface can be part of a CPE management interface 453 or be provided as part of the customer care portal. 455 o The HTTP server embeds also a PCP client. 457 o HTTP requests are translated into appropriate PCP requests in 458 order to install the requested state. 460 o The PCP client uses THIRD_PARTY option. 462 o The PCP client should be configured with the PCP server that 463 controls the on-path PCP-controlled device for that user. 465 o One or multiple PCP servers can be deployed. The logic of 466 contacting these PCP servers may be explicitly configured to the 467 PCP client. If not, the procedure defined in 468 [I-D.ietf-pcp-server-selection] is used to contact those PCP 469 servers. 471 o The use of a well-known address ([I-D.ietf-pcp-anycast]) to reach 472 internal PCP servers might not be convenient if all PCP servers do 473 not manage the same set of mapping entries (e.g., NAT64, NPTv6, 474 IPv6 firewall, etc.). 476 +------------------------------------+ 477 | Administrative Domain | 478 +----------+ | +----------------------+ | 479 | Host |---|----|HTTP Server+PCP client| | 480 +----------+ | +----------------------+ | 481 | | | | 482 | | | | 483 | +------+------+ +-+------------+ | 484 | | PCP server | | PCP server | | 485 | +-------------+ +--------------+ | 486 +------------------------------------+ 488 5. Separated PCP Server & PCP-controlled Device Model 490 This model assumes the PCP server is not co-located with the PCP- 491 controlled device. Moreover: 493 o In order to prevent single failure scenarios, multiple PCP servers 494 can be hosted within an administrative domain. 496 o A PCP server can control one or many PCP-controlled devices. 498 o Multiple PCP servers can be enabled; each of them manages a set of 499 PCP-controlled devices. 501 o Internal PCP clients are configured with the IP address(es) of the 502 appropriate PCP server. 504 * If all PCP servers interact with the same PCP-controlled 505 devices, the same PCP server's IP address can be provisioned to 506 PCP clients. 508 * If PCP servers do not interact with the same set of PCP- 509 controlled devices, PCP server IP address(es) are to be 510 returned to each requesting PCP client. 512 Note, PCP is not used between the PCP server and the PCP-controlled 513 device. Other protocols (e.g., H.248) can be used for that purpose. 515 6. Security Considerations 517 PCP-related security considerations are discussed in [RFC6887]. 519 7. IANA Considerations 521 This document does not require any action from IANA. 523 8. References 525 8.1. Normative References 527 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 528 Requirement Levels", BCP 14, RFC 2119, March 1997. 530 [RFC6887] Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. 531 Selkirk, "Port Control Protocol (PCP)", RFC 6887, April 532 2013. 534 8.2. Informative References 536 [I-D.ietf-pcp-anycast] 537 Kiesel, S., Penno, R., and S. Cheshire, "PCP Anycast 538 Address", draft-ietf-pcp-anycast-01 (work in progress), 539 February 2014. 541 [I-D.ietf-pcp-dhcp] 542 Boucadair, M., Penno, R., and D. Wing, "DHCP Options for 543 the Port Control Protocol (PCP)", draft-ietf-pcp-dhcp-13 544 (work in progress), April 2014. 546 [I-D.ietf-pcp-proxy] 547 Perreault, S., Boucadair, M., Penno, R., Wing, D., and S. 548 Cheshire, "Port Control Protocol (PCP) Proxy Function", 549 draft-ietf-pcp-proxy-05 (work in progress), February 2014. 551 [I-D.ietf-pcp-server-selection] 552 Boucadair, M., Penno, R., Wing, D., Patil, P., and T. 553 Reddy, "PCP Server Selection", draft-ietf-pcp-server- 554 selection-03 (work in progress), April 2014. 556 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 557 NAT64: Network Address and Protocol Translation from IPv6 558 Clients to IPv4 Servers", RFC 6146, April 2011. 560 [RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix 561 Translation", RFC 6296, June 2011. 563 [RFC6970] Boucadair, M., Penno, R., and D. Wing, "Universal Plug and 564 Play (UPnP) Internet Gateway Device - Port Control 565 Protocol Interworking Function (IGD-PCP IWF)", RFC 6970, 566 July 2013. 568 Author's Address 570 Mohamed Boucadair 571 France Telecom 572 Rennes 35000 573 France 575 Email: mohamed.boucadair@orange.com