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

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

update Sebastian's address

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