idnits 2.17.1 draft-cheshire-nat-pmp-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 19. -- Found old boilerplate from RFC 3978, Section 5.5 on line 626. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. == There are 1 instance of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 == There are 2 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 2005) is 6862 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2401 (Obsoleted by RFC 4301) ** Downref: Normative reference to an Informational RFC: RFC 2663 ** Downref: Normative reference to an Informational RFC: RFC 3022 ** Downref: Normative reference to an Informational RFC: RFC 3424 -- Possible downref: Non-RFC (?) normative reference: ref. 'ETEAISD' Summary: 11 errors (**), 0 flaws (~~), 4 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Document: draft-cheshire-nat-pmp-00.txt Stuart Cheshire 2 Internet-Draft Marc Krochmal 3 Expires 7th December 2005 Kiren Sekar 4 Apple Computer, Inc. 5 7th June 2005 7 NAT Port Mapping Protocol (NAT-PMP) 9 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 For the purposes of this document, the term "BCP 79" refers 18 exclusively to RFC 3979, "Intellectual Property Rights in IETF 19 Technology", published March 2005. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 Abstract 39 This document describes a protocol for automating the process of 40 creating Network Address Translation (NAT) port mappings. Included 41 in the protocol is a method for retrieving the public IP address of a 42 NAT gateway, thus allowing a client to make this public IP address 43 and port number known to peers that may wish to communicate with it. 44 This protocol is implemented in current Apple products including 45 Mac OS X v10.4 Tiger and Bonjour for Windows. 47 1. Introduction 49 Network Address Translation (NAT) is a method of sharing one public 50 internet address with a number of devices. This document is focused 51 on what "IP Network Address Translator (NAT) Terminology and 52 Considerations" [RFC 2663] calls "NAPTs" (Network Address/Port 53 Translators). A full description of NAT is beyond the scope of this 54 document. The following brief overview will cover the aspects 55 relevant to this port mapping protocol. For more information on 56 NAT, see "Traditional IP Network Address Translator" [RFC 3022]. 58 NATs have one or more public IP addresses. A private network is set 59 up behind the NAT. Devices behind the NAT are assigned private 60 addresses and the private address of the NAT device is used as the 61 gateway. 63 When a packet from any device behind the NAT is sent to an address on 64 the public internet, the packet first passes through the NAT box. The 65 NAT box looks at the source port and address. In some cases, a NAT 66 will also keep track of the destination port and address. The NAT 67 then creates a mapping from the private address and private port to a 68 public address and public port if a mapping does not already exist. 69 The NAT box replaces the private address and port number in the 70 packet with the public entries from the mapping and sends the packet 71 on to the next gateway. 73 When a packet from any address on the internet is received on the 74 NAT's public side, the NAT will look up the destination port (public 75 port) in the list of mappings. If an entry is found, it will contain 76 the private address and port that the packet should be sent to. The 77 NAT gateway will then rewrite the destination address and port with 78 those from the mapping. The packet will then be forwarded to the new 79 destination addresses. If the packet did not match any mapping, the 80 packet will most likely be dropped. Various NATs implement different 81 strategies to handle this. The important thing to note is that if 82 there is no mapping, the NAT does not know which private address the 83 packet should be sent to. 85 Mappings are usually created automatically as a result of observing 86 outbound traffic. There are a few exceptions. Some NATs may allow 87 manually-created permanent mappings that map a public port to a 88 specific private IP address and port. Such a mapping allows incoming 89 connections to the device with that private address. Some NATs also 90 implement a default mapping where any inbound traffic that does not 91 match a mapping will always be forwarded to a specific private 92 address. Both types of mappings are usually set up manually through 93 some configuration tool. 95 Without these manually-created inbound port mappings, clients behind 96 the NAT would be unable to receive inbound connections, which 97 represents a loss of connectivity when compared to the original 98 Internet architecture [ETEAISD]. For those who view this loss of 99 connectivity as a bad thing, NAT-PMP allows clients to operate much 100 more like a host directly connected to the unrestricted public 101 Internet, with an unrestricted public IP address. NAT-PMP allows 102 client hosts to communicate with the NAT gateway to request the 103 creation of inbound mappings on demand. Having created a NAT mapping 104 to allow inbound connections, the client can then record its public 105 IP address and public port number in a public registry (e.g. the 106 world-wide Domain Name System) or otherwise make it accessible to 107 peers that wish to communicate with it. 109 2. Conventions and Terminology Used in this Document 111 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 112 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 113 document are to be interpreted as described in "Key words for use in 114 RFCs to Indicate Requirement Levels" [RFC 2119]. 116 3. Protocol and Packet Format 118 NAT Port Mapping Protocol runs over UDP. Every packet starts with an 119 8 bit version followed by an 8 bit operation code. 121 This document specifies version 0 of the protocol. Any NAT-PMP 122 gateway implementing this version of the protocol, receiving a 123 packet with a version number other than 0, MUST return result code 1 124 (Unsupported Version). 126 Opcodes between 0 and 127 are client requests. Opcodes from 128 to 127 255 are server responses. Responses always contain a 16 bit result 128 code in network byte order. A result code of zero indicates success. 129 Responses also contain a 32 bit unsigned integer corresponding to the 130 number of seconds since the NAT gateway was rebooted or since its 131 port mapping state was reset. 133 This protocol SHOULD only be used when the client determines that its 134 primary source IPv4 address is in the range of private IP addresses 135 defined in RFC 1918. This includes the address ranges 10/8, 136 172.16/12, and 192.168/16. 138 Clients always send their Port Mapping Protocol requests to their 139 default gateway, as learned via DHCP [RFC 2131], or similar means. 140 This protocol is designed for small home networks, with a single 141 logical link (subnet) where the client's default gateway is also the 142 NAT translator for that network. For more complicated networks where 143 the NAT translator is some device other than the client's default 144 gateway, this protocol is not appropriate. 146 3.1 Determining the Public Address 148 To determine the public address, the client behind the NAT sends the 149 following UDP payload to port 5351 of the configured gateway address: 151 0 1 152 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 154 | Vers = 0 | OP = 0 | 155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 157 This packet is sent by clients to determine the public IP address and 158 to determine whether or not the gateway supports this protocol. After 159 sending the request, the client then waits for the NAT gateway to 160 respond. If after 250ms, the gateway doesn't respond (and doesn't 161 generate "ICMP Port Unreachable" messages), the client SHOULD 162 re-issue its request. The client SHOULD repeat this process with the 163 interval between attempts doubling each time. If, after two minutes, 164 the client has not received any response, then it SHOULD conclude 165 that this gateway does not support NAT Port Mapping Protocol and MAY 166 log an error message indicating this fact. 168 A compatible NAT gateway MUST generate a response with the following 169 format: 171 0 1 2 3 172 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 173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 174 | Vers = 0 | OP = 128 + 0 | Result Code | 175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 176 | Seconds Since Start of Epoch | 177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 178 | Public IP Address (a.b.c.d) | 179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 181 This response indicates that the NAT gateway implements this version 182 of the protocol and returns the public IP address of the NAT gateway. 183 If the result code is non-zero, the value of Public IP Address is 184 undefined (MUST be set to zero on transmission, and MUST be ignored 185 on reception). 187 The NAT gateway MUST fill in the "Seconds Since Start of Epoch" field 188 with the time elapsed since its port mapping table was initialized on 189 startup or reset for any other reason (see Section 3.7 "Seconds Since 190 Start of Epoch"). 192 If the client receives an "ICMP Port Unreachable" message from the 193 gateway, then it SHOULD conclude that this gateway does not support 194 NAT Port Mapping Protocol and MAY log an error message. 196 3.1.1 Announcing Address Changes 198 When the public IP address of the NAT changes, the NAT gateway MUST 199 send a gratuitous response to the link-local multicast address 200 224.0.0.1, port 5351 with the packet format above to notify clients 201 of the new public IP address. To compensate for packet loss, the NAT 202 gateway SHOULD multicast 10 address change notifications. The 203 interval between the first two notifications SHOULD be 250ms, and the 204 interval between each subsequent notification SHOULD double. 206 3.2 Creating a Mapping 208 To create a mapping, the client sends a UDP packet to port 5351 of 209 the gateway's private IP address with the following format: 211 0 1 2 3 212 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 213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 214 | Vers = 0 | OP = x | Reserved (MUST be zero) | 215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 216 | Private Port | Requested Public Port | 217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 218 | Requested Port Mapping Lifetime in Seconds | 219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 221 Opcodes supported: 222 1 - Map UDP 223 2 - Map TCP 225 The reserved field MUST be set to zero on transmission and MUST be 226 ignored on reception. The RECOMMENDED Port Mapping Lifetime for 227 this protocol is 3600 seconds. 229 After sending the port mapping request, the client then waits for the 230 NAT gateway to respond. If after 250ms, the gateway doesn't respond, 231 the client SHOULD re-issue its request. The client SHOULD repeat 232 this process with the interval between attempts doubling each time. 233 If after two minutes, the client has not received any response, it 234 SHOULD log an error message and give up. 236 The NAT gateway responds with the following packet format: 238 0 1 2 3 239 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 240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 241 | Vers = 0 | OP = 128 + x | Result Code | 242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 243 | Seconds Since Start of Epoch | 244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 | Private Port | Mapped Public Port | 246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 247 | Port Mapping Lifetime in Seconds | 248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 The 'x' in the OP field MUST match what the client requested. Some 251 NAT gateways are incapable of creating a UDP port mapping without 252 also creating a corresponding TCP port mapping, and vice versa, and 253 these gateways MUST NOT implement NAT Port Mapping Protocol until 254 this deficiency is fixed. A NAT gateway which implements this 255 protocol MUST be able to create TCP-only and UDP-only port mappings. 256 If a NAT gateway silently creates a pair of mappings for a client 257 that only requested one mapping, then it may expose that client to 258 receiving inbound UDP packets or inbound TCP connection requests that 259 it did not ask for and does not want. 261 While a NAT gateway MUST NOT automatically create mappings for TCP 262 when the client requests UDP, and vice versa, the NAT gateway SHOULD 263 reserve the companion port so the same client can choose to map it in 264 the future. For example, if a client requests to map TCP port 80, as 265 long as the client maintains the lease for that TCP port mapping, 266 another client with a different IP address SHOULD NOT be able to 267 successfully acquire the mapping for UDP port 80. 269 The client normally requests the public port matching the private 270 port. If that public port is not available, the NAT gateway MUST 271 return a public port that is available or return an error code if no 272 ports are available. If the client has no preference about what 273 public port is assigned, then it should set the requested public port 274 to zero. 276 The source address of the packet MUST be used for the private address 277 in the mapping. This protocol is not intended to facilitate one 278 device behind a NAT creating mappings for other devices. If there 279 are legacy devices that require inbound mappings, permanent mappings 280 can be created manually by the administrator, just as they are today. 282 If a mapping already exists for a given private port on a given local 283 client, and that client requests another mapping for the same private 284 port, possibly requesting a different public port, then the mapping 285 request should succeed, returning the already-assigned public port. 286 This is necessary to handle the case where a client requests a 287 mapping with requested public port X, and is granted a mapping with 288 actual public port Y, but the acknowledgement packet gets lost. 289 When the client retransmits its mapping request, it should get back 290 the same positive acknowledgement as was sent the first time. 292 The NAT gateway SHOULD NOT accept mapping requests destined to the 293 NAT gateway's public IP address or received on its public network 294 interface. Only packets received on the private interface(s) with a 295 destination address matching the private address(es) of the NAT 296 gateway should be allowed. 298 The NAT gateway MUST fill in the "Seconds Since Start of Epoch" field 299 with the time elapsed since its port mapping table was initialized on 300 startup or reset for any other reason (see Section 3.7 "Seconds Since 301 Start of Epoch"). 303 The Port Mapping Lifetime is an unsigned integer in seconds. The NAT 304 gateway MAY reduce the lifetime from what the client requested. The 305 NAT gateway SHOULD NOT offer a lease lifetime greater than that 306 requested by the client. 308 The client SHOULD begin trying to renew the mapping halfway to expiry 309 time, like DHCP. The renewal packet should look exactly the same as 310 a request packet, except that the client SHOULD set the requested 311 public port to what the router previously mapped. If the router 312 crashes or is rebooted, this helps the router recover its mapping 313 state. 315 3.3 Destroying a Mapping 317 A mapping may be destroyed in a variety of ways. If a client fails 318 to renew a mapping, then when its lifetime expires the mapping MUST 319 be automatically deleted. In the common case where the gateway 320 device is a combined DHCP server and NAT gateway, when a client's 321 DHCP address lease expires, the gateway device MAY automatically 322 delete any mappings belonging to that client. Otherwise a new client 323 being assigned the same IP address could receive unexpected inbound 324 UDP packets or inbound TCP connection requests that it did not ask 325 for and does not want. 327 A client MAY also send an explicit packet to request deletion of a 328 mapping that is no longer needed. A client requests explicit 329 deletion of a mapping by sending a message to the NAT gateway 330 requesting the mapping, with the Requested Lifetime in Seconds set 331 to 0. The requested public port MUST be set to zero by the client 332 on sending, and MUST be ignored by the gateway on reception. 334 When a mapping is destroyed successfully as a result of the client 335 explicitly requesting the deletion, the NAT gateway MUST send a 336 response packet which is formatted as defined in section 3.2. The 337 response MUST contain a result code of 0, the private port as 338 indicated in the deletion request, a public port of 0, and a lifetime 339 of 0. The NAT gateway MUST respond to a request to destroy a mapping 340 that does not exist as if the request were successful. This is 341 because of the case where the acknowledgement is lost, and the client 342 retransmits its request to delete the mapping. In this case the 343 second request to delete the mapping MUST return the same response 344 packet as the first request. 346 If the deletion request was unsuccessful, the response MUST contain a 347 non-zero result code and the requested mapping; the lifetime is 348 undefined (MUST be set to zero on transmission, and MUST be ignored 349 on reception). If the client attempts to delete a port mapping which 350 was manually assigned by some kind of configuration tool, the NAT 351 gateway MUST respond with a 'Not Authorized' error, result code 2. 353 When a mapping is destroyed as a result of its lifetime expiring or 354 for any other reason, if the NAT gateway's internal state indicates 355 that there are still active TCP connections traversing that now- 356 defunct mapping, then the NAT gateway SHOULD send appropriately- 357 constructed TCP RST (reset) packets both to the local client and to 358 the remote peer on the Internet to terminate that TCP connection. 360 A client can request the explicit deletion of all its UDP or TCP 361 mappings by sending the same deletion request to the NAT gateway with 362 public port, private port, and lifetime set to 0. A client MAY 363 choose to do this when it first acquires a new IP address in order to 364 protect itself from port mappings that were performed by a previous 365 owner of the IP address. After receiving such a deletion request, 366 the gateway MUST delete all its UDP or TCP port mappings (depending 367 on the opcode). The gateway responds to such a deletion request with 368 a response as described above, with the private port set to zero. If 369 the gateway is unable to delete a port mapping, for example, because 370 the mapping was manually configured by the administrator, the gateway 371 MUST still delete as many port mappings as possible, but respond with 372 a non-zero result code. The exact result code to return depends on 373 the cause of the failure. If the gateway is able to successfully 374 delete all port mappings as requested, it MUST respond with a result 375 code of 0. 377 3.4 Result Codes 379 Currently defined result codes: 380 0 - Success 381 1 - Unsupported Version 382 2 - Not Authorized/Refused 383 (e.g. box supports mapping, but user has turned feature off) 384 3 - Network Failure 385 (e.g. NAT box itself has not obtained a DHCP lease) 386 4 - Out of resources 387 (NAT box cannot create any more mappings at this time) 388 5 - Unsupported opcode 390 If the result code is non-zero, the format of the packet following 391 the result code may be truncated. For example, if the client sends a 392 request to the server with an opcode of 17 and the server does not 393 recognize that opcode, the server SHOULD respond with a message where 394 the opcode is 17 + 128 and the result code is 5 (opcode not 395 supported). Since the server does not understand the format of 396 opcode 17, it may not know what to place after the result code. In 397 some cases, relevant data may follow the opcode to identify the 398 operation that failed. For example, a client may request a mapping 399 but that mapping may fail due to resource exhaustion. The server 400 SHOULD respond with the result code to indicate resource exhaustion 401 (4) followed by the requested port mapping so the client may identify 402 which operation failed. 404 Clients MUST be able to properly handle result codes not defined in 405 this document. Undefined results codes MUST be treated as fatal 406 errors of the request. 408 3.5 Recreating Mappings On Reboot 410 The NAT gateway MAY store mappings in persistent storage so when it 411 is powered off or rebooted, it remembers the port mapping state of 412 the network. However, maintaining this state is not necessary. When 413 the NAT gateway powers on or clears its port mapping state as the 414 result of a configuration change, it MUST reset the epoch time and 415 re-announce its IP address as described in Section 3.2.1 "Announcing 416 Address Changes". This will signal to clients on the network that 417 they need to redo their mappings. When a client renews its port 418 mappings as the result of receiving such a packet, it MUST delay each 419 port mapping request by a random amount of time selected with uniform 420 random distribution in the range 0 to 3 seconds. 422 3.6 Seconds Since Start of Epoch 424 Every packet sent by the NAT gateway includes a "Seconds since start 425 of epoch" field (SSSOE). If the NAT gateway resets or loses the 426 state of its port mapping table, due to reboot, power failure, or any 427 other reason, it MUST reset its epoch time and begin counting SSSOE 428 from 0 again. Whenever a client receives any packet from the NAT 429 gateway, either gratuitously or in response to a client request, the 430 client computes its own conservative estimate of the expected SSSOE 431 value by taking the SSSOE value in the last packet it received from 432 the gateway and adding 7/8 (87.5%) of the time elapsed since that 433 packet was received. If the SSSOE in the newly received packet is 434 less than the client's conservative estimate, then the client 435 concludes that the NAT gateway has undergone a reboot or other loss 436 of port mapping state, and the client MUST immediately renew all its 437 active port mapping leases as described in Section 3.6 "Recreating 438 Mappings On Reboot". 440 4. UNSAF Considerations 442 The document "IAB Considerations for UNSAF Across NAT" [RFC 3424] 443 covers a number of issues when working with NATs. RFC 3424 outlines 444 some requirements for any document that attempts to work around 445 problems associated with NATs. This section addresses those 446 requirements. 448 4.1 Scope 450 This protocol addresses the needs of TCP and UDP transport peers that 451 are separated from the public internet by exactly one NAT. Such 452 peers must have access to some form of directory server for 453 registering the public IP address and port at which they can be 454 reached. 456 4.2 Transition Plan 458 Any client making use of this protocol SHOULD implement IPv6 support. 459 If a client supports IPv6 and is running on a device with a global 460 IPv6 address, that IPv6 address SHOULD be preferred to the IPv4 461 public address using this NAT mapping protocol. In case other 462 clients do not have IPv6 connectivity, both the IPv4 and IPv6 463 addresses SHOULD be registered with whatever form of directory server 464 is used. Preference SHOULD be given to IPv6 addresses when 465 available. By implementing support for IPv6 and using this protocol 466 for IPv4, vendors can ship products today that will work under both 467 scenarios. As IPv6 is more widely deployed, clients of this protocol 468 following these recommendations will transparently make use of IPv6. 470 4.3 Failure Cases 472 Aside from NATs that do not implement this protocol, there are a 473 number of situations where this protocol may not work. 475 4.3.1 NAT Behind NAT 477 Some people's primary IP address, assigned by their ISP, may itself 478 be a NAT address. In addition, some people may have a public IP 479 address, but may then double NAT themselves, perhaps by choice or 480 perhaps by accident. Although it might be possible in principle for 481 one NAT gateway to recursively request a mapping from the next one, 482 this document does not advocate that and does not try to prescribe 483 how it would be done. 485 It would be a lot of work to implement nested NAT port mapping 486 correctly, and there are a number of reasons why the end result might 487 not be as useful as we might hope. Consider the case of an ISP that 488 offers each of its customers only a single NAT address. This ISP 489 could instead have chosen to provide each customer with a single 490 public IP address, or, if the ISP insists on running NAT, it could 491 have chosen to allow each customer a reasonable number of addresses, 492 enough for each customer device to have its own NAT address directly 493 from the ISP. If instead this ISP chooses to allow each customer 494 just one and only one NAT address, forcing said customer to run 495 nested NAT in order to use more than one device, it seems unlikely 496 that such an ISP would be so obliging as to provide a NAT service 497 that supports NAT Port Mapping Protocol. Supposing that such an ISP 498 did wish to offer its customers NAT service with NAT-PMP so as to 499 give them the ability to receive inbound connections, this ISP could 500 easily choose to allow each client to request a reasonable number of 501 DHCP addresses from that gateway. Remember that Net 10 [RFC 1918] 502 allows for over 16 million addresses, so NAT addresses are not in any 503 way in short supply. A single NAT gateway with 16 million available 504 addresses is likely to run out of packet forwarding capacity before 505 it runs out of private addresses to hand out. In this way the ISP 506 could offer single-level NAT with NAT-PMP, obviating the need to 507 support nested NAT-PMP. In addition, an ISP that is motivated to 508 provide their customers with unhindered access to the Internet by 509 allowing incoming as well as outgoing connections has better ways to 510 offer this service. Such an ISP could offer its customers real 511 public IP addresses instead of NAT addresses, or could even choose to 512 offer its customers full IPv6 connectivity, where no mapping or 513 translation is required at all. 515 4.3.2 NATs with Multiple Public IP Addresses 517 If a NAT maps private addresses to multiple public addresses, 518 then it SHOULD pick one of those addresses as the one it will 519 support for inbound connections, and for the purposes of this 520 protocol it SHOULD act as if that address were its only address. 522 4.3.3 NATs and Routed Private Networks 524 In some cases, a large network may be subnetted. Some sites may 525 install a NAT gateway and subnet the private network. Such 526 subnetting breaks this protocol because the router address is not 527 necessarily the address of the device performing NAT. 529 Addressing this problem is not a high priority. Any site with the 530 resources to set up such a configuration should have the resources to 531 add manual mappings or attain a range of globally unique addresses. 533 Not all NATs will support this protocol. In the case where a client 534 is run behind a NAT that does not support this protocol, the software 535 relying on the functionality of this protocol may be unusable. 537 4.3.4 Communication Between Hosts Behind the Same NAT 539 NAT gateways supporting NAT-PMP should also implement "hairpin 540 translation". Hairpin translation means supporting communication 541 between two local clients being served by the same NAT gateway. 543 Suppose device A is listening on private address and port 10.0.0.2:80 544 for incoming connections. Using NAT-PMP, device A has obtained a 545 mapping to public address and port x.x.x.x:80, and has recorded this 546 public address and port in a public directory of some kind. For 547 example, it could have created a DNS SRV record containing this 548 information, and recorded it, using DNS Dynamic Update [RFC 3007], in 549 a publicly accessible DNS server. Suppose then that device B, behind 550 the same NAT gateway as device A, but unknowing or uncaring of this 551 fact, retrieves device A's DNS SRV record and attempts to open a TCP 552 connection to x.x.x.x:80. The outgoing packets addressed to this 553 public Internet address will be sent to the NAT gateway for 554 translation and forwarding. Having translated the source address and 555 port number on the outgoing packet, the NAT gateway needs to be smart 556 enough to recognize that the destination address is in fact itself, 557 and then feed this packet back into its packet reception engine, to 558 perform the destination port mapping lookup to translate and forward 559 this packet to device A at address and port 10.0.0.2:80. 561 4.3.5 Non UDP/TCP Transport Traffic 563 Any communication over transport protocols other than TCP and UDP 564 will not be served by this protocol. Examples are Generic Routing 565 Encapsulation (GRE), Authentication Header (AH) and Encapsulating 566 Security Payload (ESP). 568 4.4 Long Term Solution 570 As IPv6 is deployed, clients of this protocol supporting IPv6 will be 571 able to bypass this protocol and the NAT when communicating with 572 other IPv6 devices. In order to ensure this transition, any client 573 implementing this protocol SHOULD also implement IPv6 and use this 574 solution only when IPv6 is not available to both peers. 576 4.5 Existing Deployed NATs 578 Existing deployed NATs will not support this protocol. This protocol 579 will only work with NATs that are upgraded to support it. 581 5. Security Considerations 583 As discussed in section 3.2, only clients on the private side of the 584 NAT may create port mappings, and only on behalf of themselves. By 585 using IP address spoofing, it's possible for one client to delete the 586 port mappings of another client. It's also possible for one client 587 to create port mappings on behalf of another client. The best way to 588 deal with this vulnerability is to use IPSec [RFC 2401]. 590 Since allowing incoming connections is often a policy decision, any 591 NAT gateway implementing this protocol SHOULD have an administration 592 mechanism to disable it. 594 Some people view the property that NATs block inbound connections as 595 a security benefit which is undermined by this protocol. The authors 596 of this document have a different point of view. In the days before 597 NAT, all hosts had unique public IP addresses, and had unhindered 598 ability to communicate with any other host on the Internet. When NAT 599 came along it broke this unhindered connectivity, relegating many 600 hosts to second-class status, unable to receive inbound connections. 601 This protocol goes some way to undo some of that damage. The purpose 602 of a NAT gateway should be to allow several hosts to share a single 603 address, not to simultaneously impede those host's ability to 604 communicate freely. Security is most properly provided by end-to-end 605 cryptographic security, and/or by explicit firewall functionality, as 606 appropriate. Blocking of certain connections should occur only as a 607 result of explicit and intentional firewall policy, not as an 608 accidental side-effect of some other technology. 610 6. Copyright Notice 612 Copyright (C) The Internet Society (2005). 614 This document is subject to the rights, licenses and restrictions 615 contained in BCP 78, and except as set forth therein, the authors 616 retain all their rights. For the purposes of this document, 617 the term "BCP 78" refers exclusively to RFC 3978, "IETF Rights 618 in Contributions", published March 2005. 620 This document and the information contained herein are provided on 621 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 622 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 623 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 624 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 625 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 626 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 628 7. IANA Considerations 630 No IANA services are required by this document. 632 8. Acknowledgments 634 The concepts described in this document have been explored, developed 635 and implemented with help from Bob Bradley, Josh Graessley, Rob 636 Newberry, Roger Pantos, John Saxton, and James Woodyatt. 638 9. References 640 [RFC 1918] Y. Rekhter et.al., "Address Allocation for Private 641 Internets", RFC 1918, February 1996. 643 [RFC 2119] RFC 2119 - Key words for use in RFCs to Indicate 644 Requirement Levels 646 [RFC 2131] R. Droms, "Dynamic Host Configuration Protocol", RFC 2131, 647 March 1997. 649 [RFC 2401] Atkinson, R. and S. Kent, "Security Architecture for the 650 Internet Protocol", RFC 2401, November 1998. 652 [RFC 2663] Srisuresh, P. and M. Holdrege, "IP Network Address 653 Translator (NAT) Terminology and Considerations", RFC 654 2663, August 1999. 656 [RFC 3007] Wellington, B., "Simple Secure Domain Name System 657 (DNS) Dynamic Update", RFC 3007, November 2000. 659 [RFC 3022] RFC 3022 - Network Address Translator 661 [RFC 3424] RFC 3424 - IAB Considerations for UNilateral Self-Address 662 Fixing (UNSAF) Across Network Address Translation 664 [ETEAISD] J. Saltzer, D. Reed and D. Clark: "End-to-end arguments in 665 system design", ACM Trans. Comp. Sys., 2(4):277-88, Nov. 666 1984 668 10. Authors' Addresses 670 Stuart Cheshire 671 Apple Computer, Inc. 672 1 Infinite Loop 673 Cupertino 674 California 95014 675 USA 677 Phone: +1 408 974 3207 678 EMail: rfc [at] stuartcheshire [dot] org 680 Marc Krochmal 681 Apple Computer, Inc. 682 1 Infinite Loop 683 Cupertino 684 California 95014 685 USA 687 Phone: +1 408 974 4368 688 EMail: marc [at] apple [dot] com 690 Kiren Sekar 691 Apple Computer, Inc. 692 1 Infinite Loop 693 Cupertino 694 California 95014 695 USA 697 Phone: +1 408 974 8051 698 EMail: kiren [at] apple [dot] com