idnits 2.17.1 draft-ietf-nat-traditional-03.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: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** 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 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 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 (September 1999) is 8962 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 641 == Missing Reference: '0' is mentioned on line 413, but not defined == Unused Reference: '2' is defined on line 649, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 652, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 654, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 657, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 660, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 662, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 665, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 667, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 670, but no explicit reference was found in the text == Unused Reference: '11' is defined on line 672, but no explicit reference was found in the text == Unused Reference: '12' is defined on line 675, 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 (~~), 17 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NAT Working Group P. Srisuresh 3 INTERNET-DRAFT Consultant 4 Obsoletes: RFC 1631 K. Egevang 5 Category: Informational Intel Corporation 6 Expire in six months September 1999 8 Traditional IP Network Address Translator (Traditional NAT) 9 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six 22 months and may be updated, replaced, or obsoleted by other documents 23 at any time. It is inappropriate to use Internet- Drafts as 24 reference material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 Preface 34 The NAT operation described in this document extends address 35 translation introduced in RFC 1631 and includes a new type 36 of network address and TCP/UDP port translation. In addition, 37 this document corrects the Checksum adjustment algorithm 38 published in RFC 1631 and attempts to discuss NAT operation 39 and limitations in detail. 41 Abstract 43 Basic Network Address Translation or Basic NAT is a method by which 44 IP addresses are mapped from one group to another, transparent to 45 end users. Network Address Port Translation, or NAPT is a method by 46 which many network addresses and their TCP/UDP ports are translated 47 into a single network address and its TCP/UDP ports. Together, 48 these two operations, referred to as traditional NAT, provide a 49 mechanism to connect a realm with private addresses to an 50 external routing network with globally unique registered addresses. 52 1. Introduction 54 The need for IP Address translation arises when a network's internal 55 IP addresses cannot be used outside the network either for privacy 56 reasons or because they are invalid for use outside the network. 58 Network topology outside a local domain can change in many ways. 59 Customers may change providers, company backbones may be 60 reorganized, or providers may merge or split. Whenever external 61 topology changes with time, address assignment for nodes within the 62 local domain must also change to reflect the external changes. 63 Changes of this type can be hidden from the users within the domain 64 by centralizing changes to a single address translation router. 66 Basic Address translation would allow hosts in a private network to 67 transparently access the external network and enable access to 68 selective local hosts from the outside. Organizations with a 69 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 a traditional NAT, 116 sessions are uni-directional, outbound from the private network. 117 Sessions in the opposite direction may be allowed on an 118 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 completely transparent. 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 the 426 headers of the packet embedded within the ICMP payload due 427 to error. 429 In order for NAT to be completely transparent to the host, the 430 IP address of the IP header embedded within the payload of the 431 ICMP packet must be modified, the checksum field of the same 432 IP header must correspondingly be modified, and the ICMP header 433 checksum must also be modified to reflect changes made to the 434 payload. 436 In a NAPT setup, if the IP message embedded within ICMP happens 437 to be a TCP, UDP or ICMP Query packet, you will also need to 438 modify the appropriate TU port number within the TCP/UDP header 439 or the Query Identifier field in the ICMP Query header. 441 Lastly, the IP header of the ICMP packet must also be modified. 443 4.4. FTP support 445 As noted in [REF1], one of the most popular applications, 446 "FTP" would require an ALG to monitor the control session 447 payload to determine the ensuing data session parameters. 448 FTP ALG is an integral part of most NAT implementations. 450 The FTP ALG would require a special table to correct the TCP 451 sequence and acknowledge numbers with source port FTP or 452 destination port FTP. The table entries should have source 453 address, destination address, source port, destination 454 port, delta for sequence numbers and a timestamp. New entries are 455 created only when FTP PORT commands or PASV responses are seen. The 456 sequence number delta may be increased or decreased for every FTP 457 PORT command or PASV response. Sequence numbers are incremented 458 on the outbound and acknowledge numbers are decremented on the 459 inbound by this delta. 461 FTP payload translations are limited to private addresses and 462 their assigned external addresses (encoded as individual octets 463 in ASCII) for Basic NAT. For NAPT setup, however, the translations 464 must be extended to include the TCP port octets (in ASCII) 465 following the address octets. 467 4.5 DNS support 469 Considering that sessions in a traditional NAT are predominantly 470 outbound from a private domain, DNS ALG may be obviated from use in 471 conjunction with traditional NAT as follows. DNS server(s) internal 472 to the private domain maintain mapping of names to IP addresses for 473 internal hosts and possibly some external hosts. External DNS 474 servers maintain name mapping for external hosts alone and not for 475 any of the internal hosts. If the private network does not have an 476 internal DNS server, all DNS requests may be directed to external 477 DNS server to find address mapping for the external hosts. 479 4.6. IP option handling 481 An IP datagram with any of the IP options Record Route, Strict 482 Source Route or Loose Source Route would involve recording or 483 using IP addresses of intermediate routers. A NAT intermediate 484 router may choose not to support these options or leave 485 the addresses untranslated while processing the options. The 486 result of leaving the addresses untranslated would be that 487 private addresses along the source route are exposed end to 488 end. This should not jeopardize the traversal path of the 489 packet, per se, as each router is supposed to look at the 490 next hop router only. 492 5. Miscellaneous issues 494 5.1. Partitioning of Local and Global Addresses 496 For NAT to operate as described in this draft, it is necessary 497 to partition the IP address space into two parts - the private 498 addresses used internal to stub domain, and the globally 499 unique addresses. Any given address must either be a private 500 address or a global address. There is no overlap. 502 The problem with overlap is the following. Say a host in stub A 503 wished to send packets to a host in stub B, but the global 504 addresses of stub B overlapped the private addressees of stub A. 505 In this case, the routers in stub A would not be able to 506 distinguish the global address of stub B from its own private 507 addresses. 509 5.2. Private address space recommendation 511 The RFC listed in ref[1] has recommendations on address space 512 allocation for private networks. Internet Assigned Numbers 513 Authority (IANA) has three blocks of IP address space, namely 514 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16 for private 515 internets. In pre-CIDR notation, the first block is nothing but 516 a single class A network number, while the second block is a set 517 of 16 contiguous class B networks, and the third block is a set of 518 256 contiguous class C networks. 520 An organization that decides to use IP addresses in the address 521 space defined above can do so without any coordination with IANA 522 or an Internet registry. The address space can thus be used 523 privately by many independent organizations at the same time, 524 with NAT operation enabled on their border routers. 526 5.3. Routing Across NAT 528 The router running NAT should not advertise the private networks to 529 the backbone. Only the networks with global addresses may be known 530 outside the stub. However, global information that NAT receives from 531 the stub border router can be advertised in the stub the usual way. 533 Typically, the NAT stub router will have a static route configured 534 to forward all external traffic to service provider router over WAN 535 link, and the service provider router will have a static route 536 configured to forward NAT packets (i.e., those whose destination 537 IP address fall within the range of NAT managed global address list) 538 to NAT router over WAN link. 540 5.4. Switch-over from Basic NAT to NAPT 542 In Basic NAT setup, when private network nodes outnumber global 543 addresses available for mapping (say, a class B private network 544 mapped to a class C global address block), external network 545 access to some of the local nodes is abruptly cut off after the 546 last global address from the address list is used up. This is 547 very inconvenient and constraining. Such an incident can be 548 safely avoided by optionally allowing the Basic NAT router to 549 switch over to NAPT setup for the last global address in the 550 address list. Doing this will ensure that hosts on private 551 network will have continued, uninterrupted access to the 552 external nodes and services for most applications. Note, 553 however, it could be confusing if some of the applications that 554 used to work with Basic NAT suddenly break due to the 555 switch-over to NAPT. 557 6.0. NAT limitations 559 [REF1] covers the limitations of all flavors of NAT, broadly 560 speaking. The following sub-sections identify limitations 561 specific to traditional NAT. 563 6.1. Privacy and Security 565 Traditional NAT can be viewed as providing a privacy mechanism 566 as sessions are uni-directional from private hosts and 567 the actual addresses of the private hosts are not visible to 568 external hosts. 570 The same characteristic that enhances privacy potentially makes 571 debugging problems (including security violations) more difficult. 572 If a host in private network is abusing the Internet in some way 573 (such as trying to attack another machine or even sending large 574 amounts of spam) it is more difficult to track the actual source 575 of trouble because the IP address of the host is hidden in a 576 NAT router. 578 6.2. ARP responses to NAT mapped global addresses on a LAN interface 580 NAT must be enabled only on border routers of a stub domain. The 581 examples provided in the document to illustrate Basic NAT and 582 NAPT have maintained a WAN link for connection to external router 583 (i.e., service provider router) from NAT router. However, if the 584 WAN link were to be replaced by a LAN connection and if part or 585 all of the global address space used for NAT mapping belongs to 586 the same IP subnet as the LAN segment, the NAT router would be 587 expected to provide ARP support for the address range that belongs 588 to the same subnet. Responding to ARP requests for the NAT 589 mapped global addresses with its own MAC address is a must in 590 such a situation with Basic NAT setup. If the NAT router did 591 not respond to these requests, there is no other node in the 592 network that has ownership to these addresses and hence will 593 go unresponded. 595 This scenario is unlikely with NAPT setup except when the single 596 address used in NAPT mapping is not the interface address of the 597 NAT router (as in the case of a switch-over from Basic NAT to NAPT 598 explained in 5.4 above, for example). 600 Using an address range from a directly connected subnet for NAT 601 address mapping would obviate static route configuration on the 602 service provider router. 604 It is the opinion of the authors that a LAN link to a service 605 provider router is not very common. However, vendors may be 606 interested to optionally support proxy ARP just in case. 608 6.3. Translation of outbound TCP/UDP fragmented packets in NAPT setup 610 Translation of outbound TCP/UDP fragments (i.e., those originating 611 from private hosts) in NAPT setup are doomed to fail. The reason is 612 as follows. Only the first fragment contains the TCP/UDP header that 613 would be necessary to associate the packet to a session for 614 translation purposes. Subsequent fragments do not contain TCP/UDP 615 port information, but simply carry the same fragmentation identifier 616 specified in the first fragment. Say, two private hosts originated 617 fragmented TCP/UDP packets to the same destination host. And, they 618 happened to use the same fragmentation identifier. When the 619 target host receives the two unrelated datagrams, carrying same 620 fragmentation id, and from the same assigned host address, it 621 is unable to determine which of the two sessions the datagrams 622 belong to. Consequently, both sessions will be corrupted. 624 7.0. Current Implementations 626 Many commercial implementations are available in the industry that 627 adhere to the NAT description provided in this document. Linux 628 public domain software contains NAT under the name of "IP 629 masquerade". FreeBSD public domain software has NAPT implementation 630 running as a daemon. Note however that Linux source is covered 631 under the GNU license and FreeBSD software is covered under the 632 UC Berkeley license. 634 Both Linux and FreeBSD software are free, so you can buy CD-ROMs 635 for these for little more than the cost of distribution. They are 636 also available on-line from a lot of FTP sites with the latest 637 patches. 639 8.0. Security Considerations 641 The security considerations described in [REF1] for all variations 642 of NATs are applicable to traditional NAT. 644 REFERENCES 646 [1] P. Srisuresh, M. Holdrege, "IP Network Address Translator (NAT) 647 Terminology and Considerations", RFC 2663 649 [2] Rekhter, Y., Moskowitz, B., Karrenberg, D., G. de Groot, and, 650 Lear, E. "Address Allocation for Private Internets", RFC 1918 652 [3] J. Reynolds and J. Postel, "Assigned Numbers", RFC 1700 654 [4] R. Braden, "Requirements for Internet Hosts -- Communication 655 Layers", RFC 1122 657 [5] R. Braden, "Requirements for Internet Hosts -- Application 658 and Support", RFC 1123 660 [6] F. Baker, "Requirements for IP Version 4 Routers", RFC 1812 662 [7] J. Postel, J. Reynolds, "FILE TRANSFER PROTOCOL (FTP)", 663 RFC 959 665 [8] "TRANSMISSION CONTROL PROTOCOL (TCP) SPECIFICATION", RFC 793 667 [9] J. Postel, "INTERNET CONTROL MESSAGE (ICMP) SPECIFICATION", 668 RFC 792 670 [10] J. Postel, "User Datagram Protocol (UDP)", RFC 768 672 [11] J. Mogul, J. Postel, "Internet Standard Subnetting Procedure", 673 RFC 950 675 [12] Brian carpenter, Jon Crowcroft, Yakov Rekhter, "IPv4 Address 676 Behaviour Today", RFC 2101 678 Authors' Addresses 680 Pyda Srisuresh 681 Consultant 682 849 Erie Circle 683 Milpitas, CA 95035 684 U.S.A. 686 Voice: (408) 263-7527 687 EMail: srisuresh@yahoo.com 689 Kjeld Borch Egevang 690 Intel Denmark ApS 692 Voice: +45 44886556 693 Fax: +45 44886051 694 EMail: kjeld.egevang@intel.com 695 http: //www.freeyellow.com/members/kbe