aboutsummaryrefslogtreecommitdiff
path: root/src/upnp/draft-cheshire-nat-pmp.txt
diff options
context:
space:
mode:
Diffstat (limited to 'src/upnp/draft-cheshire-nat-pmp.txt')
-rw-r--r--src/upnp/draft-cheshire-nat-pmp.txt1160
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 @@
1Document: draft-cheshire-nat-pmp-02.txt Stuart Cheshire
2Internet-Draft Marc Krochmal
3Category: Standards Track Apple Computer, Inc.
4Expires 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
12Status 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
39Abstract
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
58Expires 14th March 2007 Cheshire, et al. [Page 1]
59
60Internet Draft NAT Port Mapping Protocol 14th September 2006
61
62
631. 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
116Expires 14th March 2007 Cheshire, et al. [Page 2]
117
118Internet 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
1332. 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
1413. 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
174Expires 14th March 2007 Cheshire, et al. [Page 3]
175
176Internet Draft NAT Port Mapping Protocol 14th September 2006
177
178
1793.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
2213.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
232Expires 14th March 2007 Cheshire, et al. [Page 4]
233
234Internet 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
2663.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
290Expires 14th March 2007 Cheshire, et al. [Page 5]
291
292Internet Draft NAT Port Mapping Protocol 14th September 2006
293
294
2953.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
348Expires 14th March 2007 Cheshire, et al. [Page 6]
349
350Internet 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
406Expires 14th March 2007 Cheshire, et al. [Page 7]
407
408Internet 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
4533.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
464Expires 14th March 2007 Cheshire, et al. [Page 8]
465
466Internet 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
522Expires 14th March 2007 Cheshire, et al. [Page 9]
523
524Internet Draft NAT Port Mapping Protocol 14th September 2006
525
526
5273.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
5593.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
580Expires 14th March 2007 Cheshire, et al. [Page 10]
581
582Internet Draft NAT Port Mapping Protocol 14th September 2006
583
584
5853.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
638Expires 14th March 2007 Cheshire, et al. [Page 11]
639
640Internet 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
696Expires 14th March 2007 Cheshire, et al. [Page 12]
697
698Internet 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
7093.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
754Expires 14th March 2007 Cheshire, et al. [Page 13]
755
756Internet Draft NAT Port Mapping Protocol 14th September 2006
757
758
7594. 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
7684.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
7774.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
7924.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
7984.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
812Expires 14th March 2007 Cheshire, et al. [Page 14]
813
814Internet 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
8464.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
8544.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
870Expires 14th March 2007 Cheshire, et al. [Page 15]
871
872Internet Draft NAT Port Mapping Protocol 14th September 2006
873
874
8754.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
8994.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
9064.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
9144.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
928Expires 14th March 2007 Cheshire, et al. [Page 16]
929
930Internet Draft NAT Port Mapping Protocol 14th September 2006
931
932
9335. 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
9646. IANA Considerations
965
966 No IANA services are required by this document.
967
968
9697. 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
9768. 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
986Expires 14th March 2007 Cheshire, et al. [Page 17]
987
988Internet 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
10229. 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
1044Expires 14th March 2007 Cheshire, et al. [Page 18]
1045
1046Internet Draft NAT Port Mapping Protocol 14th September 2006
1047
1048
104910. 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
105811. 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
1102Expires 14th March 2007 Cheshire, et al. [Page 19]
1103
1104Internet Draft NAT Port Mapping Protocol 14th September 2006
1105
1106
110712. 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
1160Expires 14th March 2007 Cheshire, et al. [Page 20]