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