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