source: draft-cheshire-pcp-anycast/draft-ietf-pcp-anycast.xml @ 351

Last change on this file since 351 was 351, checked in by ietf-pcp@…, 8 years ago

add informative reference to rfc 4786 - operation of anycast services

File size: 25.6 KB
Line 
1<?xml version="1.0" encoding="US-ASCII"?>
2<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
3<?rfc toc="yes"?>
4<?rfc tocompact="yes"?>
5<?rfc tocdepth="3"?>
6<?rfc tocindent="yes"?>
7<?rfc symrefs="yes"?>
8<?rfc sortrefs="yes"?>
9<?rfc comments="yes"?>
10<?rfc inline="yes"?>
11<?rfc compact="no"?>
12<?rfc subcompact="no"?>
13<rfc category="std" docName="draft-ietf-pcp-anycast-02" ipr="trust200902">
14  <front>
15    <title abbrev="PCP Anycast Address">PCP Anycast Address</title>
16
17    <author fullname="Sebastian Kiesel" initials="S." surname="Kiesel">
18      <organization abbrev="University of Stuttgart">University of Stuttgart
19      Computing Center</organization>
20
21      <address>
22        <postal>
23          <street>Allmandring 30</street>
24
25          <city>Stuttgart</city>
26
27          <code>70550</code>
28
29          <country>Germany</country>
30        </postal>
31
32        <email>ietf-pcp@skiesel.de</email>
33
34        <uri>http://www.rus.uni-stuttgart.de/nks/</uri>
35      </address>
36    </author>
37
38    <author fullname="Reinaldo Penno" initials="R." surname="Penno">
39      <organization>Cisco Systems, Inc.</organization>
40
41      <address>
42        <postal>
43          <street/>
44
45          <city>San Jose</city>
46
47          <region>CA</region>
48
49          <code/>
50
51          <country>US</country>
52        </postal>
53
54        <phone/>
55
56        <facsimile/>
57
58        <email>repenno@cisco.com</email>
59
60        <uri/>
61      </address>
62    </author>
63
64    <author fullname="Stuart Cheshire" initials="S." surname="Cheshire">
65      <organization abbrev="Apple">Apple Inc.</organization>
66
67      <address>
68        <postal>
69          <street>1 Infinite Loop</street>
70
71          <city>Cupertino</city>
72
73          <region>California</region>
74
75          <code>95014</code>
76
77          <country>USA</country>
78        </postal>
79
80        <phone>+1 408 974 3207</phone>
81
82        <email>cheshire@apple.com</email>
83      </address>
84    </author>
85
86
87    <date year="2014"/>
88
89    <workgroup>PCP working group</workgroup>
90
91    <abstract>
92      <t>The Port Control Protocol (PCP) Anycast Address enables PCP clients to
93      transmit signaling messages to their closest on-path NAT, Firewall, or other
94      middlebox, without having to learn the IP address of that middlebox via
95      some external channel.  This document establishes one well-known
96      IPv4 address and one well-known IPv6 address to be used as
97      PCP Anycast Address.</t>
98    </abstract>
99  </front>
100
101  <middle>
102    <section anchor="intro" title="Introduction">
103
104      <t>The Port Control Protocol (PCP) <xref target="RFC6887"/>
105      provides a mechanism to control how
106      incoming packets are forwarded by upstream devices such as Network
107      Address Translator IPv6/IPv4 (NAT64), Network Address Translator
108      IPv4/IPv4 (NAT44), IPv6 and IPv4 firewall devices, and a mechanism to
109      reduce application keep alive traffic.</t>
110
111      <t>The PCP document <xref target="RFC6887"/>
112      specifies the message formats used, but the address to which a client
113      sends its request is either assumed to be the default router (which is
114      appropriate in a typical single-link residential network) or has to be
115      configured otherwise via some external mechanism, such as DHCP.
116      The properties and drawbacks of various mechanisms are discussed in
117      <xref target="appendix-alternatives"/>.</t>
118
119      <t>This document follows a different approach: it establishes a
120      well-known anycast address for the PCP Server.
121      PCP clients are expected to send requests to this
122      address during the PCP Server discovery process. A PCP Server configured
123      with the anycast address could optionally redirect or return a list of
124      unicast PCP Servers to the client. For a more extensive discussion
125      on anycasting see <xref target="appendix_anycast_discussion"/>.</t>
126
127      <t>The benefit of using an anycast address is simplicity and
128      reliability. In an example deployment scenario: <list style="numbers">
129          <t>A network administrator installs a PCP-capable NAT.</t>
130
131          <t>An end user (who may be the same person) runs a PCP-enabled
132          application. This application can implement PCP with purely
133          user-level code -- no operating system support is required.</t>
134
135          <t>This PCP-enabled application sends its PCP request to the PCP
136          anycast address. This packet travels through the network like any
137          other, without any special support from DNS, DHCP, other routers, or
138          anything else, until it reaches the PCP-capable NAT, which receives
139          it, handles it, and sends back a reply.</t>
140        </list> Using the PCP anycast address, the only two things that need
141      to be deployed in the network are the two things that actually use PCP:
142      The PCP-capable NAT, and the PCP-enabled application. Nothing else in
143      the network needs to be changed or upgraded, and nothing needs to be
144      configured, including the PCP client.</t>
145
146    </section>
147
148
149
150    <section anchor="spec"
151             title="PCP Server Discovery based on well-known IP Address">
152      <section title="PCP Discovery Client behavior">
153        <t>PCP Clients that need to discover PCP servers SHOULD first send a
154        PCP request to the configured PCP server or to the default router,
155        as described in Section 8.1 of <xref target="RFC6887"/>.  However,
156        differing from Section 8.1.1 of <xref target="RFC6887"/>, MRC
157        (Maximum Retransmission Count) is set to 4.  Trying the configured
158        PCP server or the default router first is important because in the
159        case of cascaded PCP Servers, all of them need to be discovered in
160        order of hop distance from the client. </t>
161       
162        <t>If contacting the configured PCP server or the default router
163        does not succeed within the retransmission period, the PCP client
164        re-initializes RT based on IRT, as described in Section 8.1.1 of
165        <xref target="RFC6887"/>. The PCP client sets
166        MRC to 4 and sends a PCP request to the PCP anycast address.
167        The PCP client SHOULD select the PCP anycast address to be of the
168        same IP address family as its requested PCP mapping (i.e., the
169        address family of the Requested External IP Address).</t>
170       
171        <t>If no reply
172        or an error message is received within the retransmission period,
173        the PCP client continues the whole procedure (i.e., starting again
174        with the configured PCP server or the default router) until it
175        receives a response or the client no longer wants a mapping.
176        However, after the first round, RT is no longer re-initialized.</t>
177      </section>
178
179      <section title="PCP Discovery Server behavior">
180        <t>A PCP Server can be configured to listen on the anycast address for
181        incoming PCP requests.</t>
182
183        <t>PCP responses are sent from that same IANA-assigned address (see
184        Page 5 of <xref target="RFC1546"/>).</t>
185      </section>
186    </section>
187
188    <section title="Deployment Considerations">
189        <t>There are known limitations when there is more than one
190        PCP server and asymmetric routing, or similar scenarios.
191        Mechanisms to deal with those situations, such as state
192        synchronization between PCP servers, are beyond
193        the scope of this document.</t>
194
195        <t>For general recommendations regarding operation of
196        anycast services see <xref target="RFC4786"/>.</t>
197
198    </section>
199
200    <section title="IANA Considerations">
201      <section title="Registration of IPv4 Special Purpose Address">
202        <t>IANA is requested to register a single IPv4 address in the IANA
203        IPv4 Special Purpose Address Registry <xref target="RFC5736"/>.</t>
204
205        <t><xref target="RFC5736"/> itemizes some information to be recorded
206        for all designations: <list style="hanging">
207            <t>1. The designated address prefix.</t>
208
209            <t>Prefix: TBD by IANA. Prefix length: /32</t>
210
211            <t>2. The RFC that called for the IANA address designation.</t>
212
213            <t>This document.</t>
214
215            <t>3. The date the designation was made.</t>
216
217            <t>TBD.</t>
218
219            <t>4. The date the use designation is to be terminated (if
220            specified as a limited-use designation).</t>
221
222            <t>Unlimited. No termination date.</t>
223
224            <t>5. The nature of the purpose of the designated address (e.g.,
225            unicast experiment or protocol service anycast).</t>
226
227            <t>protocol service anycast.</t>
228
229            <t>6. For experimental unicast applications and otherwise as
230            appropriate, the registry will also identify the entity and
231            related contact details to whom the address designation has been
232            made.</t>
233
234            <t>N/A.</t>
235
236            <t>7. The registry will also note, for each designation, the
237            intended routing scope of the address, indicating whether the
238            address is intended to be routable only in scoped, local, or
239            private contexts, or whether the address prefix is intended to be
240            routed globally.</t>
241
242            <t>Typically used within a network operator's network domain, but
243            in principle globally routable.</t>
244
245            <t>8. The date in the IANA registry is the date of the IANA
246            action, i.e., the day IANA records the allocation.</t>
247
248            <t>TBD.</t>
249          </list></t>
250      </section>
251
252      <section title="Registration of IPv6 Special Purpose Address">
253        <t>IANA is requested to register a single IPv6 address in the IANA
254        IPv6 Special Purpose Address Block <xref target="RFC4773"/>.</t>
255
256        <t><xref target="RFC4773"/> itemizes some information to be recorded
257        for all designations: <list style="hanging">
258            <t>1. The designated address prefix.</t>
259
260            <t>Prefix: TBD by IANA. Prefix length: /128</t>
261
262            <t>2. The RFC that called for the IANA address designation.</t>
263
264            <t>This document.</t>
265
266            <t>3. The date the designation was made.</t>
267
268            <t>TBD.</t>
269
270            <t>4. The date the use designation is to be terminated (if
271            specified as a limited-use designation).</t>
272
273            <t>Unlimited. No termination date.</t>
274
275            <t>5. The nature of the purpose of the designated address (e.g.,
276            unicast experiment or protocol service anycast).</t>
277
278            <t>protocol service anycast.</t>
279
280            <t>6. For experimental unicast applications and otherwise as
281            appropriate, the registry will also identify the entity and
282            related contact details to whom the address designation has been
283            made.</t>
284
285            <t>N/A.</t>
286
287            <t>7. The registry will also note, for each designation, the
288            intended routing scope of the address, indicating whether the
289            address is intended to be routable only in scoped, local, or
290            private contexts, or whether the address prefix is intended to be
291            routed globally.</t>
292
293            <t>Typically used within a network operator's network domain, but
294            in principle globally routable.</t>
295
296            <t>8. The date in the IANA registry is the date of the IANA
297            action, i.e., the day IANA records the allocation.</t>
298
299            <t>TBD.</t>
300          </list></t>
301      </section>
302
303    </section>
304
305    <section anchor="security" title="Security Considerations">
306      <t>In a network without any border gateway, NAT or firewall that is
307      aware of the PCP anycast address, outgoing PCP requests could leak out
308      onto the external Internet, possibly revealing information about
309      internal devices.</t>
310
311      <t>Using an IANA-assigned well-known PCP anycast address enables border
312      gateways to block such outgoing packets. In the default-free zone,
313      routers should be configured to drop such packets. Such configuration
314      can occur naturally via BGP messages advertising that no route exists to
315      said address.</t>
316
317      <t>Sensitive clients that do not wish to leak information about their
318      presesence can set an IP TTL on their PCP requests that limits how far
319      they can travel into the public Internet.</t>
320    </section>
321  </middle>
322
323  <back>
324    <?rfc needLines="6" ?>
325
326    <references title="Normative References">
327      <?rfc include="reference.RFC.1546"?>
328
329      <!-- <?rfc include="reference.RFC.2119"?> -->
330
331      <?rfc include="reference.RFC.3958"?>
332
333      <?rfc include="reference.RFC.4773"?>
334
335      <?rfc include="reference.RFC.5736"?>
336
337      <?rfc include="reference.RFC.6887"?>
338
339    </references>
340
341    <references title="Informative References">
342      <?rfc include="reference.RFC.4786"?>
343      <?rfc include="reference.I-D.chen-pcp-mobile-deployment"?>
344      <?rfc include="reference.I-D.ietf-pcp-dhcp"?>
345
346      <?rfc include="reference.I-D.ietf-dhc-container-opt"?>
347
348      <reference anchor="DhcpRequestParams"
349                 target="http://msdn.microsoft.com/en-us/library/windows/desktop/aa363298%28v=vs.85%29.aspx">
350        <front>
351          <title>OpenFlow Switch Specification</title>
352
353          <author fullname="OpenFlow" surname="OpenFlow">
354            <organization>OpenFlow</organization>
355          </author>
356
357          <date month="February" year="2011"/>
358        </front>
359      </reference>
360
361      <reference anchor="DNSDisc">
362        <front>
363          <title>Analysis of DNS Server Discovery Mechanisms for IPv6</title>
364
365          <author fullname="Jun-ichiro Hagino" initials="J" surname="Hagino">
366            <organization/>
367          </author>
368
369          <author fullname="Dave Thaler" initials="D" surname="Thaler">
370            <organization/>
371          </author>
372
373          <date day="27" month="November" year="2001"/>
374        </front>
375
376        <seriesInfo name="Internet-Draft"
377                    value="draft-ietf-ipngwg-dns-discovery-01"/>
378
379        <format target="http://tools.ietf.org/id/draft-ietf-ipngwg-dns-discovery-01.txt"
380                type="TXT"/>
381      </reference>
382    </references>
383
384
385
386    <section anchor="appendix-alternatives" title="Discussion of other PCP Discovery methods">
387      <t>Several algorithms have been specified that allows PCP Client to
388      discover the PCP Servers on a network . However, each of this approaches
389      has technical or operational issues that will hinder the fast deployment
390      of PCP.</t>
391
392      <section anchor="default_router" title="Default Router">
393        <t>The PCP specification allows one mode of operation in which the
394        PCP client sends its requests to the default router. This approach
395        is appropriate in a typical single-link residential network but
396        has limitations in more complex network topologies.</t>
397
398        <t>If PCP server does not reside in first hop router, whether because
399        subscriber has a existing home router or in the case of Wireless
400        Networks (3G, LTE) <xref target="I-D.chen-pcp-mobile-deployment"/>,
401        trying to send a request to default router will not work.</t>
402      </section>
403
404      <section anchor="dhcp_option" title="DHCP PCP Options">
405        <t>One general drawback of relying on external configuration mechanisms,
406        such as DHCP <xref target="I-D.ietf-pcp-dhcp"/>, is that it creates
407        an external dependency on another piece of network infrastructure which
408        must be configured with the right address for PCP to work. In some
409        environments the staff managing the DHCP servers may not be the same
410        staff managing the NAT gateways, and in any case, constantly keeping the
411        DHCP server address information up to date as NAT gateways are added,
412        removed, or reconfigured, is burdensome.</t>
413
414        <t>Another drawback of relying on DHCP for configuration is that at
415        least one significant target deployment environments for PCP -- namely
416        3GPP for mobile telephones -- does not use DHCP.</t>
417        <t>There are two problems with DHCP Options: DHCP Server on Home
418        Gateways (HGW) and Operating Systems DHCP clients</t>
419
420        <t>Currently what the HGW does with the options it receives from the
421        ISP is not standardized in any general way. As a matter of practice,
422        the HGW is most likely to use its own customer-LAN-facing IP address
423        for the DNS server address. As for other options, it's free to offer
424        the same values to the client, offer no value at all, or offer its own
425        IP address if that makes sense, as it does (sort of) for DNS.</t>
426
427        <t>In scenarios where PCP Server resides on ISP network and is
428        intended to work with arbitrary home gateways that don't know they are
429        being used in a PCP context, that won't work, because there's no
430        reason to think that the HGW will even request the option from the
431        DHCP server, much less offer the value it gets from the server on the
432        customer-facing LAN. There is work on the DHC WG to overcome some of
433        these limitations <xref target="I-D.ietf-dhc-container-opt"/> but in
434        terms of deployment it also needs HGW to be upgraded.</t>
435
436        <t>The problems with Operating Systems is that even if DHCP PCP Option
437        were made available to customer-facing LAN, host stack DHCP
438        enhancements are required to process or request new DHCP PCP option.
439        One exception is Windows <xref target="DhcpRequestParams"/></t>
440
441        <t>Finally, in the case of IPv6 there are networks where there is
442        DHCPv6 infrastructure at all or some hosts do not have a DHCPv6
443        client.</t>
444      </section>
445
446
447      <section anchor="user_input" title="User Input">
448        <t>A regular subscriber can not be expected to input IP address of PCP
449        Server or network domain name. Moreover, user can be at a Wi-Fi
450        hotspot, Hotel or related. Therefore relying on user input is not
451        reliable.</t>
452      </section>
453
454      <section anchor="dns_based" title="Domain Name System Based ">
455        <t>There are three separate category of problems with NAPTR <xref
456        target="RFC3958"/> <list style="numbers">
457            <t>End Points: It relies on PCP client determining the domain name
458            and supporting certain DNS queries</t>
459
460            <t>DNS Servers: DNS server need to be provisioned with the
461            necessary records</t>
462
463            <t>CPEs: CPEs might interfere with DNS queries and the DHCP domain
464            name option conveyed by ISP that could be used to bootstrap NAPTR
465            might not be relayed to home network.</t>
466          </list></t>
467      </section>
468
469      <section anchor="port_based" title="Addressing only based on Destination Port">
470        <t>One design option that was considered for Apple's NAT gateways was to
471        have the NAT gateway simply handle and respond to all packets addressed
472        to UDP port 5351, regardless of the destination address in the packet.
473        Since the device is a NAT gateway, it already examines every packet in
474        order to rewrite port numbers, so also detecting packets addressed to
475        UDP port 5351 is not a significant additional burden. Also, since this
476        device is a NAT gateway which rewrites port numbers, any attempt by a
477        client to talk *though* this first NAT gateway to create mappings in
478        some second upstream NAT gateway is futile and pointless. Any mappings
479        created in the second NAT gateway are useful to the client only if there
480        are also corresponding mappings created in the first NAT gateway.
481        Consequently, there is no case where it is useful for PCP requests to
482        pass transparently through the first PCP-aware NAT gateway on their way
483        to the second PCP-aware NAT gateway. In all cases, for useful
484        connectivity to be established, the PCP request must be handled by the
485        first NAT gateway, and then the first NAT gateway generates a
486        corresponding new upstream request to establish a mapping in the second
487        NAT gateway. (This process can be repeated recursively for as many times
488        as necessary for the depth of nesting of NAT gateways; this is
489        transparent to the client device.)</t>
490      </section>
491    </section>
492
493    <section anchor="appendix_anycast_discussion"
494             title="Discussion of IP Anycast Address usage for PCP">
495      <section title="Motivation">
496        <t>The two issues identified in <xref target="port_based"/>
497        result in the following related observations: the
498        PCP client may not *know* what destination address to use in its PCP
499        request packets; the PCP server doesn't *care* what destination address
500        is in the PCP request packets.</t>
501
502        <t>Given that the devices neither need to know nor care what destination
503        address goes in the packet, all we need to do is pick one and use it.
504        It's little more than a placeholder in the IP header. Any globally
505        routable unicast address will do. Since this address is one that
506        automatically routes its packet to the closest on-path device that
507        implements the desired functionality, it is an anycast address.</t>
508      </section>
509      <section title="Scenarios">
510        <t>In the simple case where the first-hop router is also the NAT gateway
511        (as is common in a typical single-link residential network), sending to
512        the PCP anycast address is equivalent to sending to the client's default
513        router, as specified in <xref target="RFC6887">the PCP base
514        document</xref>.</t>
515
516        <t>In the case of a larger corporate network, where there may be several
517        internal routed subnets and one or more border NAT gateway(s) connecting
518        to the rest of the Internet, sending to the PCP anycast address has the
519        interesting property that it magically finds the right border NAT
520        gateway for that client. Since we posit that other network
521        infrastructure does not need (and should not have) any special knowledge
522        of PCP (or its anycast address) this means that to other non-NAT
523        routers, the PCP anycast address will look like any other unicast
524        destination address on the public Internet, and consequently the packet
525        will be forwarded as for any other packet destined to the public
526        Internet, until it reaches a NAT or firewall device that is aware of the
527        PCP anycast address. This will result in the packet naturally arriving
528        the NAT gateway that handles this client's outbound traffic destined to
529        the public Internet, which is exactly the NAT gateway that the client
530        wishes to communicate with when managing its port mappings.</t>
531      </section>
532
533      <section anchor="history" title="Historical Objections to Anycast">
534        <t>In March 2001 a draft document entitled <xref
535        target="DNSDisc">"Analysis of DNS Server Discovery Mechanisms for
536        IPv6"</xref> proposed using anycast to discover DNS servers, a proposal
537        that was subsequently abandoned in later revisions of that draft
538        document.</t>
539   
540        <t>There are legitimate reasons why using anycast to discover DNS
541        servers is not compelling, mainly because it requires explicit
542        configuration of routing tables to direct those anycast packets to the
543        desired DNS server. However, DNS server discovery is very different to
544        NAT gateway discovery. A DNS server is something a client explicitly
545        talks to, via IP address. The DNS server may be literally anywhere on
546        the Internet. Various reasons make anycast an uncompelling technique for
547        DNS server discovery: <list style="symbols">
548            <t>DNS is a pure application-layer protocol, running over UDP.</t>
549   
550            <t>On an operating system without appropriate support for
551            configuring anycast addresses, a DNS server would have to use
552            something like Berkeley Packet Filter (BPF) to snoop on received
553            packets to intercept DNS requests, which is inelegant and
554            inefficient.</t>
555   
556            <t>Without appropriate routing changes elsewhere in the network,
557            there's no reason to assume that packets sent to that anycast
558            address would even make it to the desired DNS server machine. This
559            places an addition configuration burden on the network
560            administrators, to install appropriate routing table entries to
561            direct packets to the desired DNS server machine.</t>
562          </list></t>
563   
564        <t>In contrast, a NAT gateway is something a client's packets stumble
565        across as they try to leave the local network and head out onto the
566        public Internet. The NAT gateway has to be on the path those packets
567        naturally take or it can't perform its NAT functions. As a result, the
568        objections to using anycast for DNS server discovery do not apply to
569        PCP: <list style="symbols">
570            <t>No routing changes are needed (or desired) elsewhere in the local
571            network, because the whole *point* of using anycast is that we want
572            the client's PCP request packet to take the same forwarding path
573            through the network as a TCP SYN to any other remote destination
574            address, because we want the *same* NAT gateway that would have made
575            a mapping in response to receiving an outbound TCP SYN packet from
576            the client to be the the one that makes a mapping in response to
577            receiving a PCP request packet from the client.</t>
578   
579            <t>A NAT engine is already snooping on (and rewriting) every packet
580            it forwards. As part of that snooping it could trivially look for
581            packets addressed to the PCP UDP port and process them locally (just
582            like the local processing it already does when it sees an outbound
583            TCP SYN packet).</t>
584          </list></t>
585      </section>
586    </section>
587
588  </back>
589</rfc>
Note: See TracBrowser for help on using the repository browser.