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