idnits 2.17.1 draft-ietf-pcp-anycast-02.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 128: '...over PCP servers SHOULD first send a P...' RFC 2119 keyword, line 150: '... The PCP client SHOULD select the PCP...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 25, 2014) is 3503 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? Summary: 4 errors (**), 0 flaws (~~), 1 warning (==), 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: February 26, 2015 Cisco Systems, Inc. 6 S. Cheshire 7 Apple 8 August 25, 2014 10 PCP Anycast Address 11 draft-ietf-pcp-anycast-02 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 February 26, 2015. 39 Copyright Notice 41 Copyright (c) 2014 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 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 62 4.1. Registration of IPv4 Special Purpose Address . . . . . . . 6 63 4.2. Registration of IPv6 Special Purpose Address . . . . . . . 7 64 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 65 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 66 6.1. Normative References . . . . . . . . . . . . . . . . . . . 10 67 6.2. Informative References . . . . . . . . . . . . . . . . . . 10 68 Appendix A. Discussion of other PCP Discovery methods . . . . . . 12 69 A.1. Default Router . . . . . . . . . . . . . . . . . . . . . . 12 70 A.2. DHCP PCP Options . . . . . . . . . . . . . . . . . . . . . 12 71 A.3. User Input . . . . . . . . . . . . . . . . . . . . . . . . 13 72 A.4. Domain Name System Based . . . . . . . . . . . . . . . . . 13 73 A.5. Addressing only based on Destination Port . . . . . . . . 13 74 Appendix B. Discussion of IP Anycast Address usage for PCP . . . 15 75 B.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 15 76 B.2. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . 15 77 B.3. Historical Objections to Anycast . . . . . . . . . . . . . 15 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 80 1. Introduction 82 The Port Control Protocol (PCP) [RFC6887] provides a mechanism to 83 control how incoming packets are forwarded by upstream devices such 84 as Network Address Translator IPv6/IPv4 (NAT64), Network Address 85 Translator IPv4/IPv4 (NAT44), IPv6 and IPv4 firewall devices, and a 86 mechanism to reduce application keep alive traffic. 88 The PCP document [RFC6887] specifies the message formats used, but 89 the address to which a client sends its request is either assumed to 90 be the default router (which is appropriate in a typical single-link 91 residential network) or has to be configured otherwise via some 92 external mechanism, such as DHCP. The properties and drawbacks of 93 various mechanisms are discussed in Appendix A. 95 This document follows a different approach: it establishes a well- 96 known anycast address for the PCP Server. PCP clients are expected 97 to send requests to this address during the PCP Server discovery 98 process. A PCP Server configured with the anycast address could 99 optionally redirect or return a list of unicast PCP Servers to the 100 client. For a more extensive discussion on anycasting see 101 Appendix B. 103 The benefit of using an anycast address is simplicity and 104 reliability. In an example deployment scenario: 106 1. A network administrator installs a PCP-capable NAT. 108 2. An end user (who may be the same person) runs a PCP-enabled 109 application. This application can implement PCP with purely 110 user-level code -- no operating system support is required. 112 3. This PCP-enabled application sends its PCP request to the PCP 113 anycast address. This packet travels through the network like 114 any other, without any special support from DNS, DHCP, other 115 routers, or anything else, until it reaches the PCP-capable NAT, 116 which receives it, handles it, and sends back a reply. 118 Using the PCP anycast address, the only two things that need to be 119 deployed in the network are the two things that actually use PCP: The 120 PCP-capable NAT, and the PCP-enabled application. Nothing else in 121 the network needs to be changed or upgraded, and nothing needs to be 122 configured, including the PCP client. 124 2. PCP Server Discovery based on well-known IP Address 126 2.1. PCP Discovery Client behavior 128 PCP Clients that need to discover PCP servers SHOULD first send a PCP 129 request to the configured PCP server or to the default router, as 130 described in Section 8.1 of [RFC6887]. However, differing from 131 Section 8.1.1 of [RFC6887], MRC (Maximum Retransmission Count) is set 132 to 4. Trying the configured PCP server or the default router first 133 is important because in the case of cascaded PCP Servers, all of them 134 need to be discovered in order of hop distance from the client. 136 If contacting the configured PCP server or the default router does 137 not succeed with this first approach, the PCP client re-initializes 138 RT based on IRT, and it resets MRC to its "normal" value (0 unless a 139 different value is requested by the application), as described in 140 Section 8.1.1 of [RFC6887]. Then, the PCP client repeatedly 141 transmits a message to the configured PCP server or the default 142 router, waits RT, transmits a message to the anycast address, waits 143 RT, recalculates RT as specified in Section 8.1.1 of [RFC6887], and 144 starts again with a retransmission to the configured PCP server or 145 the default router. This procedure continues until a reply is 146 received or the PCP client is no longer interested in the PCP 147 transaction or the message exchange is considered to have failed 148 according to MRC/MRD. 150 The PCP client SHOULD select the PCP anycast address to be of the 151 same IP address family as its requested PCP mapping, i.e., the 152 address family of the Requested Internal IP Address. 154 2.2. PCP Discovery Server behavior 156 A PCP Server can be configured to listen on the anycast address for 157 incoming PCP requests. 159 PCP responses are sent from that same IANA-assigned address (see Page 160 5 of [RFC1546]). 162 3. Deployment Considerations 164 There are known limitations when there is more than one PCP server 165 and asymmetric routing, or similar scenarios. Mechanisms to deal 166 with those situations, such as state synchronization between PCP 167 servers, are beyond the scope of this document. 169 For general recommendations regarding operation of anycast services 170 see [RFC4786]. 172 4. IANA Considerations 174 4.1. Registration of IPv4 Special Purpose Address 176 IANA is requested to register a single IPv4 address in the IANA IPv4 177 Special Purpose Address Registry [RFC5736]. 179 [RFC5736] itemizes some information to be recorded for all 180 designations: 182 1. The designated address prefix. 184 Prefix: TBD by IANA. Prefix length: /32 186 2. The RFC that called for the IANA address designation. 188 This document. 190 3. The date the designation was made. 192 TBD. 194 4. The date the use designation is to be terminated (if specified 195 as a limited-use designation). 197 Unlimited. No termination date. 199 5. The nature of the purpose of the designated address (e.g., 200 unicast experiment or protocol service anycast). 202 protocol service anycast. 204 6. For experimental unicast applications and otherwise as 205 appropriate, the registry will also identify the entity and 206 related contact details to whom the address designation has been 207 made. 209 N/A. 211 7. The registry will also note, for each designation, the 212 intended routing scope of the address, indicating whether the 213 address is intended to be routable only in scoped, local, or 214 private contexts, or whether the address prefix is intended to be 215 routed globally. 217 Typically used within a network operator's network domain, but in 218 principle globally routable. 220 8. The date in the IANA registry is the date of the IANA action, 221 i.e., the day IANA records the allocation. 223 TBD. 225 4.2. Registration of IPv6 Special Purpose Address 227 IANA is requested to register a single IPv6 address in the IANA IPv6 228 Special Purpose Address Block [RFC4773]. 230 [RFC4773] itemizes some information to be recorded for all 231 designations: 233 1. The designated address prefix. 235 Prefix: TBD by IANA. Prefix length: /128 237 2. The RFC that called for the IANA address designation. 239 This document. 241 3. The date the designation was made. 243 TBD. 245 4. The date the use designation is to be terminated (if specified 246 as a limited-use designation). 248 Unlimited. No termination date. 250 5. The nature of the purpose of the designated address (e.g., 251 unicast experiment or protocol service anycast). 253 protocol service anycast. 255 6. For experimental unicast applications and otherwise as 256 appropriate, the registry will also identify the entity and 257 related contact details to whom the address designation has been 258 made. 260 N/A. 262 7. The registry will also note, for each designation, the 263 intended routing scope of the address, indicating whether the 264 address is intended to be routable only in scoped, local, or 265 private contexts, or whether the address prefix is intended to be 266 routed globally. 268 Typically used within a network operator's network domain, but in 269 principle globally routable. 271 8. The date in the IANA registry is the date of the IANA action, 272 i.e., the day IANA records the allocation. 274 TBD. 276 5. Security Considerations 278 In a network without any border gateway, NAT or firewall that is 279 aware of the PCP anycast address, outgoing PCP requests could leak 280 out onto the external Internet, possibly revealing information about 281 internal devices. 283 Using an IANA-assigned well-known PCP anycast address enables border 284 gateways to block such outgoing packets. In the default-free zone, 285 routers should be configured to drop such packets. Such 286 configuration can occur naturally via BGP messages advertising that 287 no route exists to said address. 289 Sensitive clients that do not wish to leak information about their 290 presesence can set an IP TTL on their PCP requests that limits how 291 far they can travel into the public Internet. 293 6. References 295 6.1. Normative References 297 [RFC1546] Partridge, C., Mendez, T., and W. Milliken, "Host 298 Anycasting Service", RFC 1546, November 1993. 300 [RFC3958] Daigle, L. and A. Newton, "Domain-Based Application 301 Service Location Using SRV RRs and the Dynamic Delegation 302 Discovery Service (DDDS)", RFC 3958, January 2005. 304 [RFC4773] Huston, G., "Administration of the IANA Special Purpose 305 IPv6 Address Block", RFC 4773, December 2006. 307 [RFC5736] Huston, G., Cotton, M., and L. Vegoda, "IANA IPv4 Special 308 Purpose Address Registry", RFC 5736, January 2010. 310 [RFC6887] Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. 311 Selkirk, "Port Control Protocol (PCP)", RFC 6887, 312 April 2013. 314 6.2. Informative References 316 [DNSDisc] Hagino, J. and D. Thaler, "Analysis of DNS Server 317 Discovery Mechanisms for IPv6", 318 draft-ietf-ipngwg-dns-discovery-01 (work in progress), 319 November 2001. 321 [DhcpRequestParams] 322 OpenFlow, "OpenFlow Switch Specification", February 2011, 323 . 326 [I-D.chen-pcp-mobile-deployment] 327 Chen, G., Cao, Z., Boucadair, M., Ales, V., and L. 328 Thiebaut, "Analysis of Port Control Protocol in Mobile 329 Network", draft-chen-pcp-mobile-deployment-04 (work in 330 progress), July 2013. 332 [I-D.ietf-dhc-container-opt] 333 Droms, R. and R. Penno, "Container Option for Server 334 Configuration", draft-ietf-dhc-container-opt-07 (work in 335 progress), April 2013. 337 [I-D.ietf-pcp-dhcp] 338 Boucadair, M., Penno, R., and D. Wing, "DHCP Options for 339 the Port Control Protocol (PCP)", draft-ietf-pcp-dhcp-13 340 (work in progress), April 2014. 342 [RFC4786] Abley, J. and K. Lindqvist, "Operation of Anycast 343 Services", BCP 126, RFC 4786, December 2006. 345 Appendix A. Discussion of other PCP Discovery methods 347 Several algorithms have been specified that allows PCP Client to 348 discover the PCP Servers on a network . However, each of this 349 approaches has technical or operational issues that will hinder the 350 fast deployment of PCP. 352 A.1. Default Router 354 The PCP specification allows one mode of operation in which the PCP 355 client sends its requests to the default router. This approach is 356 appropriate in a typical single-link residential network but has 357 limitations in more complex network topologies. 359 If PCP server does not reside in first hop router, whether because 360 subscriber has a existing home router or in the case of Wireless 361 Networks (3G, LTE) [I-D.chen-pcp-mobile-deployment], trying to send a 362 request to default router will not work. 364 A.2. DHCP PCP Options 366 One general drawback of relying on external configuration mechanisms, 367 such as DHCP [I-D.ietf-pcp-dhcp], is that it creates an external 368 dependency on another piece of network infrastructure which must be 369 configured with the right address for PCP to work. In some 370 environments the staff managing the DHCP servers may not be the same 371 staff managing the NAT gateways, and in any case, constantly keeping 372 the DHCP server address information up to date as NAT gateways are 373 added, removed, or reconfigured, is burdensome. 375 Another drawback of relying on DHCP for configuration is that at 376 least one significant target deployment environments for PCP -- 377 namely 3GPP for mobile telephones -- does not use DHCP. 379 There are two problems with DHCP Options: DHCP Server on Home 380 Gateways (HGW) and Operating Systems DHCP clients 382 Currently what the HGW does with the options it receives from the ISP 383 is not standardized in any general way. As a matter of practice, the 384 HGW is most likely to use its own customer-LAN-facing IP address for 385 the DNS server address. As for other options, it's free to offer the 386 same values to the client, offer no value at all, or offer its own IP 387 address if that makes sense, as it does (sort of) for DNS. 389 In scenarios where PCP Server resides on ISP network and is intended 390 to work with arbitrary home gateways that don't know they are being 391 used in a PCP context, that won't work, because there's no reason to 392 think that the HGW will even request the option from the DHCP server, 393 much less offer the value it gets from the server on the customer- 394 facing LAN. There is work on the DHC WG to overcome some of these 395 limitations [I-D.ietf-dhc-container-opt] but in terms of deployment 396 it also needs HGW to be upgraded. 398 The problems with Operating Systems is that even if DHCP PCP Option 399 were made available to customer-facing LAN, host stack DHCP 400 enhancements are required to process or request new DHCP PCP option. 401 One exception is Windows [DhcpRequestParams] 403 Finally, in the case of IPv6 there are networks where there is DHCPv6 404 infrastructure at all or some hosts do not have a DHCPv6 client. 406 A.3. User Input 408 A regular subscriber can not be expected to input IP address of PCP 409 Server or network domain name. Moreover, user can be at a Wi-Fi 410 hotspot, Hotel or related. Therefore relying on user input is not 411 reliable. 413 A.4. Domain Name System Based 415 There are three separate category of problems with NAPTR [RFC3958] 417 1. End Points: It relies on PCP client determining the domain name 418 and supporting certain DNS queries 420 2. DNS Servers: DNS server need to be provisioned with the necessary 421 records 423 3. CPEs: CPEs might interfere with DNS queries and the DHCP domain 424 name option conveyed by ISP that could be used to bootstrap NAPTR 425 might not be relayed to home network. 427 A.5. Addressing only based on Destination Port 429 One design option that was considered for Apple's NAT gateways was to 430 have the NAT gateway simply handle and respond to all packets 431 addressed to UDP port 5351, regardless of the destination address in 432 the packet. Since the device is a NAT gateway, it already examines 433 every packet in order to rewrite port numbers, so also detecting 434 packets addressed to UDP port 5351 is not a significant additional 435 burden. Also, since this device is a NAT gateway which rewrites port 436 numbers, any attempt by a client to talk *though* this first NAT 437 gateway to create mappings in some second upstream NAT gateway is 438 futile and pointless. Any mappings created in the second NAT gateway 439 are useful to the client only if there are also corresponding 440 mappings created in the first NAT gateway. Consequently, there is no 441 case where it is useful for PCP requests to pass transparently 442 through the first PCP-aware NAT gateway on their way to the second 443 PCP-aware NAT gateway. In all cases, for useful connectivity to be 444 established, the PCP request must be handled by the first NAT 445 gateway, and then the first NAT gateway generates a corresponding new 446 upstream request to establish a mapping in the second NAT gateway. 447 (This process can be repeated recursively for as many times as 448 necessary for the depth of nesting of NAT gateways; this is 449 transparent to the client device.) 451 Appendix B. Discussion of IP Anycast Address usage for PCP 453 B.1. Motivation 455 The two issues identified in Appendix A.5 result in the following 456 related observations: the PCP client may not *know* what destination 457 address to use in its PCP request packets; the PCP server doesn't 458 *care* what destination address is in the PCP request packets. 460 Given that the devices neither need to know nor care what destination 461 address goes in the packet, all we need to do is pick one and use it. 462 It's little more than a placeholder in the IP header. Any globally 463 routable unicast address will do. Since this address is one that 464 automatically routes its packet to the closest on-path device that 465 implements the desired functionality, it is an anycast address. 467 B.2. Scenarios 469 In the simple case where the first-hop router is also the NAT gateway 470 (as is common in a typical single-link residential network), sending 471 to the PCP anycast address is equivalent to sending to the client's 472 default router, as specified in the PCP base document [RFC6887]. 474 In the case of a larger corporate network, where there may be several 475 internal routed subnets and one or more border NAT gateway(s) 476 connecting to the rest of the Internet, sending to the PCP anycast 477 address has the interesting property that it magically finds the 478 right border NAT gateway for that client. Since we posit that other 479 network infrastructure does not need (and should not have) any 480 special knowledge of PCP (or its anycast address) this means that to 481 other non-NAT routers, the PCP anycast address will look like any 482 other unicast destination address on the public Internet, and 483 consequently the packet will be forwarded as for any other packet 484 destined to the public Internet, until it reaches a NAT or firewall 485 device that is aware of the PCP anycast address. This will result in 486 the packet naturally arriving the NAT gateway that handles this 487 client's outbound traffic destined to the public Internet, which is 488 exactly the NAT gateway that the client wishes to communicate with 489 when managing its port mappings. 491 B.3. Historical Objections to Anycast 493 In March 2001 a draft document entitled "Analysis of DNS Server 494 Discovery Mechanisms for IPv6" [DNSDisc] proposed using anycast to 495 discover DNS servers, a proposal that was subsequently abandoned in 496 later revisions of that draft document. 498 There are legitimate reasons why using anycast to discover DNS 499 servers is not compelling, mainly because it requires explicit 500 configuration of routing tables to direct those anycast packets to 501 the desired DNS server. However, DNS server discovery is very 502 different to NAT gateway discovery. A DNS server is something a 503 client explicitly talks to, via IP address. The DNS server may be 504 literally anywhere on the Internet. Various reasons make anycast an 505 uncompelling technique for DNS server discovery: 507 o DNS is a pure application-layer protocol, running over UDP. 509 o On an operating system without appropriate support for configuring 510 anycast addresses, a DNS server would have to use something like 511 Berkeley Packet Filter (BPF) to snoop on received packets to 512 intercept DNS requests, which is inelegant and inefficient. 514 o Without appropriate routing changes elsewhere in the network, 515 there's no reason to assume that packets sent to that anycast 516 address would even make it to the desired DNS server machine. 517 This places an addition configuration burden on the network 518 administrators, to install appropriate routing table entries to 519 direct packets to the desired DNS server machine. 521 In contrast, a NAT gateway is something a client's packets stumble 522 across as they try to leave the local network and head out onto the 523 public Internet. The NAT gateway has to be on the path those packets 524 naturally take or it can't perform its NAT functions. As a result, 525 the objections to using anycast for DNS server discovery do not apply 526 to PCP: 528 o No routing changes are needed (or desired) elsewhere in the local 529 network, because the whole *point* of using anycast is that we 530 want the client's PCP request packet to take the same forwarding 531 path through the network as a TCP SYN to any other remote 532 destination address, because we want the *same* NAT gateway that 533 would have made a mapping in response to receiving an outbound TCP 534 SYN packet from the client to be the the one that makes a mapping 535 in response to receiving a PCP request packet from the client. 537 o A NAT engine is already snooping on (and rewriting) every packet 538 it forwards. As part of that snooping it could trivially look for 539 packets addressed to the PCP UDP port and process them locally 540 (just like the local processing it already does when it sees an 541 outbound TCP SYN packet). 543 Authors' Addresses 545 Sebastian Kiesel 546 University of Stuttgart Information Center 547 Networks and Communication Systems Department 548 Allmandring 30 549 Stuttgart 70550 550 Germany 552 Email: ietf-pcp@skiesel.de 554 Reinaldo Penno 555 Cisco Systems, Inc. 556 San Jose, CA 557 US 559 Phone: 560 Fax: 561 Email: repenno@cisco.com 562 URI: 564 Stuart Cheshire 565 Apple Inc. 566 1 Infinite Loop 567 Cupertino, California 95014 568 USA 570 Phone: +1 408 974 3207 571 Email: cheshire@apple.com