idnits 2.17.1 draft-kiesel-pcp-ip-based-srv-disc-01.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 is 1 instance of too long lines in the document, the longest one being 4 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 19, 2013) is 3902 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC2616' is defined on line 347, but no explicit reference was found in the text == Unused Reference: 'RFC2732' is defined on line 351, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 1546 ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 2732 (Obsoleted by RFC 3986) ** Obsolete normative reference: RFC 4773 (Obsoleted by RFC 6890) ** Obsolete normative reference: RFC 5736 (Obsoleted by RFC 6890) == Outdated reference: A later version (-13) exists of draft-ietf-pcp-dhcp-08 Summary: 6 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PCP S. Kiesel 3 Internet-Draft University of Stuttgart 4 Intended status: Standards Track R. Penno 5 Expires: February 20, 2014 Cisco Systems 6 August 19, 2013 8 PCP Server Discovery based on well-known IP Address 9 draft-kiesel-pcp-ip-based-srv-disc-01 11 Abstract 13 The Port Control Protocol (PCP) provides a mechanism to control how 14 incoming packets are forwarded by upstream devices such as Network 15 Address Translator IPv6/IPv4 (NAT64), Network Address Translator 16 IPv4/IPv4 (NAT44), IPv6 and IPv4 firewall devices, and a mechanism to 17 reduce application keep alive traffic. 19 This document establishes a well-known IP address for the PCP Server 20 and documents how PCP clients embedded in endpoints can use it during 21 the discovery and regular operation phases. 23 Requirements Language 25 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 26 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 27 document are to be interpreted as described in RFC 2119 [RFC2119]. 29 Status of this Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on February 20, 2014. 46 Copyright Notice 48 Copyright (c) 2013 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 2. PCP Server Discovery based on well-known IP Address . . . . . 5 65 2.1. Well-Known PCP Server IP Address (WkPsdIPa) . . . . . . . 5 66 2.2. PCP Discovery Client behavior . . . . . . . . . . . . . . 5 67 2.3. PCP Discovery Server behavior . . . . . . . . . . . . . . 5 68 3. Deployment Considerations . . . . . . . . . . . . . . . . . . 6 69 3.1. Multiple PCP Servers, Symmetric Routing . . . . . . . . . 6 70 3.2. Multiple PCP Servers, Assymetric Routing . . . . . . . . . 6 71 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 72 4.1. Registration of IPv4 Special Purpose Address . . . . . . . 8 73 4.2. Registration of IPv6 Special Purpose Address . . . . . . . 9 74 4.3. PCP Option . . . . . . . . . . . . . . . . . . . . . . . . 10 75 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 76 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 77 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 78 7.1. Normative References . . . . . . . . . . . . . . . . . . . 13 79 7.2. Informative References . . . . . . . . . . . . . . . . . . 13 80 Appendix A. Problems with Other Discovery methods . . . . . . . . 15 81 A.1. DHCP PCP Options . . . . . . . . . . . . . . . . . . . . . 15 82 A.2. Default Router . . . . . . . . . . . . . . . . . . . . . . 15 83 A.3. User Input . . . . . . . . . . . . . . . . . . . . . . . . 15 84 A.4. Domain Name System Based . . . . . . . . . . . . . . . . . 16 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 87 1. Introduction 89 The Port Control Protocol (PCP) [I-D.ietf-pcp-base] provides a 90 mechanism to control how incoming packets are forwarded by upstream 91 devices such as Network Address Translator IPv6/IPv4 (NAT64), Network 92 Address Translator IPv4/IPv4 (NAT44), IPv6 and IPv4 firewall devices, 93 and a mechanism to reduce application keep alive traffic. 95 But before a PCP client can perform any of these tasks it needs to 96 discover one or more PCP servers. Several algorithms have been 97 specified that produce a suitable PCP Server address given PCP client 98 (i.e., the address may vary for different clients or different points 99 of network attachment, etc.). These approaches are based on user 100 input, DHCP [I-D.ietf-pcp-dhcp] or default router, which is the one 101 detailed in the PCP base document [I-D.ietf-pcp-base]. 103 But unfortunately in many deployments, the first-hop router does not 104 run a PCP server, or DHCP cannot be used. These and other problems 105 are described in detail in the Appendix.Appendix A. 107 This document follows a different approach: it establishes a well- 108 known address for the PCP Server (TBD: this approach could easily be 109 generalized in order to discover other services as well. But this is 110 for further study). PCP clients are expected to send requests to 111 this address during the PCP Server discovery process. A PCP Server 112 configured with the anycast address could optionally redirect or 113 return a list of unicast PCP Servers to the client. 115 2. PCP Server Discovery based on well-known IP Address 117 2.1. Well-Known PCP Server IP Address (WkPsdIPa) 119 IANA is requested to register a single IPv4 address 192.0.0.X (TBD) 120 and a single IPv6 address 2001:YYYY::ZZZZ (TBD) within the respective 121 Special Purpose Address Registries as the well-known IP anycast 122 addresses for PCP Servers. These addresses are called WkPsdIPa 123 (well-known PCP server discovery IP address(es)) in this document. 125 2.2. PCP Discovery Client behavior 127 PCP Clients that need to discover PCP servers should first send a PCP 128 request to its default router. This is important because in the case 129 of cascaded PCP Servers, all of them need to be discovered in order 130 of hop distance from the client. The PCP client then SHOULD send a 131 PCP request to the WkPsdIPa. PCP Clients must be prepared to receive 132 an error and try other discovery methods. 134 2.3. PCP Discovery Server behavior 136 PCP Server can be configured to listen on the WkPsdIPa for incoming 137 PCP requests. 139 PCP responses are sent from that same IANA-assigned address (see Page 140 5 of [RFC1546]). 142 3. Deployment Considerations 144 Network operators should install one or more PCP Servers as specified 145 above. Depending on the network deployment scenario they may use IP 146 routing tables, or other suitable mechanisms to direct PCP requests 147 to one of these servers. 149 [TBD: explain in more detail] This works fine even with cascaded 150 access routers with NATs. After each router hop the operator may 151 decide whether to handle the discovery requests, e.g., using a static 152 routing table entry, or whether let them flow "automatically" towards 153 the Internet backbones using the default routing table entry. 155 3.1. Multiple PCP Servers, Symmetric Routing 157 In the case of symmetric routing all inbound and outbound packets 158 from a PCP client traverse the same PCP Server or controlled device. 159 Multiple PCP Servers sharing an anycast address in a symmetric 160 routing scenario are used for two purposes: ease of network 161 configuration and redundancy. In the case of redundancy, If there is 162 a network or routing change a PCP client might start interacting with 163 a different PCP Server sharing the same anycast address. From a PCP 164 Client point of view this would be the same as a PCP Server reboot 165 and a PCP Client could find out about it by examining the Epoch field 166 during the next PCP request or ANNOUNCE message. 168 3.2. Multiple PCP Servers, Assymetric Routing 170 In the case of asymmetric routing inbound packets from a PCP client 171 traverse a different PCP Server or controlled device than outbound 172 packets. If these PCP Servers are firewalls, the PCP client would 173 need to create mappings on both of them in order to properly 174 communicate with other hosts. But if these PCP Servers share an 175 anycast address the PCP Client will create mappings in only on, when 176 in fact should create mapping on both of them. 178 Therefore in order to support this scenario we propose a new option 179 for the ANNOUNCE opcode. This will allow a PCP Client to request 180 from a PCP Server a list of unicast IP addresses associated with 181 other PCP Servers. The client can then proceed to create mappings on 182 these PCP Servers using their unicast addresses. 184 This Option: 185 Option Name: LIST_PCP_SRVS 186 Number: TBA (IANA) 187 Purpose: Allows a PCP Client to request from a PCP Server a list of 188 all PCP Servers configured 189 Valid for Opcodes: ANNOUNCE 190 Length: 0x0 191 May appear in: request and reply 192 Maximum occurrences in request: 1 194 0 1 2 3 195 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 196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 197 | LIST_PCP_SRVS | Reserved | Option Length=0 | 198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 200 The Reply from the PCP Server would be a list of IP addresses 202 Length in reply: 128 bits * number of IP addresses 203 Maximum occurrences in reply: as many as fit within maximum PCP message size 205 0 1 2 3 206 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 207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 208 | LIST | Reserved | Variable | 209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 210 | | 211 | | 212 | List of IP Addresses | 213 | | 214 |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| 216 Figure 1: List of PCP Servers 218 4. IANA Considerations 220 4.1. Registration of IPv4 Special Purpose Address 222 IANA is requested to register a single IPv4 address in the IANA IPv4 223 Special Purpose Address Registry [RFC5736]. 225 [RFC5736] itemizes some information to be recorded for all 226 designations: 228 1. The designated address prefix. 230 Prefix: TBD by IANA. Prefix length: /32 232 2. The RFC that called for the IANA address designation. 234 This document. 236 3. The date the designation was made. 238 TBD. 240 4. The date the use designation is to be terminated (if specified 241 as a limited-use designation). 243 Unlimited. No termination date. 245 5. The nature of the purpose of the designated address (e.g., 246 unicast experiment or protocol service anycast). 248 protocol service anycast. 250 6. For experimental unicast applications and otherwise as 251 appropriate, the registry will also identify the entity and 252 related contact details to whom the address designation has been 253 made. 255 N/A. 257 7. The registry will also note, for each designation, the 258 intended routing scope of the address, indicating whether the 259 address is intended to be routable only in scoped, local, or 260 private contexts, or whether the address prefix is intended to be 261 routed globally. 263 Typically used within a network operator's network domain, but in 264 principle globally routable. 266 8. The date in the IANA registry is the date of the IANA action, 267 i.e., the day IANA records the allocation. 269 TBD. 271 4.2. Registration of IPv6 Special Purpose Address 273 IANA is requested to register a single IPv6 address in the IANA IPv6 274 Special Purpose Address Block [RFC4773]. 276 [RFC4773] itemizes some information to be recorded for all 277 designations: 279 1. The designated address prefix. 281 Prefix: TBD by IANA. Prefix length: /128 283 2. The RFC that called for the IANA address designation. 285 This document. 287 3. The date the designation was made. 289 TBD. 291 4. The date the use designation is to be terminated (if specified 292 as a limited-use designation). 294 Unlimited. No termination date. 296 5. The nature of the purpose of the designated address (e.g., 297 unicast experiment or protocol service anycast). 299 protocol service anycast. 301 6. For experimental unicast applications and otherwise as 302 appropriate, the registry will also identify the entity and 303 related contact details to whom the address designation has been 304 made. 306 N/A. 308 7. The registry will also note, for each designation, the 309 intended routing scope of the address, indicating whether the 310 address is intended to be routable only in scoped, local, or 311 private contexts, or whether the address prefix is intended to be 312 routed globally. 314 Typically used within a network operator's network domain, but in 315 principle globally routable. 317 8. The date in the IANA registry is the date of the IANA action, 318 i.e., the day IANA records the allocation. 320 TBD. 322 4.3. PCP Option 324 The following PCP Option should be allocated: 326 LIST_PCP_SRVS 328 5. Security Considerations 330 TBD 332 6. Acknowledgements 334 Ted Lemon for insightful DHCP discussions and Dave Thaler for 335 pointing out the asymmetric routing case. 337 7. References 339 7.1. Normative References 341 [RFC1546] Partridge, C., Mendez, T., and W. Milliken, "Host 342 Anycasting Service", RFC 1546, November 1993. 344 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 345 Requirement Levels", BCP 14, RFC 2119, March 1997. 347 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 348 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 349 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 351 [RFC2732] Hinden, R., Carpenter, B., and L. Masinter, "Format for 352 Literal IPv6 Addresses in URL's", RFC 2732, December 1999. 354 [RFC3958] Daigle, L. and A. Newton, "Domain-Based Application 355 Service Location Using SRV RRs and the Dynamic Delegation 356 Discovery Service (DDDS)", RFC 3958, January 2005. 358 [RFC4773] Huston, G., "Administration of the IANA Special Purpose 359 IPv6 Address Block", RFC 4773, December 2006. 361 [RFC5736] Huston, G., Cotton, M., and L. Vegoda, "IANA IPv4 Special 362 Purpose Address Registry", RFC 5736, January 2010. 364 7.2. Informative References 366 [DhcpRequestParams] 367 OpenFlow, "OpenFlow Switch Specification", February 2011, 368 . 371 [I-D.chen-pcp-mobile-deployment] 372 Chen, G., Cao, Z., Boucadair, M., Ales, V., and L. 373 Thiebaut, "Analysis of Port Control Protocol in Mobile 374 Network", draft-chen-pcp-mobile-deployment-04 (work in 375 progress), July 2013. 377 [I-D.ietf-dhc-container-opt] 378 Droms, R. and R. Penno, "Container Option for Server 379 Configuration", draft-ietf-dhc-container-opt-07 (work in 380 progress), April 2013. 382 [I-D.ietf-pcp-base] 383 Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. 384 Selkirk, "Port Control Protocol (PCP)", 385 draft-ietf-pcp-base-29 (work in progress), November 2012. 387 [I-D.ietf-pcp-dhcp] 388 Boucadair, M., Penno, R., and D. Wing, "DHCP Options for 389 the Port Control Protocol (PCP)", draft-ietf-pcp-dhcp-08 390 (work in progress), August 2013. 392 Appendix A. Problems with Other Discovery methods 394 Several algorithms have been specified that allows PCP Client to 395 discover the PCP Servers on a network . However, each of this 396 approaches has technical or operational issues that will hinder the 397 fast deployment of PCP. 399 A.1. DHCP PCP Options 401 There are two problems with DHCP Options: DHCP Server on Home 402 Gateways (HGW) and Operating Systems DHCP clients 404 Currently what the HGW does with the options it receives from the ISP 405 is not standardized in any general way. As a matter of practice, the 406 HGW is most likely to use its own customer-LAN-facing IP address for 407 the DNS server address. As for other options, it's free to offer the 408 same values to the client, offer no value at all, or offer its own IP 409 address if that makes sense, as it does (sort of) for DNS. 411 In scenarios where PCP Server resides on ISP network and is intended 412 to work with arbitrary home gateways that don't know they are being 413 used in a PCP context, that won't work, because there's no reason to 414 think that the HGW will even request the option from the DHCP server, 415 much less offer the value it gets from the server on the customer- 416 facing LAN. There is work on the DHC WG to overcome some of these 417 limitations [I-D.ietf-dhc-container-opt] but in terms of deployment 418 it also needs HGW to be upgraded. 420 The problems with Operating Systems is that even if DHCP PCP Option 421 were made available to customer-facing LAN, host stack DHCP 422 enhancements are required to process or request new DHCP PCP option. 423 One exception is Windows [DhcpRequestParams] 425 Finally, in the case of IPv6 there are networks where there is DHCPv6 426 infrastructure at all or some hosts do not have a DHCPv6 client. 428 A.2. Default Router 430 If PCP server does not reside in first hop router, whether because 431 subscriber has a existing home router or in the case of Wireless 432 Networks (3G, LTE) [I-D.chen-pcp-mobile-deployment], trying to send a 433 request to default router will not work. 435 A.3. User Input 437 A regular subscriber can not be expected to input IP address of PCP 438 Server or network domain name. Moreover, user can be at a Wi-Fi 439 hotspot, Hotel or related. Therefore relying on user input is not 440 reliable. 442 A.4. Domain Name System Based 444 There are three separate category of problems with NAPTR [RFC3958] 446 1. End Points: It relies on PCP client determining the domain name 447 and supporting certain DNS queries 449 2. DNS Servers: DNS server need to be provisioned with the necessary 450 records 452 3. CPEs: CPEs might interfere with DNS queries and the DHCP domain 453 name option conveyed by ISP that could be used to bootstrap NAPTR 454 might not be relayed to home network. 456 Authors' Addresses 458 Sebastian Kiesel 459 University of Stuttgart Computing Center 460 Allmandring 30 461 Stuttgart 70550 462 Germany 464 Email: ietf-pcp@skiesel.de 465 URI: http://www.rus.uni-stuttgart.de/nks/ 467 Reinaldo Penno 468 Cisco Systems 469 170 West Tasman Dr 470 San Jose CA 471 USA 473 Email: repenno@cisco.com