idnits 2.17.1 draft-cheshire-nat-pmp-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. == There are 2 instances 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 IETF Trust and authors 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 (27 August 2012) is 4260 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-29) exists of draft-ietf-pcp-base-26 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Document: draft-cheshire-nat-pmp-04.txt Stuart Cheshire 3 Internet-Draft Marc Krochmal 4 Category: Informational Apple Inc. 5 Expires 27th February 2013 27 August 2012 7 NAT Port Mapping Protocol (NAT-PMP) 8 10 Abstract 12 This document describes a protocol for automating the process of 13 creating Network Address Translation (NAT) port mappings. Included in 14 the protocol is a method for retrieving the external IPv4 address of 15 a NAT gateway, thus allowing a client to make this external IPv4 16 address and port known to peers that may wish to communicate with it. 17 This protocol is implemented in current Apple products including Mac 18 OS X, Bonjour for Windows, and AirPort wireless base stations. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 Copyright Notice 37 Copyright (c) 2012 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction.................................................3 53 2. Conventions and Terminology Used in this Document............4 54 3. Protocol and Packet Format...................................5 55 3.1 Requests and Responses.......................................5 56 3.2 Determining the External Address.............................7 57 3.2.1 Announcing Address Changes...................................7 58 3.3 Requesting a Mapping.........................................9 59 3.4 Destroying a Mapping........................................12 60 3.5 Result Codes................................................13 61 3.6 Seconds Since Start of Epoch................................14 62 3.7 Recreating Mappings On NAT Gateway Reboot...................15 63 3.8 NAT Gateways with NAT Function Disabled.....................17 64 3.9 All Mappings are Bidirectional..............................18 65 4. UNSAF Considerations........................................19 66 4.1 Scope.......................................................19 67 4.2 Transition Plan.............................................19 68 4.3 Failure Cases...............................................19 69 4.4 Long Term Solution..........................................21 70 4.5 Existing Deployed NATs......................................21 71 5. Security Considerations.....................................22 72 6. IANA Considerations.........................................22 73 7. Acknowledgments.............................................23 74 8. Deployment History..........................................22 75 9. Noteworthy Features of NAT Port Mapping Protocol and PCP....24 76 9.1 Simplicity..................................................25 77 9.2 Focussed Scope..............................................25 78 9.3 Efficiency..................................................25 79 9.4 Atomic Allocation Operations................................27 80 9.5 Garbage Collection..........................................27 81 9.6 State Change Announcements..................................28 82 9.7 Soft State Recovery.........................................28 83 10. Normative References .......................................29 84 11. Informative References .....................................29 85 12. Authors' Addresses..........................................30 87 1. Introduction 89 Network Address Translation (NAT) is a method of sharing one public 90 internet address with a number of devices. This document is focused 91 on devices that are formally classified as "NAPTs" (Network 92 Address/Port Translators) [RFC 2663]. A full description of NAT is 93 beyond the scope of this document. The following brief overview will 94 cover the aspects relevant to this port mapping protocol. For more 95 information on NAT, see "Traditional IP Network Address Translator" 96 [RFC 3022]. 98 NATs have one or more external IP addresses. A private network is 99 set up behind the NAT. Devices behind the NAT are assigned private 100 addresses and the private address of the NAT device is used as the 101 gateway. 103 When a packet from any device behind the NAT is sent to an address on 104 the public Internet, the packet first passes through the NAT box. The 105 NAT box looks at the source port and address. In some cases, a NAT 106 will also keep track of the destination port and address. The NAT 107 then creates a mapping from the internal address and internal port to 108 an external address and external port if a mapping does not already 109 exist. 111 The NAT box replaces the internal address and port in the 112 packet with the external entries from the mapping and sends the 113 packet on to the next gateway. 115 When a packet from any address on the Internet is received on the 116 NAT's external side, the NAT will look up the destination address and 117 port (external address and port) in the list of mappings. If an entry 118 is found, it will contain the internal address and port that the 119 packet should be sent to. The NAT gateway will then rewrite the 120 destination address and port with those from the mapping. The packet 121 will then be forwarded to the new destination addresses. If the 122 packet did not match any mapping, the packet will most likely be 123 dropped. Various NATs implement different strategies to handle this. 124 The important thing to note is that if there is no mapping, the NAT 125 does not know to which internal address the packet should be sent. 127 Mappings are usually created automatically as a result of observing 128 outbound packets. There are a few exceptions. Some NATs may allow 129 manually-created permanent mappings that map an external port to a 130 specific internal IP address and port. Such a mapping allows incoming 131 connections to the device with that internal address. Some NATs also 132 implement a default mapping where any inbound packet that does not 133 match any other more specific mapping will be forwarded to a 134 specified internal address. Both types of mappings are usually set up 135 manually through some configuration tool. 137 Without these manually-created inbound port mappings, clients behind 138 the NAT would be unable to receive inbound connections, which 139 represents a loss of connectivity when compared to the original 140 Internet architecture [ETEAISD]. For those who view this loss of 141 connectivity as a bad thing, NAT-PMP allows clients to operate 142 more like a host directly connected to the unrestricted public 143 Internet, with an unrestricted public IPv4 address. NAT-PMP allows 144 client hosts to communicate with the NAT gateway to request the 145 creation of inbound mappings on demand. Having created a NAT mapping 146 to allow inbound connections, the client can then record its external 147 IPv4 address and external port in a public registry (e.g. the 148 world-wide Domain Name System) or otherwise make it accessible to 149 peers that wish to communicate with it. 151 2. Conventions and Terminology Used in this Document 153 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 154 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 155 document are to be interpreted as described in "Key words for use in 156 RFCs to Indicate Requirement Levels" [RFC 2119]. 158 3. Protocol and Packet Format 160 NAT Port Mapping Protocol runs over UDP. Every packet starts with an 161 8 bit version followed by an 8 bit operation code. 163 All numeric quantities in NAT-PMP larger than a single byte are 164 transmitted in the traditional IETF network byte order (i.e. most 165 significant byte first). 167 This document specifies version 0 of the protocol. Any NAT-PMP 168 gateway implementing this version of the protocol, receiving a 169 request with a version number other than 0, MUST return result code 1 170 (Unsupported Version), indicating the highest version number it 171 does support (i.e. 0) in the version field of the response. 173 Opcodes between 0 and 127 are client requests. Opcodes from 128 to 174 255 are server responses. Responses always contain a 16 bit result 175 code in network byte order. A result code of zero indicates success. 176 Responses also contain a 32 bit unsigned integer corresponding to the 177 number of seconds since the NAT gateway was rebooted or since its 178 port mapping state was reset. 180 This protocol SHOULD only be used when the client determines that 181 its primary IPv4 address is in one of the private IPv4 address ranges 182 defined in "Address Allocation for Private Internets" [RFC 1918]. 183 This includes the address ranges 10/8, 172.16/12, and 192.168/16. 185 Clients always send their Port Mapping Protocol requests to their 186 default gateway, as learned via DHCP [RFC 2131], or similar means. 187 This protocol is designed for small home networks, with a single 188 logical link (subnet) where the client's default gateway is also the 189 NAT translator for that network. For more complicated networks where 190 the NAT translator is some device other than the client's default 191 gateway, this protocol is not appropriate. 193 3.1. Requests and Responses 195 NAT gateways are often low-cost devices, with limited memory and 196 CPU speed. For this reason, to avoid making excessive demands on 197 the NAT gateway, clients machines SHOULD NOT issue multiple requests 198 simultaneously in parallel. If a client needs to perform multiple 199 requests (e.g. on boot, wake from sleep, network connection, etc.) 200 it SHOULD queue them and issue them serially one at a time. Once the 201 NAT gateway responds to one request the client machine may issue the 202 next. In the case of a fast NAT gateway, the client may be able to 203 complete requests at a rate of hundreds per second. In the case of 204 a slow NAT gateway that takes perhaps half a second to respond to 205 a NAT-PMP request, the client SHOULD respect this and allow the 206 NAT gateway to operate at the pace it can manage, and not overload 207 it by issuing requests faster than the rate it's answering them. 209 To determine the external IPv4 address or request a port mapping, 210 a NAT-PMP client sends its request packet to port 5351 of its 211 configured gateway address, and waits 250ms for a response. If no 212 NAT-PMP response is received from the gateway after 250ms, the client 213 retransmits its request and waits 500ms. The client SHOULD repeat 214 this process with the interval between attempts doubling each time. 215 If, after sending its 9th attempt (and then waiting for 64 seconds), 216 the client has still received no response, then it SHOULD conclude 217 that this gateway does not support NAT Port Mapping Protocol and 218 MAY log an error message indicating this fact. In addition, if the 219 NAT-PMP client receives an "ICMP Port Unreachable" message from the 220 gateway for port 5351 then it can skip any remaining retransmissions 221 and conclude immediately that the gateway does not support NAT-PMP. 223 As a performance optimization the client MAY record this information 224 and use it to suppress further attempts to use NAT-PMP, but the 225 client should not retain this information for too long. In 226 particular, any event that may indicate a potential change of gateway 227 or a change in gateway configuration (hardware link change 228 indication, change of gateway MAC address, acquisition of new DHCP 229 lease, receipt of NAT-PMP announcement packet from gateway, etc.) 230 should cause the client to discard its previous information regarding 231 the gateway's lack of NAT-PMP support, and send its next NAT-PMP 232 request packet normally. 234 When deleting a port mapping, the client uses the same initial 250ms 235 timeout, doubling on each successive interval, except that clients 236 may choose not to try the full nine times before giving up. This 237 is because mapping deletion requests are in some sense advisory. 238 They are useful for efficiency, but not required for correctness; 239 it is always possible for client software to crash, or for power to 240 fail, or for a client device to be physically unplugged from the 241 network before it gets a chance to send its mapping deletion 242 request(s), so NAT gateways already need to cope with this case. 243 Because of this, it may be acceptable for a client to retry only once 244 or twice before giving up on deleting its port mapping(s), but a 245 client SHOULD always send at least one deletion request whenever 246 possible, to reduce the amount of stale state that accumulates on 247 NAT gateways. 249 A client need not continue trying to delete a port mapping after the 250 time when that mapping would naturally have expired anyway. 252 3.2. Determining the External Address 254 To determine the external address, the client behind the NAT sends 255 the following UDP payload to port 5351 of the configured gateway 256 address: 258 0 1 259 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 261 | Vers = 0 | OP = 0 | 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 A compatible NAT gateway MUST generate a response with the following 265 format: 267 0 1 2 3 268 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 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 | Vers = 0 | OP = 128 + 0 | Result Code (net byte order) | 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 | Seconds Since Start of Epoch (in network byte order) | 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 | External IPv4 Address (a.b.c.d) | 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 277 This response indicates that the NAT gateway implements this version 278 of the protocol and returns the external IPv4 address of the NAT 279 gateway. If the result code is non-zero, the value of External IPv4 280 Address is undefined (MUST be set to zero on transmission, and MUST 281 be ignored on reception). 283 The NAT gateway MUST fill in the "Seconds Since Start of Epoch" field 284 with the time elapsed since its port mapping table was initialized on 285 startup or reset for any other reason (see Section 3.6 "Seconds Since 286 Start of Epoch"). 288 Upon receiving a response packet, the client MUST check the source 289 IP address, and silently discard the packet if the address is not the 290 address of the gateway to which the request was sent. 292 3.2.1. Announcing Address Changes 294 Upon boot, acquisition of an external IPv4 address, subsequent change 295 of the external IPv4 address, reboot, or any other event that may 296 indicate possible loss or change of NAT mapping state, the NAT 297 gateway MUST send a gratuitous response to the link-local multicast 298 address 224.0.0.1, port 5350, with the packet format above, to notify 299 clients of the external IPv4 address and Seconds Since Start of 300 Epoch. 302 To accommodate packet loss, the NAT gateway SHOULD multicast 10 303 address notifications. The interval between the first two 304 notifications SHOULD be 250ms, and the interval between each 305 subsequent notification SHOULD double. The Seconds Since Start of 306 Epoch field in each transmission MUST be updated appropriately to 307 reflect the passage of time, so as not to trigger unnecessary 308 additional mapping renewals (See Section 3.7 "Recreating Mappings On 309 NAT Gateway Reboot".) 311 Upon receiving a gratuitous address announcement packet, the client 312 MUST check the source IP address, and silently discard the packet if 313 the address is not the address of the client's current configured 314 gateway. This is to guard against inadvertent misconfigurations where 315 there may be more than one NAT gateway active on the network. 317 If the source IP address is correct, then the Seconds Since Start of 318 Epoch field is checked as described in Section 3.6, and if the value 319 is outside the expected plausible range, indicating that a NAT 320 gateway state loss has occurred, then the NAT-PMP client promptly 321 recreates all its active port mapping leases, as described in 322 Section 3.7 "Recreating Mappings On NAT Gateway Reboot". 324 IMPLEMENTATION NOTE: Earlier implementations of NAT-PMP used UDP port 325 5351 as the destination both for client requests (address and port 326 mapping) and for address announcements. NAT-PMP servers would listen 327 on UDP 5351 for client requests, and NAT-PMP clients would listen on 328 UDP 5351 for server announcements. However, implementers encountered 329 difficulties when a single device is acting in both roles, for 330 example a home computer with Internet Sharing enabled. This computer 331 is acting in the role of NAT-PMP server to its DHCP clients, yet at 332 the same time it has to act in the role of NAT-PMP client in order to 333 determine whether it is, itself, behind another NAT gateway. While in 334 principle it might be possible on some operating systems for two 335 processes to coordinate sharing of a single UDP port, on many 336 platforms this is difficult or even impossible, so for pragmatic 337 engineering reasons it is convenient to have clients listen on UDP 338 5350 and servers listen on UDP 5351. 340 IMPLEMENTATION NOTE: A given host may have more than one independent 341 NAT-PMP client running at the same time, and address announcements 342 need to be available to all of them. Clients should therefore set the 343 SO_REUSEPORT option or equivalent in order to allow other processes 344 to also listen on port 5350. Additionally, implementers have 345 encountered issues when one or more processes on the same device 346 listen to port 5350 on *all* addresses. Clients should therefore bind 347 specifically to 224.0.0.1:5350, not to 0.0.0.0:5350. 349 3.3. Requesting a Mapping 351 To create a mapping, the client sends a UDP packet to port 5351 352 of the gateway's internal IP address with the following format: 354 0 1 2 3 355 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 356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 357 | Vers = 0 | OP = x | Reserved | 358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 359 | Internal Port | Suggested External Port | 360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 361 | Requested Port Mapping Lifetime in Seconds | 362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 364 Opcodes supported: 365 1 - Map UDP 366 2 - Map TCP 368 The Reserved field MUST be set to zero on transmission and MUST 369 be ignored on reception. 371 The Ports and Lifetime are transmitted in the traditional network 372 byte order (i.e. most significant byte first). 374 The Internal Port is set to the local port on which the client is 375 listening. 377 If the client would prefer to have a high-numbered "anonymous" 378 external port assigned, then it should set the Suggested External 379 Port to zero, which indicates to the gateway that it should allocate 380 a high-numbered port of its choosing. If the client would prefer 381 instead to have the mapped external port be the same as its local 382 Internal Port if possible (e.g. a web server listening on port 80 383 that would ideally like to have external port 80) then it should set 384 the Suggested External Port to the desired value. However, the 385 gateway is not obliged to assign the port suggested, and may choose 386 not to, either for policy reasons (e.g. port 80 is reserved and 387 clients may not request it) or because that port has already been 388 assigned to some other client. Because of this, some product 389 developers have questioned the value of having the Suggested External 390 Port field at all. The reason is for failure recovery. Most low-cost 391 home NAT gateways do not record temporary port mappings in persistent 392 storage, so if the gateway crashes or is rebooted, all the mappings 393 are lost. A renewal packet is formatted identically to an initial 394 mapping request packet, except that for renewals the client sets the 395 Suggested External Port field to the port the gateway actually 396 assigned, rather than the port the client originally wanted. When a 397 freshly-rebooted NAT gateway receives a renewal packet from a client, 398 it appears to the gateway just like an ordinary initial request for 399 a port mapping, except that in this case the Suggested External Port 400 is likely to be one that the NAT gateway *is* willing to allocate 401 (it allocated it to this client right before the reboot, so it should 402 presumably be willing to allocate it again). This improves the 403 stability of external ports across NAT gateway restarts. 405 The RECOMMENDED Port Mapping Lifetime is 7200 seconds (two hours). 407 After sending the port mapping request, the client then waits for the 408 NAT gateway to respond. If after 250ms, the client hasn't received a 409 response from the gateway, the client SHOULD re-issue its request as 410 described above in Section 3.1 "Requests and Responses". 412 The NAT gateway responds with the following packet format: 414 0 1 2 3 415 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 416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 417 | Vers = 0 | OP = 128 + x | Result Code | 418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 419 | Seconds Since Start of Epoch | 420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 421 | Internal Port | Mapped External Port | 422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 423 | Port Mapping Lifetime in Seconds | 424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 426 The Epoch time, Ports and Lifetime are transmitted in the traditional 427 network byte order (i.e. most significant byte first). 429 The 'x' in the OP field MUST match what the client requested. Some 430 NAT gateways are incapable of creating a UDP port mapping without 431 also creating a corresponding TCP port mapping, and vice versa, and 432 these gateways MUST NOT implement NAT Port Mapping Protocol until 433 this deficiency is fixed. A NAT gateway which implements this 434 protocol MUST be able to create TCP-only and UDP-only port mappings. 435 If a NAT gateway silently creates a pair of mappings for a client 436 that only requested one mapping, then it may expose that client to 437 receiving inbound UDP packets or inbound TCP connection requests 438 that it did not ask for and does not want. 440 While a NAT gateway MUST NOT automatically create mappings for TCP 441 when the client requests UDP, and vice versa, the NAT gateway MUST 442 reserve the companion port so the same client can choose to map it 443 in the future. For example, if a client requests to map TCP port 80, 444 as long as the client maintains the lease for that TCP port mapping, 445 another client with a different internal IP address MUST NOT be able 446 to successfully acquire the mapping for UDP port 80. 448 The client normally requests the external port matching the internal 449 port. If that external port is not available, the NAT gateway MUST 450 return an available external port if possible, or return an error 451 code if no external ports are available. 453 The source address of the packet MUST be used for the internal 454 address in the mapping. This protocol is not intended to facilitate 455 one device behind a NAT creating mappings for other devices. If there 456 are legacy devices that require inbound mappings, permanent mappings 457 can be created manually by the user through an administrative 458 interface, just as they are today. 460 If a mapping already exists for a given internal address and port 461 (whether that mapping was created explicitly using NAT-PMP, 462 implicitly as a result of an outgoing TCP SYN packet, or manually by 463 a human administrator) and that client requests another mapping for 464 the same internal port (possibly requesting a different external 465 port) then the mapping request should succeed, returning the 466 already-assigned external port. This is necessary to handle the case 467 where a client requests a mapping with suggested external port X, and 468 is granted a mapping with actual external port Y, but the 469 acknowledgement packet gets lost. When the client retransmits its 470 mapping request, it should get back the same positive acknowledgement 471 as was sent (and lost) the first time. 473 The NAT gateway MUST NOT accept mapping requests destined to the 474 NAT gateway's external IP address or received on its external network 475 interface. Only packets received on the internal interface(s) with 476 a destination address matching the internal address(es) of the NAT 477 gateway should be allowed. 479 The NAT gateway MUST fill in the "Seconds Since Start of Epoch" field 480 with the time elapsed since its port mapping table was initialized on 481 startup or reset for any other reason (see Section 3.6 "Seconds Since 482 Start of Epoch"). 484 The Port Mapping Lifetime is an unsigned integer in seconds. The NAT 485 gateway MAY reduce the lifetime from what the client requested. The 486 NAT gateway SHOULD NOT offer a lease lifetime greater than that 487 requested by the client. 489 Upon receiving the response packet, the client MUST check the source 490 IP address, and silently discard the packet if the address is not the 491 address of the gateway to which the request was sent. 493 The client SHOULD begin trying to renew the mapping halfway to expiry 494 time, like DHCP. The renewal packet should look exactly the same as 495 a request packet, except that the client SHOULD set the Suggested 496 External Port to what the NAT gateway previously mapped, not what the 497 client originally suggested. As described above, this enables the 498 gateway to automatically recover its mapping state after a crash or 499 reboot. 501 3.4. Destroying a Mapping 503 A mapping may be destroyed in a variety of ways. If a client fails 504 to renew a mapping, then when its lifetime expires the mapping MUST 505 be automatically deleted. In the common case where the gateway 506 device is a combined DHCP server and NAT gateway, when a client's 507 DHCP address lease expires, the gateway device MAY automatically 508 delete any mappings belonging to that client. Otherwise a new client 509 being assigned the same IP address could receive unexpected inbound 510 UDP packets or inbound TCP connection requests that it did not ask 511 for and does not want. 513 A client MAY also send an explicit packet to request deletion of a 514 mapping that is no longer needed. A client requests explicit 515 deletion of a mapping by sending a message to the NAT gateway 516 requesting the mapping, with the Requested Lifetime in Seconds set 517 to zero. The Suggested External Port MUST be set to zero by the 518 client on sending, and MUST be ignored by the gateway on reception. 520 When a mapping is destroyed successfully as a result of the client 521 explicitly requesting the deletion, the NAT gateway MUST send a 522 response packet which is formatted as defined in Section 3.3 523 "Requesting a Mapping". The response MUST contain a result code of 0, 524 the internal port as indicated in the deletion request, an external 525 port of 0, and a lifetime of 0. The NAT gateway MUST respond to 526 a request to destroy a mapping that does not exist as if the 527 request were successful. This is because of the case where the 528 acknowledgement is lost, and the client retransmits its request to 529 delete the mapping. In this case the second request to delete the 530 mapping MUST return the same response packet as the first request. 532 If the deletion request was unsuccessful, the response MUST contain 533 a non-zero result code and the requested mapping; the lifetime is 534 undefined (MUST be set to zero on transmission, and MUST be ignored 535 on reception). If the client attempts to delete a port mapping which 536 was manually assigned by some kind of configuration tool, the NAT 537 gateway MUST respond with a 'Not Authorized' error, result code 2. 539 When a mapping is destroyed as a result of its lifetime expiring or 540 for any other reason, if the NAT gateway's internal state indicates 541 that there are still active TCP connections traversing that now- 542 defunct mapping, then the NAT gateway SHOULD send appropriately- 543 constructed TCP RST (reset) packets both to the local client and to 544 the remote peer on the Internet to terminate that TCP connection. 546 A client can request the explicit deletion of all its UDP or TCP 547 mappings by sending the same deletion request to the NAT gateway with 548 external port, internal port, and lifetime set to zero. A client MAY 549 choose to do this when it first acquires a new IP address in order to 550 protect itself from port mappings that were performed by a previous 551 owner of the IP address. After receiving such a deletion request, the 552 gateway MUST delete all its UDP or TCP port mappings (depending on 553 the opcode). The gateway responds to such a deletion request with a 554 response as described above, with the internal port set to zero. If 555 the gateway is unable to delete a port mapping, for example, because 556 the mapping was manually configured by the administrator, the gateway 557 MUST still delete as many port mappings as possible, but respond with 558 a non-zero result code. The exact result code to return depends on 559 the cause of the failure. If the gateway is able to successfully 560 delete all port mappings as requested, it MUST respond with a result 561 code of zero. 563 3.5. Result Codes 565 Currently defined result codes: 566 0 - Success 567 1 - Unsupported Version 568 2 - Not Authorized/Refused 569 (e.g. box supports mapping, but user has turned feature off) 570 3 - Network Failure 571 (e.g. NAT box itself has not obtained a DHCP lease) 572 4 - Out of resources 573 (NAT box cannot create any more mappings at this time) 574 5 - Unsupported opcode 576 If the version in the request is not zero, then the NAT-PMP server 577 MUST return the following "Unsupported Version" error response to the 578 client: 580 0 1 2 3 581 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 582 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 583 | Vers = 0 | OP = 0 | Result Code = 1 | 584 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 585 | Seconds Since Start of Epoch (in network byte order) | 586 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 588 If the opcode in the request is 128 or greater, then this is not a 589 request; it's a response, and the NAT-PMP server MUST silently ignore 590 it. Otherwise, if the opcode in the request is less than 128, but is 591 not a supported opcode (currently 0, 1 or 2), then the entire request 592 MUST be returned to the sender, with the top bit of the opcode set 593 (to indicate that this is a response) and the result code set to 5 594 (Unsupported opcode). 596 For version 0 and a supported opcode (0, 1 or 2), if the operation 597 fails for some reason (Not Authorized, Network Failure, or Out of 598 resources) then a valid response MUST be sent to the client, 599 with the top bit of the opcode set (to indicate that this is a 600 response) and the result code set appropriately. Other fields in 601 the response MUST be set appropriately. Specifically: 603 o Seconds Since Start of Epoch MUST be set correctly 605 o The External IPv4 Address should be set to the correct address, 606 or to 0.0.0.0, as appropriate. 608 o The Internal Port MUST be set to the client's requested Internal 609 Port. This is particularly important, because the client needs 610 this information to identify which request suffered the failure. 612 o The Mapped External Port and Port Mapping Lifetime MUST be set 613 appropriately -- i.e. zero if no successful port mapping was 614 created. 616 Should future NAT-PMP opcodes be defined, their error responses MUST 617 similarly be specified to include sufficient information to identify 618 which request suffered the failure. By design, NAT-PMP messages do 619 not contain any transaction identifier. All NAT-PMP messages are 620 idempotent and self-describing; therefore the specifications of 621 future NAT-PMP messages need to include enough information for their 622 responses to be self-describing. 624 Clients MUST be able to properly handle result codes not defined in 625 this document. Undefined results codes MUST be treated as fatal 626 errors of the request. 628 3.6. Seconds Since Start of Epoch 630 Every packet sent by the NAT gateway includes a "Seconds since start 631 of epoch" field (SSSOE). If the NAT gateway resets or loses the state 632 of its port mapping table, due to reboot, power failure, or any other 633 reason, it MUST reset its epoch time and begin counting SSSOE from 634 zero again. Whenever a client receives any packet from the NAT 635 gateway, either gratuitously or in response to a client request, the 636 client computes its own conservative estimate of the expected SSSOE 637 value by taking the SSSOE value in the last packet it received from 638 the gateway and adding 7/8 (87.5%) of the time elapsed according to 639 the client's local clock since that packet was received. If the SSSOE 640 in the newly received packet is less than the client's conservative 641 estimate by more than two seconds, then the client concludes that 642 the NAT gateway has undergone a reboot or other loss of port mapping 643 state, and the client MUST immediately renew all its active port 644 mapping leases as described in Section 3.7 "Recreating Mappings On 645 NAT Gateway Reboot". 647 3.7. Recreating Mappings On NAT Gateway Reboot 649 The NAT gateway MAY store mappings in persistent storage so that when 650 it is powered off or rebooted, it remembers the port mapping state of 651 the network. 653 However, maintaining this state is not essential for correct 654 operation. When the NAT gateway powers on or clears its port mapping 655 state as the result of a configuration change, it MUST reset the 656 epoch time and re-announce its IPv4 address as described in Section 657 3.2.1 "Announcing Address Changes". Reception of this packet where 658 time has apparently gone backwards serves as a hint to clients 659 on the network that they SHOULD immediately send renewal packets 660 (to immediately recreate their mappings) instead of waiting until 661 the originally scheduled time for those renewals. Clients who miss 662 receiving those gateway announcement packets for any reason will 663 still renew their mappings at the originally scheduled time and cause 664 their mappings to be recreated; it will just take a little longer for 665 these clients. 667 A mapping renewal packet is formatted identically to an original 668 mapping request; from the point of view of the client it is a 669 renewal of an existing mapping, but from the point of view of the 670 freshly-rebooted NAT gateway it appears as a new mapping request. 672 This self-healing property of the protocol is very important. 674 The remarkable reliability of the Internet as a whole derives 675 in large part from the fact that important state is held in the 676 endpoints, not in the network itself [ETEAISD]. Power-cycling an 677 Ethernet switch results only in a brief interruption in the flow 678 of packets; established TCP connections through that switch are not 679 broken, merely delayed for a few seconds. Indeed, a failing Ethernet 680 switch can even be replaced with a new one, and as long as the cables 681 are transferred over reasonably quickly, after the upgrade all the 682 TCP connections that were previously going though the old switch will 683 be unbroken and now going through the new one. The same is true of 684 IP routers, wireless base stations, etc. The one exception is NAT 685 gateways. Because the port mapping state is required for the NAT 686 gateway to know where to forward inbound packets, loss of that state 687 breaks connectivity through the NAT gateway. By allowing clients to 688 detect when this loss of NAT gateway state has occurred, and recreate 689 it on demand, we turn hard state in the network into soft state, and 690 allow it to be recovered automatically when needed. 692 Without this automatic recreation of soft state in the NAT gateway, 693 reliable long-term networking would not be achieved. As mentioned 694 above, the reliability of the Internet does not come from trying 695 to build a perfect network in which errors never happen, but from 696 accepting that in any sufficiently large system there will always be 697 some component somewhere that's failing, and designing mechanisms 698 that can handle those failures and recover. To illustrate this point 699 with an example, consider the following scenario: Imagine a network 700 security camera that has a web interface and accepts incoming 701 connections from web browser clients. Imagine this network security 702 camera uses NAT-PMP or a similar protocol to set up an inbound 703 port mapping in the NAT gateway so that it can receive incoming 704 connections from clients the other side of the NAT gateway. 705 Now, this camera may well operate for weeks, months, or even years. 706 During that time it's possible that the NAT gateway could experience 707 a power failure or be rebooted. The user could upgrade the NAT 708 gateway's firmware, or even replace the entire NAT gateway device 709 with a newer model. The general point is that if the camera operates 710 for a long enough period of time, some kind of disruption to the NAT 711 gateway becomes inevitable. The question is not whether the NAT 712 gateway will lose its port mappings, but when, and how often. 713 If the network camera and devices like it on the network can detect 714 when the NAT gateway has lost its port mappings, and recreate them 715 automatically, then these disruptions are self-correcting and largely 716 invisible to the end user. If, on the other hand, the disruptions are 717 not self-correcting, and after a NAT gateway reboot the user has to 718 manually reset or reboot all the other devices on the network too, 719 then these disruptions are *very* visible to the end user. This 720 aspect of the design is part of what makes the difference between a 721 protocol that keeps on working indefinitely over a time scale of 722 months or years, and a protocol that works in brief testing, but in 723 the real world is continually failing and requiring manual 724 intervention to get it going again. 726 When a client renews its port mappings as the result of receiving 727 a packet where the "Seconds since start of epoch" field (SSSOE) 728 indicates that a reboot or similar loss of state has occurred, 729 the client MUST first delay by a random amount of time selected 730 with uniform random distribution in the range 0 to 5 seconds, and 731 then send its first port mapping request. After that request is 732 acknowledged by the gateway, the client may then send its second 733 request, and so on, as rapidly as the gateway allows. The requests 734 SHOULD be issued serially, one at a time; the client SHOULD NOT issue 735 multiple requests simultaneously in parallel. 737 The discussion in this section focusses on recreating inbound port 738 mappings after loss of NAT gateway state, because that is the more 739 serious problem. Losing port mappings for outgoing connections 740 destroys those currently active connections, but does not prevent 741 clients from establishing new outgoing connections. In contrast, 742 losing inbound port mappings not only destroys all existing inbound 743 connections, but also prevents the reception of any new inbound 744 connections until the port mapping is recreated. Accordingly, 745 we consider recovery of inbound port mappings the more important 746 priority. However, clients that want outgoing connections to survive 747 a NAT gateway reboot can also achieve that using NAT-PMP. After 748 initiating an outbound TCP connection (which will cause the NAT 749 gateway to establish an implicit port mapping) the client should send 750 the NAT gateway a port mapping request for the source port of its TCP 751 connection, which will cause the NAT gateway to send a response 752 giving the external port it allocated for that mapping. The client 753 can then store this information, and use later to recreate the 754 mapping if it determines that the NAT gateway has lost its mapping 755 state. 757 3.8. NAT Gateways with NAT Function Disabled 759 Note that only devices that are *currently* acting in the role of 760 NAT gateway should participate in NAT-PMP protocol exchanges with 761 clients. A network device that is capable of NAT (and NAT-PMP), but 762 is currently configured not to perform that function, (e.g. it is 763 acting as a traditional IP router, forwarding packets without 764 modifying them), MUST NOT respond to NAT-PMP requests from clients, 765 nor send spontaneous NAT-PMP address-change announcements. 767 In particular, a network device not currently acting in the role of 768 NAT gateway should not even respond to NAT-PMP requests by returning 769 an error code such as "2 - Not Authorized/Refused", since to do so 770 is misleading to clients -- it suggests that NAT port mapping is 771 necessary on this network for the client to successfully receive 772 inbound connections, but is not available because the administrator 773 has chosen to disable that functionality. 775 Clients should also be careful to avoid making unfounded assumptions, 776 such as the assumption that if the client has an IPv4 address in 777 one of the RFC 1918 private IPv4 address ranges then that means 778 NAT necessarily must be in use. Net 10/8 has enough addresses 779 to build a private network with millions of hosts and thousands 780 of interconnected subnets, all without any use of NAT. Many 781 organizations have built such private networks that benefit from 782 using standard TCP/IP technology, but by choice do not connect 783 to the public Internet. The purpose of NAT-PMP is to mitigate some 784 of the damage caused by NAT. It would be an ironic and unwanted 785 side-effect of this protocol if it were to lead well-meaning but 786 misguided developers to create products that refuse to work on a 787 private network *unless* they can find a NAT gateway to talk to. 788 Consequently, a client finding that NAT-PMP is not available on its 789 network should not give up, but should proceed on the assumption 790 that the network may be a traditional routed IP network, with no 791 address translation being used. This assumption may not always be 792 true, but it is better than the alternative of falsely assuming 793 the worst and not even trying to use normal (non-NAT) IP networking. 795 If a network device not currently acting in the role of NAT gateway 796 receives UDP packets addressed to port 5351, it SHOULD respond 797 immediately with an "ICMP Port Unreachable" message to tell the 798 client that it needn't continue with timeouts and retransmissions, 799 and it should assume that NAT-PMP is not available and not needed 800 on this network. Typically this behaviour can be achieved merely 801 by not having an open socket listening on UDP port 5351. 803 3.9 All Mappings are Bidirectional 805 All NAT mappings, whether created implicitly by an outbound packet, 806 created explicitly using NAT-PMP, or statically configured, are 807 bidirectional. This means that when an outbound packet from a 808 particular internal address and port is translated to an external 809 address and port, replies addressed to that external address and port 810 need to be translated back to the corresponding internal address and 811 port. 813 The converse is also true. When an inbound packet is received that is 814 addressed to an external address and port that matches an existing 815 mapping (implicit, explicit, or static), it is translated to the 816 corresponding internal address and port and forwarded. Outbound 817 replies from that internal address and port need to be translated to 818 the correct external address and port so that they are correctly 819 recognized by the remote peer. 821 In particular, if an outbound UDP reply, that matches an existing 822 explicit or static mapping, is instead treated like a "new" outbound 823 UDP packet, and a new dynamic mapping is created (with a different 824 external address and port) then when that packet arrives at the 825 remote peer it will not be recognized as a valid reply. For TCP this 826 bug is quickly spotted because all TCP implementations will ignore 827 replies with the wrong apparent source address and port. For UDP this 828 bug can more easily go unnoticed, because some UDP clients neglect to 829 check the source address and port of replies, and thus will appear to 830 work some of the time with NAT gateways that put the wrong source 831 address and port in outbound packets. All NAT gateways MUST ensure 832 that mappings, however created, are bidirectional. 834 4. UNSAF Considerations 836 The document "IAB Considerations for UNilateral Self-Address Fixing 837 Across NAT" [RFC 3424] covers a number of issues when working with 838 NATs. It outlines some requirements for any document that attempts to 839 work around problems associated with NATs. This section addresses 840 those requirements. 842 4.1. Scope 844 This protocol addresses the needs of TCP and UDP transport peers 845 that are separated from the public Internet by exactly one IPv4 NAT. 846 Such peers must have access to some form of directory server for 847 registering the public IPv4 address and port at which they can be 848 reached. 850 4.2. Transition Plan 852 Any client making use of this protocol SHOULD implement IPv6 support. 853 If a client supports IPv6 and is running on a device with a global 854 IPv6 address, that IPv6 address SHOULD be preferred to the IPv4 855 external address learned via this NAT mapping protocol. In case 856 other clients do not have IPv6 connectivity, both the IPv4 and IPv6 857 addresses SHOULD be registered with whatever form of directory server 858 is used. Preference SHOULD be given to IPv6 addresses when 859 available. By implementing support for IPv6 and using this protocol 860 for IPv4, vendors can ship products today that will work under both 861 scenarios. As IPv6 is more widely deployed, clients of this protocol 862 following these recommendations will transparently make use of IPv6. 864 4.3. Failure Cases 866 Aside from NATs that do not implement this protocol, there are a 867 number of situations where this protocol may not work. 869 4.3.1. NAT Behind NAT 871 Some people's primary IPv4 address, assigned by their ISP, may itself 872 be a NAT address. In addition, some people may have an external IPv4 873 address, but may then double NAT themselves, perhaps by choice or 874 perhaps by accident. Although it might be possible in principle for 875 one NAT gateway to recursively request a mapping from the next one, 876 this document does not advocate that and does not try to prescribe 877 how it would be done. 879 It would be a lot of work to implement nested NAT port mapping 880 correctly, and there are a number of reasons why the end result might 881 not be as useful as we might hope. Consider the case of an ISP that 882 offers each of its customers only a single NAT address. This ISP 883 could instead have chosen to provide each customer with a single 884 public IPv4 address, or, if the ISP insists on running NAT, it could 885 have chosen to allow each customer a reasonable number of addresses, 886 enough for each customer device to have its own NAT address directly 887 from the ISP. If instead this ISP chooses to allow each customer 888 just one and only one NAT address, forcing said customer to run 889 nested NAT in order to use more than one device, it seems unlikely 890 that such an ISP would be so obliging as to provide a NAT service 891 that supports NAT Port Mapping Protocol. Supposing that such an ISP 892 did wish to offer its customers NAT service with NAT-PMP so as to 893 give them the ability to receive inbound connections, this ISP could 894 easily choose to allow each client to request a reasonable number of 895 DHCP addresses from that gateway. Remember that Net 10/8 [RFC 1918] 896 allows for over 16 million addresses, so NAT addresses are not in any 897 way in short supply. A single NAT gateway with 16 million available 898 addresses is likely to run out of packet forwarding capacity before 899 it runs out of internal addresses to hand out. In this way the ISP 900 could offer single-level NAT with NAT-PMP, obviating the need to 901 support nested NAT-PMP. In addition, an ISP that is motivated to 902 provide their customers with unhindered access to the Internet by 903 allowing incoming as well as outgoing connections has better ways 904 to offer this service. Such an ISP could offer its customers real 905 public IPv4 addresses instead of NAT addresses, or could choose to 906 offer its customers full IPv6 connectivity, where no mapping or 907 translation is required at all. 909 4.3.2. NATs with Multiple External IPv4 Addresses 911 If a NAT maps internal addresses to multiple external addresses, 912 then it SHOULD pick one of those external addresses as the one it 913 will support for inbound connections, and for the purposes of this 914 protocol it SHOULD act as if that address were its only address. 916 4.3.3. NATs and Routed Private Networks 918 In some cases, a large network may be subnetted. Some sites 919 may install a NAT gateway and subnet the private network. 920 Such subnetting breaks this protocol because the router address 921 is not necessarily the address of the device performing NAT. 923 Addressing this problem is not a high priority. Any site with the 924 resources to set up such a configuration should have the resources to 925 add manual mappings or attain a range of globally unique addresses. 927 Not all NATs will support this protocol. In the case where a client 928 is run behind a NAT that does not support this protocol, the software 929 relying on the functionality of this protocol may be unusable. 931 4.3.4. Communication Between Hosts Behind the Same NAT 933 NAT gateways supporting NAT-PMP should also implement "hairpin 934 translation". Hairpin translation means supporting communication 935 between two local clients being served by the same NAT gateway. 937 Suppose device A is listening on internal address and port 938 10.0.0.2:80 for incoming connections. Using NAT-PMP, device A has 939 obtained a mapping to external address and port x.x.x.x:80, and has 940 recorded this external address and port in a public directory of some 941 kind. For example, it could have created a DNS SRV record containing 942 this information, and recorded it, using DNS Dynamic Update 943 [RFC 3007], in a publicly accessible DNS server. Suppose then that 944 device B, behind the same NAT gateway as device A, but unknowing 945 or uncaring of this fact, retrieves device A's DNS SRV record and 946 attempts to open a TCP connection to x.x.x.x:80. The outgoing packets 947 addressed to this public Internet address will be sent to the NAT 948 gateway for translation and forwarding. Having translated the source 949 address and port number on the outgoing packet, the NAT gateway needs 950 to be smart enough to recognize that the destination address is in 951 fact itself, and then feed this packet back into its packet reception 952 engine, to perform the destination port mapping lookup to translate 953 and forward this packet to device A at address and port 10.0.0.2:80. 955 4.3.5. Non UDP/TCP Transport Traffic 957 Any communication over transport protocols other than TCP and UDP 958 will not be served by this protocol. Examples are Generic Routing 959 Encapsulation (GRE), Authentication Header (AH) and Encapsulating 960 Security Payload (ESP). 962 4.4. Long Term Solution 964 As IPv6 is deployed, clients of this protocol supporting IPv6 will be 965 able to bypass this protocol and the NAT when communicating with 966 other IPv6 devices. In order to ensure this transition, any client 967 implementing this protocol SHOULD also implement IPv6 and use this 968 solution only when IPv6 is not available to both peers. 970 4.5. Existing Deployed NATs 972 Existing deployed NATs will not support this protocol. This protocol 973 will only work with NATs that are upgraded to support it. 975 5. Security Considerations 977 As discussed in Section 3.2 "Determining the External Address", only 978 clients on the internal side of the NAT may create port mappings, 979 and only on behalf of themselves. By using IP address spoofing, 980 it's possible for one client to delete the port mappings of another 981 client. It's also possible for one client to create port mappings on 982 behalf of another client. In cases where this is a concern, it can be 983 dealt with using IPSec [RFC 4301]. One concern is that rogue software 984 running on a local host could create port mappings for unsuspecting 985 hosts, thereby rendering them vulnerable to external attack. However, 986 it's not clear how realistic this threat model is, since rogue 987 software on a local host could attack such unsuspecting hosts 988 directly itself, without resorting to such a convoluted indirect 989 technique. This concern is also a little misguided because it is 990 based on the assumption that a NAT gateway and a firewall are the 991 same thing, which they are not. 993 Some people view the property that NATs block inbound connections as 994 a security benefit which is undermined by this protocol. The authors 995 of this document have a different point of view. In the days before 996 NAT became prevalent, all hosts had unique public IP addresses, and 997 had unhindered ability to communicate with any other host on the 998 Internet (a configuration that is still surprisingly common). 999 Using NAT breaks this unhindered connectivity, relegating hosts to 1000 second-class status, unable to receive inbound connections. This 1001 protocol goes some way to partially reverse that damage. The purpose 1002 of a NAT gateway should be to allow several hosts to share a single 1003 address, not to simultaneously impede those host's ability to 1004 communicate freely. Security is most properly provided by end-to-end 1005 cryptographic security, and/or by explicit firewall functionality, as 1006 appropriate. Blocking of certain connections should occur only as a 1007 result of explicit and intentional firewall policy, not as an 1008 accidental side-effect of some other technology. 1010 However, since many users do have an expectation that their NAT 1011 gateways can function as a kind of firewall, any NAT gateway 1012 implementing this protocol SHOULD have an administrative mechanism 1013 to disable it, thereby restoring the pre-NAT-PMP behaviour. 1015 6. IANA Considerations 1017 UDP ports 5350 and 5351 have been assigned for use by NAT-PMP, and 1018 subsequently by its sucessor, Port Control Protocol [PCP]. 1020 No further IANA services are required by this document. 1022 7. Acknowledgments 1024 The concepts described in this document have been explored, developed 1025 and implemented with help from Mark Baugher, Bob Bradley, Josh 1026 Graessley, Rory McGuire, Rob Newberry, Roger Pantos, John Saxton, 1027 Kiren Sekar, Jessica Vazquez and James Woodyatt. 1029 Special credit goes to Mike Bell, the Apple Vice President who 1030 recognized the need for a clean, elegant, reliable Port Mapping 1031 Protocol, and made the decision early on that Apple's AirPort base 1032 stations would support NAT-PMP. 1034 8. Deployment History 1036 In August 2004 NAT-PMP client software first became available to the 1037 public through Apple's Darwin Open Source code. In April 2005 NAT-PMP 1038 implementations began shipping to end users with the launch of Mac OS 1039 X 10.4 Tiger and Bonjour for Windows 1.0. 1041 The NAT-PMP client in Mac OS X 10.4 Tiger and Bonjour for Windows 1042 exists as part of the mDNSResponder/mdnsd system service. When a 1043 client advertises a service using Wide Area Bonjour [DNS-SD], and the 1044 machine is behind a NAT-PMP-capable NAT gateway, and the machine is 1045 so configured, the mDNSResponder system service automatically uses 1046 NAT-PMP to set up an inbound port mapping, and then records the 1047 external IPv4 address and port in the global DNS. Existing client 1048 software using the Bonjour programming APIs [Bonjour] got this new 1049 NAT traversal functionality automatically. The logic behind this 1050 decision was that if client software publishes its information into 1051 the global DNS via Wide Area Bonjour service advertising, then it's 1052 reasonable to infer an expectation that this information should 1053 actually be usable by the peers retrieving it. Generally speaking, 1054 recording a private IPv4 address like 10.0.0.2 in the public DNS is 1055 likely to be pointless because that address is not reachable from 1056 clients on the other side of the NAT gateway. In the case of a home 1057 user with a single computer directly connected to their Cable or DSL 1058 modem, with a single global IPv4 address and no NAT gateway (a common 1059 configuration at that time), publishing the machine's global IPv4 1060 address into the global DNS is useful, because that IPv4 address is 1061 globally reachable. In contrast, a home user using a NAT gateway to 1062 share a single global IPv4 address between several computers loses 1063 this ability to receive inbound connections. This breaks many 1064 peer-to-peer collaborative applications, like the multi-user text 1065 editor SubEthaEdit [SEE]. For many users, moving from one computer 1066 with a global IPv4 address, to two computers using NAT to share a 1067 single global IPv4 address, loss of inbound reachability was an 1068 unwanted side-effect of using NAT for address sharing. Automatically 1069 creating the necessary inbound port mappings helped remedy this 1070 unwanted side-effect of NAT. 1072 The server side of the NAT-PMP protocol is implemented in Apple's 1073 "AirPort Extreme", "AirPort Express", and "Time Capsule" wireless 1074 base stations, and in the "Internet Sharing" feature of Mac OS X 1075 10.4 and later. 1077 In Mac OS X 10.4 Tiger, the NAT-PMP client was invoked automatically 1078 as a side-effect of clients requesting Wide Area Bonjour service 1079 registrations. Using NAT-PMP without an associated Wide Area Bonjour 1080 service registration required use of a third-party client library. 1082 In October 2007 Mac OS X 10.5 Leopard added the "DNSServiceNATPort- 1083 MappingCreate" API, which made NAT-PMP client functionality directly 1084 available, so software could use it with other directory and 1085 rendezvous mechanisms in addition to Wide Area Bonjour DNS Updates. 1087 In 2012 NAT-PMP was superseded by the IETF Standards-Track Port 1088 Control Protocol [PCP]. PCP builds on NAT-PMP and uses a compatible 1089 packet format, and adds a number of significant enhancements, 1090 including IPv6 support, management of outbound mappings, management 1091 of firewall rules, full compatibility with large-scale NATs with a 1092 pool of external addresses, error lifetimes, and an extension 1093 mechanism to enable future enhancements. 1095 9. Noteworthy Features of NAT Port Mapping Protocol and PCP 1097 Some readers have asked how NAT-PMP and PCP compare to other similar 1098 solutions, particularly the UPnP Forum's Internet Gateway Device 1099 (IGD) Device Control Protocol [IGD]. 1101 The answer is that although UPnP IGD is often used as a way for 1102 client devices to create port mappings programmatically, it's not 1103 ideal for that task. Whereas NAT-PMP was explicitly designed to be 1104 used primarily by software entities managing their own port mappings, 1105 UPnP IGD is more tailored towards being used by humans configuring 1106 all the settings of their gateway using some GUI tool. This 1107 difference in emphasis leads to protocol differences. For example, 1108 while it is reasonable and sensible to require software entities to 1109 renew their mappings periodically to prove that they are still there 1110 (like a device renewing its DHCP address lease), it would be 1111 unreasonable to require the same thing of a human user. When a human 1112 user configures their gateway, they expect it to stay configured that 1113 way until they decide to change it. If they configure a port mapping, 1114 they expect it to stay configured until they decide to delete it. 1116 Because of this focus on being a general administration protocol for 1117 all aspects of home gateway configuration, UPnP IGD is a large and 1118 complicated collection of protocols (360 pages of specification 1119 spread over 13 separate documents, not counting supporting protocol 1120 specifications like SSDP and XML). While it may be a fine way for 1121 human users to configure their home gateways, it is not especially 1122 suited to the task of programmatically creating dynamic port 1123 mappings. 1125 The requirements for a good port mapping protocol, requirements which 1126 are met by NAT-PMP, are outlined below: 1128 9.1. Simplicity 1130 Many home gateways, and many of the devices that connect to them, 1131 are small, low-cost devices, with limited RAM, flash memory, and 1132 CPU resources. Protocols they use should be considerate of this, 1133 supporting a small number of simple operations that can be 1134 implemented easily with a small amount of code. A quick comparison, 1135 based on page count of the respective documents alone, suggests that 1136 NAT-PMP is at least ten times simpler than UPnP IGD. 1138 9.2. Focussed Scope 1140 The more things a protocol can do, the more chance there is that 1141 something it does could be exploited for malicious purposes. NAT-PMP 1142 is tightly focussed on the specific task of creating port mappings. 1143 Were the protocol to be misused in some way, this helps limit the 1144 scope of what mischief could be performed using the protocol. 1146 Because UPnP IGD allows control over all home gateway configuration 1147 settings, the potential for mischief is far greater. For example, a 1148 UPnP IGD home gateway allows messages that tell it to change the DNS 1149 server addresses that it sends to clients in its DHCP packets. Using 1150 this mechanism, a single item of malicious web content (e.g. a rogue 1151 Flash banner advert on a web page) can make a persistent change to 1152 the home gateway's configuration without the user's knowledge, such 1153 that all future DNS requests by all local clients will be sent to a 1154 rogue DNS server. This allows criminals to perform a variety of 1155 mischief, such as hijacking connections to bank web sites and 1156 redirecting them to the criminals' web servers instead [VU347812]. 1158 9.3. Efficiency 1160 In addition to low-cost home gateways, many of the clients will also 1161 be similarly constrained low-cost devices with limited RAM resources. 1163 When implementing a NAT-PMP client on a constrained device, it's 1164 beneficial to have well-defined bounds on RAM requirements that 1165 are fixed and known in advance. For example, when requesting the 1166 gateway's external IPv4 address, a NAT-PMP client on Ethernet knows 1167 that to receive the reply it will require 14 bytes for the Ethernet 1168 header, 20 bytes for the IPv4 header, 8 bytes for the UDP header, 1169 and 12 bytes for the NAT-PMP payload, making a total of 54 bytes. 1171 In contrast, UPnP IGD uses an XML reply of unbounded size. It is not 1172 uncommon for a UPnP IGD device to return an XML document 4000 to 8000 1173 bytes in size to communicate its four-byte external IPv4 address, and 1174 the protocol specification places no upper bound on how large the XML 1175 response may be, so there's nothing to stop the reply being even 1176 larger. This means that developers of UPnP client devices can only 1177 guess at how much memory they may need to receive the XML reply. 1178 Operational experience suggests that 10,000 bytes is usually enough 1179 for most UPnP IGD home gateways today, but that's no guarantee that 1180 some future UPnP IGD home gateway might not return a perfectly legal 1181 XML reply much larger than that. 1183 In addition, because the XML reply is too large to fit in a single 1184 UDP packet, UPnP IGD has to use a TCP connection, thereby adding 1185 the overhead of TCP connection setup and teardown. 1187 The process of discovering a UPnP IGD home gateway's external IPv4 1188 address consists of: 1190 o SSDP transaction to discover the TCP port to use, and the 1191 "URL" of the XML document to fetch from the gateway. If following 1192 the SSDP specification, this is 3 multicast requests, eliciting 9 1193 unicast responses. 1195 o HTTP "GET" request to get the device description. Typically 16 1196 packets: 3 for TCP connection setup, 9 packets of data exchange, 1197 and a 4-packet FIN-ACK-FIN-ACK sequence to close the connection. 1199 o HTTP "POST" to request the external IPv4 address. Typically 14 1200 packets: 3 for TCP connection setup, 7 packets of data exchange, 1201 and a 4-packet FIN-ACK-FIN-ACK sequence to close the connection. 1203 To retrieve the external IPv4 address NAT-PMP takes a two-packet UDP 1204 exchange (44-byte request, 54-byte response); the same thing using 1205 UPnP IGD takes 42 packets and thousands of bytes. 1207 Similarly, UPnP IGD's HTTP "POST" request for a port mapping is 1208 typically a 14-packet exchange, compared with NAT-PMP's two-packet 1209 UDP exchange. 1211 9.4. Atomic Allocation Operations 1213 Some of the useful properties of NAT-PMP were inspired by DHCP, a 1214 reliable and successful protocol. For example, DHCP allows a client 1215 to request a desired IP address, but if that address is already in 1216 use the DHCP server will instead assign some other available address. 1218 Correspondingly, NAT-PMP allows a client to request a desired 1219 external port, and if that external port is already in use by some 1220 other client, the NAT-PMP server will instead assign some other 1221 available external port. 1223 UPnP IGD does not do this. If a UPnP IGD client requests an external 1224 port that has already been allocated, then one of two things happens. 1226 Some UPnP IGD home gateways just silently overwrite the old mapping 1227 with the new one, causing the previous client to lose connectivity. 1228 If the previous client renews its port mapping, then it in turn 1229 overwrites the new mapping, and the two clients fight over the same 1230 external port indefinitely, neither achieving reliable connectivity. 1232 Other IGD home gateways return a "Conflict" error if the port is 1233 already in use, which does at least tell the client what happened, 1234 but doesn't tell the client what to do. Instead of the NAT gateway 1235 (which does know which ports are available) assigning one to the 1236 client, the NAT gateway makes the client (which doesn't know) keep 1237 guessing until it gets lucky. This problem remains mild as long as 1238 not many clients are using UPnP IGD, but gets progressively worse as 1239 the number of clients on the network requesting port mappings goes 1240 up. In addition, UPnP IGD works particularly badly in conjunction with 1241 the emerging policy of allocating pre-assigned port ranges to each 1242 client. If a client is assigned TCP port range 63488-64511, and the 1243 UPnP IGD client requests TCP port 80, trying successive incrementing 1244 ports until it succeeds, then the UPnP IGD client will have to issue 1245 63,409 requests before it succeeds. 1247 9.5. Garbage Collection 1249 In any system that operates for a long period of time (as a home 1250 gateway should) it is important that garbage data does not accumulate 1251 indefinitely until the system runs out of memory and fails. 1253 Like DHCP address leases, NAT-PMP leases a port mapping to a client 1254 for a finite length of time. The NAT-PMP client must renew the port 1255 mapping before it expires or, like an unrenewed DHCP address, it will 1256 be reclaimed. If a laptop computer is abruptly disconnected from the 1257 network without the opportunity to delete its port mappings, the 1258 NAT gateway will reclaim those mappings when they are not renewed. 1260 In principle UPnP IGD should allow clients to specify a lifetime on 1261 port mappings. However, a Google search for "UPnP NewLeaseDuration" 1262 shows that in practice pretty much every client uses 1263 "0" to request an infinite 1264 lease, and the protocol has no way for the NAT gateway to decline 1265 that infinite lease request and require the client to renew it at 1266 reasonable intervals. Furthermore, anecdotal evidence is that if the 1267 client requests a lease other than zero, there are IGD home gateways 1268 that will ignore the request, fail in other ways, or even crash 1269 completely. As a client implementer then, you would be well advised 1270 not to attempt to request a lease other than zero, unless you want 1271 to suffer the support costs and bad publicity of lots of people 1272 complaining that your device brought down their entire network. 1274 Because none of the early UPnP IGD clients requested port mapping 1275 leases, many UPnP IGD home gateway vendors never tested that 1276 functionality, and got away with shipping home gateways where that 1277 functionality was buggy or nonexistent. Because there are so many 1278 buggy UPnP IGD home gateways already deployed, client writers wisely 1279 stick to the well-trodden path of only requesting infinite leases. 1280 Because there are now few (if any) clients attempting to request 1281 non-zero leases, home gateway vendors have little incentive to expend 1282 resources implementing a feature no one uses. 1284 This unfortunate consequence of the way UPnP IGD was developed and 1285 deployed means that in practice it has no usable port mapping lease 1286 facility today, and therefore when run for a long period of time UPnP 1287 IGD home gateways have no good way to avoid accumulating an unbounded 1288 number of stale port mappings. 1290 9.6. State Change Announcements 1292 When using DHCP on the external interface, as is the norm for home 1293 gateways, there is no guarantee that a UPnP IGD home gateway's 1294 external IPv4 address will remain unchanged. Indeed, some ISPs change 1295 their customer's IPv4 address every 24 hours (possibly in an effort 1296 to make it harder for their customers to "run a server" at home). 1297 What this means is that if the home gateway's external IPv4 address 1298 changes, it needs to inform its clients, so that they can make any 1299 necessary updates to global directory information (e.g. performing a 1300 Dynamic DNS update to update their address record). 1302 When a NAT-PMP gateway's external IPv4 address changes, it broadcasts 1303 announcement packets to inform clients of this. UPnP IGD does not. 1305 9.7. Soft State Recovery 1307 When run for a long enough period of time, any network will have 1308 devices that fail, get rebooted, suffer power outages, or lose state 1309 for other reasons. A home gateway that runs for long enough is likely 1310 to suffer some such incident eventually. After losing state, it has 1311 no record of the port mappings it created, and clients suffer a 1312 consequent loss of connectivity. 1314 To handle this case, NAT-PMP has the "Seconds Since Start of Epoch" 1315 mechanism. After a reboot or other loss of state, a NAT-PMP gateway 1316 broadcasts announcement packets giving its external IPv4 address, 1317 with the "Seconds Since Start of Epoch" field reset to begin counting 1318 from zero again. When a NAT-PMP client observes packets from its 1319 NAT-PMP gateway where the gateway's notion of time has apparently 1320 gone backwards compared to the client's, the client knows the gateway 1321 has probably lost state, and immediately recreates its mappings to 1322 restore connectivity. 1324 UPnP IGD has no equivalent mechanism. 1326 10. Normative References 1328 [RFC 1918] Y. Rekhter et.al., "Address Allocation for Private 1329 Internets", RFC 1918, February 1996. 1331 [RFC 2119] RFC 2119 - Key words for use in RFCs to Indicate 1332 Requirement Levels 1334 11. Informative References 1336 [Bonjour] Apple "Bonjour" 1338 [ETEAISD] J. Saltzer, D. Reed and D. Clark: "End-to-end arguments in 1339 system design", ACM Trans. Comp. Sys., 2(4):277-88, Nov. 1340 1984 1342 [DNS-SD] Cheshire, S., and M. Krochmal, "DNS-Based Service 1343 Discovery", Internet-Draft (work in progress), 1344 draft-cheshire-dnsext-dns-sd-11.txt, December 2011. 1346 [IGD] UPnP Standards "Internet Gateway Device (IGD) Standardized 1347 Device Control Protocol V 1.0", November 2001. 1348 1350 [mDNS] Cheshire, S., and M. Krochmal, "Multicast DNS", 1351 Internet-Draft (work in progress), 1352 draft-cheshire-dnsext-multicastdns-15.txt, December 2011. 1354 [PCP] Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. 1355 Selkirk, "Port Control Protocol (PCP)", 1356 draft-ietf-pcp-base-26 (work in progress), June 2012. 1358 [RFC 2131] R. Droms, "Dynamic Host Configuration Protocol", RFC 2131, 1359 March 1997. 1361 [RFC 4301] S. Kent and K. Seo, "Security Architecture for 1362 the Internet Protocol", RFC 4301, December 2005. 1364 [RFC 2663] Srisuresh, P. and M. Holdrege, "IP Network Address 1365 Translator (NAT) Terminology and Considerations", RFC 1366 2663, August 1999. 1368 [RFC 3007] Wellington, B., "Simple Secure Domain Name System 1369 (DNS) Dynamic Update", RFC 3007, November 2000. 1371 [SEE] 1373 [RFC 3022] RFC 3022 - Network Address Translator 1375 [RFC 3424] RFC 3424 - IAB Considerations for UNilateral Self-Address 1376 Fixing (UNSAF) Across Network Address Translation 1378 [VU347812] United States Computer Emergency Readiness Team 1379 Vulnerability Note VU#347812 1380 1382 12. Authors' Addresses 1384 Stuart Cheshire 1385 Apple Inc. 1386 1 Infinite Loop 1387 Cupertino 1388 California 95014 1389 USA 1391 Phone: +1 408 974 3207 1392 Email: cheshire@apple.com 1394 Marc Krochmal 1395 Apple Inc. 1396 1 Infinite Loop 1397 Cupertino 1398 California 95014 1399 USA 1401 Phone: +1 408 974 4368 1402 Email: marc@apple.com