idnits 2.17.1 draft-ietf-nat-traditional-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 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 Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. 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 349 has weird spacing: '... issues are...' == Line 371 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 (July 1998) is 9416 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: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: 'REF1' on line 640 == Missing Reference: '0' is mentioned on line 412, 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 -- Possible downref: Non-RFC (?) normative reference: ref. '1' ** Obsolete normative reference: RFC 1700 (ref. '3') (Obsoleted by RFC 3232) ** Obsolete normative reference: RFC 793 (ref. '8') (Obsoleted by RFC 9293) ** Downref: Normative reference to an Informational RFC: RFC 2101 (ref. '12') Summary: 11 errors (**), 0 flaws (~~), 17 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NAT Working Group P. Srisuresh 3 INTERNET-DRAFT Lucent Technologies 4 Obsoletes: RFC 1631 K. Egevang 5 Category: BCP Intel Corporation 6 Expire in six months July 1998 8 Traditional IP Network Address Translator (Traditional NAT) 9 11 Status of this Memo 13 This document is an Internet-Draft. Internet-Drafts are working 14 documents of the Internet Engineering Task Force (IETF), its 15 areas, and its working groups. Note that other groups may also 16 distribute working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six 19 months and may be updated, replaced, or obsoleted by other 20 documents at any time. It is inappropriate to use Internet- 21 Drafts as reference material or to cite them other than as 22 "work in progress." 24 To view the entire list of current Internet-Drafts, please check 25 the "1id-abstracts.txt" listing contained in the Internet-Drafts 26 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net 27 (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au 28 (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu 29 (US West Coast). 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 routing realm with private addresses to the 49 external routing network 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 security 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 the users within the domain 63 by centralizing changes to a single address translation router. 65 Basic Address translation would allow hosts in a private network to 66 transparently access the external network and enable access to 67 selective local hosts from the outside. Organizations with a 68 network setup predominantly for internal use, with a need for 69 occasional external access are good candidates for this scheme. 71 Many Small Office, Home Office (SOHO) users and telecommuting 72 employees have multiple Network nodes in their office, running 73 TCP/UDP applications, but have a single IP address assigned to 74 their remote access router by their service provider to access 75 remote networks. This ever increasing community of remote access 76 users would be benefited by NAPT, which would permit multiple 77 nodes in a local network to simultaneously access remote networks 78 using the single IP address assigned to their router. 80 There are limitations to using the translation method. It is 81 mandatory that all requests and responses pertaining to a session 82 be routed via the same NAT router. One way to ascertain this would 83 be to have NAT based on a border router that is unique to a stub 84 domain, where all IP packets are either originated from the domain 85 or destined to the domain. There are other ways to ensure this 86 with multiple NAT devices. For example, a private domain could have 87 two distinct exit points to different providers and the session flow 88 from the hosts in a private network could traverse through whichever 89 NAT device has the best metric for an external host. 91 Address translation is application independent and often accompanied 92 by application specific gateways (ALGs) to perform payload 93 monitoring and alterations. FTP is the most popular ALG resident on 94 NAT devices. Applications requiring ALG intervention must not have 95 their payload encoded, as doing that would effectively disables the 96 ALG, unless the ALG has the key to decrypt the the payload. 98 This solution has the disadvantage of taking away the end-to-end 99 significance of an IP address, and making up for it with increased 100 state in the network. As a result, end-to-end IP network level 101 security assured by IPSec cannot be assumed to end hosts, with a 102 NAT device enroute. The advantage of this approach however is that 103 it can be installed without changes to hosts or routers. 105 The definition of terms used in this document may be found in "IP 106 Network Address Translator Terminology and Considerations" [REF1]. 108 2. Overview of traditional NAT 110 The Address Translation operation presented in this document is 111 referred to as "Traditional NAT". There are other variations of 112 NAT that will not be explored in this document. Traditional NAT 113 would allow hosts within a private network to transparently 114 access hosts in the external network. In a traditional NAT, 115 sessions are uni-directional, outbound from the private network. 116 Sessions in the opposite direction may be allowed on an 117 exceptional basis using static address maps for pre-selected 118 hosts. Basic NAT and NAPT are two variations of traditional NAT, 119 in that translation is Basic NAT is limited to IP addresses alone, 120 whereas translation in NAPT is extended to include IP address and 121 Transport identifier (such as TCP/UDP port or ICMP query ID). 123 Unless mentioned otherwise, Address Translation or NAT throughout 124 this document will pertain to traditional NAT, namely Basic NAT 125 as well as NAPT. Only the stub border routers as described in 126 figure 1 below may be configured to perform address translation. 128 \ | / . / 129 +---------------+ WAN . +-----------------+/ 130 |Regional Router|----------------------|Stub Router w/NAT|--- 131 +---------------+ . +-----------------+\ 132 . | \ 133 . | LAN 134 . --------------- 135 Stub border 137 Figure 1: Traditional NAT Configuration 139 2.1 Overview of Basic NAT 141 Basic NAT operation is as follows. A stub domain with a set of 142 private network addresses could be enabled to communicate with 143 external network by dynamically mapping to a set of globally valid 144 network addresses. If the number of local nodes are less than or 145 equal to addresses in the global set, each local address is 146 guaranteed a global address to map to. Otherwise, nodes allowed to 147 have simultaneous access to external network are limited by the 148 number of addresses in global set. Individual local addresses may 149 be statically mapped to specific global addresses to ensure 150 guaranteed access to the outside or to allow access to the local 151 host from external hosts. Multiple simultaneous sessions may be 152 initiated from a local node, using the same address mapping. 154 Addresses inside a stub domain are local to that domain and not 155 valid outside the domain. Thus, addresses inside a stub domain 156 can be reused by any other stub domain. For instance, a single 157 Class A address could be used by many stub domains. At each exit 158 point between a stub domain and backbone, NAT is installed. If 159 there is more than one exit point it is of great importance that 160 each NAT has the same translation table. 162 \ | / 163 +---------------+ 164 |Regional Router| 165 +---------------+ 166 WAN | | WAN 167 | | 168 Stub A .............|.... ....|............ Stub B 169 | | 170 {s=198.76.29.7,^ | | v{s=198.76.29.7, 171 d=198.76.28.4}^ | | v d=198.76.28.4} 172 +-----------------+ +-----------------+ 173 |Stub Router w/NAT| |Stub Router w/NAT| 174 +-----------------+ +-----------------+ 175 | | 176 | LAN LAN | 177 ------------- ------------- 178 | | 179 {s=10.33.96.5, ^ | | v{s=198.76.29.7, 180 d=198.76.28.4}^ +--+ +--+ v d=10.81.13.22} 181 |--| |--| 182 /____\ /____\ 183 10.33.96.5 10.81.13.22 185 Figure 2: Basic NAT Operation 187 For instance, in the example of figure 2, both stubs A and B 188 internally use class A address 10.0.0.0. Stub A's NAT is 189 assigned the class C address 198.76.29.0, and Stub B's NAT is 190 assigned the class C address 198.76.28.0. The class C addresses 191 are globally unique no other NAT boxes can use them. 193 When stub A host 10.33.96.5 wishes to send a packet to stub B host 194 10.81.13.22, it uses the globally unique address 198.76.28.4 as 195 destination, and sends the packet to it's primary router. The stub 196 router has a static route for net 198.76.0.0 so the packet is 197 forwarded to the WAN-link. However, NAT translates the source 198 address 10.33.96.5 of the IP header to the globally unique 199 198.76.29.7 before the packet is forwarded. Likewise, IP packets 200 on the return path go through similar address translations. 202 Notice that this requires no changes to hosts or routers. For 203 instance, as far as the stub A host is concerned, 198.76.28.4 is 204 the address used by the host in stub B. The address translations 205 are completely transparent. Of course, this is just a simple 206 example. There are numerous issues to be explored. 208 2.2. Overview of NAPT 210 Say, an organization has a private IP network and a WAN link to a 211 service provider. The private network's stub router is assigned 212 a globally valid address on the WAN link and the remaining nodes 213 in the organization have IP addresses that have only local 214 significance. In such a case, nodes on the private network could 215 be allowed simultaneous access to external network, using the 216 single registered IP address with the aid of NAPT. NAPT would 217 allow mapping of tuples of the type (local IP addresses, local 218 TU port number) to tuples of the type (registered IP address, 219 assigned TU port number). 221 This model fits the requirements of most Small Office Home Office 222 (SOHO) groups to access external network using a single service 223 provider assigned IP address. This model could be extended to 224 allow inbound access by statically mapping a local node per each 225 service TU port of the registered IP address. 227 In the example of figure 3 below, stub A internally uses class A 228 address 10.0.0.0. The stub router's WAN interface is assigned an 229 IP address 138.76.28.4 by the service provider. 231 \ | / 232 +-----------------------+ 233 |Service Provider Router| 234 +-----------------------+ 235 WAN | 236 | 237 Stub A .............|.... 238 | 239 ^{s=138.76.28.4,sport=1024, | v{s=138.76.29.7, sport = 23, 240 ^ d=138.76.29.7,dport=23} | v d=138.76.28.4, dport = 1024} 241 +------------------+ 242 |Stub Router w/NAPT| 243 +------------------+ 244 | 245 | LAN 246 -------------------------------------------- 247 | ^{s=10.0.0.10,sport=3017, | v{s=138.76.29.7, sport=23, 248 | ^ d=138.76.29.7,dport=23} | v d=10.0.0.10, dport=3017} 249 | | 250 +--+ +--+ +--+ 251 |--| |--| |--| 252 /____\ /____\ /____\ 253 10.0.0.1 10.0.0.2 ..... 10.0.0.10 255 Figure 3: Network Address Port Translation (NAPT) Operation 257 When stub A host 10.0.0.10 sends a telnet packet to host 258 138.76.29.7, it uses the globally unique address 138.76.29.7 as 259 destination, and sends the packet to it's primary router. The 260 stub router has a static route for net 138.76.0.0 so the packet 261 is forwarded to the WAN-link. However, NAPT translates the tuple 262 of source address 10.0.0.10 and source TCP port 3017 in the IP 263 and TCP headers into the globally unique 138.76.28.4 and a 264 uniquely assigned TCP port, say 1024, before the packet is 265 forwarded. Packets on the return path go through similar address 266 and TCP port translations for the target IP address and target 267 TCP port. Once again, notice that this requires no changes to 268 hosts or routers. The translation is completely transparent. 270 In this setup, only TCP/UDP sessions are allowed and must originate 271 from the local network. However, there are services such as DNS 272 that demand inbound access. There may be other services for which 273 an organization wishes to allow inbound session access. It is 274 possible to statically configure a TU port service on the stub 275 router to be directed to a specific node in the private network. 277 In addition to TCP/UDP sessions, ICMP messages, with the exception 278 of REDIRECT message type may also be monitored by NAPT router. 279 ICMP query type packets are translated similar to that of TCP/UDP 280 packets, in that the identifier field in ICMP message header will 281 be uniquely mapped to a query identifier of the registered IP 282 address. The identifier field in ICMP query messages is set by 283 Query sender and returned unchanged in response message from the 284 Query responder. So, the tuple of (Local IP address, local ICMP 285 query identifier) is mapped to a tuple of (registered IP address, 286 assigned ICMP query Identifier) by the NAPT router to uniquely 287 identify ICMP queries of all types from any of the local hosts. 288 Modifications to ICMP error messages are discussed in a later 289 section, as that involves modifications to ICMP payload as well 290 as the IP and ICMP headers. 292 In NAPT setup, where the registered IP address is the same as the IP 293 address of the stub router WAN interface, the router has to be sure 294 to make distinction between TCP, UDP or ICMP query sessions 295 originated from itself versus those originated from the nodes on 296 local network. All inbound sessions (including TCP, UDP and ICMP 297 query sessions) are assumed to be directed to the NAT router as 298 the end node, unless the target service port is statically mapped to 299 a different node in the local network. 301 Sessions other than TCP, UDP and ICMP query type are simply not 302 permitted from local nodes, serviced by a NAPT router. 304 3.0. Translation phases of a session. 306 The translation phases with traditional NAT are same as described in 307 [REF1]. The following sub-sections identify items that are specific 308 to traditional NAT. 310 3.1. Address binding: 312 With Basic NAT, a private address is bound to an external address, 313 when the first outgoing session is initiated from the private host. 314 Subsequent to that, all other outgoing sessions originating 315 from the same private address will use the same address binding for 316 packet translation. 318 In the case of NAPT, where many private addresses are mapped to a 319 single globally unique address, the binding would be from the 320 tuple of (private address, private TU port) to the tuple of 321 (assigned address, assigned TU port). As with Basic NAT, this 322 binding is determined when the first outgoing session is initiated 323 by the tuple of (private address, private TU port) on the private 324 host. While not a common practice, it is possible to have an 325 application on private host establish multiple simultaneous 326 sessions originating from the same tuple of (private address, 327 private TU port). In such a case, a single binding for the tuple 328 of (private address, private TU port) may be used for translation 329 of packets pertaining to all sessions originating from the same 330 tuple on a host. 332 3.2. Address lookup and translation: 334 After an address binding or (address, TU port) tuple binding in 335 case of NAPT is established, a soft state may be maintained for 336 each of the connections using the binding. Packets belonging to 337 the same session will be subject to session lookup for translation 338 purposes. The exact nature of translation is discussed in the 339 follow-on section. 341 3.3. Address unbinding: 343 When the last session based on an address or (address, TU port) 344 tuple binding is terminated, the binding itself may be terminated. 346 4.0. Packet Translations 348 Packets pertaining to NAT managed sessions undergo translation 349 in either direction. Individual packet translation issues are 350 covered in detail in the following sub-sections. 352 4.1. IP, TCP, UDP and ICMP Header Manipulations 354 In Basic NAT model, the IP header of every packet must be 355 modified. This modification includes IP address (source IP 356 address for outbound packets and destination IP address for 357 inbound packets) and the IP checksum. 359 For TCP/UDP sessions, modifications must include update of 360 checksum in the TCP/UDP headers. This is because TCP/UDP 361 checksum also covers a pseudo header which contains the source 362 and destination IP addresses. As an exception, UDP headers 363 with 0 checksum should not be modified. As for ICMP Query 364 packets, no further changes in ICMP header are required as 365 the checksum in ICMP header does not cover IP addresses. 367 In NAPT model, modifications to IP header are similar to that of 368 Basic NAT. For TCP/UDP sessions, modifications must be extended 369 to include translation of TU port (source TU port for outbound 370 packets and destination TU port for inbound packets) in the 371 TCP/UDP header. ICMP header in ICMP Query packets must also 372 be modified to replace the query ID and ICMP header checksum. 373 Private host query ID must be translated into assigned ID on 374 the outbound and the exact reverse on the inbound. ICMP header 375 checksum must be corrected to account for Query ID translation. 377 4.2. Checksum Adjustment 379 NAT modifications are per packet based and can be very compute 380 intensive, as they involve one or more checksum modifications 381 in addition to simple field translations. Luckily, we have 382 an algorithm below, which makes checksum adjustment to IP, TCP, 383 UDP and ICMP headers very simple and efficient. Since all these 384 headers use a one's complement sum, it is sufficient to calculate 385 the arithmetic difference between the before-translation and after- 386 translation addresses and add this to the checksum. The algorithm 387 below is applicable only for even offsets (i.e., optr below must 388 be at an even offset from start of header) and even lengths 389 (i.e., olen and nlen below must be even). Sample code (in C) for 390 this is as follows. 392 void checksumadjust(unsigned char *chksum, unsigned char *optr, 393 int olen, unsigned char *nptr, int nlen) 394 /* assuming: unsigned char is 8 bits, long is 32 bits. 395 - chksum points to the chksum in the packet 396 - optr points to the old data in the packet 397 - nptr points to the new data in the packet 398 */ 399 { 400 long x, old, new; 401 x=chksum[0]*256+chksum[1]; 402 x=~x & 0xFFFF; 403 while (olen) 404 { 405 old=optr[0]*256+optr[1]; optr+=2; 406 x-=old & 0xffff; 407 if (x<=0) { x--; x&=0xffff; } 408 olen-=2; 409 } 410 while (nlen) 411 { 412 new=nptr[0]*256+nptr[1]; nptr+=2; 413 x+=new & 0xffff; 414 if (x & 0x10000) { x++; x&=0xffff; } 415 nlen-=2; 416 } 417 x=~x & 0xFFFF; 418 chksum[0]=x/256; chksum[1]=x & 0xff; 419 } 421 4.3. ICMP error packet modifications 423 Changes to ICMP error message will include changes to IP and 424 ICMP headers on the outer layer as well as changes to the 425 headers of the packet embedded within the ICMP payload due 426 to error. 428 In order for NAT to be completely transparent to the host, the 429 IP address of the IP header embedded within the payload of the 430 ICMP packet must be modified, the checksum field of the same 431 IP header must correspondingly be modified, and the ICMP header 432 checksum must also be modified to reflect changes made to the 433 payload. 435 In a NAPT setup, if the IP message embedded within ICMP happens 436 to be a TCP, UDP or ICMP Query packet, you will also need to 437 modify the appropriate TU port number within the TCP/UDP header 438 or the Query Identifier field in the ICMP Query header. 440 Lastly, the IP header of the ICMP packet must also be modified. 442 4.4. FTP support 444 As noted in [REF1], one of the most popular applications, 445 "FTP" would require an ALG to monitor the control session 446 payload to determine the ensuing data session parameters. 447 FTP ALG is an integral part of most NAT implementations. 449 The FTP ALG would require a special table to correct the TCP 450 sequence and acknowledge numbers with source port FTP or 451 destination port FTP. The table entries should have source 452 address, destination address, source port, destination 453 port, delta for sequence numbers and a timestamp. New entries are 454 created only when FTP PORT commands or PASV responses are seen. The 455 sequence number delta may be increased or decreased for every FTP 456 PORT command or PASV response. Sequence numbers are incremented 457 on the outbound and acknowledge numbers are decremented on the 458 inbound by this delta. 460 FTP payload translations are limited to private addresses and 461 their assigned external addresses (encoded as individual octets 462 in ASCII) for Basic NAT. For NAPT setup, however, the translations 463 must be extended to include the TCP port octets (in ASCII) 464 following the address octets. 466 4.5 DNS support 468 Considering that sessions in a traditional NAT are predominantly 469 outbound from a private domain, DNS ALG may be obviated from use in 470 conjunction with traditional NAT as follows. DNS server(s) internal 471 to the private domain maintain mapping of names to IP addresses for 472 internal hosts and possibly some external hosts. External DNS 473 servers maintain name mapping for external hosts alone and not for 474 any of the internal hosts. If the private network does not have an 475 internal DNS server, all DNS requests may be directed to external 476 DNS server to find address mapping for the external hosts. 478 4.6. IP option handling 480 An IP datagram with any of the IP options Record Route, Strict 481 Source Route or Loose Source Route would involve recording or 482 using IP addresses of intermediate routers. A NAT intermediate 483 router may choose not to support these options or leave 484 the addresses untranslated while processing the options. The 485 result of leaving the addresses untranslated would be that 486 private addresses along the source route are exposed end to 487 end. This should not jeopardize the traversal path of the 488 packet, per se, as each router is supposed to look at the 489 next hop router only. 491 5. Miscellaneous issues 493 5.1. Partitioning of Local and Global Addresses 495 For NAT to operate as described in this draft, it is necessary 496 to partition the IP address space into two parts - the private 497 addresses used internal to stub domain, and the globally 498 unique addresses. Any given address must either be a private 499 address or a global address. There is no overlap. 501 The problem with overlap is the following. Say a host in stub A 502 wished to send packets to a host in stub B, but the global 503 addresses of stub B overlapped the private addressees of stub A. 504 In this case, the routers in stub A would not be able to 505 distinguish the global address of stub B from its own private 506 addresses. 508 5.2. Private address space recommendation 510 The RFC listed in ref[1] has recommendations on address space 511 allocation for private networks. Internet Assigned Numbers 512 Authority (IANA) has three blocks of IP address space, namely 513 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16 for private 514 internets. In pre-CIDR notation, the first block is nothing but 515 a single class A network number, while the second block is a set 516 of 16 contiguous class B networks, and the third block is a set of 517 256 contiguous class C networks. 519 An organization that decides to use IP addresses in the address 520 space defined above can do so without any coordination with IANA 521 or an Internet registry. The address space can thus be used 522 privately by many independent organizations at the same time, 523 with NAT operation enabled on their border routers. 525 5.3. Routing Across NAT 527 The router running NAT should not advertise the private networks to 528 the backbone. Only the networks with global addresses may be known 529 outside the stub. However, global information that NAT receives from 530 the stub border router can be advertised in the stub the usual way. 532 Typically, the NAT stub router will have a static route configured 533 to forward all external traffic to service provider router over WAN 534 link, and the service provider router will have a static route 535 configured to forward NAT packets (i.e., those whose destination 536 IP address fall within the range of NAT managed global address list) 537 to NAT router over WAN link. 539 5.4. Switch-over from Basic NAT to NAPT 541 In Basic NAT setup, when private network nodes outnumber global 542 addresses available for mapping (say, a class B private network 543 mapped to a class C global address block), external network 544 access to some of the local nodes is abruptly cut off after the 545 last global address from the address list is used up. This is 546 very inconvenient and constraining. Such an incident can be 547 safely avoided by optionally allowing the Basic NAT router to 548 switch over to NAPT setup for the last global address in the 549 address list. Doing this will ensure that hosts on private 550 network will have continued, uninterrupted access to the 551 external nodes and services for most applications. Note, 552 however, it could be confusing if some of the applications that 553 used to work with Basic NAT suddenly break due to the 554 switch-over to NAPT. 556 6.0. NAT limitations 558 [REF1] covers the limitations of all flavors of NAT, broadly 559 speaking. The following sub-sections identify limitations 560 specific to traditional NAT. 562 6.1. Privacy and Security 564 Traditional NAT can be viewed as providing a privacy mechanism 565 as sessions are uni-directional from private hosts and 566 the actual addresses of the private hosts are not visible to 567 external hosts. 569 The same characteristic that enhances privacy potentially makes 570 debugging problems (including security violations) more difficult. 571 If a host in private network is abusing the Internet in some way 572 (such as trying to attack another machine or even sending large 573 amounts of spam) it is more difficult to track the actual source 574 of trouble because the IP address of the host is hidden in a 575 NAT router. 577 6.2. ARP responses to NAT mapped global addresses on a LAN interface 579 NAT must be enabled only on border routers of a stub domain. The 580 examples provided in the document to illustrate Basic NAT and 581 NAPT have maintained a WAN link for connection to external router 582 (i.e., service provider router) from NAT router. However, if the 583 WAN link were to be replaced by a LAN connection and if part or 584 all of the global address space used for NAT mapping belongs to 585 the same IP subnet as the LAN segment, the NAT router would be 586 expected to provide ARP support for the address range that belongs 587 to the same subnet. Responding to ARP requests for the NAT 588 mapped global addresses with its own MAC address is a must in 589 such a situation with Basic NAT setup. If the NAT router did 590 not respond to these requests, there is no other node in the 591 network that has ownership to these addresses and hence will 592 go unresponded. 594 This scenario is unlikely with NAPT setup except when the single 595 address used in NAPT mapping is not the interface address of the 596 NAT router (as in the case of a switch-over from Basic NAT to NAPT 597 explained in 5.4 above, for example). 599 Using an address range from a directly connected subnet for NAT 600 address mapping would obviate static route configuration on the 601 service provider router. 603 It is the opinion of the authors that a LAN link to a service 604 provider router is not very common. However, vendors may be 605 interested to optionally support proxy ARP just in case. 607 6.3. Translation of outbound TCP/UDP fragmented packets in NAPT setup 609 Translation of outbound TCP/UDP fragments (i.e., those originating 610 from private hosts) in NAPT setup are doomed to fail. The reason is 611 as follows. Only the first fragment contains the TCP/UDP header that 612 would be necessary to associate the packet to a session for 613 translation purposes. Subsequent fragments do not contain TCP/UDP 614 port information, but simply carry the same fragmentation identifier 615 specified in the first fragment. Say, two private hosts originated 616 fragmented TCP/UDP packets to the same destination host. And, they 617 happened to use the same fragmentation identifier. When the 618 target host receives the two unrelated datagrams, carrying same 619 fragmentation id, and from the same assigned host address, it 620 is unable to determine which of the two sessions the datagrams 621 belong to. Consequently, both sessions will be corrupted. 623 7.0. Current Implementations 625 Many commercial implementations are available in the industry that 626 adhere to the NAT description provided in this document. Linux 627 public domain software contains NAT under the name of "IP 628 masquerade". FreeBSD public domain software has NAPT implementation 629 running as a daemon. Note however that Linux source is covered 630 under the GNU license and FreeBSD software is covered under the 631 UC Berkeley license. 633 Both Linux and FreeBSD software are free, so you can buy CD-ROMs 634 for these for little more than the cost of distribution. They are 635 also available on-line from a lot of FTP sites with the latest 636 patches. 638 8.0. Security Considerations 640 The security considerations described in [REF1] for all variations 641 of NATs are applicable to traditional NAT. 643 REFERENCES 645 [1] P. Srisuresh, M. Holdrege, "IP Network Address Translator (NAT) 646 Terminology and Considerations", 647 - Work in progress. 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 Lucent technologies 682 4464 Willow Road 683 Pleasanton, CA 94588-8519 684 U.S.A. 686 Voice: (925) 737-2153 687 Fax: (925) 737-2110 688 EMail: suresh@ra.lucent.com 690 Kjeld Borch Egevang 691 Intel Denmark ApS 693 Voice: +45 44530100 694 Fax: +45 44531415 695 EMail: kbe@casetech.dk 696 http: //www.freeyellow.com/members/kbe