idnits 2.17.1
draft-cheshire-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 :
----------------------------------------------------------------------------
== There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses
in the document. If these are example addresses, they should be changed.
== There are 1 instance of lines with non-RFC3849-compliant IPv6 addresses
in the document. If these are example addresses, they should be changed.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
-- The document date (July 14, 2013) is 3939 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)
-- No information found for draft-ietf-ipngwg-dns-discovery - is the name
correct?
Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 PCP working group S. Cheshire
3 Internet-Draft Apple
4 Intended status: Standards Track July 14, 2013
5 Expires: January 15, 2014
7 PCP Anycast Address
8 draft-cheshire-pcp-anycast-02
10 Abstract
12 The Port Control Protocol Anycast Address enables PCP clients to
13 transmit messages to their closest on-path NAT, Firewall, or other
14 middlebox, without having to learn the IP address of that middlebox
15 via some external channel.
17 Status of this Memo
19 This Internet-Draft is submitted in full conformance with the
20 provisions of BCP 78 and BCP 79.
22 Internet-Drafts are working documents of the Internet Engineering
23 Task Force (IETF). Note that other groups may also distribute
24 working documents as Internet-Drafts. The list of current Internet-
25 Drafts is at http://datatracker.ietf.org/drafts/current/.
27 Internet-Drafts are draft documents valid for a maximum of six months
28 and may be updated, replaced, or obsoleted by other documents at any
29 time. It is inappropriate to use Internet-Drafts as reference
30 material or to cite them other than as "work in progress."
32 This Internet-Draft will expire on January 15, 2014.
34 Copyright Notice
36 Copyright (c) 2013 IETF Trust and the persons identified as the
37 document authors. All rights reserved.
39 This document is subject to BCP 78 and the IETF Trust's Legal
40 Provisions Relating to IETF Documents
41 (http://trustee.ietf.org/license-info) in effect on the date of
42 publication of this document. Please review these documents
43 carefully, as they describe your rights and restrictions with respect
44 to this document. Code Components extracted from this document must
45 include Simplified BSD License text as described in Section 4.e of
46 the Trust Legal Provisions and are provided without warranty as
47 described in the Simplified BSD License.
49 1. Introduction
51 The Port Control Protocol document [RFC6887] specifies the message
52 formats used, but the address to which a client sends its request is
53 either assumed to be the default router (which is appropriate in a
54 typical single-link residential network) or has to be configured
55 otherwise via some external mechanism, such as DHCP.
57 One drawback of relying on external configuration is that it creates
58 an external dependency on another piece of network infrastructure
59 which must be configured with the right address for PCP to work. In
60 some environments the staff managing the DHCP servers may not be the
61 same staff managing the NAT gateways, and in any case, constantly
62 keeping the DHCP server address information up to date as NAT
63 gateways are added, removed, or reconfigured, is burdensome.
65 Another drawback of relying on DHCP for configuration is that one of
66 the target deployment environments for PCP -- 3GPP for mobile
67 telephones -- does not use DHCP.
69 One design option that was considered for Apple's NAT gateways was to
70 have the NAT gateway simply handle and respond to all packets
71 addressed to UDP port 5351, regardless of the destination address in
72 the packet. Since the device is a NAT gateway, it already examines
73 every packet in order to rewrite port numbers, so also detecting
74 packets addressed to UDP port 5351 is not a significant additional
75 burden. Also, since this device is a NAT gateway which rewrites port
76 numbers, any attempt by a client to talk *though* this first NAT
77 gateway to create mappings in some second upstream NAT gateway is
78 futile and pointless. Any mappings created in the second NAT gateway
79 are useful to the client only if there are also corresponding
80 mappings created in the first NAT gateway. Consequently, there is no
81 case where it is useful for PCP requests to pass transparently
82 through the first PCP-aware NAT gateway on their way to the second
83 PCP-aware NAT gateway. In all cases, for useful connectivity to be
84 established, the PCP request must be handled by the first NAT
85 gateway, and then the first NAT gateway generates a corresponding new
86 upstream request to establish a mapping in the second NAT gateway.
87 (This process can be repeated recursively for as many times as
88 necessary for the depth of nesting of NAT gateways; this is
89 transparent to the client device [Recurs].)
91 These two issues result in the following related observations: the
92 PCP client may not *know* what destination address to use in its PCP
93 request packets; the PCP server doesn't *care* what destination
94 address is in the PCP request packets.
96 Given that the devices neither need to know nor care what destination
97 address goes in the packet, all we need to do is pick one and use it.
98 It's little more than a placeholder in the IP header. Any globally
99 routable unicast address will do. Since this address is one that
100 automatically routes its packet to the closest on-path device that
101 implements the desired functionality, it is an anycast address.
103 In the simple case where the first-hop router is also the NAT gateway
104 (as is common in a typical single-link residential network), sending
105 to the PCP anycast address is equivalent to sending to the client's
106 default router, as specified in the PCP base document [RFC6887].
108 In the case of a larger corporate network, where there may be several
109 internal routed subnets and one or more border NAT gateway(s)
110 connecting to the rest of the Internet, sending to the PCP anycast
111 address has the interesting property that it magically finds the
112 right border NAT gateway for that client. Since we posit that other
113 network infrastructure does not need (and should not have) any
114 special knowledge of PCP (or its anycast address) this means that to
115 other non-NAT routers, the PCP anycast address will look like any
116 other unicast destination address on the public Internet, and
117 consequently the packet will be forwarded as for any other packet
118 destined to the public Internet, until it reaches a NAT or firewall
119 device that is aware of the PCP anycast address. This will result in
120 the packet naturally arriving the NAT gateway that handles this
121 client's outbound traffic destined to the public Internet, which is
122 exactly the NAT gateway that the client wishes to communicate with
123 when managing its port mappings.
125 2. Benefit of using a PCP Anycast Address
127 The benefit of using an anycast address is simplicity and
128 reliability. In an example deployment scenario:
130 1. A network administrator installs a PCP-capable NAT.
132 2. An end user (who may be the same person) runs a PCP-enabled
133 application. This application can implement PCP with purely
134 user-level code -- no operating system support is required.
136 3. This PCP-enabled application sends its PCP request to the PCP
137 anycast address. This packet travels through the network like
138 any other, without any special support from DNS, DHCP, other
139 routers, or anything else, until it reaches the PCP-capable NAT,
140 which receives it, handles it, and sends back a reply.
142 Using the PCP anycast address, the only two things that need to be
143 deployed in the network are the two things that actually use PCP: The
144 PCP-capable NAT, and the PCP-enabled application. Nothing else in
145 the network needs to be changed or upgraded, and nothing needs to be
146 configured, including the PCP client.
148 3. Historical Objections to Anycast
150 In March 2001 a draft document entitled "Analysis of DNS Server
151 Discovery Mechanisms for IPv6" [DNSDisc] proposed using anycast to
152 discover DNS servers, a proposal that was subsequently abandoned in
153 later revisions of that draft document.
155 There are legitimate reasons why using anycast to discover DNS
156 servers is not compelling, mainly because it requires explicit
157 configuration of routing tables to direct those anycast packets to
158 the desired DNS server. However, DNS server discovery is very
159 different to NAT gateway discovery. A DNS server is something a
160 client explicitly talks to, via IP address. The DNS server may be
161 literally anywhere on the Internet. Various reasons make anycast an
162 uncompelling technique for DNS server discovery:
164 o DNS is a pure application-layer protocol, running over UDP.
166 o On an operating system without appropriate support for configuring
167 anycast addresses, a DNS server would have to use something like
168 Berkeley Packet Filter (BPF) to snoop on received packets to
169 intercept DNS requests, which is inelegant and inefficient.
171 o Without appropriate routing changes elsewhere in the network,
172 there's no reason to assume that packets sent to that anycast
173 address would even make it to the desired DNS server machine.
174 This places an addition configuration burden on the network
175 administrators, to install approprate routing table entries to
176 direct packets to the desired DNS server machine.
178 In contrast, a NAT gateway is something a client's packets stumble
179 across as they try to leave the local network and head out onto the
180 public Internet. The NAT gateway has to be on the path those packets
181 naturally take or it can't perform its NAT functions. As a result,
182 the objections to using anycast for DNS server discovery do not apply
183 to PCP:
185 o No routing changes are needed (or desired) elsewhere in the local
186 network, because the whole *point* of using anycast is that we
187 want the client's PCP request packet to take the same forwarding
188 path through the network as a TCP SYN to any other remote
189 destination address, because we want the *same* NAT gateway that
190 would have made a mapping in response to receiving an outbound TCP
191 SYN packet from the client to be the the one that makes a mapping
192 in response to receiving a PCP request packet from the client.
194 o A NAT engine is already snooping on (and rewriting) every packet
195 it forwards. As part of that snooping it could trivially look for
196 packets addressed to the PCP UDP port and process them locally
197 (just like the local processing it already does when it sees an
198 outbound TCP SYN packet).
200 4. IANA Considerations
202 IANA should allocate an IPv4 and an IPv6 well-known PCP anycast
203 address.
205 192.0.0.0/24 and 2001:0000::/23 are reserved for IETF Protocol
206 Assignments, as listed at
207 and
208
210 Suitable addresses in these ranges, such as 192.0.0.8, and a
211 corresponding suitable IPv6 address, should be allocated.
213 5. Security Considerations
215 In a network without any border gateway, NAT or firewall that is
216 aware of the PCP anycast address, outgoing PCP requests could leak
217 out onto the external Internet, possibly revealing information about
218 internal devices.
220 Using an IANA-assigned well-known PCP anycast address enables border
221 gateways to block such outgoing packets. In the default-free zone,
222 routers should be configured to drop such packets. Such
223 configuration can occur naturally via BGP messages advertising that
224 no route exists to said address.
226 Sensitive clients that do not wish to leak information about their
227 presesence can set an IP TTL on their PCP requests that limits how
228 far they can travel into the public Internet.
230 6. References
232 6.1. Normative References
234 [RFC6887] Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P.
235 Selkirk, "Port Control Protocol (PCP)", RFC 6887,
236 April 2013.
238 6.2. Informative References
240 [DNSDisc] Hagino, J. and D. Thaler, "Analysis of DNS Server
241 Discovery Mechanisms for IPv6",
242 draft-ietf-ipngwg-dns-discovery-01 (work in progress),
243 November 2001.
245 [Recurs] Cheshire, S., "Recursive PCP",
246 draft-cheshire-recursive-pcp-02 (work in progress),
247 Mar 2013.
249 Author's Address
251 Stuart Cheshire
252 Apple Inc.
253 1 Infinite Loop
254 Cupertino, California 95014
255 USA
257 Phone: +1 408 974 3207
258 Email: cheshire@apple.com