diff options
Diffstat (limited to 'src/upnp/draft-cheshire-nat-pmp.txt')
-rw-r--r-- | src/upnp/draft-cheshire-nat-pmp.txt | 1160 |
1 files changed, 1160 insertions, 0 deletions
diff --git a/src/upnp/draft-cheshire-nat-pmp.txt b/src/upnp/draft-cheshire-nat-pmp.txt new file mode 100644 index 000000000..727b5fad7 --- /dev/null +++ b/src/upnp/draft-cheshire-nat-pmp.txt | |||
@@ -0,0 +1,1160 @@ | |||
1 | Document: draft-cheshire-nat-pmp-02.txt Stuart Cheshire | ||
2 | Internet-Draft Marc Krochmal | ||
3 | Category: Standards Track Apple Computer, Inc. | ||
4 | Expires 14th March 2007 Kiren Sekar | ||
5 | Sharpcast, Inc. | ||
6 | 14th September 2006 | ||
7 | |||
8 | NAT Port Mapping Protocol (NAT-PMP) | ||
9 | |||
10 | <draft-cheshire-nat-pmp-02.txt> | ||
11 | |||
12 | Status of this Memo | ||
13 | |||
14 | By submitting this Internet-Draft, each author represents that any | ||
15 | applicable patent or other IPR claims of which he or she is aware | ||
16 | have been or will be disclosed, and any of which he or she becomes | ||
17 | aware will be disclosed, in accordance with Section 6 of BCP 79. | ||
18 | For the purposes of this document, the term "BCP 79" refers | ||
19 | exclusively to RFC 3979, "Intellectual Property Rights in IETF | ||
20 | Technology", published March 2005. | ||
21 | |||
22 | Internet-Drafts are working documents of the Internet Engineering | ||
23 | Task Force (IETF), its areas, and its working groups. Note that | ||
24 | other groups may also distribute working documents as Internet- | ||
25 | Drafts. | ||
26 | |||
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." | ||
31 | |||
32 | The list of current Internet-Drafts can be accessed at | ||
33 | http://www.ietf.org/1id-abstracts.html | ||
34 | |||
35 | The list of Internet-Draft Shadow Directories can be accessed at | ||
36 | http://www.ietf.org/shadow.html | ||
37 | |||
38 | |||
39 | Abstract | ||
40 | |||
41 | This document describes a protocol for automating the process of | ||
42 | creating Network Address Translation (NAT) port mappings. Included | ||
43 | in the protocol is a method for retrieving the public IP address of | ||
44 | a NAT gateway, thus allowing a client to make this public IP address | ||
45 | and port number known to peers that may wish to communicate with it. | ||
46 | This protocol is implemented in current Apple products including | ||
47 | Mac OS X, Bonjour for Windows, and AirPort wireless base stations. | ||
48 | |||
49 | |||
50 | |||
51 | |||
52 | |||
53 | |||
54 | |||
55 | |||
56 | |||
57 | |||
58 | Expires 14th March 2007 Cheshire, et al. [Page 1] | ||
59 | |||
60 | Internet Draft NAT Port Mapping Protocol 14th September 2006 | ||
61 | |||
62 | |||
63 | 1. Introduction | ||
64 | |||
65 | Network Address Translation (NAT) is a method of sharing one public | ||
66 | internet address with a number of devices. This document is focused | ||
67 | on what "IP Network Address Translator (NAT) Terminology and | ||
68 | Considerations" [RFC 2663] calls "NAPTs" (Network Address/Port | ||
69 | Translators). A full description of NAT is beyond the scope of this | ||
70 | document. The following brief overview will cover the aspects | ||
71 | relevant to this port mapping protocol. For more information on | ||
72 | NAT, see "Traditional IP Network Address Translator" [RFC 3022]. | ||
73 | |||
74 | NATs have one or more public IP addresses. A private network is set | ||
75 | up behind the NAT. Devices behind the NAT are assigned private | ||
76 | addresses and the private address of the NAT device is used as the | ||
77 | gateway. | ||
78 | |||
79 | When a packet from any device behind the NAT is sent to an address on | ||
80 | the public internet, the packet first passes through the NAT box. The | ||
81 | NAT box looks at the source port and address. In some cases, a NAT | ||
82 | will also keep track of the destination port and address. The NAT | ||
83 | then creates a mapping from the private address and private port to a | ||
84 | public address and public port if a mapping does not already exist. | ||
85 | The NAT box replaces the private address and port number in the | ||
86 | packet with the public entries from the mapping and sends the packet | ||
87 | on to the next gateway. | ||
88 | |||
89 | When a packet from any address on the internet is received on the | ||
90 | NAT's public side, the NAT will look up the destination port (public | ||
91 | port) in the list of mappings. If an entry is found, it will contain | ||
92 | the private address and port that the packet should be sent to. The | ||
93 | NAT gateway will then rewrite the destination address and port with | ||
94 | those from the mapping. The packet will then be forwarded to the new | ||
95 | destination addresses. If the packet did not match any mapping, the | ||
96 | packet will most likely be dropped. Various NATs implement different | ||
97 | strategies to handle this. The important thing to note is that if | ||
98 | there is no mapping, the NAT does not know which private address the | ||
99 | packet should be sent to. | ||
100 | |||
101 | Mappings are usually created automatically as a result of observing | ||
102 | outbound traffic. There are a few exceptions. Some NATs may allow | ||
103 | manually-created permanent mappings that map a public port to a | ||
104 | specific private IP address and port. Such a mapping allows incoming | ||
105 | connections to the device with that private address. Some NATs also | ||
106 | implement a default mapping where any inbound traffic that does not | ||
107 | match a mapping will always be forwarded to a specific private | ||
108 | address. Both types of mappings are usually set up manually through | ||
109 | some configuration tool. | ||
110 | |||
111 | Without these manually-created inbound port mappings, clients behind | ||
112 | the NAT would be unable to receive inbound connections, which | ||
113 | represents a loss of connectivity when compared to the original | ||
114 | |||
115 | |||
116 | Expires 14th March 2007 Cheshire, et al. [Page 2] | ||
117 | |||
118 | Internet Draft NAT Port Mapping Protocol 14th September 2006 | ||
119 | |||
120 | |||
121 | Internet architecture [ETEAISD]. For those who view this loss of | ||
122 | connectivity as a bad thing, NAT-PMP allows clients to operate much | ||
123 | more like a host directly connected to the unrestricted public | ||
124 | Internet, with an unrestricted public IP address. NAT-PMP allows | ||
125 | client hosts to communicate with the NAT gateway to request the | ||
126 | creation of inbound mappings on demand. Having created a NAT mapping | ||
127 | to allow inbound connections, the client can then record its public | ||
128 | IP address and public port number in a public registry (e.g. the | ||
129 | world-wide Domain Name System) or otherwise make it accessible to | ||
130 | peers that wish to communicate with it. | ||
131 | |||
132 | |||
133 | 2. Conventions and Terminology Used in this Document | ||
134 | |||
135 | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | ||
136 | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | ||
137 | document are to be interpreted as described in "Key words for use in | ||
138 | RFCs to Indicate Requirement Levels" [RFC 2119]. | ||
139 | |||
140 | |||
141 | 3. Protocol and Packet Format | ||
142 | |||
143 | NAT Port Mapping Protocol runs over UDP. Every packet starts with an | ||
144 | 8 bit version followed by an 8 bit operation code. | ||
145 | |||
146 | This document specifies version 0 of the protocol. Any NAT-PMP | ||
147 | gateway implementing this version of the protocol, receiving a | ||
148 | packet with a version number other than 0, MUST return result code 1 | ||
149 | (Unsupported Version). | ||
150 | |||
151 | Opcodes between 0 and 127 are client requests. Opcodes from 128 to | ||
152 | 255 are server responses. Responses always contain a 16 bit result | ||
153 | code in network byte order. A result code of zero indicates success. | ||
154 | Responses also contain a 32 bit unsigned integer corresponding to the | ||
155 | number of seconds since the NAT gateway was rebooted or since its | ||
156 | port mapping state was reset. | ||
157 | |||
158 | This protocol SHOULD only be used when the client determines that | ||
159 | its primary IPv4 address is in one of the private IP address ranges | ||
160 | defined in "Address Allocation for Private Internets" [RFC 1918]. | ||
161 | This includes the address ranges 10/8, 172.16/12, and 192.168/16. | ||
162 | |||
163 | Clients always send their Port Mapping Protocol requests to their | ||
164 | default gateway, as learned via DHCP [RFC 2131], or similar means. | ||
165 | This protocol is designed for small home networks, with a single | ||
166 | logical link (subnet) where the client's default gateway is also the | ||
167 | NAT translator for that network. For more complicated networks where | ||
168 | the NAT translator is some device other than the client's default | ||
169 | gateway, this protocol is not appropriate. | ||
170 | |||
171 | |||
172 | |||
173 | |||
174 | Expires 14th March 2007 Cheshire, et al. [Page 3] | ||
175 | |||
176 | Internet Draft NAT Port Mapping Protocol 14th September 2006 | ||
177 | |||
178 | |||
179 | 3.1 Requests and Responses | ||
180 | |||
181 | NAT gateways are often low-cost devices, with limited memory and | ||
182 | CPU speed. For this reason, to avoid making excessive demands on | ||
183 | the NAT gateway, clients machines SHOULD NOT issue multiple requests | ||
184 | simultaneously in parallel. If a client needs to perform multiple | ||
185 | requests (e.g. on boot, wake from sleep, network connection, etc.) | ||
186 | it SHOULD queue them and issue them serially one at a time. Once the | ||
187 | NAT gateway responds to one request the client machine may issue the | ||
188 | next. In the case of a fast NAT gateway, the client may be able to | ||
189 | complete requests at a rate of hundreds per second. In the case of | ||
190 | a slow NAT gateway that takes perhaps half a second to respond to | ||
191 | a NAT-PMP request, the client SHOULD respect this and allow the | ||
192 | NAT gateway to operate at the pace it can manage, and not overload | ||
193 | it by issuing requests faster than the rate it's answering them. | ||
194 | |||
195 | To determine the puclic IP address or request a port mapping, | ||
196 | a NAT-PMP client sends its request packet to port 5351 of its | ||
197 | configured gateway address, and waits 250ms for a response. If no | ||
198 | NAT-PMP response is received from the gateway after 250ms, the client | ||
199 | retransmits its request and waits 500ms. The client SHOULD repeat | ||
200 | this process with the interval between attempts doubling each time. | ||
201 | If, after sending its 9th attempt (and then waiting for 64 seconds), | ||
202 | the client has still received no response, then it SHOULD conclude | ||
203 | that this gateway does not support NAT Port Mapping Protocol and | ||
204 | MAY log an error message indicating this fact. In addition, if the | ||
205 | NAT-PMP client receives an "ICMP Port Unreachable" message from the | ||
206 | gateway for port 5351 then it can skip any remaining retransmissions | ||
207 | and conclude immediately that the gateway does not support NAT-PMP. | ||
208 | |||
209 | As a performance optimization the client MAY record this information | ||
210 | and use it to suppress further attempts to use NAT-PMP, but the | ||
211 | client should not retain this information for too long. In | ||
212 | particular, any event that may indicate a potential change of gateway | ||
213 | or a change in gateway configuration (hardware link change | ||
214 | indication, change of gateway MAC address, acquisition of new DHCP | ||
215 | lease, receipt of NAT-PMP announcement packet from gateway, etc.) | ||
216 | should cause the client to discard its previous information regarding | ||
217 | the gateway's lack of NAT-PMP support, and send its next NAT-PMP | ||
218 | request packet normally. | ||
219 | |||
220 | |||
221 | 3.2 Determining the Public Address | ||
222 | |||
223 | To determine the public address, the client behind the NAT sends the | ||
224 | following UDP payload to port 5351 of the configured gateway address: | ||
225 | |||
226 | 0 1 | ||
227 | 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 | ||
228 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||
229 | | Vers = 0 | OP = 0 | | ||
230 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||
231 | |||
232 | Expires 14th March 2007 Cheshire, et al. [Page 4] | ||
233 | |||
234 | Internet Draft NAT Port Mapping Protocol 14th September 2006 | ||
235 | |||
236 | |||
237 | A compatible NAT gateway MUST generate a response with the following | ||
238 | format: | ||
239 | |||
240 | 0 1 2 3 | ||
241 | 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | ||
242 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||
243 | | Vers = 0 | OP = 128 + 0 | Result Code | | ||
244 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||
245 | | Seconds Since Start of Epoch | | ||
246 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||
247 | | Public IP Address (a.b.c.d) | | ||
248 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||
249 | |||
250 | This response indicates that the NAT gateway implements this version | ||
251 | of the protocol and returns the public IP address of the NAT gateway. | ||
252 | If the result code is non-zero, the value of Public IP Address is | ||
253 | undefined (MUST be set to zero on transmission, and MUST be ignored | ||
254 | on reception). | ||
255 | |||
256 | The NAT gateway MUST fill in the "Seconds Since Start of Epoch" field | ||
257 | with the time elapsed since its port mapping table was initialized on | ||
258 | startup or reset for any other reason (see Section 3.6 "Seconds Since | ||
259 | Start of Epoch"). | ||
260 | |||
261 | Upon receiving the response packet, the client MUST check the source | ||
262 | IP address, and silently discard the packet if the address is not the | ||
263 | address of the gateway to which the request was sent. | ||
264 | |||
265 | |||
266 | 3.2.1 Announcing Address Changes | ||
267 | |||
268 | When the public IP address of the NAT changes, the NAT gateway MUST | ||
269 | send a gratuitous response to the link-local multicast address | ||
270 | 224.0.0.1, port 5351 with the packet format above to notify clients | ||
271 | of the new public IP address. To accommodate packet loss, the | ||
272 | NAT gateway SHOULD multicast 10 address change notifications. | ||
273 | The interval between the first two notifications SHOULD be 250ms, | ||
274 | and the interval between each subsequent notification SHOULD double. | ||
275 | |||
276 | Upon receiving a gratuitous address change announcement packet, | ||
277 | the client MUST check the source IP address, and silently discard | ||
278 | the packet if the address is not the address of the client's | ||
279 | current configured gateway. This is to guard against inadvertent | ||
280 | misconfigurations where there may be more than one NAT gateway | ||
281 | active on the network. | ||
282 | |||
283 | |||
284 | |||
285 | |||
286 | |||
287 | |||
288 | |||
289 | |||
290 | Expires 14th March 2007 Cheshire, et al. [Page 5] | ||
291 | |||
292 | Internet Draft NAT Port Mapping Protocol 14th September 2006 | ||
293 | |||
294 | |||
295 | 3.3 Creating a Mapping | ||
296 | |||
297 | To create a mapping, the client sends a UDP packet to port 5351 | ||
298 | of the gateway's private IP address with the following format: | ||
299 | |||
300 | 0 1 2 3 | ||
301 | 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | ||
302 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||
303 | | Vers = 0 | OP = x | Reserved (MUST be zero) | | ||
304 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||
305 | | Private Port | Requested Public Port | | ||
306 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||
307 | | Requested Port Mapping Lifetime in Seconds | | ||
308 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||
309 | |||
310 | Opcodes supported: | ||
311 | 1 - Map UDP | ||
312 | 2 - Map TCP | ||
313 | |||
314 | The Reserved field MUST be set to zero on transmission and MUST | ||
315 | be ignored on reception. | ||
316 | |||
317 | The Private Port is set to the local port on which the client is | ||
318 | listening. | ||
319 | |||
320 | The Requested Public Port SHOULD usually be set to the same value as | ||
321 | the local Private Port, or zero if the client has no preference for | ||
322 | what port is assigned. However, the gateway is not obliged to assign | ||
323 | the port requested, and may choose not to, either for policy reasons | ||
324 | (e.g. port 80 is reserved and clients may not request it) or because | ||
325 | that port has already been assigned to some other client. Because | ||
326 | of this, some product developers have questioned the value of having | ||
327 | the Requested Public Port field at all. The reason is for failure | ||
328 | recovery. Most low-cost home NAT gateways do not record temporary | ||
329 | port mappings in persistent storage, so if the gateway crashes or is | ||
330 | rebooted, all the mappings are lost. A renewal packet is formatted | ||
331 | identically to an initial mapping request packet, except that for | ||
332 | renewals the client sets the Requested Public Port field to the | ||
333 | port the gateway actually assigned, rather than the port the client | ||
334 | originally wanted. When a freshly-rebooted NAT gateway receives a | ||
335 | renewal packet from a client, it appears to the gateway just like | ||
336 | an ordinary initial request for a port mapping, except that in this | ||
337 | case the Requested Public Port is likely to be one that the NAT | ||
338 | gateway *is* willing to allocate (it allocated it to this client | ||
339 | right before the reboot, so it should presumably be willing to | ||
340 | allocate it again). | ||
341 | |||
342 | The RECOMMENDED Port Mapping Lifetime is 3600 seconds. | ||
343 | |||
344 | |||
345 | |||
346 | |||
347 | |||
348 | Expires 14th March 2007 Cheshire, et al. [Page 6] | ||
349 | |||
350 | Internet Draft NAT Port Mapping Protocol 14th September 2006 | ||
351 | |||
352 | |||
353 | After sending the port mapping request, the client then waits for the | ||
354 | NAT gateway to respond. If after 250ms, the gateway doesn't respond, | ||
355 | the client SHOULD re-issue its request as described above in Section | ||
356 | 3.1 "Requests and Responses". | ||
357 | |||
358 | The NAT gateway responds with the following packet format: | ||
359 | |||
360 | 0 1 2 3 | ||
361 | 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | ||
362 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||
363 | | Vers = 0 | OP = 128 + x | Result Code | | ||
364 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||
365 | | Seconds Since Start of Epoch | | ||
366 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||
367 | | Private Port | Mapped Public Port | | ||
368 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||
369 | | Port Mapping Lifetime in Seconds | | ||
370 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||
371 | |||
372 | The 'x' in the OP field MUST match what the client requested. Some | ||
373 | NAT gateways are incapable of creating a UDP port mapping without | ||
374 | also creating a corresponding TCP port mapping, and vice versa, and | ||
375 | these gateways MUST NOT implement NAT Port Mapping Protocol until | ||
376 | this deficiency is fixed. A NAT gateway which implements this | ||
377 | protocol MUST be able to create TCP-only and UDP-only port mappings. | ||
378 | |||
379 | If a NAT gateway silently creates a pair of mappings for a client | ||
380 | that only requested one mapping, then it may expose that client to | ||
381 | receiving inbound UDP packets or inbound TCP connection requests | ||
382 | that it did not ask for and does not want. | ||
383 | |||
384 | While a NAT gateway MUST NOT automatically create mappings for TCP | ||
385 | when the client requests UDP, and vice versa, the NAT gateway MUST | ||
386 | reserve the companion port so the same client can choose to map it | ||
387 | in the future. For example, if a client requests to map TCP port 80, | ||
388 | as long as the client maintains the lease for that TCP port mapping, | ||
389 | another client with a different IP address MUST NOT be able to | ||
390 | successfully acquire the mapping for UDP port 80. | ||
391 | |||
392 | The client normally requests the public port matching the private | ||
393 | port. If that public port is not available, the NAT gateway MUST | ||
394 | return a public port that is available or return an error code if | ||
395 | no ports are available. | ||
396 | |||
397 | The source address of the packet MUST be used for the private address | ||
398 | in the mapping. This protocol is not intended to facilitate one | ||
399 | device behind a NAT creating mappings for other devices. If there | ||
400 | are legacy devices that require inbound mappings, permanent mappings | ||
401 | can be created manually by the administrator, just as they are today. | ||
402 | |||
403 | |||
404 | |||
405 | |||
406 | Expires 14th March 2007 Cheshire, et al. [Page 7] | ||
407 | |||
408 | Internet Draft NAT Port Mapping Protocol 14th September 2006 | ||
409 | |||
410 | |||
411 | If a mapping already exists for a given private port on a given local | ||
412 | client (whether that mapping was created explicitly using NAT-PMP, | ||
413 | implicitly as a result of an outgoing TCP SYN packet, or manually by | ||
414 | a human administrator) and that client requests another mapping for | ||
415 | the same private port (possibly requesting a different public port) | ||
416 | then the mapping request should succeed, returning the already- | ||
417 | assigned public port. This is necessary to handle the case where | ||
418 | a client requests a mapping with requested public port X, and is | ||
419 | granted a mapping with actual public port Y, but the acknowledgement | ||
420 | packet gets lost. When the client retransmits its mapping request, | ||
421 | it should get back the same positive acknowledgement as was sent (and | ||
422 | lost) the first time. | ||
423 | |||
424 | The NAT gateway SHOULD NOT accept mapping requests destined to the | ||
425 | NAT gateway's public IP address or received on its public network | ||
426 | interface. Only packets received on the private interface(s) with | ||
427 | a destination address matching the private address(es) of the NAT | ||
428 | gateway should be allowed. | ||
429 | |||
430 | The NAT gateway MUST fill in the "Seconds Since Start of Epoch" field | ||
431 | with the time elapsed since its port mapping table was initialized on | ||
432 | startup or reset for any other reason (see Section 3.6 "Seconds Since | ||
433 | Start of Epoch"). | ||
434 | |||
435 | The Port Mapping Lifetime is an unsigned integer in seconds. The NAT | ||
436 | gateway MAY reduce the lifetime from what the client requested. The | ||
437 | NAT gateway SHOULD NOT offer a lease lifetime greater than that | ||
438 | requested by the client. | ||
439 | |||
440 | Upon receiving the response packet, the client MUST check the source | ||
441 | IP address, and silently discard the packet if the address is not the | ||
442 | address of the gateway to which the request was sent. | ||
443 | |||
444 | The client SHOULD begin trying to renew the mapping halfway to expiry | ||
445 | time, like DHCP. The renewal packet should look exactly the same as | ||
446 | a request packet, except that the client SHOULD set the requested | ||
447 | public port to what the NAT gateway previously mapped, not what the | ||
448 | client originally requested. As described above, this enables the | ||
449 | gateway to automatically recover its mapping state after a crash or | ||
450 | reboot. | ||
451 | |||
452 | |||
453 | 3.4 Destroying a Mapping | ||
454 | |||
455 | A mapping may be destroyed in a variety of ways. If a client fails | ||
456 | to renew a mapping, then when its lifetime expires the mapping MUST | ||
457 | be automatically deleted. In the common case where the gateway | ||
458 | device is a combined DHCP server and NAT gateway, when a client's | ||
459 | DHCP address lease expires, the gateway device MAY automatically | ||
460 | delete any mappings belonging to that client. Otherwise a new client | ||
461 | being assigned the same IP address could receive unexpected inbound | ||
462 | |||
463 | |||
464 | Expires 14th March 2007 Cheshire, et al. [Page 8] | ||
465 | |||
466 | Internet Draft NAT Port Mapping Protocol 14th September 2006 | ||
467 | |||
468 | |||
469 | UDP packets or inbound TCP connection requests that it did not ask | ||
470 | for and does not want. | ||
471 | |||
472 | A client MAY also send an explicit packet to request deletion of a | ||
473 | mapping that is no longer needed. A client requests explicit | ||
474 | deletion of a mapping by sending a message to the NAT gateway | ||
475 | requesting the mapping, with the Requested Lifetime in Seconds set | ||
476 | to 0. The requested public port MUST be set to zero by the client | ||
477 | on sending, and MUST be ignored by the gateway on reception. | ||
478 | |||
479 | When a mapping is destroyed successfully as a result of the client | ||
480 | explicitly requesting the deletion, the NAT gateway MUST send a | ||
481 | response packet which is formatted as defined in section 3.3 | ||
482 | "Creating a Mapping". The response MUST contain a result code of 0, | ||
483 | the private port as indicated in the deletion request, a public port | ||
484 | of 0, and a lifetime of 0. The NAT gateway MUST respond to a request | ||
485 | to destroy a mapping that does not exist as if the request were | ||
486 | successful. This is because of the case where the acknowledgement is | ||
487 | lost, and the client retransmits its request to delete the mapping. | ||
488 | In this case the second request to delete the mapping MUST return the | ||
489 | same response packet as the first request. | ||
490 | |||
491 | If the deletion request was unsuccessful, the response MUST contain a | ||
492 | non-zero result code and the requested mapping; the lifetime is | ||
493 | undefined (MUST be set to zero on transmission, and MUST be ignored | ||
494 | on reception). If the client attempts to delete a port mapping which | ||
495 | was manually assigned by some kind of configuration tool, the NAT | ||
496 | gateway MUST respond with a 'Not Authorized' error, result code 2. | ||
497 | |||
498 | When a mapping is destroyed as a result of its lifetime expiring or | ||
499 | for any other reason, if the NAT gateway's internal state indicates | ||
500 | that there are still active TCP connections traversing that now- | ||
501 | defunct mapping, then the NAT gateway SHOULD send appropriately- | ||
502 | constructed TCP RST (reset) packets both to the local client and to | ||
503 | the remote peer on the Internet to terminate that TCP connection. | ||
504 | |||
505 | A client can request the explicit deletion of all its UDP or TCP | ||
506 | mappings by sending the same deletion request to the NAT gateway | ||
507 | with public port, private port, and lifetime set to 0. A client MAY | ||
508 | choose to do this when it first acquires a new IP address in order to | ||
509 | protect itself from port mappings that were performed by a previous | ||
510 | owner of the IP address. After receiving such a deletion request, | ||
511 | the gateway MUST delete all its UDP or TCP port mappings (depending | ||
512 | on the opcode). The gateway responds to such a deletion request with | ||
513 | a response as described above, with the private port set to zero. If | ||
514 | the gateway is unable to delete a port mapping, for example, because | ||
515 | the mapping was manually configured by the administrator, the gateway | ||
516 | MUST still delete as many port mappings as possible, but respond with | ||
517 | a non-zero result code. The exact result code to return depends on | ||
518 | the cause of the failure. If the gateway is able to successfully | ||
519 | delete all port mappings as requested, it MUST respond with a result | ||
520 | code of 0. | ||
521 | |||
522 | Expires 14th March 2007 Cheshire, et al. [Page 9] | ||
523 | |||
524 | Internet Draft NAT Port Mapping Protocol 14th September 2006 | ||
525 | |||
526 | |||
527 | 3.5 Result Codes | ||
528 | |||
529 | Currently defined result codes: | ||
530 | 0 - Success | ||
531 | 1 - Unsupported Version | ||
532 | 2 - Not Authorized/Refused | ||
533 | (e.g. box supports mapping, but user has turned feature off) | ||
534 | 3 - Network Failure | ||
535 | (e.g. NAT box itself has not obtained a DHCP lease) | ||
536 | 4 - Out of resources | ||
537 | (NAT box cannot create any more mappings at this time) | ||
538 | 5 - Unsupported opcode | ||
539 | |||
540 | If the result code is non-zero, the format of the packet following | ||
541 | the result code may be truncated. For example, if the client sends a | ||
542 | request to the server with an opcode of 17 and the server does not | ||
543 | recognize that opcode, the server SHOULD respond with a message where | ||
544 | the opcode is 17 + 128 and the result code is 5 (opcode not | ||
545 | supported). Since the server does not understand the format of | ||
546 | opcode 17, it may not know what to place after the result code. In | ||
547 | some cases, relevant data may follow the opcode to identify the | ||
548 | operation that failed. For example, a client may request a mapping | ||
549 | but that mapping may fail due to resource exhaustion. The server | ||
550 | SHOULD respond with the result code to indicate resource exhaustion | ||
551 | (4) followed by the requested port mapping so the client may identify | ||
552 | which operation failed. | ||
553 | |||
554 | Clients MUST be able to properly handle result codes not defined in | ||
555 | this document. Undefined results codes MUST be treated as fatal | ||
556 | errors of the request. | ||
557 | |||
558 | |||
559 | 3.6 Seconds Since Start of Epoch | ||
560 | |||
561 | Every packet sent by the NAT gateway includes a "Seconds since start | ||
562 | of epoch" field (SSSOE). If the NAT gateway resets or loses the | ||
563 | state of its port mapping table, due to reboot, power failure, or any | ||
564 | other reason, it MUST reset its epoch time and begin counting SSSOE | ||
565 | from 0 again. Whenever a client receives any packet from the NAT | ||
566 | gateway, either gratuitously or in response to a client request, the | ||
567 | client computes its own conservative estimate of the expected SSSOE | ||
568 | value by taking the SSSOE value in the last packet it received from | ||
569 | the gateway and adding 7/8 (87.5%) of the time elapsed since that | ||
570 | packet was received. If the SSSOE in the newly received packet is | ||
571 | less than the client's conservative estimate by more than one second, | ||
572 | then the client concludes that the NAT gateway has undergone a reboot | ||
573 | or other loss of port mapping state, and the client MUST immediately | ||
574 | renew all its active port mapping leases as described in Section 3.7 | ||
575 | "Recreating Mappings On NAT Gateway Reboot". | ||
576 | |||
577 | |||
578 | |||
579 | |||
580 | Expires 14th March 2007 Cheshire, et al. [Page 10] | ||
581 | |||
582 | Internet Draft NAT Port Mapping Protocol 14th September 2006 | ||
583 | |||
584 | |||
585 | 3.7 Recreating Mappings On NAT Gateway Reboot | ||
586 | |||
587 | The NAT gateway MAY store mappings in persistent storage so when it | ||
588 | is powered off or rebooted, it remembers the port mapping state of | ||
589 | the network. | ||
590 | |||
591 | However, maintaining this state is not essential for correct | ||
592 | operation. When the NAT gateway powers on or clears its port mapping | ||
593 | state as the result of a configuration change, it MUST reset the | ||
594 | epoch time and re-announce its IP address as described in Section | ||
595 | 3.2.1 "Announcing Address Changes". Reception of this packet where | ||
596 | time has apparently gone backwards serves as a hint to clients | ||
597 | on the network that they SHOULD immediately send renewal packets | ||
598 | (to immediately recreate their mappings) instead of waiting until | ||
599 | the originally scheduled time for those renewals. Clients who miss | ||
600 | receiving those gateway announcement packets for any reason will | ||
601 | still renew their mappings at the originally scheduled time and cause | ||
602 | their mappings to be recreated; it will just take a little longer for | ||
603 | these clients. | ||
604 | |||
605 | A mapping renewal packet is formatted identically to an original | ||
606 | mapping request; from the point of view of the client it is a | ||
607 | renewal of an existing mapping, but from the point of view of the | ||
608 | freshly-rebooted NAT gateway it appears as a new mapping request. | ||
609 | |||
610 | This self-healing property of the protocol is very important. | ||
611 | |||
612 | The remarkable reliability of the Internet as a whole derives | ||
613 | in large part from the fact that important state is held in the | ||
614 | endpoints, not in the network itself [ETEAISD]. Power-cycling an | ||
615 | Ethernet switch results only in a brief interruption in the flow | ||
616 | of packets; established TCP connections through that switch are not | ||
617 | broken, merely delayed for a few seconds. Indeed, an old Ethernet | ||
618 | switch can even be replaced with a new one, and as long as the cables | ||
619 | are transferred over reasonably quickly, after the upgrade all the | ||
620 | TCP connections that were previously going though the old switch will | ||
621 | be unbroken and now going through the new one. The same is true of | ||
622 | IP routers, wireless base stations, etc. The one exception is NAT | ||
623 | gateways. Because the port mapping state is required for the NAT | ||
624 | gateway to know where to forward inbound packets, loss of that state | ||
625 | breaks connectivity through the NAT gateway. By allowing clients to | ||
626 | detect when this loss of NAT gateway state has occurred, and recreate | ||
627 | it on demand, we turn hard state in the network into soft state, and | ||
628 | allow it to be recovered automatically when needed. | ||
629 | |||
630 | Without this automatic recreation of soft state in the NAT gateway, | ||
631 | reliable long-term networking would not be achieved. As mentioned | ||
632 | above, the reliability of the Internet does not come from trying | ||
633 | to build a perfect network in which errors never happen, but from | ||
634 | accepting that in any sufficiently large system there will always be | ||
635 | some component somewhere that's failing, and designing mechanisms | ||
636 | |||
637 | |||
638 | Expires 14th March 2007 Cheshire, et al. [Page 11] | ||
639 | |||
640 | Internet Draft NAT Port Mapping Protocol 14th September 2006 | ||
641 | |||
642 | |||
643 | that can handle those failures and recover. To illustrate this point | ||
644 | with an example, consider the following scenario: Imagine a network | ||
645 | security camera that has a web interface and accepts incoming | ||
646 | connections from web browser clients. Imagine this network security | ||
647 | camera uses NAT-PMP or a similar protocol to set up an inbound | ||
648 | port mapping in the NAT gateway so that it can receive incoming | ||
649 | connections from clients the other side of the NAT gateway. | ||
650 | Now, this camera may well operate for weeks, months, or even years. | ||
651 | During that time it's possible that the NAT gateway could experience | ||
652 | a power failure or be rebooted. The user could upgrade the NAT | ||
653 | gateway's firmware, or even replace the entire NAT gateway device | ||
654 | with a newer model. The general point is that if the camera operates | ||
655 | for a long enough period of time, some kind of disruption to the NAT | ||
656 | gateway becomes inevitable. The question is not whether the NAT | ||
657 | gateway will lose its port mappings, but when, and how often. | ||
658 | If the network camera and devices like it on the network can detect | ||
659 | when the NAT gateway has lost its port mappings, and recreate them | ||
660 | automatically, then these disruptions are self-correcting and | ||
661 | invisible to the end user. If, on the other hand, the disruptions are | ||
662 | not self-correcting, and after a NAT gateway reboot the user has to | ||
663 | manually reset or reboot all the other devices on the network too, | ||
664 | then these disruptions are *very* visible to the end user. This | ||
665 | aspect of the design is what makes the difference between a protocol | ||
666 | that keeps on working indefinitely over a time scale of months or | ||
667 | years, and a protocol that works in brief testing, but in the real | ||
668 | world is continually failing and requiring manual intervention to get | ||
669 | it going again. | ||
670 | |||
671 | When a client renews its port mappings as the result of receiving | ||
672 | a packet where the "Seconds since start of epoch" field (SSSOE) | ||
673 | indicates that a reboot or similar loss of state has occurred, | ||
674 | the client MUST first delay by a random amount of time selected | ||
675 | with uniform random distribution in the range 0 to 5 seconds, and | ||
676 | then send its first port mapping request. After that request is | ||
677 | acknowledged by the gateway, the client may then send its second | ||
678 | request, and so on, as rapidly as the gateway allows. The requests | ||
679 | SHOULD be issued serially, one at a time; the client SHOULD NOT issue | ||
680 | multiple requests simultaneously in parallel. | ||
681 | |||
682 | The discussion in this section focusses on recreating inbound port | ||
683 | mappings after loss of NAT gateway state, because that is the more | ||
684 | serious problem. Losing port mappings for outgoing connections | ||
685 | destroys those currently active connections, but does not prevent | ||
686 | clients from establishing new outgoing connections. In contrast, | ||
687 | losing inbound port mappings not only destroys all existing inbound | ||
688 | connections, but also prevents the reception of any new inbound | ||
689 | connections until the port mapping is recreated. Accordingly, | ||
690 | we consider recovery of inbound port mappings the more important | ||
691 | priority. However, clients that want outgoing connections to survive | ||
692 | a NAT gateway reboot can also achieve that using NAT-PMP. After | ||
693 | initiating an outbound TCP connection (which will cause the NAT | ||
694 | |||
695 | |||
696 | Expires 14th March 2007 Cheshire, et al. [Page 12] | ||
697 | |||
698 | Internet Draft NAT Port Mapping Protocol 14th September 2006 | ||
699 | |||
700 | |||
701 | gateway to establish an implicit port mapping) the client should send | ||
702 | the NAT gateway a port mapping request for the source port of its TCP | ||
703 | connection, which will cause the NAT gateway to send a response | ||
704 | giving the public port it allocated for that mapping. The client can | ||
705 | then store this information, and use later to recreate the mapping | ||
706 | if it determines that the NAT gateway has lost its mapping state. | ||
707 | |||
708 | |||
709 | 3.8 NAT Gateways with NAT Function Disabled | ||
710 | |||
711 | Note that *only* devices currently acting in the role of NAT gateway | ||
712 | should participate in NAT-PMP protocol exchanges with clients. | ||
713 | A network device that is capable of NAT (and NAT-PMP), but is | ||
714 | currently configured not to perform that function, (e.g. it is | ||
715 | acting as a traditional IP router, forwarding packets without | ||
716 | modifying them), MUST NOT respond to NAT-PMP requests from clients, | ||
717 | or send spontaneous NAT-PMP address-change announcements. | ||
718 | |||
719 | In particular, a network device not currently acting in the role of | ||
720 | NAT gateway should not even respond to NAT-PMP requests by returning | ||
721 | an error code such as "2 - Not Authorized/Refused", since to do so | ||
722 | is misleading to clients -- it suggests that NAT port mapping is | ||
723 | necessary on this network for the client to successfully receive | ||
724 | inbound connections, but is not available because the administrator | ||
725 | has chosen to disable that functionality. | ||
726 | |||
727 | Clients should also be careful to avoid making unfounded assumptions, | ||
728 | such as the assumption that if the client has an IPv4 address in | ||
729 | one of the RFC 1918 private IP address ranges then that means | ||
730 | NAT necessarily must be in use. Net 10/8 has enough addresses | ||
731 | to build a private network with millions of hosts and thousands | ||
732 | of interconnected subnets, all without any use of NAT. Many | ||
733 | organizations have built such private networks that benefit from | ||
734 | using standard TCP/IP technology, but by choice do not connect | ||
735 | to the public Internet. The purpose of NAT-PMP is to mitigate some | ||
736 | of the damage caused by NAT. It would be an ironic and unwanted | ||
737 | side-effect of this protocol if it were to lead well-meaning but | ||
738 | misguided developers to create products that refuse to work on a | ||
739 | private network *unless* they can find a NAT gateway to talk to. | ||
740 | Consequently, a client finding that NAT-PMP is not available on its | ||
741 | network should not give up, but should proceed on the assumption | ||
742 | that the network may be a traditional routed IP network, with no | ||
743 | address translation being used. This assumption may not always be | ||
744 | true, but it is better than the alternative of falsely assuming | ||
745 | the worst and not even trying to use normal (non-NAT) IP networking. | ||
746 | |||
747 | If a network device not currently acting in the role of NAT gateway | ||
748 | receives UDP packets addressed to port 5351, it SHOULD respond | ||
749 | immediately with an "ICMP Port Unreachable" message to tell the | ||
750 | client that it needn't continue with timeouts and retransmissions, | ||
751 | and it should assume that NAT-PMP is not available and not needed | ||
752 | on this network. | ||
753 | |||
754 | Expires 14th March 2007 Cheshire, et al. [Page 13] | ||
755 | |||
756 | Internet Draft NAT Port Mapping Protocol 14th September 2006 | ||
757 | |||
758 | |||
759 | 4. UNSAF Considerations | ||
760 | |||
761 | The document "IAB Considerations for UNSAF Across NAT" [RFC 3424] | ||
762 | covers a number of issues when working with NATs. RFC 3424 outlines | ||
763 | some requirements for any document that attempts to work around | ||
764 | problems associated with NATs. This section addresses those | ||
765 | requirements. | ||
766 | |||
767 | |||
768 | 4.1 Scope | ||
769 | |||
770 | This protocol addresses the needs of TCP and UDP transport peers that | ||
771 | are separated from the public internet by exactly one NAT. Such | ||
772 | peers must have access to some form of directory server for | ||
773 | registering the public IP address and port at which they can be | ||
774 | reached. | ||
775 | |||
776 | |||
777 | 4.2 Transition Plan | ||
778 | |||
779 | Any client making use of this protocol SHOULD implement IPv6 support. | ||
780 | If a client supports IPv6 and is running on a device with a global | ||
781 | IPv6 address, that IPv6 address SHOULD be preferred to the IPv4 | ||
782 | public address using this NAT mapping protocol. In case other | ||
783 | clients do not have IPv6 connectivity, both the IPv4 and IPv6 | ||
784 | addresses SHOULD be registered with whatever form of directory server | ||
785 | is used. Preference SHOULD be given to IPv6 addresses when | ||
786 | available. By implementing support for IPv6 and using this protocol | ||
787 | for IPv4, vendors can ship products today that will work under both | ||
788 | scenarios. As IPv6 is more widely deployed, clients of this protocol | ||
789 | following these recommendations will transparently make use of IPv6. | ||
790 | |||
791 | |||
792 | 4.3 Failure Cases | ||
793 | |||
794 | Aside from NATs that do not implement this protocol, there are a | ||
795 | number of situations where this protocol may not work. | ||
796 | |||
797 | |||
798 | 4.3.1 NAT Behind NAT | ||
799 | |||
800 | Some people's primary IP address, assigned by their ISP, may itself | ||
801 | be a NAT address. In addition, some people may have a public IP | ||
802 | address, but may then double NAT themselves, perhaps by choice or | ||
803 | perhaps by accident. Although it might be possible in principle for | ||
804 | one NAT gateway to recursively request a mapping from the next one, | ||
805 | this document does not advocate that and does not try to prescribe | ||
806 | how it would be done. | ||
807 | |||
808 | It would be a lot of work to implement nested NAT port mapping | ||
809 | correctly, and there are a number of reasons why the end result might | ||
810 | |||
811 | |||
812 | Expires 14th March 2007 Cheshire, et al. [Page 14] | ||
813 | |||
814 | Internet Draft NAT Port Mapping Protocol 14th September 2006 | ||
815 | |||
816 | |||
817 | not be as useful as we might hope. Consider the case of an ISP that | ||
818 | offers each of its customers only a single NAT address. This ISP | ||
819 | could instead have chosen to provide each customer with a single | ||
820 | public IP address, or, if the ISP insists on running NAT, it could | ||
821 | have chosen to allow each customer a reasonable number of addresses, | ||
822 | enough for each customer device to have its own NAT address directly | ||
823 | from the ISP. If instead this ISP chooses to allow each customer | ||
824 | just one and only one NAT address, forcing said customer to run | ||
825 | nested NAT in order to use more than one device, it seems unlikely | ||
826 | that such an ISP would be so obliging as to provide a NAT service | ||
827 | that supports NAT Port Mapping Protocol. Supposing that such an ISP | ||
828 | did wish to offer its customers NAT service with NAT-PMP so as to | ||
829 | give them the ability to receive inbound connections, this ISP could | ||
830 | easily choose to allow each client to request a reasonable number of | ||
831 | DHCP addresses from that gateway. Remember that Net 10/8 [RFC 1918] | ||
832 | allows for over 16 million addresses, so NAT addresses are not in any | ||
833 | way in short supply. A single NAT gateway with 16 million available | ||
834 | addresses is likely to run out of packet forwarding capacity before | ||
835 | it runs out of private addresses to hand out. In this way the ISP | ||
836 | could offer single-level NAT with NAT-PMP, obviating the need to | ||
837 | support nested NAT-PMP. In addition, an ISP that is motivated to | ||
838 | provide their customers with unhindered access to the Internet by | ||
839 | allowing incoming as well as outgoing connections has better ways | ||
840 | to offer this service. Such an ISP could offer its customers real | ||
841 | public IP addresses instead of NAT addresses, or could even choose | ||
842 | to offer its customers full IPv6 connectivity, where no mapping or | ||
843 | translation is required at all. | ||
844 | |||
845 | |||
846 | 4.3.2 NATs with Multiple Public IP Addresses | ||
847 | |||
848 | If a NAT maps private addresses to multiple public addresses, | ||
849 | then it SHOULD pick one of those addresses as the one it will | ||
850 | support for inbound connections, and for the purposes of this | ||
851 | protocol it SHOULD act as if that address were its only address. | ||
852 | |||
853 | |||
854 | 4.3.3 NATs and Routed Private Networks | ||
855 | |||
856 | In some cases, a large network may be subnetted. Some sites | ||
857 | may install a NAT gateway and subnet the private network. | ||
858 | Such subnetting breaks this protocol because the router address | ||
859 | is not necessarily the address of the device performing NAT. | ||
860 | |||
861 | Addressing this problem is not a high priority. Any site with the | ||
862 | resources to set up such a configuration should have the resources to | ||
863 | add manual mappings or attain a range of globally unique addresses. | ||
864 | |||
865 | Not all NATs will support this protocol. In the case where a client | ||
866 | is run behind a NAT that does not support this protocol, the software | ||
867 | relying on the functionality of this protocol may be unusable. | ||
868 | |||
869 | |||
870 | Expires 14th March 2007 Cheshire, et al. [Page 15] | ||
871 | |||
872 | Internet Draft NAT Port Mapping Protocol 14th September 2006 | ||
873 | |||
874 | |||
875 | 4.3.4 Communication Between Hosts Behind the Same NAT | ||
876 | |||
877 | NAT gateways supporting NAT-PMP should also implement "hairpin | ||
878 | translation". Hairpin translation means supporting communication | ||
879 | between two local clients being served by the same NAT gateway. | ||
880 | |||
881 | Suppose device A is listening on private address and port 10.0.0.2:80 | ||
882 | for incoming connections. Using NAT-PMP, device A has obtained a | ||
883 | mapping to public address and port x.x.x.x:80, and has recorded this | ||
884 | public address and port in a public directory of some kind. For | ||
885 | example, it could have created a DNS SRV record containing this | ||
886 | information, and recorded it, using DNS Dynamic Update [RFC 3007], in | ||
887 | a publicly accessible DNS server. Suppose then that device B, behind | ||
888 | the same NAT gateway as device A, but unknowing or uncaring of this | ||
889 | fact, retrieves device A's DNS SRV record and attempts to open a TCP | ||
890 | connection to x.x.x.x:80. The outgoing packets addressed to this | ||
891 | public Internet address will be sent to the NAT gateway for | ||
892 | translation and forwarding. Having translated the source address and | ||
893 | port number on the outgoing packet, the NAT gateway needs to be smart | ||
894 | enough to recognize that the destination address is in fact itself, | ||
895 | and then feed this packet back into its packet reception engine, to | ||
896 | perform the destination port mapping lookup to translate and forward | ||
897 | this packet to device A at address and port 10.0.0.2:80. | ||
898 | |||
899 | 4.3.5 Non UDP/TCP Transport Traffic | ||
900 | |||
901 | Any communication over transport protocols other than TCP and UDP | ||
902 | will not be served by this protocol. Examples are Generic Routing | ||
903 | Encapsulation (GRE), Authentication Header (AH) and Encapsulating | ||
904 | Security Payload (ESP). | ||
905 | |||
906 | 4.4 Long Term Solution | ||
907 | |||
908 | As IPv6 is deployed, clients of this protocol supporting IPv6 will be | ||
909 | able to bypass this protocol and the NAT when communicating with | ||
910 | other IPv6 devices. In order to ensure this transition, any client | ||
911 | implementing this protocol SHOULD also implement IPv6 and use this | ||
912 | solution only when IPv6 is not available to both peers. | ||
913 | |||
914 | 4.5 Existing Deployed NATs | ||
915 | |||
916 | Existing deployed NATs will not support this protocol. This protocol | ||
917 | will only work with NATs that are upgraded to support it. | ||
918 | |||
919 | |||
920 | |||
921 | |||
922 | |||
923 | |||
924 | |||
925 | |||
926 | |||
927 | |||
928 | Expires 14th March 2007 Cheshire, et al. [Page 16] | ||
929 | |||
930 | Internet Draft NAT Port Mapping Protocol 14th September 2006 | ||
931 | |||
932 | |||
933 | 5. Security Considerations | ||
934 | |||
935 | As discussed in section 3.2 "Determining the Public Address", only | ||
936 | clients on the private side of the NAT may create port mappings, and | ||
937 | only on behalf of themselves. By using IP address spoofing, it's | ||
938 | possible for one client to delete the port mappings of another | ||
939 | client. It's also possible for one client to create port mappings on | ||
940 | behalf of another client. The best way to deal with this | ||
941 | vulnerability is to use IPSec [RFC 2401]. | ||
942 | |||
943 | Since allowing incoming connections is often a policy decision, any | ||
944 | NAT gateway implementing this protocol SHOULD have an administrative | ||
945 | mechanism to disable it. | ||
946 | |||
947 | Some people view the property that NATs block inbound connections as | ||
948 | a security benefit which is undermined by this protocol. The authors | ||
949 | of this document have a different point of view. In the days before | ||
950 | NAT, all hosts had unique public IP addresses, and had unhindered | ||
951 | ability to communicate with any other host on the Internet. When NAT | ||
952 | came along it broke this unhindered connectivity, relegating many | ||
953 | hosts to second-class status, unable to receive inbound connections. | ||
954 | This protocol goes some way to undo some of that damage. The purpose | ||
955 | of a NAT gateway should be to allow several hosts to share a single | ||
956 | address, not to simultaneously impede those host's ability to | ||
957 | communicate freely. Security is most properly provided by end-to-end | ||
958 | cryptographic security, and/or by explicit firewall functionality, as | ||
959 | appropriate. Blocking of certain connections should occur only as a | ||
960 | result of explicit and intentional firewall policy, not as an | ||
961 | accidental side-effect of some other technology. | ||
962 | |||
963 | |||
964 | 6. IANA Considerations | ||
965 | |||
966 | No IANA services are required by this document. | ||
967 | |||
968 | |||
969 | 7. Acknowledgments | ||
970 | |||
971 | The concepts described in this document have been explored, developed | ||
972 | and implemented with help from Bob Bradley, Josh Graessley, Rob | ||
973 | Newberry, Roger Pantos, John Saxton, and James Woodyatt. | ||
974 | |||
975 | |||
976 | 8. Deployment History | ||
977 | |||
978 | NAT-PMP client software first became available to the public | ||
979 | through Apple's Darwin Open Source code in August 2004. | ||
980 | NAT-PMP implementations began shipping to end users in large | ||
981 | volumes (i.e. millions) with the launch of Mac OS X 10.4 Tiger | ||
982 | and Bonjour for Windows 1.0 in April 2005. | ||
983 | |||
984 | |||
985 | |||
986 | Expires 14th March 2007 Cheshire, et al. [Page 17] | ||
987 | |||
988 | Internet Draft NAT Port Mapping Protocol 14th September 2006 | ||
989 | |||
990 | |||
991 | The NAT-PMP client in Mac OS X 10.4 Tiger and Bonjour for Windows | ||
992 | exists as part of the mDNSResponder system service. When a client | ||
993 | advertises a service using Wide Area Bonjour [DNS-SD], and the | ||
994 | machine is behind a NAT-PMP-capable NAT gateway, then if the machine | ||
995 | is so configured, the mDNSResponder system service automatically uses | ||
996 | NAT-PMP to set up an inbound port mapping, and then records the | ||
997 | public IP address and port in the global DNS. Existing client | ||
998 | software using the existing Bonjour programming APIs [Bonjour] | ||
999 | gets this functionality automatically. The logic is that if client | ||
1000 | software publishes its information into the global DNS via Wide Area | ||
1001 | Bonjour service advertising, then it's reasonable to infer an | ||
1002 | expectation that this information should be usable by the peers | ||
1003 | retrieving it. Generally speaking, recording a private IP address | ||
1004 | like 10.0.0.2 in the public DNS is completely pointless because that | ||
1005 | address is not reachable from clients on the other side of the NAT | ||
1006 | gateway. In the case of a home user with a single computer directly | ||
1007 | connected to their Cable or DSL modem, with a single global IPv4 | ||
1008 | address and no NAT gateway (a surprisingly common configuration), | ||
1009 | publishing that IP address into the global DNS is useful because that | ||
1010 | IP address is reachable. In contrast, a home user using a NAT gateway | ||
1011 | to share a single global IPv4 address between several computers loses | ||
1012 | this ability to receive inbound connections easily. This breaks many | ||
1013 | peer-to-peer collaborative applications, like the multi-user text | ||
1014 | editor SubEthaEdit [SEE]. Automatically creating the necessary | ||
1015 | inbound port mappings helps remedy this unintended side-effect of | ||
1016 | NAT. | ||
1017 | |||
1018 | The server side of the NAT-PMP protocol is implemented in Apple's | ||
1019 | "AirPort Extreme" and "AirPort Express" wireless base stations. | ||
1020 | |||
1021 | |||
1022 | 9. Copyright Notice | ||
1023 | |||
1024 | Copyright (C) The Internet Society (2006). | ||
1025 | |||
1026 | This document is subject to the rights, licenses and restrictions | ||
1027 | contained in BCP 78, and except as set forth therein, the authors | ||
1028 | retain all their rights. For the purposes of this document, | ||
1029 | the term "BCP 78" refers exclusively to RFC 3978, "IETF Rights | ||
1030 | in Contributions", published March 2005. | ||
1031 | |||
1032 | This document and the information contained herein are provided on | ||
1033 | an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE | ||
1034 | REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE | ||
1035 | INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR | ||
1036 | IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF | ||
1037 | THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED | ||
1038 | WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. | ||
1039 | |||
1040 | |||
1041 | |||
1042 | |||
1043 | |||
1044 | Expires 14th March 2007 Cheshire, et al. [Page 18] | ||
1045 | |||
1046 | Internet Draft NAT Port Mapping Protocol 14th September 2006 | ||
1047 | |||
1048 | |||
1049 | 10. Normative References | ||
1050 | |||
1051 | [RFC 1918] Y. Rekhter et.al., "Address Allocation for Private | ||
1052 | Internets", RFC 1918, February 1996. | ||
1053 | |||
1054 | [RFC 2119] RFC 2119 - Key words for use in RFCs to Indicate | ||
1055 | Requirement Levels | ||
1056 | |||
1057 | |||
1058 | 11. Informative References | ||
1059 | |||
1060 | [Bonjour] Apple "Bonjour" <http://developer.apple.com/bonjour/> | ||
1061 | |||
1062 | [ETEAISD] J. Saltzer, D. Reed and D. Clark: "End-to-end arguments in | ||
1063 | system design", ACM Trans. Comp. Sys., 2(4):277-88, Nov. | ||
1064 | 1984 | ||
1065 | |||
1066 | [DNS-SD] Cheshire, S., and M. Krochmal, "DNS-Based Service | ||
1067 | Discovery", Internet-Draft (work in progress), | ||
1068 | draft-cheshire-dnsext-dns-sd-04.txt, August 2006. | ||
1069 | |||
1070 | [mDNS] Cheshire, S., and M. Krochmal, "Multicast DNS", | ||
1071 | Internet-Draft (work in progress), | ||
1072 | draft-cheshire-dnsext-multicastdns-06.txt, August 2006. | ||
1073 | |||
1074 | [RFC 2131] R. Droms, "Dynamic Host Configuration Protocol", RFC 2131, | ||
1075 | March 1997. | ||
1076 | |||
1077 | [RFC 2401] Atkinson, R. and S. Kent, "Security Architecture for the | ||
1078 | Internet Protocol", RFC 2401, November 1998. | ||
1079 | |||
1080 | [RFC 2663] Srisuresh, P. and M. Holdrege, "IP Network Address | ||
1081 | Translator (NAT) Terminology and Considerations", RFC | ||
1082 | 2663, August 1999. | ||
1083 | |||
1084 | [RFC 3007] Wellington, B., "Simple Secure Domain Name System | ||
1085 | (DNS) Dynamic Update", RFC 3007, November 2000. | ||
1086 | |||
1087 | [SEE] <http://www.codingmonkeys.de/subethaedit/> | ||
1088 | |||
1089 | [RFC 3022] RFC 3022 - Network Address Translator | ||
1090 | |||
1091 | [RFC 3424] RFC 3424 - IAB Considerations for UNilateral Self-Address | ||
1092 | Fixing (UNSAF) Across Network Address Translation | ||
1093 | |||
1094 | |||
1095 | |||
1096 | |||
1097 | |||
1098 | |||
1099 | |||
1100 | |||
1101 | |||
1102 | Expires 14th March 2007 Cheshire, et al. [Page 19] | ||
1103 | |||
1104 | Internet Draft NAT Port Mapping Protocol 14th September 2006 | ||
1105 | |||
1106 | |||
1107 | 12. Authors' Addresses | ||
1108 | |||
1109 | Stuart Cheshire | ||
1110 | Apple Computer, Inc. | ||
1111 | 1 Infinite Loop | ||
1112 | Cupertino | ||
1113 | California 95014 | ||
1114 | USA | ||
1115 | |||
1116 | Phone: +1 408 974 3207 | ||
1117 | EMail: rfc [at] stuartcheshire [dot] org | ||
1118 | |||
1119 | |||
1120 | Marc Krochmal | ||
1121 | Apple Computer, Inc. | ||
1122 | 1 Infinite Loop | ||
1123 | Cupertino | ||
1124 | California 95014 | ||
1125 | USA | ||
1126 | |||
1127 | Phone: +1 408 974 4368 | ||
1128 | EMail: marc [at] apple [dot] com | ||
1129 | |||
1130 | |||
1131 | Kiren Sekar | ||
1132 | Sharpcast, Inc. | ||
1133 | 250 Cambridge Ave, Suite 101 | ||
1134 | Palo Alto | ||
1135 | California 94306 | ||
1136 | USA | ||
1137 | |||
1138 | Phone: +1 650 323 1960 | ||
1139 | EMail: ksekar [at] sharpcast [dot] com | ||
1140 | |||
1141 | |||
1142 | |||
1143 | |||
1144 | |||
1145 | |||
1146 | |||
1147 | |||
1148 | |||
1149 | |||
1150 | |||
1151 | |||
1152 | |||
1153 | |||
1154 | |||
1155 | |||
1156 | |||
1157 | |||
1158 | |||
1159 | |||
1160 | Expires 14th March 2007 Cheshire, et al. [Page 20] | ||