idnits 2.17.1 draft-ford-behave-gen-01.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 3667, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1196. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 1188), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 41. ** The document claims conformance with section 10 of RFC 2026, but uses some RFC 3978/3979 boilerplate. As RFC 3978/3979 replaces section 10 of RFC 2026, you should not claim conformance with it if you have changed to using RFC 3978/3979 boilerplate. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. == 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 an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) == 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 == Line 333 has weird spacing: '...nly the packe...' == Line 619 has weird spacing: '...sary to assoc...' == Line 678 has weird spacing: '...lematic scena...' == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: In each of these scenarios, where an inbound packet is prohibited by a NAT device to traverse through it for resource/authorization considerations, the NAT device SHOULD not simply drop the packet silently. Instead, the NAT device SHOULD send ICMP destination unreachable message, with a code of 10 (Communication with destination host administratively prohibited) to the sender prior to dropping the packet. Unfortunately, there is not another ICMP code currently defined to indicate "Communication with destination host port administratively prohibited". So, the same code should be used for host as well as port filtering. Lastly, it is also advisable for the NAT device to log the error or record the event in a statistic counter. -- 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 (May 2005) is 6918 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) == Unused Reference: 'ARP' is defined on line 1046, but no explicit reference was found in the text == Unused Reference: 'NAT-PT' is defined on line 1062, but no explicit reference was found in the text == Unused Reference: 'RFC 1122' is defined on line 1076, but no explicit reference was found in the text == Unused Reference: 'RFC 1123' is defined on line 1079, but no explicit reference was found in the text == Unused Reference: 'RFC 1812' is defined on line 1082, but no explicit reference was found in the text == Unused Reference: 'FTP' is defined on line 1085, but no explicit reference was found in the text == Unused Reference: 'FTP-EXT' is defined on line 1095, but no explicit reference was found in the text == Unused Reference: 'BEH-IGMP' is defined on line 1104, but no explicit reference was found in the text == Unused Reference: 'BEH-TCP' is defined on line 1111, but no explicit reference was found in the text == Unused Reference: 'BEH-TOP' is defined on line 1115, but no explicit reference was found in the text == Unused Reference: 'BEH-UDP' is defined on line 1119, but no explicit reference was found in the text == Unused Reference: 'SIP' is defined on line 1133, but no explicit reference was found in the text == Unused Reference: 'TURN' is defined on line 1144, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 3235 (ref. 'NAT-APPL') ** Obsolete normative reference: RFC 4008 (ref. 'NAT-MIB') (Obsoleted by RFC 7658) ** Downref: Normative reference to an Informational RFC: RFC 3027 (ref. 'NAT-PROT') ** Obsolete normative reference: RFC 2766 (ref. 'NAT-PT') (Obsoleted by RFC 4966) ** Downref: Normative reference to an Informational RFC: RFC 2663 (ref. 'NAT-TERM') ** Downref: Normative reference to an Informational RFC: RFC 3022 (ref. 'NAT-TRAD') ** Downref: Normative reference to an Informational RFC: RFC 2694 (ref. 'DNS-ALG') -- Obsolete informational reference (is this intentional?): RFC 3489 (ref. 'STUN') (Obsoleted by RFC 5389) Summary: 19 errors (**), 0 flaws (~~), 20 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft B. Ford 3 Document: draft-ford-behave-gen-01.txt M.I.T. 4 Expires: November 8, 2005 P. Srisuresh 5 Caymas Systems 6 S. Sivakumar 7 Cisco Systems 8 May 2005 10 Operating Principles and General Behavioral Requirements 11 for Network Address Translators (BEH-GEN) 13 Status of this Memo 15 By submitting this Internet-Draft, I certify that any applicable 16 patent or other IPR claims of which I am aware have been disclosed, 17 or will be disclosed, and any of which I become aware will be 18 disclosed, in accordance with RFC 3668. 20 This document is an Internet-Draft and is subject to all provisions 21 of Section 10 of RFC2026. Internet-Drafts are working documents of 22 the Internet Engineering Task Force (IETF), its areas, and its 23 working groups. Note that other groups may also distribute working 24 documents as Internet-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/1id-abstracts.html 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html 37 Distribution of this document is unlimited. 39 Copyright Notice 41 Copyright (C) The Internet Society (2005). All Rights Reserved. 43 Abstract 45 This document discusses the operating principles of Network Address 46 Translator (NAT) devices and the behavioral properties required to 47 make NAT more predictable and compatible with diverse application 48 protocols. First, this document presents an architectural model for 49 NAT devices and defines important terms used in conjunction with 50 NAT operation. The architectural model sets the stage for a set of 51 concrete recommendations for NAT implementers. The recommendations 52 made by this document are independent of transport protocol. A set 53 of companion documents provide behavioral recommendations specific 54 to particular transport protocols. 56 Table of Contents 58 1. Introduction & Scope ......................................... 59 2. Operating principles and terminology ......................... 60 2.1. Address/Port Maps ....................................... 61 2.2. Address/Port Bindings ................................... 62 2.3. NAT Session ............................................. 63 2.4. Cone/Symmetric NAT behaviors ............................ 64 2.4.1. Symmetric NAT ......................................... 65 2.4.2. Port Restricted Cone NAT .............................. 66 2.4.3. Address Restricted Cone NAT ........................... 67 2.4.4. Full Cone NAT ......................................... 68 2.5. Multi Level NAT topology ................................ 69 2.6. Hairpin NAT Session & Hairpin NAT translation ........... 70 3. General Behavioral Requirements for NATs ..................... 71 3.1. Transport Protocol support .............................. 72 3.2. Address Binding and/or Port Binding support ............. 73 3.3. Fragment support for inbound IP packets ................. 74 3.4. Fragment processing on the outbound ..................... 75 3.5. Hairpin NAT translation ................................. 76 3.6. DHCP-Configured NATs .................................... 77 3.7. Honor the DF bit in IP header ........................... 78 3.8. ICMP Error packet handling .............................. 79 3.9. Rejection of IP packets not permitted by NAT ............ 80 3.10. ALG support ............................................ 81 3.11 Denial-of-Service Protection ............................ 82 4. Hints to implementers ......................................... 83 4.1. Inbound fragmented packet processing .................... 84 4.2. Port reservation ........................................ 85 4.3. DHCP Configured NATs .................................... 86 5. Summary of Requirements ...................................... 87 6. Security Considerations ...................................... 89 1. Introduction & Scope 91 Due to various technical and market pressures, Network Address 92 Translators (NATs) have become a ubiquitous part of today's 93 Internet. NATs cause well-known problems for applications, 94 especially those that carry IP addresses in their message payloads 95 [NAT-PROT]. RFC 3235 [NAT-APPL] provides some recommendations for 96 making application protocols compatible with NAT. But, these 97 recommendations do not adequately address applications with 98 "peer-to-peer" (P2P) communication patterns, which by their nature 99 carry IP addresses in message payloads. Peer-to-peer applications 100 that suffer from this problem include Voice Over IP and Multimedia 101 Over IP [SIP, H.323], as well as online games. In the face of the 102 prevalence of NAT, applications are forced to use ad-hoc techniques 103 in an attempt to function reliably across NATs. A companion document 104 [BEH-STATE] describes the current "state of the art" in NAT traversal 105 techniques adapted by peer-to-peer applications. 107 As stated in RFC 3424 [UNSAF], there is wide degree of variability in 108 how NAT devices behave. This document defines a set of requirements 109 for NAT behavior that will reduce the unpredictability and 110 brittleness of the NAT devices and enable applications to traverse 111 them reliably. The requirements specified here apply generally to all 112 NAT variations described in RFC 2663 [NAT-TERM], including 113 Traditional NAT (i.e., Basic NAT and NAPT), Bi-directional NAT, and 114 Twice NAT. However, the primary focus of this document is NAPT, a 115 variant of Traditional NAT that is most widely deployed today. 117 Traditional NAT inherently mandates a certain level of firewall-like 118 functionality. However, firewall functionality in general is out of 119 the scope of this specification. 121 NAT traversal strategies that involve explicit signaling between the 122 application and the NAT [SOCKS, RSIP, MIDCOM, UPNP] are out of the 123 scope of this document. 125 This document focuses strictly on the behavior of the NAT itself, 126 and not on the behavior of applications that traverse NATs. 127 A separate companion document [BEH-APP] provides recommendations for 128 application designers on how to make applications work robustly over 129 NATs that follow the behavioral requirements specified here and the 130 companion Behave documents. 132 The following section is devoted to describing the principles of 133 NAT operation and the various terms used throughout the behave 134 working group documents. This section serves to provide a technical 135 perspective behind the recommendations made in the next section. 136 Section 3 lists the general recommendations to NAT vendors, 137 independent of the transport protocol specific recommendations. 138 Section 4 provides some hints on how to implement some of the 139 requirements listed in section 3. Lastly, section 5 summarizes 140 all the requirements in one place. 142 2. Operating principles and terminology 144 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 145 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 146 document are to be interpreted as described in RFC 2119 [KEYWORDS]. 148 Readers are urged to refer to RFC 2663 [NAT-TERM] for information on 149 basic NAT taxonomy and terminology. Most NAT devices deployed today 150 fall under the category of Traditional NAT, which implement an 151 asymmetric translation scheme that multiplexes many hosts on a 152 "private" network onto one or a few "public" IP addresses. Readers 153 may refer to RFC 3022 [NAT-TRAD] for a detailed description on 154 traditional NAT. 156 This section uses the combination of RFC 2663 [NAT-TERM] and RFC 4008 157 [NAT-MIB] to outline the basic principles of NAT operation, and 158 defining technical terms used throughout. Newer terms not found in 159 either of the documents may also be found defined in this section. 161 The following diagram presents a general architectural model 162 describing NAT operation. The model does not provide a method of 163 implementing NAT, but serves as a framework for understanding the 164 rationale behind behavioral requirements described later in the 165 document. 167 NAT Device 168 +------------------------------------------------+ 169 | | 170 | +------------+ +----------+ +----------+ | 171 | | Address/ | | Address/ | | | | 172 | | Port |==>| Port |==>| NAT | | 173 | | Maps | | Bindings | | Sessions | | 174 | | (Admin | | (Static &| | (Dynamic)| | 175 | | Configured)| | Dynamic) | | | | 176 | +------------+ +----------+ +----------+ | 177 | ^ | 178 | | | 179 | +----------------------+ | 180 | | | 181 Incoming | +-------+------+ +-------------+ |Outgoing 182 Packets | | NAT Packet | | IP routing/ | |Packets 183 -------->+ ---->| Translation |---->| Forwarding |----> |-------> 184 | | | | | | 185 | +--------------+ +-------------+ | 186 | | 187 +------------------------------------------------+ 189 Figure 1: Architectural model describing NAT operation 191 Figure-1 above is a pictorial overview of how a NAT operates and 192 encompasses the building blocks of a NAT device. Central to the 193 NAT operation is three tables comprised of "Address/Port Maps", 194 "Address/Port Bindings", and "NAT Sessions". The tables are 195 described in detail in the following subsections. Implementation 196 of these tables vary across different vendors. All vendors 197 implement Address/port maps and NAT Sessions in some form. 198 Vendors supporting Symmetric NAT behavior do not 199 implement Address/Port Bindings, but derive the NAT Sessions 200 directly from the address/port maps. 202 Packet processing within a NAT device works roughly as follows. 203 The NAT device first looks up the incoming packet against the 204 known set of NAT Sessions. If a match is not found and this is 205 likely the first packet of a new session, a new NAT session may 206 be created based on either the existing bindings or the address 207 maps. NAT translates the packet as specified by the matching NAT 208 Session. The translated packet is looked up in the routing 209 table for forwarding to the next hop. 211 2.1. Address/Port Maps 213 This document used the term Address Map as defined in RFC 4008 215 [NAT-MIB]. The Address/Port Map table represents the 216 configuration database set up by the NAT administrator. The 217 entries of the table determine the type of NAT the device 218 implements. For example, Basic NAT, NAPT, Bidirectional NAT, 219 Twice-NAT, or a combination thereof. The Address Map table may 220 also contain static (i.e., permanent) mappings between IP 221 addresses and/or port endpoints. Say, a mapping between port 222 80 on the NAT's public IP address and a particular Web server 223 located on the internal network. 225 2.2. Address/Port Bindings 227 This document uses the term "Address Binding" as defined in RFC 3022 228 and "port binding" as defined in RFC 4008. A NAT device may 229 implement both Address and Port Bindings. 231 Address Binding is a persistent association between a particular 232 IP address on the NAT's internal address realm, and an IP address on 233 its external realm, which the NAT assigns as the internal node's 234 "public address" for the purpose of communicating across the NAT. 236 A Port Binding similarly represents a persistent association between 237 an internal (IP address, TCP/UDP port) endpoint and a corresponding 238 external (IP address, TCP/UDP port) endpoint. A NAPT generally 239 establishes a Port Binding while setting up the first outgoing NAT 240 session originating from a particular internal (IP address, TCP/UDP 241 port) endpoint. Once that Binding has been established, the NAT re- 242 uses the same Port Binding whenever it subsequently establishes a new 243 outgoing NAT Session originating from the same internal endpoint (but 244 possibly targeted at a different external endpoint). 246 Not all existing NATs use Address or Port Bindings to determine their 247 IP address and port translation behavior, however. Some existing 248 NATs setup NAT Sessions directly from the Address/Port maps without 249 creating any Bindings. The notion of address/port binding is crucial 250 to making NATs behave in a predictable fashion for a number of 251 application communication patterns. 253 A Binding represents the association between internal and external 254 entities (addresses or endpoints) the NAT has set up. The NAT can 255 create Bindings in the Binding table either statically, to reflect 256 the static one-to-one configuration entries in the NAT Address Map 257 table, or dynamically prior to setting up NAT session flows across 258 the NAT. A Binding can be between a pair of IP addresses or a pair 259 of end points representing the same entity across two realms. 260 Binding between a pair of addresses is called Address Binding. 261 Binding between a pair of TCP/UDP endpoints is called TCP/UDP Port 262 Binding, or simply, Port Binding, for short. Bindings are 263 directional. 265 2.3. NAT Session 267 The term "NAT Session" was first defined in RFC 4008[NAT-MIB] 268 to represent the dynamic state the NAT uses to translate the 269 individual packets comprising a particular communication session 270 flowing across the NAT. 272 A NAT session is conceptually defined by a tuple of the 273 following form: 275 (origin session, origin side, target session, target side) 277 The "origin side" and "target side" components of this tuple are 278 simply the tags "Internal" or "External". An actual NAT 279 implementation might use a one-bit flag, for example, or a physical 280 network interface name or number, to represent these "side" tags. 281 The "origin side" indicates which side of the NAT, and thus which IP 282 address realm, the logical session originated from: that is, on which 283 side the NAT received the packet that first initiated the session. 284 The "target side" indicates which side of the NAT and which address 285 realm the logical session is targeted toward. A NAT Session's 286 origin and target endpoints are usually on opposite sides of the NAT, 287 but not always. 289 The "origin session" and "target session" components are ordinary 290 session tuples as described above, describing the session's identity 291 within the IP address realm indicated by the corresponding "side" 292 component. For example, the "origin session" is the complete (source 293 IP, source port, dest IP, dest port) tuple describing the session's 294 identity on the side of the NAT from which the session was initiated, 295 and the "target session" is the complete (source IP, source port, 296 dest IP, dest port) tuple describing the session's identity as it 297 appears on the side of the NAT to which the session was targeted. 299 2.4. Cone/Symmetric NAT behaviors 301 RFC 3489 [STUN] defines terminology for several different NAT 302 variations. In particular, it uses the terms "Full Cone", 303 "Restricted Cone", "Port Restricted Cone" and "Symmetric" to refer to 304 different variations of a NAT's IP address and port assignment 305 behavior. These terms have historically been used only to describe a 306 NAT's behavior with respect to the UDP transport, although the issues 307 these terms were intended to address are also important for TCP. 309 Unfortunately, besides being historically attached to the UDP 310 transport protocol, these categories have proven insufficient to 311 represent the full range of NAT behaviors that have been observed to 312 exist. This specification therefore defines specific NAT behaviors 313 individually instead of using the broad Cone/Symmetric terminology. 314 The specific relationship between the historical Cone/Symmetric 315 terminology and the individual NAT behaviors may be defined as below. 317 2.4.1. Symmetric NAT 319 Symmetric NAT behavior is one exhibited by a NAT device that does NOT 320 use Address Binding or Port Binding for TCP/UDP based NAT sessions. 321 If a TCP/UDP endpoint on a private host, denoted by the tuple of 322 (IP address, port no), originated multiple sessions, a new public 323 TCP/UDP port is assigned to translate the private endpoint in each 324 new session. 326 2.4.2. Port Restricted Cone NAT 328 Port Restricted Cone NAT behavior is one exhibited by a NAT device 329 that uses Address/Port Binding and behaves as follows. If the TCP/UDP 330 endpoint on a private host, denoted by the tuple of (IP address, 331 port no), originated multiple sessions, the same public TCP/UDP port 332 is assigned to translate the private endpoint in each new session. 333 Further, only the packets that belong to the sessions initiated by 334 the private host are permitted on the inbound. 336 2.4.3. Address Restricted Cone NAT 338 Address Restricted Cone NAT behavior is one exhibited by a NAT 339 device that uses Address/Port Binding and behaves as follows. Once 340 a UDP endpoint on a private host, denoted by the tuple of 341 (IP address, port no), originated a UDP session, Address-restricted 342 Cone NAT will accept incoming UDP packets to the corresponding 343 public port from only those external endpoints whose IP address 344 match the address of external endpoint to which the private endpoint 345 had initiated outgoing sessions. 347 2.4.4. Full Cone NAT 349 Full Cone NAT behavior is one exhibited by a NAT device 350 that uses Address/Port Binding and behaves as follows. Once a UDP 351 endpoint on a private host, denoted by the tuple of (IP address, 352 port no), originated a UDP session, Full Cone NAT will accept 353 incoming UDP packets to the corresponding public port from any 354 external endpoint. 356 2.5. Multi Level NAT topology 358 The term "Multi Level NAT" is not defined in any earlier documents. 360 The term is being defined for the first time in this document. 361 Multi Level NAT topology is a network topology in which NAT devices 362 can be found at two or more levels between communicating endpoints. 363 NATs are increasingly, and often unintentionally, used to create 364 hierarchically interconnected clusters of private networks in which 365 some hosts are separated from the Internet by more than one level of 366 Traditional NAT. The following diagram illustrates this situation. 368 Internet 369 (public IP addresses) 370 ------------------+---------------+-- 371 | | 372 | | 373 +-------------+ Host S 374 | NAT-1 | 375 +-------------+ 376 | 377 | 378 Private Network 1 379 (private IP addresses) 380 ----+---------------------------+---- 381 | | 382 | | 383 +-------+ +-------+ 384 | NAT-2 | | NAT-3 | 385 +-------+ +-------+ 386 | | 387 | | 388 Private Network 2 Private Network 3 389 (private IP addresses) (private IP addresses) 390 ----+-----------+---- ----+-----------+---- 391 | | | | 392 | | | | 393 Host A Host B Host C Host D 395 Figure 2. Multi Level NAT topology 397 NAT-1 may for example be a large enterprise NAT deployed by an ISP 398 that does not have enough IP addresses to assign one to each of its 399 customers, an increasingly common situation especially in developing 400 countries. NAT-2 and NAT-3 are consumer-level NATs deployed 401 independently by the ISP's customers to multiplex their small home 402 or business networks onto the single IP address their ISP gives 403 them via DHCP. 405 Neither the ISP nor the customers necessarily intend to create this 406 hierarchical Multi Level NAT topology. Multi Level NAT topologies 407 arise merely as a consequence of the same technical and economic 408 factors that drove the wide deployment of NATs in the first place. 410 2.6. Hairpin NAT Session & Hairpin NAT translation 412 The terms "Hairpin NAT Session" and "Hairpin NAT translation" are 413 not defined in any earlier documents. The terms are being defined 414 for the first time in this document. 416 Hairpin NAT Session is a NAT Session having the form (origin session, 417 Internal, target session, Internal), and represents a logical 418 communication session whose endpoints are both on the internal 419 network, but which nevertheless flows "through" the NAT and requires 420 address translation. The translation of packets subject to a Hairpin 421 NAT Session is called Hairpin NAT translation, or simply Hairpin NAT. 422 Packets subject to Hairpin NAT translation would undergo translation 423 for both source and destination endpoints within the same NAT device. 425 The need for Hairpin NAT arises out of the necessity to support 426 application traversal through Multi Level NATs. Hairpin NAT 427 translation refers to the ability of a NAT device to allow multiple 428 private endpoints behind the NAT to communicate with each other 429 using each other's *public* (translated) endpoints. 431 When two hosts reside on different private networks but nevertheless 432 have at least one NAT in common, it is not possible for the two hosts 433 to establish direct peer-to-peer communication with each other unless 434 the common NAT(s) support hairpin translation. The following diagram 435 illustrates this situation. 437 Server S 438 (S:s) 439 | 440 ^ Session A-S ^ | ^ Session B-S ^ 441 | (A1:a1,S:s) | | | (B1:b1,S:s) | 442 | 443 +-------------+ 444 | NAT-1 | 445 +-------------+ 446 | 447 | Private Network 1 448 +------------------------+------------------------+ 449 | | 450 | ^ Session A-S ^ ^ Session B-S ^ | 451 | | (A2:a2,S:s) | | (B3:b3,S:s) | | 452 | | 453 | ^ Session A-B | ^ Session B-A ^ | 454 | | (A2:a2,B1:b1) | | (B2:b2,A1:a1) | | 455 | | 456 +-------------+ +-------------+ 457 | NAT-2 | | NAT-3 | 458 +-------------+ +-------------+ 459 | | 460 | Private Network 2 Private Network 3 | 461 ---+---+------------- ------------------+---+----- 462 | | 463 | ^ Session A-S ^ ^ Session B-S ^ | 464 | | (A:a,S:s) | | (B:b,S:s) | | 465 | | 466 | ^ Session A-B ^ ^ Session B-A ^ | 467 | | (A:a,B1:b1) | | (B:b,A1:a1) | | 468 | | 469 Host A Host B 470 (A:a) (B:b) 472 Figure 3. Hairpin NAT translation in a Multi Level NAT scenario 474 Suppose Host A in the topology above initiates an outgoing session 475 A-S from private endpoint A:a to public endpoint S:s on Host S, a 476 "well-known" server on the Internet. In setting up this 477 outgoing session, NAT-2 first creates an outgoing NAT Session that 478 translates the session tuple (A:a, S:s) on Private Network 2 to a 479 corresponding session tuple (A2:a2, S:s) on Private Network 1. This 480 outgoing session then traverses through NAT-1, which creates a new 481 NAT session mapping the session tuple (A2:a2, S:s) on Private 482 Network 1 to the session tuple (A1:a1, S:s) on the main Internet. 484 Host B similarly initiates an outgoing session from B:b to S:s, 485 causing NAT-3 to assign "intermediate" source endpoint B3:b3 to this 486 session as it appears on Private Network 2, and in turn causing NAT-1 487 to assign public source endpoint B1:b1 to this session as it appears 488 on the Internet. 490 Client hosts A and B now obtain from S each other's public source 491 endpoints as known to S, namely B1:b1 and A1:a1, respectively. Each 492 client then attempts to open a peer-to-peer communication session 493 targeting the other host's public endpoint, as described fully in 494 the companion document [BEH-APP]. 496 To NAT-1, the common NAT, Host A's attempt to open a peer-to-peer 497 connection to B appears as an attempt received from private endpoint 498 A2:a2, and directed to "public" endpoint B1:a1. This "public" 499 endpoint, however, is merely one of the temporary public endpoints 500 that NAT-1 itself previously assigned to represent B's "intermediate" 501 private endpoint B3:b3! 503 In order to handle this communication attempt properly, NAT-1 needs 504 to set up a Hairpin NAT session for packets traveling from A to B. 505 Subsequent to that, NAT-1 would translate A's "intermediate" private 506 source endpoint A2:a2 into A's corresponding public source endpoint 507 A1:a1, and simultaneously translates B's public destination endpoint 508 B1:b1 into B's corresponding "intermediate" private endpoint B3:b3, 509 before forwarding the translated packet on to B3:b3 on its private 510 network. This packet will then traverse NAT-3 and reach Host B with 511 a destination endpoint of B:b and a source endpoint of A1:a1. 513 Conversely, for packets flowing from B to A, NAT-1 translates B's 514 intermediate private source endpoint B3:b3 into its corresponding 515 public source endpoint B1:b1, and simultaneously translates A's 516 public destination endpoint A1:a1 into A's intermediate private 517 endpoint A2:a2, before forwarding the translated packet on to A2:a2 518 and eventually to A:a. 520 3. General Behavioral Requirements for NATs 522 This section lists the general behavioral requirements for a NAT 523 device when processing IP packets. Even though ICMP is a transport 524 protocol on top of IP, ICMP packet processing is considered an 525 integral of IP processing itself. With the exception of ICMP, 526 the behavioral requirements laid out below are independent of the 527 transport protocol. Associated with each requirement, the 528 rationale behind the requirement is discussed in detail. 530 3.1. Transport Protocol support 532 TCP and UDP are by far the most common and widely deployed IP 533 transport protocols, although other transports exist as well. 534 Of the various NAT types, NAPT is the most restrictive in terms of 535 the transport protocol support. For widespread application 536 compatibility, therefore, it is crucial that any NAT support at least 537 the TCP and UDP transports, and NATs are encouraged to support other 538 transport protocols as well as they become standardized and deployed. 540 REQ-1: A NAT MUST support the traversal of TCP based applications 541 and unicast UDP based applications. 543 3.2. Address Binding and/or Port Binding support 545 Several applications use the same endpoint within a realm to 546 establish multiple simultaneous sessions. Many peer-to-peer 547 applications use the public endpoint registration of peering hosts 548 to initiate sessions into. 550 In order to support peer-to-peer applications and applications 551 that entertain multiple simultaneous session using the same TCP/UDP 552 endpoint, NAT MUST retain the association it assigned to an endpoint 553 between realms and reuse the same endpoint association when 554 multiple sessions using the same endpoint are routed through the 555 NAT device. This issue is of general relevance for any transport 556 protocol that use port numbers to represent communication endpoints, 557 including TCP and UDP. Such a binding between endpoints can 558 occur when a NAT device maintains Address Bindings or Port 559 Bindings. 561 REQ-2: A NAT device MUST support Address and/or Port Bindings. 562 Specifically, Symmetric NAT type behavior MUST be deprecated. 564 3.3. Fragment support for inbound IP packets 566 Routers in the network are able to forward fragmented IP packets 567 just as they do any other non-fragmented IP packets because packet 568 forwarding is based solely on looking up the destination IP 569 address in the routing table and finding the largest prefix match 570 to identify the next-hop to forward to. Routers do not need to 571 retain any state pertaining to fragmented packets traversing them. 573 A NAT device operates differently from a router in that the NAT 574 device must find the matching NAT Session for an IP packet and 575 perform NAT translation on the packet, prior to forwarding. NAT 576 Session lookup requires the full 5-tuple of the IP datagram. Only 577 the first fragment of the IP datagram contains the full-tuple. 578 Subsequent fragmented packets contain the fragment Id, but do not 579 contain transport protocol specific details such as source and 580 destination port numbers. The NAT device must be able to associate 581 the same session tuple for all fragments by virtue of the fragment 582 ID and use that information to locate the NAT Session the packets 583 belong to. Note however, the IP fragments cannot be assumed to 584 arrive in order. Some operating systems transmit the fragments of 585 an IP datagram out of their logical order as a matter of course. 586 In addition, network conditions can also cause dynamic packet 587 reordering in transit. 589 A NAT device MUST be capable of processing all fragments of an 590 IP datagram inbound to the NAT device. The NAT device MUST retain 591 the assembly state pertaining to a fragmentation ID until all 592 fragments of the IP datagram are processed. By doing this, NAT is 593 able to process all fragments pertaining to an IP datagram using 594 the same NAT Session the IP datagram belongs to. 596 Applications such as NFSv2 over UDP assume a default read/write 597 buffer size of 8192 bytes and rely on IP fragmentation support 598 in the network. A fully assembled IP datagram will be about 599 8300 bytes long. NAT devices MUST support the traversal of 600 common applications such as this. 602 REQ-3: A NAT device MUST be able to process (i.e., receive, 603 translate, and forward) all fragments of an IP datagram, whether 604 they arrive in order or out of order. A NAT device MUST process 605 IP fragments that assemble to a maximum of 8300 byte IP 606 datagrams. 608 3.4. Fragment processing on the outbound 610 Say, two private hosts originated TCP/UDP packets (fragmented 611 or not) to the same destination host and both packets transit 612 the same NAPT device and use the same fragmentation identifier. 613 Say, the NAPT device assembled the IP packets (in the case they 614 were fragmented) and translated the same using the appropriate 615 NAT Sessions. When NAPT translates IP datagrams, it would assign 616 all outbound IP datagrams the same Public IP, but different 617 TCP/UDP numbers. While forwarding, an IP datagram may be 618 fragmented on the way out. Only the first fragment contains the 619 TCP/UDP header that would be necessary to associate the packet to 620 a specific session. Subsequent fragments do not contain TCP/UDP 621 port information, but simply carry the same fragmentation 622 identifier specified in the first fragment. 624 When the target host receives the two unrelated datagrams, carrying 625 same fragmentation id, and from the same assigned host address, the 626 target host is unable to determine which of the two sessions the 627 datagrams belong to and might corrupt both sessions. 629 In order to avoid problems of this kind, the NAPT device SHOULD 630 further translate fragment ID in the outgoing packets such 631 that the tuples of (SrcIP, DestIP, fragment Id, Protocol) are 632 unique and distinguishable across all outgoing packets from the 633 NAT device. 635 REQ-4: When fragmenting packets on the outbound, a NAT device SHOULD 636 ensure that the tuples of (SrcIP, DestIP, fragment Id, Protocol) 637 are unique across all outgoing packets. This requirement pertains 638 specifically to NAPT devices. 640 3.5. Hairpin NAT translation 642 Multi Level NATs are commonly deployed. Private hosts behind the 643 Multi Level NATs use their public endpoint identity to communicate 644 with each other. Hairpin NAT translation MUST be supported in the 645 NAT devices to allow applications on the private hosts to 646 communicate with each other. 648 REQ-5: All NATs MUST support hairpin NAT translation. 650 3.6. DHCP-Configured NATs 652 Many NATs, particularly consumer-level devices designed to be 653 deployed by nontechnical users, also act as DHCP clients. In its 654 default configuration, a consumer NAT typically obtains its public IP 655 address, default router, and other IP configuration information via 656 DHCP from an ISP or other "upstream" network. 658 On its internal network side, the NAT then automatically sets up its 659 own private "downstream" subnet in one of the private IP address 660 regions assigned to this purpose in RFC 1918 [PRIV-ADDR]. The NAT 661 typically acts as a DHCP server for its private downstream network, 662 managing its pool of private IP addresses automatically and handing 663 them out to the hosts (and perhaps other NATs) on the private network 664 on demand. 666 This auto-configuration of private networks can be problematic, 667 however, if the NAT's upstream network is also in RFC 1918 private 668 address space. In the Multi Level NAT scenario described in section 669 2.5, NAT-2 and NAT-3 are likely to be consumer-level NATs that obtain 670 their "external" IP addresses on Private Network 2 from NAT-1's DHCP 671 server. Thus, from the viewpoint of NAT-2 or NAT-3, both their 672 "internal" and "external" networks are probably in the private 673 RFC 1918 address regions, and may even use numerically overlapping 674 IP addresses. 676 DHCP configured NAT vendors must carefully design their NATs to 677 ensure that they function correctly and robustly even in such 678 problematic scenarios. 680 REQ-6: A NAT device whose external IP interface can be configured 681 via DHCP MUST operate correctly even if its external interface's IP 682 address and subnet configuration numerically conflicts with the 683 IP address and subnet configuration of the NAT's internal 684 interface(s). 686 3.7. Honor the DF bit in IP header 688 A NAT device MUST honor the DF (Don't Fragment) bit in the IP header 689 of the packets that transit the NAT device. Majority of the TCP 690 sessions have the DF bit set and will expect the devices enroute to 691 not fragment the TCP segments. If the MTU on the forwarding interface 692 of the NAT device is such that the IP datagram cannot be forwarded 693 without fragmentation, NAT MUST send a destination unreachable ICMP 694 message (ICMP type 3, Code 4) with a suggested MTU back to the sender 695 and drop the IP packet. The sender will resend after taking an 696 appropriate corrective action. 698 REQ-7: If DF bit is set on an inbound IP packet and the NAT device 699 cannot forward the packet without fragmentation, the NAT device 700 MUST send a destination unreachable ICMP message (ICMP 701 type 3, Code 4) with a suggested MTU back to the sender prior to 702 dropping the IP packet. 704 3.8. ICMP Error packet handling 706 A NAT device MUST transparently forward ICMP error messages ([ICMP]) 707 it receives from intermediate or end nodes in either realm to the 708 intended endnode. Unlike other IP packets, the basis for translation 709 of an ICMP error packet is the NAT Session to which the packet 710 embedded within the ICMP error message payload belongs to, not the IP 711 and ICMP headers in the outer layer. 713 Consider the following scenario in figure 4. Say, NAT-xy is a 714 traditional NAT device connecting hosts in private and external 715 networks. Router-x and Host-x are in the external network. Router-y 716 and Host-y are in the private network. The subnets in the external 717 network are routable from the private as well as the external 718 domains. Whereas, the subnets in the private network are only 719 routable within the private domain. When Host-y initiated a session 720 to Host-x, let us say that the NAT device assigned an IP address of 721 Host-y' to associate with Host-y in the external network. 723 Host-x 724 | 725 | 726 ---------------+------------------- 727 | 728 | 729 +-------------+ 730 | Router-x | 731 +-------------+ 732 | 733 External Network | 734 --------------------+--------+------------------- 735 | 736 | ^ | 737 | | (Host-y', Host-x) | 738 | | v 739 | 740 +-------------+ 741 | NAT-xy | 742 +-------------+ 743 | 744 | Private Network 745 ----------------+------------+---------------- 746 | 747 | 748 | 749 +-------------+ 750 | Router-y | 751 +-------------+ 752 | 753 | 754 ----------------+-------+-------- 755 | 756 | ^ | 757 | | (Host-y, Host-x) | 758 | | v 759 | 760 Host-y 762 Figure 4. NAT topology with intermediate routers in both realms 764 Say, a packet from Host-y to Host-x triggered an ICMP error message 765 from one of Router-x or Host-x (both of which are in the external 766 domain). Such an ICMP error packet will have one of Router-x or 767 Host-x as the source IP address and Host-y' as the destination IP 768 address. When the NAT device receives the ICMP error packet, the 769 NAT device must use the packet embedded within the ICMP error 770 message (i.e., the IP packet from Host-y to Host-x) to look up the 771 NAT Session the embedded packet belongs to and use the NAT Session 772 to translate the embedded payload. The NAT device must also use the 773 NAT Session to translate the outer IP header. In the outer header, 774 the source IP address will remain unchanged because the originator 775 of the ICMP error message (Host-x or Router-x) is in external 776 domain and routable from the private domain. The destination IP 777 address Host-y' must however be translated to Host-y using the NAT 778 Session parameters. 780 Now, say, a packet from Host-x to Host-y triggered an ICMP error 781 message from one of Router-y or Host-y (both of which are in the 782 private domain). Such an ICMP error packet will have one of 783 Router-y or Host-y as the source IP address and Host-x as the 784 destination IP address. When the NAT device receives the ICMP error 785 packet, the NAT device must use the packet embedded within the ICMP 786 error message (i.e., the IP packet from Host-x to Host-y) to look up 787 the NAT Session the embedded packet belongs to and use the NAT 788 Session to translate the embedded payload. The NAT device must also 789 use the NAT Session to translate the outer IP header. In the outer 790 header, the destination IP address will remain unchanged, as the IP 791 addresses for Host-x is already in the external domain. If the ICMP 792 error message is generated by Host-y, the NAT device must simply 793 use the NAT Session to translate the source IP address Host-y to 794 Host-y'. However, if the ICMP error message is generated by the 795 intermediate node Router-y, the NAT device will not have had a 796 translation entry for Router-y within the NAT Session. The NAT may 797 also not have an Address Binding in place for Router-y. In such a 798 case, the NAT device must simply use its own IP address in the 799 external domain to translate the source IP address. 801 Changes to ICMP error message ([ICMP]) MUST include changes to IP and 802 ICMP headers on the outer layer as well as changes to the relevant 803 IP and transport headers of the packet embedded within the ICMP-error 804 message payload. Section 4.3 of the RFC 3022 describes the various 805 items within the ICMP error message that MUST be translated by the 806 NAT device. 808 REQ-8: A NAT device MUST transparently forward the ICMP error 809 messages it receives from the intermediate or end nodes in either 810 realm to the intended endnode. The NAT device MUST use the packet 811 embedded within the ICMP error message payload as the basis to 812 translate not only the embedded payload, but also the IP and ICMP 813 headers in the outer layer. In the case the ICMP error packet is 814 generated by an intermediate node for which the NAT has no Binding 815 translation, the NAT device MUST use its own IP address in the realm 816 of the recipient node to translate the intermediate node IP address. 818 3.9 Rejection of IP packets not permitted by NAT 820 Unlike a router, a NAT device is session oriented and permits 821 sessions from/to specific endpoints in either the external or 822 internal realm based on how the NAT device is configured with 823 Address/Port Maps. For example, a TCP packet is not permitted across 824 a NAT device unless the specific TCP session is already in progress 825 and known to the NAT device. Further, inbound sessions are not 826 permitted into a traditional NAT device by default. In addition, a 827 new session may not be able to transit a NAT device due to the 828 NAT device running of addresses in the address pool or ports in the 829 TCP/UDP port pool or because of an administrative policy. 831 In each of these scenarios, where an inbound packet is prohibited by 832 a NAT device to traverse through it for resource/authorization 833 considerations, the NAT device SHOULD not simply drop the packet 834 silently. Instead, the NAT device SHOULD send ICMP destination 835 unreachable message, with a code of 10 (Communication with 836 destination host administratively prohibited) to the sender prior to 837 dropping the packet. Unfortunately, there is not another ICMP code 838 currently defined to indicate "Communication with destination host 839 port administratively prohibited". So, the same code should be used 840 for host as well as port filtering. Lastly, it is also advisable for 841 the NAT device to log the error or record the event in a statistic 842 counter. 844 REQ-9: When an inbound packet is prohibited by a NAT device due to 845 resource/authorization considerations, the NAT device SHOULD send 846 ICMP destination unreachable message, with a code of 10 847 (Communication with destination host administratively prohibited) 848 to the sender prior to dropping the packet. 850 3.10. ALG support 852 Strictly speaking, NAT devices are not required to include ALGs. 853 However, vast majority of the NAT devices in deployment do support 854 Application Level Gateways (ALGs) for FTP and DNS applications. 855 The ALG for FTP is discussed briefly in RFC 3022 and RFC 2766. The 856 ALG for DNS is described in detail in [DNS-ALG]. Given that majority 857 of the applications assume this to be part of NAT devices, and 858 majority of the NAT devices support these ALGs anyway as an integral 859 part, we recommend the NAT devices to support the ALGs for these two 860 applications by default. 862 REQ-10: A NAT device SHOULD support ALGs for FTP and DNS, so as to 863 enable traversal of these applications across NAT. In addition, NAT 864 devices SHOULD explicitly identify the ALGs supported, and make ALG 865 support configurable (enable/disable). 867 3.11 Denial-of-Service Protection 869 Since NAT devices are Internet hosts they can be the target of a 870 number of different attacks. NAT devices should employ the same sort 871 of protection techniques as Internet-based servers do. 873 For example, storing incomplete IP packet fragments unfortunately 874 creates a well-known vulnerability to denial-of-service attacks, 875 against which NATs should protect themselves. NATs typically do so 876 by limiting the length of time they retain an incomplete IP packet 877 before discarding it, or alternatively by limiting the amount of 878 internal buffer space such incomplete IP packets may consume before 879 the oldest fragments are discarded. The appropriate values of these 880 limits vary depending on the size and purpose of the NAT, however, 881 and therefore are left to be determined by the NAT designer or 882 network administrator. 884 Further, the NAT device should impose a rate limit on the ICMP 885 error messages it generates for whatever reason. 887 REQ-11: A NAT device SHOULD protect itself against Denial of Service 888 attacks arising out of fragment processing and generating ICMP error 889 responses to unauthorized packets. 891 4. Hints to implementers 893 The following subsections provides hints to implementers on how to go 894 about the requirements outlined in the previous section. Note, these 895 are merely hints, not requirements. Implementers may choose to ignore 896 the hints. 898 4.1. Inbound fragmented packet processing 900 Large IP datagrams (sometimes, even the small IP datagrams) may 901 arrive as fragmented IP packets into a NAT device. The tuples of 902 (SrcIP, DestIP, Fragment Id, Protocol) will be unique for these 903 packets. However, the fragments pertaining to any of the tuples 904 may not arrive in order (i.e., first fragment, followed 905 by subsequent fragments in the increasing offset). Further, due 906 to a problem in some host Operating System IP stacks, the 907 fragments originating from the host may have overlapping payload 908 segments. In order to meet Req-4 in all of these scenarios, NAT 909 devices often fully re-assemble the incoming fragments into a 910 complete IP datagram first and use the assembled datagram to look 911 up the NAT Session table. 913 However, there often are limitations on how long a state can be 914 retained, the size of the largest assembled IP datagram it can 915 support and how many simultaneous states a NAT device can retain 916 at once. Implementers adapting the fragment reassembly approach 917 should refer Section 3.3.2 of RFC 1122 for the various design 918 options they might need to consider. 920 4.2. Port reservation 922 A NAPT device often shares the source ports for its public IP 923 address with nodes in the private realm. In order for the NAT 924 device to do any of its own TCP/UDP session initiations, it MUST 925 ensure that the ports it uses for itself are not shared with 926 private nodes. This may be accomplished either through explicit 927 address/port mapping for NAT use during config time (or) reserve 928 a block of ports explicitly within the device for local use vs. 929 NAT use. 931 Reserving port blocks explicitly for local use vs. NAT use is 932 valuable for several reasons. Consider the following scenario. 934 Say, an application on the NAPT runs on port 5060 (SIP Server), but 935 not enabled. A host in the private domain uses 5060 at this time and 936 say, gets the port 5060 from the NAT device. While this Port Binding 937 is active, say, the application running on NAT is activated. Several 938 things can go wrong now depending on the implementation. 940 1. The application is totally unaware of NAT's existence, (maybe 941 because NAT never does a bind on the ports it is using). So it starts 942 using 5060 and the subsequent packets directed to this server could 943 end up in the end host within the private domain or the packets meant 944 for the application on the end host could end up in the NAT box's 945 TCP/UDP stack. Both are bad and can cause unpredictable behavior. 947 2. The application on the NAT box is aware that someone is using 5060 948 so the Bind fails and the app fails to come up. The administrator 949 would have to clear the NAT session and restart the application. 951 3. The application on the NAT box is intelligent enough to tell NAT 952 to clean up any sessions that it plans to use and NAT cleans up its 953 session(s). The application on the end host is effected as a result. 955 Clearly, there can be unpredictable behavior when ports are not 956 reserved explicitly for local use vs NAT use. 958 4.3. DHCP Configured NATs 960 Many of the residential NAT devices acts as a DHCP client on the 961 external interface and as DHCP server on the internal interface. When 962 doing so, there is a possibility that the IP subnet on the external 963 and internal interfaces could overlap, especially in the case of a 964 Multi-level NAT setup. 966 One way to avoid problems due to private IP address conflicts is by 967 supporting multiple RFC 1918 address ranges for its private network. 968 The NAT's DHCP server might for example hand out IP addresses in the 969 10.0.0.0/24 range to downstream hosts by default as long as its own 970 DHCP-assigned "external" IP address is not in this region, and 971 otherwise hand out addresses in the 172.16.0.0/12 private region. 973 5. Summary of Requirements 975 This section summarizes the requirements specified and discussed at 976 length in the preceding sections. A NAT that supports all of the 977 mandatory requirements of this specification (the "MUST" 978 requirements), is "compliant with this specification." A NAT that 979 supports all of the requirements of this specification including the 980 optional, "RECOMMENDED" requirements, is "fully compliant with all 981 the mandatory and recommended requirements of this specification." 983 REQ-1 A NAT MUST support the traversal of TCP based applications 984 and unicast UDP based applications. 986 REQ-2 A NAT device MUST support Address and/or Port Bindings. 987 Specifically, Symmetric NAT type behavior MUST be deprecated. 989 REQ-3: A NAT device MUST be able to process (i.e., receive, 990 translate, and forward) all fragments of an IP datagram, 991 whether they arrive in order or out of order. A NAT device 992 MUST process IP fragments that assemble to a maximum of 8300 993 byte IP datagrams. 995 REQ-4 When fragmenting packets on the outbound, a NAT device SHOULD 996 ensure that the tuples of (SrcIP, DestIP, fragment Id, 997 Protocol) are unique across all outgoing packets. This 998 requirement pertains specifically to NAPT devices. 1000 REQ-5 All NATs MUST support hairpin NAT translation. 1002 REQ-6 A NAT device whose external IP interface can be configured 1003 via DHCP MUST operate correctly even if its external 1004 interface's IP address and subnet configuration numerically 1005 conflicts with the IP address and subnet configuration of 1006 the NAT's internal interface(s). 1008 REQ-7: If DF bit is set on an inbound IP packet and the NAT device 1009 cannot forward the packet without fragmentation, the NAT 1010 device MUST send a destination unreachable ICMP message 1011 (ICMP type 3, Code 4) with a suggested MTU back to the 1012 sender prior to dropping the IP packet. 1014 REQ-8: A NAT device MUST transparently forward the ICMP error 1015 messages it receives from the intermediate or end nodes in 1016 either realm to the intended endnode. The NAT device MUST 1017 use the packet embedded within the ICMP error message payload 1018 as the basis to translate not only the embedded payload, but 1019 also the IP and ICMP headers in the outer layer. In the case 1020 the ICMP error packet is generated by an intermediate node for 1021 which the NAT has no Binding translation, the NAT device MUST 1022 use its own IP address in the realm of the recipient node to 1023 translate the intermediate node IP address. 1025 REQ-9 When an inbound packet is prohibited by a NAT device due to 1026 resource/authorization considerations, the NAT device SHOULD 1027 send ICMP destination unreachable message, with a code of 10 1028 (Communication with destination host administratively 1029 prohibited) to the sender prior to dropping the packet. 1031 REQ-10 A NAT device SHOULD support ALGs for FTP and DNS, so as to 1032 enable traversal of these applications across NAT. In 1033 addition, NAT devices SHOULD explicitly identify the ALGs 1034 supported, and make ALG support configurable (enable/disable). 1036 REQ-11 A NAT device SHOULD protect itself against Denial of Service 1037 attacks arising out of fragment processing and generating ICMP 1038 error responses to unauthorized packets. 1040 6. Security Considerations 1042 None yet. 1044 Normative References 1046 [ARP] David C. Plummer, "An Ethernet Address Resolution Protocol", 1047 RFC 826, November 1982. 1049 [KEYWORDS] S. Bradner, "Key words for use in RFCs to Indicate 1050 Requirement Levels", RFC 2119, March 1997. 1052 [NAT-APPL] D. Senie, "Network Address Translator (NAT)-Friendly 1053 Application Design Guidelines", RFC 3235, January 2002. 1055 [NAT-MIB] R. Rohit, P. Srisuresh, R. Raghunarayan, N. Pai, and C. 1056 Wang, "Definitions of Managed Objects for Network Address 1057 Translators (NAT)", RFC 4008, February 2005. 1059 [NAT-PROT] M. Holdrege and P. Srisuresh, "Protocol Complications with 1060 the IP Network Address Translator", RFC 3027, January 2001. 1062 [NAT-PT] G. Tsirtsis and P. Srisuresh, "Network Address Translation - 1063 Protocol Translation (NAT-PT)", RFC 2766, February 2000. 1065 [NAT-TERM] P. Srisuresh and M. Holdrege, "IP Network Address Translator 1066 (NAT) Terminology and Considerations", RFC 2663, August 1067 1999. 1069 [NAT-TRAD] P. Srisuresh and K. Egevang, "Traditional IP Network Address 1070 Translator (Traditional NAT)", RFC 3022, January 2001. 1072 [PRIV-ADDR] Y. Rekhter, B. Moskowitz, D. Karrenberg, G. J. de Groot, and 1073 E. Lear, "Address Allocation for Private Internets", RFC 1074 1918, February 1996. 1076 [RFC 1122] Braden, R., "Requirements for Internet Hosts -- 1077 Communication Layers", STD 3, RFC 1122, October 1989. 1079 [RFC 1123] Braden, R., "Requirements for Internet Hosts -- Application 1080 and Support", STD 3, RFC 1123, October 1989. 1082 [RFC 1812] Baker, F., "Requirements for IP Version 4 Routers", RFC 1083 1812, June 1995. 1085 [FTP] Postel, J. and J. Reynolds, "FILE TRANSFER PROTOCOL (FTP)", 1086 STD 9, RFC 959, October 1985. 1088 [ICMP] Postel, J., "INTERNET CONTROL MESSAGE (ICMP) 1089 SPECIFICATION", STD 5, RFC 792, September 1981. 1091 [DNS-ALG] Srisuresh, P., Tsirtsis, G., Akkiraju, P. and A. Heffernan, 1092 "DNS extensions to Network Address Translators (DNS_ALG)", 1093 RFC 2694, September 1999. 1095 [FTP-EXT] Allman, M., Ostermann, S. and C. Metz, "FTP Extensions for 1096 IPv6 and NATs", RFC 2428, September 1998. 1098 Informative References 1100 [BEH-APP] B. Ford, P. Srisuresh, and D. Kegel, "Application Design 1101 Guidelines for Traversal of Network Address Translators", 1102 Internet-Draft (Work In Progress), February 2005. 1104 [BEH-IGMP] D. Wing, "IGMP Proxy Behavior", Internet-Draft (Work In 1105 Progress), October 2004. 1107 [BEH-STATE] P. Srisuresh, B. Ford, and D. Kegel, "State of Peer-to-Peer 1108 (P2P) communication across Network Address Translators 1109 (NATs)", Internet-Draft (Work In Progress), December 2004. 1111 [BEH-TCP] P. Srisuresh, S. Sivakumar, K. Biswas, and, B. Ford, "NAT 1112 Behavioral Requirements for TCP", Internet-Draft (Work In 1113 Progress), January 2005. 1115 [BEH-TOP] B. Ford and P. Srisuresh, "Topological Complications from 1116 Network Address Translation (NAT-TOP)", Internet-Draft (Work 1117 In Progress), February 2005. 1119 [BEH-UDP] F. Audet and C. Jennings, "NAT Behavioral Requirements for 1120 Unicast UDP", Internet-Draft (Work In Progress), January 1121 2005. 1123 [MIDCOM] P. Srisuresh, J. Kuthan, J. Rosenberg, A. Molitor, and A. 1124 Rayhan, "Middlebox communication architecture and 1125 framework", RFC 3303, August 2002. 1127 [H.323] "Packet-based Multimedia Communications Systems", ITU-T 1128 Recommendation H.323, July 2003. 1130 [RSIP] M. Borella, J. Lo, D. Grabelsky, and G. Montenegro, "Realm 1131 Specific IP: Framework", RFC 3102, October 2001. 1133 [SIP] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. 1134 Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP: 1135 Session Initiation Protocol", RFC 3261, June 2002. 1137 [SOCKS] M. Leech, M. Ganis, Y. Lee, R. Kuris, D. Koblas, and L. 1138 Jones, "SOCKS Protocol Version 5", RFC 1928, March 1996. 1140 [STUN] J. Rosenberg, J. Weinberger, C. Huitema, and R. Mahy, "STUN 1141 - Simple Traversal of User Datagram Protocol (UDP) Through 1142 Network Address Translators (NATs)", RFC 3489, March 2003. 1144 [TURN] J. Rosenberg, J. Weinberger, R. Mahy, and C. Huitema, 1145 "Traversal Using Relay NAT (TURN)", Internet-Draft (Work In 1146 Progress), March 2003. 1148 [UNSAF] L. Daigle and IAB, "IAB Considerations for UNilateral Self- 1149 Address Fixing (UNSAF) Across Network Address Translation", 1150 RFC 3424, November 2002. 1152 [UPNP] UPnP Forum, "Internet Gateway Device (IGD) Standardized 1153 Device Control Protocol V 1.0", November 2001. 1154 http://www.upnp.org/standardizeddcps/igd.asp 1156 Authors' Addresses: 1158 Bryan Ford 1159 Computer Science and Artificial Intelligence Laboratory 1160 Massachusetts Institute of Technology 1161 77 Massachusetts Ave. 1162 Cambridge, MA 02139 1163 U.S.A. 1164 Phone: (617) 253-5261 1165 E-mail: baford@mit.edu 1166 Web: http://www.brynosaurus.com/ 1168 Pyda Srisuresh 1169 Caymas Systems, Inc. 1170 1179-A North McDowell Blvd. 1171 Petaluma, CA 94954 1172 U.S.A. 1173 Phone: (707)283-5063 1174 E-mail: srisuresh@yahoo.com 1176 Senthil Sivakumar 1177 Cisco Systems, Inc. 1178 170 West Tasman Dr. 1179 San Jose, CA 95134 1180 U.S.A. 1181 Phone: 1182 Email: ssenthil@cisco.com 1184 Copyright Statement 1186 Copyright (C) The Internet Society (2005). This document is subject 1187 to the rights, licenses and restrictions contained in BCP 78, and 1188 except as set forth therein, the authors retain all their rights. 1190 This document and the information contained herein are provided on an 1191 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1192 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1193 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1194 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1195 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1196 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.