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