idnits 2.17.1 draft-ietf-nat-traditional-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? 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.) ** The document seems to lack an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 5 instances of lines with control characters in the document. == There are 13 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 6 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. == The 'Obsoletes: ' line in the draft header should list only the _numbers_ of the RFCs which will be obsoleted by this document (if approved); it should not include the word 'RFC' in the list. -- The draft header indicates that this document obsoletes RFC1631, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 65 has weird spacing: '...cept as noted...' == Line 350 has weird spacing: '... issues are...' == Line 372 has weird spacing: '...ts must also...' -- 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 (April 9, 2000) is 8754 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: 'REF1' on line 639 == Missing Reference: '0' is mentioned on line 413, but not defined == Unused Reference: '2' is defined on line 647, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 650, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 652, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 655, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 658, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 660, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 663, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 665, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 668, but no explicit reference was found in the text == Unused Reference: '11' is defined on line 670, but no explicit reference was found in the text == Unused Reference: '12' is defined on line 673, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1700 (ref. '3') (Obsoleted by RFC 3232) ** Obsolete normative reference: RFC 793 (ref. '8') (Obsoleted by RFC 9293) Summary: 8 errors (**), 0 flaws (~~), 18 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 NAT Working Group P. Srisuresh 2 INTERNET-DRAFT Campio Communications 3 Obsoletes: RFC 1631 K. Egevang 4 Category: Informational Intel Corporation 5 Expires as of October 9, 2000 April 9, 2000 7 Traditional IP Network Address Translator (Traditional NAT) 8 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 months and may be updated, replaced, or obsoleted by other documents 22 at any time. It is inappropriate to use Internet- Drafts as 23 reference material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Preface 33 The NAT operation described in this document extends address 34 translation introduced in RFC 1631 and includes a new type 35 of network address and TCP/UDP port translation. In addition, 36 this document corrects the Checksum adjustment algorithm 37 published in RFC 1631 and attempts to discuss NAT operation 38 and limitations in detail. 40 Abstract 42 Basic Network Address Translation or Basic NAT is a method by which 43 IP addresses are mapped from one group to another, transparent to 44 end users. Network Address Port Translation, or NAPT is a method by 45 which many network addresses and their TCP/UDP ports are translated 46 into a single network address and its TCP/UDP ports. Together, 47 these two operations, referred to as traditional NAT, provide a 48 mechanism to connect a realm with private addresses to an 49 external realm with globally unique registered addresses. 51 1. Introduction 53 The need for IP Address translation arises when a network's internal 54 IP addresses cannot be used outside the network either for privacy 55 reasons or because they are invalid for use outside the network. 57 Network topology outside a local domain can change in many ways. 58 Customers may change providers, company backbones may be 59 reorganized, or providers may merge or split. Whenever external 60 topology changes with time, address assignment for nodes within the 61 local domain must also change to reflect the external changes. 62 Changes of this type can be hidden from users within the domain 63 by centralizing changes to a single address translation router. 65 Basic Address translation would (in many cases, except as noted in 66 RFC 2663 and section 6 of this document) allow hosts in a private 67 network to transparently access the external network and enable 68 access to selective local hosts from the outside. Organizations with 69 a network setup predominantly for internal use, with a need for 70 occasional external access are good candidates for this scheme. 72 Many Small Office, Home Office (SOHO) users and telecommuting 73 employees have multiple Network nodes in their office, running 74 TCP/UDP applications, but have a single IP address assigned to 75 their remote access router by their service provider to access 76 remote networks. This ever increasing community of remote access 77 users would be benefited by NAPT, which would permit multiple 78 nodes in a local network to simultaneously access remote networks 79 using the single IP address assigned to their router. 81 There are limitations to using the translation method. It is 82 mandatory that all requests and responses pertaining to a session 83 be routed via the same NAT router. One way to ascertain this would 84 be to have NAT based on a border router that is unique to a stub 85 domain, where all IP packets are either originated from the domain 86 or destined to the domain. There are other ways to ensure this 87 with multiple NAT devices. For example, a private domain could have 88 two distinct exit points to different providers and the session flow 89 from the hosts in a private network could traverse through whichever 90 NAT device has the best metric for an external host. 92 Address translation is application independent and often accompanied 93 by application specific gateways (ALGs) to perform payload 94 monitoring and alterations. FTP is the most popular ALG resident on 95 NAT devices. Applications requiring ALG intervention must not have 96 their payload encoded, as doing that would effectively disables the 97 ALG, unless the ALG has the key to decrypt the the payload. 99 This solution has the disadvantage of taking away the end-to-end 100 significance of an IP address, and making up for it with increased 101 state in the network. As a result, end-to-end IP network level 102 security assured by IPSec cannot be assumed to end hosts, with a 103 NAT device enroute. The advantage of this approach however is that 104 it can be installed without changes to hosts or routers. 106 The definition of terms used in this document may be found in "IP 107 Network Address Translator Terminology and Considerations" [REF1]. 109 2. Overview of traditional NAT 111 The Address Translation operation presented in this document is 112 referred to as "Traditional NAT". There are other variations of 113 NAT that will not be explored in this document. Traditional NAT 114 would allow hosts within a private network to transparently 115 access hosts in the external network, in most cases. In a 116 traditional NAT, sessions are uni-directional, outbound from the 117 private network. Sessions in the opposite direction may be allowed 118 on an exceptional basis using static address maps for pre-selected 119 hosts. Basic NAT and NAPT are two variations of traditional NAT, 120 in that translation is Basic NAT is limited to IP addresses alone, 121 whereas translation in NAPT is extended to include IP address and 122 Transport identifier (such as TCP/UDP port or ICMP query ID). 124 Unless mentioned otherwise, Address Translation or NAT throughout 125 this document will pertain to traditional NAT, namely Basic NAT 126 as well as NAPT. Only the stub border routers as described in 127 figure 1 below may be configured to perform address translation. 129 \ | / . / 130 +---------------+ WAN . +-----------------+/ 131 |Regional Router|----------------------|Stub Router w/NAT|--- 132 +---------------+ . +-----------------+\ 133 . | \ 134 . | LAN 135 . --------------- 136 Stub border 138 Figure 1: Traditional NAT Configuration 140 2.1 Overview of Basic NAT 142 Basic NAT operation is as follows. A stub domain with a set of 143 private network addresses could be enabled to communicate with 144 external network by dynamically mapping to a set of globally valid 145 network addresses. If the number of local nodes are less than or 146 equal to addresses in the global set, each local address is 147 guaranteed a global address to map to. Otherwise, nodes allowed to 148 have simultaneous access to external network are limited by the 149 number of addresses in global set. Individual local addresses may 150 be statically mapped to specific global addresses to ensure 151 guaranteed access to the outside or to allow access to the local 152 host from external hosts. Multiple simultaneous sessions may be 153 initiated from a local node, using the same address mapping. 155 Addresses inside a stub domain are local to that domain and not 156 valid outside the domain. Thus, addresses inside a stub domain 157 can be reused by any other stub domain. For instance, a single 158 Class A address could be used by many stub domains. At each exit 159 point between a stub domain and backbone, NAT is installed. If 160 there is more than one exit point it is of great importance that 161 each NAT has the same translation table. 163 \ | / 164 +---------------+ 165 |Regional Router| 166 +---------------+ 167 WAN | | WAN 168 | | 169 Stub A .............|.... ....|............ Stub B 170 | | 171 {s=198.76.29.7,^ | | v{s=198.76.29.7, 172 d=198.76.28.4}^ | | v d=198.76.28.4} 173 +-----------------+ +-----------------+ 174 |Stub Router w/NAT| |Stub Router w/NAT| 175 +-----------------+ +-----------------+ 176 | | 177 | LAN LAN | 178 ------------- ------------- 179 | | 180 {s=10.33.96.5, ^ | | v{s=198.76.29.7, 181 d=198.76.28.4}^ +--+ +--+ v d=10.81.13.22} 182 |--| |--| 183 /____\ /____\ 184 10.33.96.5 10.81.13.22 186 Figure 2: Basic NAT Operation 188 For instance, in the example of figure 2, both stubs A and B 189 internally use class A address 10.0.0.0. Stub A's NAT is 190 assigned the class C address 198.76.29.0, and Stub B's NAT is 191 assigned the class C address 198.76.28.0. The class C addresses 192 are globally unique no other NAT boxes can use them. 194 When stub A host 10.33.96.5 wishes to send a packet to stub B host 195 10.81.13.22, it uses the globally unique address 198.76.28.4 as 196 destination, and sends the packet to it's primary router. The stub 197 router has a static route for net 198.76.0.0 so the packet is 198 forwarded to the WAN-link. However, NAT translates the source 199 address 10.33.96.5 of the IP header to the globally unique 200 198.76.29.7 before the packet is forwarded. Likewise, IP packets 201 on the return path go through similar address translations. 203 Notice that this requires no changes to hosts or routers. For 204 instance, as far as the stub A host is concerned, 198.76.28.4 is 205 the address used by the host in stub B. The address translations 206 are transparent to end hosts. Of course, this is just a simple 207 example. There are numerous issues to be explored. 209 2.2. Overview of NAPT 211 Say, an organization has a private IP network and a WAN link to a 212 service provider. The private network's stub router is assigned 213 a globally valid address on the WAN link and the remaining nodes 214 in the organization have IP addresses that have only local 215 significance. In such a case, nodes on the private network could 216 be allowed simultaneous access to external network, using the 217 single registered IP address with the aid of NAPT. NAPT would 218 allow mapping of tuples of the type (local IP addresses, local 219 TU port number) to tuples of the type (registered IP address, 220 assigned TU port number). 222 This model fits the requirements of most Small Office Home Office 223 (SOHO) groups to access external network using a single service 224 provider assigned IP address. This model could be extended to 225 allow inbound access by statically mapping a local node per each 226 service TU port of the registered IP address. 228 In the example of figure 3 below, stub A internally uses class A 229 address 10.0.0.0. The stub router's WAN interface is assigned an 230 IP address 138.76.28.4 by the service provider. 232 \ | / 233 +-----------------------+ 234 |Service Provider Router| 235 +-----------------------+ 236 WAN | 237 | 238 Stub A .............|.... 239 | 240 ^{s=138.76.28.4,sport=1024, | v{s=138.76.29.7, sport = 23, 241 ^ d=138.76.29.7,dport=23} | v d=138.76.28.4, dport = 1024} 242 +------------------+ 243 |Stub Router w/NAPT| 244 +------------------+ 245 | 246 | LAN 247 -------------------------------------------- 248 | ^{s=10.0.0.10,sport=3017, | v{s=138.76.29.7, sport=23, 249 | ^ d=138.76.29.7,dport=23} | v d=10.0.0.10, dport=3017} 250 | | 251 +--+ +--+ +--+ 252 |--| |--| |--| 253 /____\ /____\ /____\ 254 10.0.0.1 10.0.0.2 ..... 10.0.0.10 256 Figure 3: Network Address Port Translation (NAPT) Operation 258 When stub A host 10.0.0.10 sends a telnet packet to host 259 138.76.29.7, it uses the globally unique address 138.76.29.7 as 260 destination, and sends the packet to it's primary router. The 261 stub router has a static route for net 138.76.0.0 so the packet 262 is forwarded to the WAN-link. However, NAPT translates the tuple 263 of source address 10.0.0.10 and source TCP port 3017 in the IP 264 and TCP headers into the globally unique 138.76.28.4 and a 265 uniquely assigned TCP port, say 1024, before the packet is 266 forwarded. Packets on the return path go through similar address 267 and TCP port translations for the target IP address and target 268 TCP port. Once again, notice that this requires no changes to 269 hosts or routers. The translation is completely transparent. 271 In this setup, only TCP/UDP sessions are allowed and must originate 272 from the local network. However, there are services such as DNS 273 that demand inbound access. There may be other services for which 274 an organization wishes to allow inbound session access. It is 275 possible to statically configure a TU port service on the stub 276 router to be directed to a specific node in the private network. 278 In addition to TCP/UDP sessions, ICMP messages, with the exception 279 of REDIRECT message type may also be monitored by NAPT router. 280 ICMP query type packets are translated similar to that of TCP/UDP 281 packets, in that the identifier field in ICMP message header will 282 be uniquely mapped to a query identifier of the registered IP 283 address. The identifier field in ICMP query messages is set by 284 Query sender and returned unchanged in response message from the 285 Query responder. So, the tuple of (Local IP address, local ICMP 286 query identifier) is mapped to a tuple of (registered IP address, 287 assigned ICMP query Identifier) by the NAPT router to uniquely 288 identify ICMP queries of all types from any of the local hosts. 289 Modifications to ICMP error messages are discussed in a later 290 section, as that involves modifications to ICMP payload as well 291 as the IP and ICMP headers. 293 In NAPT setup, where the registered IP address is the same as the IP 294 address of the stub router WAN interface, the router has to be sure 295 to make distinction between TCP, UDP or ICMP query sessions 296 originated from itself versus those originated from the nodes on 297 local network. All inbound sessions (including TCP, UDP and ICMP 298 query sessions) are assumed to be directed to the NAT router as 299 the end node, unless the target service port is statically mapped to 300 a different node in the local network. 302 Sessions other than TCP, UDP and ICMP query type are simply not 303 permitted from local nodes, serviced by a NAPT router. 305 3.0. Translation phases of a session. 307 The translation phases with traditional NAT are same as described in 308 [REF1]. The following sub-sections identify items that are specific 309 to traditional NAT. 311 3.1. Address binding: 313 With Basic NAT, a private address is bound to an external address, 314 when the first outgoing session is initiated from the private host. 315 Subsequent to that, all other outgoing sessions originating 316 from the same private address will use the same address binding for 317 packet translation. 319 In the case of NAPT, where many private addresses are mapped to a 320 single globally unique address, the binding would be from the 321 tuple of (private address, private TU port) to the tuple of 322 (assigned address, assigned TU port). As with Basic NAT, this 323 binding is determined when the first outgoing session is initiated 324 by the tuple of (private address, private TU port) on the private 325 host. While not a common practice, it is possible to have an 326 application on private host establish multiple simultaneous 327 sessions originating from the same tuple of (private address, 328 private TU port). In such a case, a single binding for the tuple 329 of (private address, private TU port) may be used for translation 330 of packets pertaining to all sessions originating from the same 331 tuple on a host. 333 3.2. Address lookup and translation: 335 After an address binding or (address, TU port) tuple binding in 336 case of NAPT is established, a soft state may be maintained for 337 each of the connections using the binding. Packets belonging to 338 the same session will be subject to session lookup for translation 339 purposes. The exact nature of translation is discussed in the 340 follow-on section. 342 3.3. Address unbinding: 344 When the last session based on an address or (address, TU port) 345 tuple binding is terminated, the binding itself may be terminated. 347 4.0. Packet Translations 349 Packets pertaining to NAT managed sessions undergo translation 350 in either direction. Individual packet translation issues are 351 covered in detail in the following sub-sections. 353 4.1. IP, TCP, UDP and ICMP Header Manipulations 355 In Basic NAT model, the IP header of every packet must be 356 modified. This modification includes IP address (source IP 357 address for outbound packets and destination IP address for 358 inbound packets) and the IP checksum. 360 For TCP/UDP sessions, modifications must include update of 361 checksum in the TCP/UDP headers. This is because TCP/UDP 362 checksum also covers a pseudo header which contains the source 363 and destination IP addresses. As an exception, UDP headers 364 with 0 checksum should not be modified. As for ICMP Query 365 packets, no further changes in ICMP header are required as 366 the checksum in ICMP header does not cover IP addresses. 368 In NAPT model, modifications to IP header are similar to that of 369 Basic NAT. For TCP/UDP sessions, modifications must be extended 370 to include translation of TU port (source TU port for outbound 371 packets and destination TU port for inbound packets) in the 372 TCP/UDP header. ICMP header in ICMP Query packets must also 373 be modified to replace the query ID and ICMP header checksum. 374 Private host query ID must be translated into assigned ID on 375 the outbound and the exact reverse on the inbound. ICMP header 376 checksum must be corrected to account for Query ID translation. 378 4.2. Checksum Adjustment 380 NAT modifications are per packet based and can be very compute 381 intensive, as they involve one or more checksum modifications 382 in addition to simple field translations. Luckily, we have 383 an algorithm below, which makes checksum adjustment to IP, TCP, 384 UDP and ICMP headers very simple and efficient. Since all these 385 headers use a one's complement sum, it is sufficient to calculate 386 the arithmetic difference between the before-translation and after- 387 translation addresses and add this to the checksum. The algorithm 388 below is applicable only for even offsets (i.e., optr below must 389 be at an even offset from start of header) and even lengths 390 (i.e., olen and nlen below must be even). Sample code (in C) for 391 this is as follows. 393 void checksumadjust(unsigned char *chksum, unsigned char *optr, 394 int olen, unsigned char *nptr, int nlen) 395 /* assuming: unsigned char is 8 bits, long is 32 bits. 396 - chksum points to the chksum in the packet 397 - optr points to the old data in the packet 398 - nptr points to the new data in the packet 399 */ 400 { 401 long x, old, new; 402 x=chksum[0]*256+chksum[1]; 403 x=~x & 0xFFFF; 404 while (olen) 405 { 406 old=optr[0]*256+optr[1]; optr+=2; 407 x-=old & 0xffff; 408 if (x<=0) { x--; x&=0xffff; } 409 olen-=2; 410 } 411 while (nlen) 412 { 413 new=nptr[0]*256+nptr[1]; nptr+=2; 414 x+=new & 0xffff; 415 if (x & 0x10000) { x++; x&=0xffff; } 416 nlen-=2; 417 } 418 x=~x & 0xFFFF; 419 chksum[0]=x/256; chksum[1]=x & 0xff; 420 } 422 4.3. ICMP error packet modifications 424 Changes to ICMP error message will include changes to IP and 425 ICMP headers on the outer layer as well as changes to headers 426 of the packet embedded within the ICMP-error message payload. 428 In order for NAT to be transparent to end-host, the IP address 429 of the IP header embedded within the payload of ICMP-Error 430 message must be modified, the checksum field of the embedded 431 IP header must be modified, and lastly, the ICMP header 432 checksum must also be modified to reflect changes to payload. 434 In a NAPT setup, if the IP message embedded within ICMP happens 435 to be a TCP, UDP or ICMP Query packet, you will also need to 436 modify the appropriate TU port number within the TCP/UDP header 437 or the Query Identifier field in the ICMP Query header. 439 Lastly, the IP header of the ICMP packet must also be modified. 441 4.4. FTP support 443 As noted in [REF1], one of the most popular applications, 444 "FTP" would require an ALG to monitor the control session 445 payload to determine the ensuing data session parameters. 446 FTP ALG is an integral part of most NAT implementations. 448 The FTP ALG would require a special table to correct the TCP 449 sequence and acknowledge numbers with source port FTP or 450 destination port FTP. The table entries should have source 451 address, destination address, source port, destination 452 port, delta for sequence numbers and a timestamp. New entries are 453 created only when FTP PORT commands or PASV responses are seen. The 454 sequence number delta may be increased or decreased for every FTP 455 PORT command or PASV response. Sequence numbers are incremented 456 on the outbound and acknowledge numbers are decremented on the 457 inbound by this delta. 459 FTP payload translations are limited to private addresses and 460 their assigned external addresses (encoded as individual octets 461 in ASCII) for Basic NAT. For NAPT setup, however, the translations 462 must be extended to include the TCP port octets (in ASCII) 463 following the address octets. 465 4.5 DNS support 467 Considering that sessions in a traditional NAT are predominantly 468 outbound from a private domain, DNS ALG may be obviated from use in 469 conjunction with traditional NAT as follows. DNS server(s) internal 470 to the private domain maintain mapping of names to IP addresses for 471 internal hosts and possibly some external hosts. External DNS 472 servers maintain name mapping for external hosts alone and not for 473 any of the internal hosts. If the private network does not have an 474 internal DNS server, all DNS requests may be directed to external 475 DNS server to find address mapping for the external hosts. 477 4.6. IP option handling 479 An IP datagram with any of the IP options Record Route, Strict 480 Source Route or Loose Source Route would involve recording or 481 using IP addresses of intermediate routers. A NAT intermediate 482 router may choose not to support these options or leave 483 the addresses untranslated while processing the options. The 484 result of leaving the addresses untranslated would be that 485 private addresses along the source route are exposed end to 486 end. This should not jeopardize the traversal path of the 487 packet, per se, as each router is supposed to look at the 488 next hop router only. 490 5. Miscellaneous issues 492 5.1. Partitioning of Local and Global Addresses 494 For NAT to operate as described in this draft, it is necessary 495 to partition the IP address space into two parts - the private 496 addresses used internal to stub domain, and the globally 497 unique addresses. Any given address must either be a private 498 address or a global address. There is no overlap. 500 The problem with overlap is the following. Say a host in stub A 501 wished to send packets to a host in stub B, but the global 502 addresses of stub B overlapped the private addressees of stub A. 503 In this case, the routers in stub A would not be able to 504 distinguish the global address of stub B from its own private 505 addresses. 507 5.2. Private address space recommendation 509 The RFC listed in ref[1] has recommendations on address space 510 allocation for private networks. Internet Assigned Numbers 511 Authority (IANA) has three blocks of IP address space, namely 512 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16 for private 513 internets. In pre-CIDR notation, the first block is nothing but 514 a single class A network number, while the second block is a set 515 of 16 contiguous class B networks, and the third block is a set of 516 256 contiguous class C networks. 518 An organization that decides to use IP addresses in the address 519 space defined above can do so without any coordination with IANA 520 or an Internet registry. The address space can thus be used 521 privately by many independent organizations at the same time, 522 with NAT operation enabled on their border routers. 524 5.3. Routing Across NAT 526 The router running NAT should not advertise the private networks to 527 the backbone. Only the networks with global addresses may be known 528 outside the stub. However, global information that NAT receives from 529 the stub border router can be advertised in the stub the usual way. 531 Typically, the NAT stub router will have a static route configured 532 to forward all external traffic to service provider router over WAN 533 link, and the service provider router will have a static route 534 configured to forward NAT packets (i.e., those whose destination 535 IP address fall within the range of NAT managed global address list) 536 to NAT router over WAN link. 538 5.4. Switch-over from Basic NAT to NAPT 540 In Basic NAT setup, when private network nodes outnumber global 541 addresses available for mapping (say, a class B private network 542 mapped to a class C global address block), external network 543 access to some of the local nodes is abruptly cut off after the 544 last global address from the address list is used up. This is 545 very inconvenient and constraining. Such an incident can be 546 safely avoided by optionally allowing the Basic NAT router to 547 switch over to NAPT setup for the last global address in the 548 address list. Doing this will ensure that hosts on private 549 network will have continued, uninterrupted access to the 550 external nodes and services for most applications. Note, 551 however, it could be confusing if some of the applications that 552 used to work with Basic NAT suddenly break due to the 553 switch-over to NAPT. 555 6.0. NAT limitations 557 [REF1] covers the limitations of all flavors of NAT, broadly 558 speaking. The following sub-sections identify limitations 559 specific to traditional NAT. 561 6.1. Privacy and Security 563 Traditional NAT can be viewed as providing a privacy mechanism 564 as sessions are uni-directional from private hosts and 565 the actual addresses of the private hosts are not visible to 566 external hosts. 568 The same characteristic that enhances privacy potentially makes 569 debugging problems (including security violations) more difficult. 570 If a host in private network is abusing the Internet in some way 571 (such as trying to attack another machine or even sending large 572 amounts of spam) it is more difficult to track the actual source 573 of trouble because the IP address of the host is hidden in a 574 NAT router. 576 6.2. ARP responses to NAT mapped global addresses on a LAN interface 578 NAT must be enabled only on border routers of a stub domain. The 579 examples provided in the document to illustrate Basic NAT and 580 NAPT have maintained a WAN link for connection to external router 581 (i.e., service provider router) from NAT router. However, if the 582 WAN link were to be replaced by a LAN connection and if part or 583 all of the global address space used for NAT mapping belongs to 584 the same IP subnet as the LAN segment, the NAT router would be 585 expected to provide ARP support for the address range that belongs 586 to the same subnet. Responding to ARP requests for the NAT 587 mapped global addresses with its own MAC address is a must in 588 such a situation with Basic NAT setup. If the NAT router did 589 not respond to these requests, there is no other node in the 590 network that has ownership to these addresses and hence will 591 go unresponded. 593 This scenario is unlikely with NAPT setup except when the single 594 address used in NAPT mapping is not the interface address of the 595 NAT router (as in the case of a switch-over from Basic NAT to NAPT 596 explained in 5.4 above, for example). 598 Using an address range from a directly connected subnet for NAT 599 address mapping would obviate static route configuration on the 600 service provider router. 602 It is the opinion of the authors that a LAN link to a service 603 provider router is not very common. However, vendors may be 604 interested to optionally support proxy ARP just in case. 606 6.3. Translation of outbound TCP/UDP fragmented packets in NAPT setup 608 Translation of outbound TCP/UDP fragments (i.e., those originating 609 from private hosts) in NAPT setup are doomed to fail. The reason is 610 as follows. Only the first fragment contains the TCP/UDP header that 611 would be necessary to associate the packet to a session for 612 translation purposes. Subsequent fragments do not contain TCP/UDP 613 port information, but simply carry the same fragmentation identifier 614 specified in the first fragment. Say, two private hosts originated 615 fragmented TCP/UDP packets to the same destination host. And, they 616 happened to use the same fragmentation identifier. When the 617 target host receives the two unrelated datagrams, carrying same 618 fragmentation id, and from the same assigned host address, it 619 is unable to determine which of the two sessions the datagrams 620 belong to. Consequently, both sessions will be corrupted. 622 7.0. Current Implementations 624 Many commercial implementations are available in the industry that 625 adhere to the NAT description provided in this document. Linux 626 public domain software contains NAT under the name of "IP 627 masquerade". FreeBSD public domain software has NAPT implementation 628 running as a daemon. Note however that Linux source is covered 629 under the GNU license and FreeBSD software is covered under the 630 UC Berkeley license. 632 Both Linux and FreeBSD software are free, so you can buy CD-ROMs 633 for these for little more than the cost of distribution. They are 634 also available on-line from a lot of FTP sites with the latest 635 patches. 637 8.0. Security Considerations 639 The security considerations described in [REF1] for all variations 640 of NATs are applicable to traditional NAT. 642 REFERENCES 644 [1] P. Srisuresh, M. Holdrege, "IP Network Address Translator (NAT) 645 Terminology and Considerations", RFC 2663 647 [2] Rekhter, Y., Moskowitz, B., Karrenberg, D., G. de Groot, and, 648 Lear, E. "Address Allocation for Private Internets", RFC 1918 650 [3] J. Reynolds and J. Postel, "Assigned Numbers", RFC 1700 652 [4] R. Braden, "Requirements for Internet Hosts -- Communication 653 Layers", RFC 1122 655 [5] R. Braden, "Requirements for Internet Hosts -- Application 656 and Support", RFC 1123 658 [6] F. Baker, "Requirements for IP Version 4 Routers", RFC 1812 660 [7] J. Postel, J. Reynolds, "FILE TRANSFER PROTOCOL (FTP)", 661 RFC 959 663 [8] "TRANSMISSION CONTROL PROTOCOL (TCP) SPECIFICATION", RFC 793 665 [9] J. Postel, "INTERNET CONTROL MESSAGE (ICMP) SPECIFICATION", 666 RFC 792 668 [10] J. Postel, "User Datagram Protocol (UDP)", RFC 768 670 [11] J. Mogul, J. Postel, "Internet Standard Subnetting Procedure", 671 RFC 950 673 [12] Brian carpenter, Jon Crowcroft, Yakov Rekhter, "IPv4 Address 674 Behaviour Today", RFC 2101 675 Authors' Addresses 677 Pyda Srisuresh 678 Campio Communications 679 630 Alder Drive 680 Milpitas, CA 95035 681 U.S.A. 683 Voice: (408) 519-3849 684 EMail: srisuresh@yahoo.com 686 Kjeld Borch Egevang 687 Intel Denmark ApS 689 Voice: +45 44886556 690 Fax: +45 44886051 691 EMail: kjeld.egevang@intel.com 692 http: //www.freeyellow.com/members/kbe