idnits 2.17.1 draft-ietf-pcp-anycast-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 130: '...over PCP servers SHOULD first send a P...' RFC 2119 keyword, line 133: '...nt. The PCP client then SHOULD send a...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 17, 2013) is 3845 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) ** Downref: Normative reference to an Informational RFC: RFC 1546 ** Obsolete normative reference: RFC 4773 (Obsoleted by RFC 6890) ** Obsolete normative reference: RFC 5736 (Obsoleted by RFC 6890) -- No information found for draft-ietf-ipngwg-dns-discovery - is the name correct? == Outdated reference: A later version (-13) exists of draft-ietf-pcp-dhcp-08 Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PCP working group S. Kiesel 3 Internet-Draft University of Stuttgart 4 Intended status: Standards Track R. Penno 5 Expires: April 20, 2014 Cisco Systems, Inc. 6 S. Cheshire 7 Apple 8 October 17, 2013 10 PCP Anycast Address 11 draft-ietf-pcp-anycast-00 13 Abstract 15 The Port Control Protocol (PCP) Anycast Address enables PCP clients 16 to transmit signaling messages to their closest on-path NAT, 17 Firewall, or other middlebox, without having to learn the IP address 18 of that middlebox via some external channel. This document 19 establishes one well-known IPv4 address and one well-known IPv6 20 address to be used as PCP Anycast Address. 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on April 20, 2014. 39 Copyright Notice 41 Copyright (c) 2013 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. PCP Server Discovery based on well-known IP Address . . . . . 4 58 2.1. PCP Discovery Client behavior . . . . . . . . . . . . . . 4 59 2.2. PCP Discovery Server behavior . . . . . . . . . . . . . . 4 60 3. Deployment Considerations . . . . . . . . . . . . . . . . . . 5 61 3.1. Multiple PCP Servers, Symmetric Routing . . . . . . . . . 5 62 3.2. Multiple PCP Servers, Asymetric Routing . . . . . . . . . 5 63 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 64 4.1. Registration of IPv4 Special Purpose Address . . . . . . . 6 65 4.2. Registration of IPv6 Special Purpose Address . . . . . . . 7 66 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 67 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 68 6.1. Normative References . . . . . . . . . . . . . . . . . . . 10 69 6.2. Informative References . . . . . . . . . . . . . . . . . . 10 70 Appendix A. Discussion of other PCP Discovery methods . . . . . . 11 71 A.1. Default Router . . . . . . . . . . . . . . . . . . . . . . 11 72 A.2. DHCP PCP Options . . . . . . . . . . . . . . . . . . . . . 11 73 A.3. User Input . . . . . . . . . . . . . . . . . . . . . . . . 12 74 A.4. Domain Name System Based . . . . . . . . . . . . . . . . . 12 75 A.5. Addressing only based on Destination Port . . . . . . . . 12 76 Appendix B. Discussion of IP Anycast Address usage for PCP . . . 14 77 B.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 14 78 B.2. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . 14 79 B.3. Historical Objections to Anycast . . . . . . . . . . . . . 14 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 82 1. Introduction 84 The Port Control Protocol (PCP) [RFC6887] provides a mechanism to 85 control how incoming packets are forwarded by upstream devices such 86 as Network Address Translator IPv6/IPv4 (NAT64), Network Address 87 Translator IPv4/IPv4 (NAT44), IPv6 and IPv4 firewall devices, and a 88 mechanism to reduce application keep alive traffic. 90 The PCP document [RFC6887] specifies the message formats used, but 91 the address to which a client sends its request is either assumed to 92 be the default router (which is appropriate in a typical single-link 93 residential network) or has to be configured otherwise via some 94 external mechanism, such as DHCP. The properties and drawbacks of 95 various mechanisms are discussed in Appendix A. 97 This document follows a different approach: it establishes a well- 98 known anycast address for the PCP Server. PCP clients are expected 99 to send requests to this address during the PCP Server discovery 100 process. A PCP Server configured with the anycast address could 101 optionally redirect or return a list of unicast PCP Servers to the 102 client. For a more extensive discussion on anycasting see 103 Appendix B. 105 The benefit of using an anycast address is simplicity and 106 reliability. In an example deployment scenario: 108 1. A network administrator installs a PCP-capable NAT. 110 2. An end user (who may be the same person) runs a PCP-enabled 111 application. This application can implement PCP with purely 112 user-level code -- no operating system support is required. 114 3. This PCP-enabled application sends its PCP request to the PCP 115 anycast address. This packet travels through the network like 116 any other, without any special support from DNS, DHCP, other 117 routers, or anything else, until it reaches the PCP-capable NAT, 118 which receives it, handles it, and sends back a reply. 120 Using the PCP anycast address, the only two things that need to be 121 deployed in the network are the two things that actually use PCP: The 122 PCP-capable NAT, and the PCP-enabled application. Nothing else in 123 the network needs to be changed or upgraded, and nothing needs to be 124 configured, including the PCP client. 126 2. PCP Server Discovery based on well-known IP Address 128 2.1. PCP Discovery Client behavior 130 PCP Clients that need to discover PCP servers SHOULD first send a PCP 131 request to its default router. This is important because in the case 132 of cascaded PCP Servers, all of them need to be discovered in order 133 of hop distance from the client. The PCP client then SHOULD send a 134 PCP request to the anycast address. PCP Clients must be prepared to 135 receive an error and try other discovery methods. 137 2.2. PCP Discovery Server behavior 139 PCP Server can be configured to listen on the anycast address for 140 incoming PCP requests. 142 PCP responses are sent from that same IANA-assigned address (see Page 143 5 of [RFC1546]). 145 3. Deployment Considerations 147 Network operators should install one or more PCP Servers as specified 148 above. Depending on the network deployment scenario they may use IP 149 routing tables, or other suitable mechanisms to direct PCP requests 150 to one of these servers. 152 3.1. Multiple PCP Servers, Symmetric Routing 154 In the case of symmetric routing all inbound and outbound packets 155 from a PCP client traverse the same PCP Server or controlled device. 156 Multiple PCP Servers sharing an anycast address in a symmetric 157 routing scenario are used for two purposes: ease of network 158 configuration and redundancy. In the case of redundancy, if there is 159 a network or routing change a PCP client might start interacting with 160 a different PCP Server sharing the same anycast address. From a PCP 161 Client point of view this would be the same as a PCP Server reboot 162 and a PCP Client could find out about it by examining the Epoch field 163 during the next PCP response or ANNOUNCE message. 165 3.2. Multiple PCP Servers, Asymetric Routing 167 In the case of asymmetric routing inbound packets from a PCP client 168 traverse a different PCP Server or controlled device than outbound 169 packets. If these PCP Servers are firewalls, the PCP client would 170 need to create mappings on both or rely on state-synch between them 171 in order to properly communicate with other hosts. But if these PCP 172 Servers share an anycast address the PCP Client will create mappings 173 in only one, when in fact should create mappings on both of them. 175 Therefore in order to support this scenario the firewalls need to 176 synch state, alleviating the development on the client, or 177 alternatively a new option could be used that informs the client of 178 the unicast address of each PCP Servers, alleviating the development 179 on the PCP Server or Firewall. 181 At the time of this writing there is no clear consensus on the PCP WG 182 if a new option is desirable. Current deployments rely on state 183 synch between Firewall devices to solve assymetric routing issues. 184 If those devices are upgraded to be controlled by PCP Servers it 185 might be desirable to maintain the client simple. 187 4. IANA Considerations 189 4.1. Registration of IPv4 Special Purpose Address 191 IANA is requested to register a single IPv4 address in the IANA IPv4 192 Special Purpose Address Registry [RFC5736]. 194 [RFC5736] itemizes some information to be recorded for all 195 designations: 197 1. The designated address prefix. 199 Prefix: TBD by IANA. Prefix length: /32 201 2. The RFC that called for the IANA address designation. 203 This document. 205 3. The date the designation was made. 207 TBD. 209 4. The date the use designation is to be terminated (if specified 210 as a limited-use designation). 212 Unlimited. No termination date. 214 5. The nature of the purpose of the designated address (e.g., 215 unicast experiment or protocol service anycast). 217 protocol service anycast. 219 6. For experimental unicast applications and otherwise as 220 appropriate, the registry will also identify the entity and 221 related contact details to whom the address designation has been 222 made. 224 N/A. 226 7. The registry will also note, for each designation, the 227 intended routing scope of the address, indicating whether the 228 address is intended to be routable only in scoped, local, or 229 private contexts, or whether the address prefix is intended to be 230 routed globally. 232 Typically used within a network operator's network domain, but in 233 principle globally routable. 235 8. The date in the IANA registry is the date of the IANA action, 236 i.e., the day IANA records the allocation. 238 TBD. 240 4.2. Registration of IPv6 Special Purpose Address 242 IANA is requested to register a single IPv6 address in the IANA IPv6 243 Special Purpose Address Block [RFC4773]. 245 [RFC4773] itemizes some information to be recorded for all 246 designations: 248 1. The designated address prefix. 250 Prefix: TBD by IANA. Prefix length: /128 252 2. The RFC that called for the IANA address designation. 254 This document. 256 3. The date the designation was made. 258 TBD. 260 4. The date the use designation is to be terminated (if specified 261 as a limited-use designation). 263 Unlimited. No termination date. 265 5. The nature of the purpose of the designated address (e.g., 266 unicast experiment or protocol service anycast). 268 protocol service anycast. 270 6. For experimental unicast applications and otherwise as 271 appropriate, the registry will also identify the entity and 272 related contact details to whom the address designation has been 273 made. 275 N/A. 277 7. The registry will also note, for each designation, the 278 intended routing scope of the address, indicating whether the 279 address is intended to be routable only in scoped, local, or 280 private contexts, or whether the address prefix is intended to be 281 routed globally. 283 Typically used within a network operator's network domain, but in 284 principle globally routable. 286 8. The date in the IANA registry is the date of the IANA action, 287 i.e., the day IANA records the allocation. 289 TBD. 291 5. Security Considerations 293 In a network without any border gateway, NAT or firewall that is 294 aware of the PCP anycast address, outgoing PCP requests could leak 295 out onto the external Internet, possibly revealing information about 296 internal devices. 298 Using an IANA-assigned well-known PCP anycast address enables border 299 gateways to block such outgoing packets. In the default-free zone, 300 routers should be configured to drop such packets. Such 301 configuration can occur naturally via BGP messages advertising that 302 no route exists to said address. 304 Sensitive clients that do not wish to leak information about their 305 presesence can set an IP TTL on their PCP requests that limits how 306 far they can travel into the public Internet. 308 6. References 310 6.1. Normative References 312 [RFC1546] Partridge, C., Mendez, T., and W. Milliken, "Host 313 Anycasting Service", RFC 1546, November 1993. 315 [RFC3958] Daigle, L. and A. Newton, "Domain-Based Application 316 Service Location Using SRV RRs and the Dynamic Delegation 317 Discovery Service (DDDS)", RFC 3958, January 2005. 319 [RFC4773] Huston, G., "Administration of the IANA Special Purpose 320 IPv6 Address Block", RFC 4773, December 2006. 322 [RFC5736] Huston, G., Cotton, M., and L. Vegoda, "IANA IPv4 Special 323 Purpose Address Registry", RFC 5736, January 2010. 325 [RFC6887] Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. 326 Selkirk, "Port Control Protocol (PCP)", RFC 6887, 327 April 2013. 329 6.2. Informative References 331 [DNSDisc] Hagino, J. and D. Thaler, "Analysis of DNS Server 332 Discovery Mechanisms for IPv6", 333 draft-ietf-ipngwg-dns-discovery-01 (work in progress), 334 November 2001. 336 [DhcpRequestParams] 337 OpenFlow, "OpenFlow Switch Specification", February 2011, 338 . 341 [I-D.chen-pcp-mobile-deployment] 342 Chen, G., Cao, Z., Boucadair, M., Ales, V., and L. 343 Thiebaut, "Analysis of Port Control Protocol in Mobile 344 Network", draft-chen-pcp-mobile-deployment-04 (work in 345 progress), July 2013. 347 [I-D.ietf-dhc-container-opt] 348 Droms, R. and R. Penno, "Container Option for Server 349 Configuration", draft-ietf-dhc-container-opt-07 (work in 350 progress), April 2013. 352 [I-D.ietf-pcp-dhcp] 353 Boucadair, M., Penno, R., and D. Wing, "DHCP Options for 354 the Port Control Protocol (PCP)", draft-ietf-pcp-dhcp-08 355 (work in progress), August 2013. 357 Appendix A. Discussion of other PCP Discovery methods 359 Several algorithms have been specified that allows PCP Client to 360 discover the PCP Servers on a network . However, each of this 361 approaches has technical or operational issues that will hinder the 362 fast deployment of PCP. 364 A.1. Default Router 366 The PCP specification allows one mode of operation in which the PCP 367 client sends its requests to the default router. This approach is 368 appropriate in a typical single-link residential network but has 369 limitations in more complex network topologies. 371 If PCP server does not reside in first hop router, whether because 372 subscriber has a existing home router or in the case of Wireless 373 Networks (3G, LTE) [I-D.chen-pcp-mobile-deployment], trying to send a 374 request to default router will not work. 376 A.2. DHCP PCP Options 378 One general drawback of relying on external configuration mechanisms, 379 such as DHCP [I-D.ietf-pcp-dhcp], is that it creates an external 380 dependency on another piece of network infrastructure which must be 381 configured with the right address for PCP to work. In some 382 environments the staff managing the DHCP servers may not be the same 383 staff managing the NAT gateways, and in any case, constantly keeping 384 the DHCP server address information up to date as NAT gateways are 385 added, removed, or reconfigured, is burdensome. 387 Another drawback of relying on DHCP for configuration is that at 388 least one significant target deployment environments for PCP -- 389 namely 3GPP for mobile telephones -- does not use DHCP. 391 There are two problems with DHCP Options: DHCP Server on Home 392 Gateways (HGW) and Operating Systems DHCP clients 394 Currently what the HGW does with the options it receives from the ISP 395 is not standardized in any general way. As a matter of practice, the 396 HGW is most likely to use its own customer-LAN-facing IP address for 397 the DNS server address. As for other options, it's free to offer the 398 same values to the client, offer no value at all, or offer its own IP 399 address if that makes sense, as it does (sort of) for DNS. 401 In scenarios where PCP Server resides on ISP network and is intended 402 to work with arbitrary home gateways that don't know they are being 403 used in a PCP context, that won't work, because there's no reason to 404 think that the HGW will even request the option from the DHCP server, 405 much less offer the value it gets from the server on the customer- 406 facing LAN. There is work on the DHC WG to overcome some of these 407 limitations [I-D.ietf-dhc-container-opt] but in terms of deployment 408 it also needs HGW to be upgraded. 410 The problems with Operating Systems is that even if DHCP PCP Option 411 were made available to customer-facing LAN, host stack DHCP 412 enhancements are required to process or request new DHCP PCP option. 413 One exception is Windows [DhcpRequestParams] 415 Finally, in the case of IPv6 there are networks where there is DHCPv6 416 infrastructure at all or some hosts do not have a DHCPv6 client. 418 A.3. User Input 420 A regular subscriber can not be expected to input IP address of PCP 421 Server or network domain name. Moreover, user can be at a Wi-Fi 422 hotspot, Hotel or related. Therefore relying on user input is not 423 reliable. 425 A.4. Domain Name System Based 427 There are three separate category of problems with NAPTR [RFC3958] 429 1. End Points: It relies on PCP client determining the domain name 430 and supporting certain DNS queries 432 2. DNS Servers: DNS server need to be provisioned with the necessary 433 records 435 3. CPEs: CPEs might interfere with DNS queries and the DHCP domain 436 name option conveyed by ISP that could be used to bootstrap NAPTR 437 might not be relayed to home network. 439 A.5. Addressing only based on Destination Port 441 One design option that was considered for Apple's NAT gateways was to 442 have the NAT gateway simply handle and respond to all packets 443 addressed to UDP port 5351, regardless of the destination address in 444 the packet. Since the device is a NAT gateway, it already examines 445 every packet in order to rewrite port numbers, so also detecting 446 packets addressed to UDP port 5351 is not a significant additional 447 burden. Also, since this device is a NAT gateway which rewrites port 448 numbers, any attempt by a client to talk *though* this first NAT 449 gateway to create mappings in some second upstream NAT gateway is 450 futile and pointless. Any mappings created in the second NAT gateway 451 are useful to the client only if there are also corresponding 452 mappings created in the first NAT gateway. Consequently, there is no 453 case where it is useful for PCP requests to pass transparently 454 through the first PCP-aware NAT gateway on their way to the second 455 PCP-aware NAT gateway. In all cases, for useful connectivity to be 456 established, the PCP request must be handled by the first NAT 457 gateway, and then the first NAT gateway generates a corresponding new 458 upstream request to establish a mapping in the second NAT gateway. 459 (This process can be repeated recursively for as many times as 460 necessary for the depth of nesting of NAT gateways; this is 461 transparent to the client device.) 463 Appendix B. Discussion of IP Anycast Address usage for PCP 465 B.1. Motivation 467 The two issues identified in Appendix A.5 result in the following 468 related observations: the PCP client may not *know* what destination 469 address to use in its PCP request packets; the PCP server doesn't 470 *care* what destination address is in the PCP request packets. 472 Given that the devices neither need to know nor care what destination 473 address goes in the packet, all we need to do is pick one and use it. 474 It's little more than a placeholder in the IP header. Any globally 475 routable unicast address will do. Since this address is one that 476 automatically routes its packet to the closest on-path device that 477 implements the desired functionality, it is an anycast address. 479 B.2. Scenarios 481 In the simple case where the first-hop router is also the NAT gateway 482 (as is common in a typical single-link residential network), sending 483 to the PCP anycast address is equivalent to sending to the client's 484 default router, as specified in the PCP base document [RFC6887]. 486 In the case of a larger corporate network, where there may be several 487 internal routed subnets and one or more border NAT gateway(s) 488 connecting to the rest of the Internet, sending to the PCP anycast 489 address has the interesting property that it magically finds the 490 right border NAT gateway for that client. Since we posit that other 491 network infrastructure does not need (and should not have) any 492 special knowledge of PCP (or its anycast address) this means that to 493 other non-NAT routers, the PCP anycast address will look like any 494 other unicast destination address on the public Internet, and 495 consequently the packet will be forwarded as for any other packet 496 destined to the public Internet, until it reaches a NAT or firewall 497 device that is aware of the PCP anycast address. This will result in 498 the packet naturally arriving the NAT gateway that handles this 499 client's outbound traffic destined to the public Internet, which is 500 exactly the NAT gateway that the client wishes to communicate with 501 when managing its port mappings. 503 B.3. Historical Objections to Anycast 505 In March 2001 a draft document entitled "Analysis of DNS Server 506 Discovery Mechanisms for IPv6" [DNSDisc] proposed using anycast to 507 discover DNS servers, a proposal that was subsequently abandoned in 508 later revisions of that draft document. 510 There are legitimate reasons why using anycast to discover DNS 511 servers is not compelling, mainly because it requires explicit 512 configuration of routing tables to direct those anycast packets to 513 the desired DNS server. However, DNS server discovery is very 514 different to NAT gateway discovery. A DNS server is something a 515 client explicitly talks to, via IP address. The DNS server may be 516 literally anywhere on the Internet. Various reasons make anycast an 517 uncompelling technique for DNS server discovery: 519 o DNS is a pure application-layer protocol, running over UDP. 521 o On an operating system without appropriate support for configuring 522 anycast addresses, a DNS server would have to use something like 523 Berkeley Packet Filter (BPF) to snoop on received packets to 524 intercept DNS requests, which is inelegant and inefficient. 526 o Without appropriate routing changes elsewhere in the network, 527 there's no reason to assume that packets sent to that anycast 528 address would even make it to the desired DNS server machine. 529 This places an addition configuration burden on the network 530 administrators, to install appropriate routing table entries to 531 direct packets to the desired DNS server machine. 533 In contrast, a NAT gateway is something a client's packets stumble 534 across as they try to leave the local network and head out onto the 535 public Internet. The NAT gateway has to be on the path those packets 536 naturally take or it can't perform its NAT functions. As a result, 537 the objections to using anycast for DNS server discovery do not apply 538 to PCP: 540 o No routing changes are needed (or desired) elsewhere in the local 541 network, because the whole *point* of using anycast is that we 542 want the client's PCP request packet to take the same forwarding 543 path through the network as a TCP SYN to any other remote 544 destination address, because we want the *same* NAT gateway that 545 would have made a mapping in response to receiving an outbound TCP 546 SYN packet from the client to be the the one that makes a mapping 547 in response to receiving a PCP request packet from the client. 549 o A NAT engine is already snooping on (and rewriting) every packet 550 it forwards. As part of that snooping it could trivially look for 551 packets addressed to the PCP UDP port and process them locally 552 (just like the local processing it already does when it sees an 553 outbound TCP SYN packet). 555 Authors' Addresses 557 Sebastian Kiesel 558 University of Stuttgart Computing Center 559 Allmandring 30 560 Stuttgart 70550 561 Germany 563 Email: ietf-pcp@skiesel.de 564 URI: http://www.rus.uni-stuttgart.de/nks/ 566 Reinaldo Penno 567 Cisco Systems, Inc. 568 San Jose, CA 569 US 571 Phone: 572 Fax: 573 Email: repenno@cisco.com 574 URI: 576 Stuart Cheshire 577 Apple Inc. 578 1 Infinite Loop 579 Cupertino, California 95014 580 USA 582 Phone: +1 408 974 3207 583 Email: cheshire@apple.com