idnits 2.17.1 draft-tsou-stateless-nat44-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 1 instance of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 22, 2012) is 4202 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group T. Tsou 3 Internet-Draft Huawei Technologies (USA) 4 Intended status: Standards Track W. Liu 5 Expires: April 25, 2013 Huawei Technologies 6 S. Perreault 7 Viagenie 8 R. Penno 9 Cisco Systems, Inc. 10 M. Chen 11 FreeBit 12 October 22, 2012 14 Stateless IPv4 Network Address Translation 15 draft-tsou-stateless-nat44-02 17 Abstract 19 This memo describes a protocol for decentralizing IPv4 NAT to the 20 customer-premises equipment (CPE) such that no state information is 21 kept on the central NAT device. The CPE uses a restricted source 22 port set that is encoded in its provisioned IPv4 WAN address. The 23 NAT device performs only strictly stateless address (not port) 24 translation. 26 Status of this Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on April 25, 2013. 43 Copyright Notice 45 Copyright (c) 2012 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 3. Address Formats . . . . . . . . . . . . . . . . . . . . . . . 4 63 4. Customer Provisioning . . . . . . . . . . . . . . . . . . . . 5 64 5. SLNAT44 Configuration . . . . . . . . . . . . . . . . . . . . 6 65 6. Port Set Computation . . . . . . . . . . . . . . . . . . . . . 6 66 7. CPE Operation . . . . . . . . . . . . . . . . . . . . . . . . 7 67 7.1. ALG Handling . . . . . . . . . . . . . . . . . . . . . . . 8 68 8. SLNAT44 Operation . . . . . . . . . . . . . . . . . . . . . . 8 69 8.1. Internal to External . . . . . . . . . . . . . . . . . . . 8 70 8.2. External to Internal . . . . . . . . . . . . . . . . . . . 8 71 8.3. Fragment Handling . . . . . . . . . . . . . . . . . . . . 9 72 9. Address Mapping Example . . . . . . . . . . . . . . . . . . . 9 73 10. Security Considerations . . . . . . . . . . . . . . . . . . . 10 74 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 75 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 76 12.1. Normative References . . . . . . . . . . . . . . . . . . . 10 77 12.2. Informative References . . . . . . . . . . . . . . . . . . 10 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 80 1. Introduction 82 IPv4 address exhaustion has become world-wide reality. NAT is one of 83 the solutions to deal with the problem. The drawbacks of traditional 84 NAT include statefulness and the need to track transport-layer 85 sessions. This makes NAT complex, hard to scale up, and fragile. 87 This document describes a method of deploying stateless NAT as a 88 backwards-compatible evolution of an IPv4-only network. 90 The assumed topology is illustrated in Figure 1. 92 +-----+ +---------+ 93 Home -----+ CPE |------+ SLNAT44 +---- Internet 94 network +-----+ +---------+ 95 ^ ^ 96 | | 97 +-- Internal Address +--- External Address 99 Figure 1: Stateless NAT44 topology 101 When CPE is configured working as a transparent bridge, internal 102 addresses are directly assigned to the end hosts in the home network, 103 as is shown in Figure 2. 105 +-----+ +---------+ 106 Home -----+ CPE |------+ SLNAT44 +---- Internet 107 network +-----+ +---------+ 108 ^ ^ 109 | | 110 +-- Internal Addresses +--- External Address 112 Figure 2: Stateless NAT44 topology: CPE as bridge 114 Note that SLNAT44 has no IPv6 component. Any deployment of IPv6 is 115 unaffected by SLNAT44. Therefore, this document only describes IPv4 116 addresses and IPv4 packets. IPv6 is not discussed further. 118 2. Terminology 120 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 121 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 122 document are to be interpreted as described in [RFC2119]. 124 The following terms are used throughout this document: 126 Port set: Set of transport-layer ports that each CPE is assigned, to 127 be used as source ports by packets sent by the CPE. 129 Port Set ID: A value from which a unique port set is algorithmically 130 derived. 132 SLNAT44: Depending on the context, either the stateless NAT44 133 protocol or the stateless NAT44 device that translates between 134 internal and external addresses. NAT44 in turn stands for "IPv4- 135 to-IPv4 NAT". 137 Internal Address: The IPv4 address assignted to a CPE. It is used 138 in the ISP network between the CPE and the SLNAT44. 140 External Address: The IPv4 address used on the Internet and routed 141 to the SLNAT44. 143 Mapping rule: A set of parameters configured on the SLNAT44 (not on 144 the CPE) describing the relationship between internal and external 145 addresses. 147 3. Address Formats 149 Internal addresses have the format illustrated in Figure 3. The 150 addresses are simply made of three parts concatenated together: the 151 Internal Prefix, the External Suffix, and the Port Set ID. 153 |0 |a |32 154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 155 | Internal Prefix | External Suffix | Port Set ID | 156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 158 Figure 3: Internal Address format 160 External Addresses have the format illustrated in Figure 4. It is 161 made of two parts: the External Prefix and the External Suffix. 163 |0 |b |32 164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 165 | External Prefix | External Suffix | 166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 168 Figure 4: External Address format 170 The lengths of the Internal and External Prefixes, "a" and "b", are 171 mandatory parameters of SLNAT44. They are determined by the ISP. 172 They need not be communicated to the CPE. Other lengths can be 173 computed from them as follows: 175 o Length of External Suffix: 32 - b 177 o Length of Port Set ID: b - a 179 4. Customer Provisioning 181 Customer Provisioning is applied to the CPE when the CPE serves a 182 gateway. 184 As part of its start up routine, the CPE is assigned an IPv4 address 185 by the ISP using regular means (DHCP, PPP, etc.). This is the 186 Internal Address. 188 In addition, using new provisioning options, the CPE is assigned a 189 Port Set ID. 191 Optionally, a Port Set Mask is also provisioned to the CPE. This 192 mask is of the same length as the Port Set ID (i.e., b-a bits). Its 193 purpose is to allow discontinuous port ranges. If no mask is 194 provided, a mask of all ones is assumed by default, which implies a 195 continuous port range. System ports (0-1023) should not to be 196 assigned to any CPE. 198 In summary, the CPE is provisioned with the following elements: 200 o IPv4 address (as usual) 202 o Port Set ID 204 o Port Set Mask (optional) 206 When the CPE is configured in the bridge mode, all the above features 207 are provisioned directly to the end host behind the CPE. 209 Note: no matter in which mode the CPE is running, the customer 210 provisioning could be either dynamic or static. Static provisioning 211 implies an address planning for the private IPv4 address (i.e., 212 RFC1918 addresses) inside in the domain. Static provisioning enables 213 servers (passive daemons) at the home network being accessible within 214 the domain. CPE running as bridge makes this feature easy to deploy 215 while running as L3 gateway requires port redirection if an in-domain 216 server at a host is demanded. 218 5. SLNAT44 Configuration 220 The SLNAT44 is configured with a set of mapping rules. Each rule 221 contains: 223 o Internal Prefix 225 o External Prefix 227 o Port Set Mask (optional) 229 Prefixes include their length. For simplicity, rule prefixes MUST 230 NOT overlap with other rules. 232 If it is absent, the Port Set Mask is assumed to be all ones by 233 default. 235 6. Port Set Computation 237 Given a Port Set ID and a Port Set Mask, both n bits in length, the 238 set of allowed ports is defined as the set of port numbers for which 239 the higher-order n bits of their binary expression whose 240 corresponding mask bits are 1 are equal to corresponding bits from 241 the Port Set ID. 243 |0 |5 244 +-+-+-+-+-+ 245 |1 1 1 0 1| Port Set ID = 29 (length n = 5 bits) 246 +-+-+-+-+-+ 247 & & & & & 248 +-+-+-+-+-+ 249 |1 1 1 1 1| Port Set Mask 250 +-+-+-+-+-+ 251 | | | | | 252 V V V V V 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 |1 1 1 0 1 x x x x x x x x x x x x| Port Set = 59392-61439 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 |0 |16 258 Figure 5: Example Contiguous Port Set Computation 260 |0 |8 261 +-+-+-+-+-+-+-+-+ 262 |0 0 1 0 1 1 1 1| Port Set ID = 29 (length n = 8 bits) 263 +-+-+-+-+-+-+-+-+ 264 & & & & & & & & 265 +-+-+-+-+-+-+-+-+ 266 |0 0 1 1 1 1 1 1| Port Set Mask 267 +-+-+-+-+-+-+-+-+ 268 | | | | | | | | 269 V V V V V V V V 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 271 |x x 1 0 1 1 1 1 x x x x x x x x x| Port Set = 12032-12287, 28416-28671, 272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 44800-45055, 61184-61439 273 |0 |16 275 Figure 6: Example Non-Contiguous Port Set Computation 277 It follows that the number of ports in the set is 2^(16-x), where x 278 is the number of ones in the Port Set Mask. 280 This computation is performed by the CPE as part of its provisioning 281 routine as well as by the SLNAT44 for dropping packets with ports 282 outside the allowed range. 284 For the purposes of SLNAT44, a "source port" corresponds to either a 285 TCP source port, a UDP source port, or an ICMPv4 identifier, while a 286 "destination port" corresponds to either a TCP destination port, a 287 UDP destination port, or an ICMPv4 identifier. Note that an ICMPv4 288 identifier plays the role of both source and destination port. 290 Transport protocols other than TCP and UDP, as well as ICMPv4 types 291 without an identifier field, are not supported. 293 7. CPE Operation 295 CPE can be configured as either a gateway or transparent bridge. 297 In the gateway mode, packets sent from the CPE MUST have the 298 provisioned IPv4 address as source and MUST have a source port that 299 is within the allowed set. This is usually accomplished by having 300 the CPE run a NAT44 configured with the provisioned address and 301 allowed port set and having it process all packets sent out the WAN 302 interface. 304 Packets received by the CPE on its WAN interface with a destination 305 port outside the allowed range MUST be dropped. 307 In the bridge mode, however, CPE only transfers packets and therefore 308 the service of stateless NAT44 is performed by the SLNAT44 directly 309 towards end hosts that possibly running as in-domain servers. 311 Regardless of any mode of the CPE, the operation involves injecting 312 private addresses (or prefixes) into the intra-domain backbone 313 routing infrastructure. It is necessary to operationally ensure that 314 there are no private addresses/prefixes are leaking into the backbone 315 route tables unless they are assigned by the SLNAT44 to CPEs or 316 directly to hosts. 318 7.1. ALG Handling 320 If the CPE implements application level gateways (ALGs) such as FTP, 321 RSTP or PPTP, it must ensure that ports present in the payload when 322 tanslated fall within the allowed range. 324 8. SLNAT44 Operation 326 8.1. Internal to External 328 When it receives a packet on an internal interface, the SLNAT44 finds 329 the rule whose Internal Prefix matches the packet's source address. 330 It extracts the Port Set ID from the packet's source address. It 331 then checks if the packet's source port is within the allowed set, 332 using the rule's Port Set Mask. If it is not, the packet MUST be 333 dropped. 335 If the packet's source port is within the allowed set, the SLNAT44 336 builds the External Address by concatenating the rule's External 337 Prefix with the External Suffix extracted from the packet's source 338 address. It then replaces the packet's source address with this 339 External Address. The IPv4 and transport-layer checksums are updated 340 as necessary. The packet is then forwarded as usual. 342 8.2. External to Internal 344 When it receives a packet on an external interface, the SLNAT44 finds 345 the rule whose External Prefix matches the packet's destination 346 address. It then builds the Internal Address by concatenating the 347 rule's Internal Prefix, the External Suffix extracted from the 348 packet's destination address, and the Port Set ID computed by 349 applying the rule's Port Set Mask to the packet's destination port's 350 higher-order bits. It then replaces the packet's destination address 351 with this Internal Address. The IPv4 and transport-layer checksums 352 are updated as necessary. The packet is then forwarded as usual. 354 8.3. Fragment Handling 356 If the incoming IP packet contains a fragment, then more processing 357 may be needed. This specification leaves open the exact details of 358 how a SLNAT44 handles incoming IP packets containing fragments, and 359 simply requires that the external behavior of the SLNAT444 be 360 compliant with the following conditions. 362 The SLNAT44 MUST handle fragments. In particular, SLNAT44 MUST 363 handle fragments arriving out of order, conditional on the following: 365 o The SLNAT44 MUST limit the amount of resources devoted to the 366 storage of fragmented packets in order to protect from DoS 367 attacks. 369 o As long as the SLNAT44 has available resources, the SLNAT44 MUST 370 allow the fragments to arrive over a time interval. The time 371 interval SHOULD be configurable and the default value MUST be of 372 at least 2 seconds. 374 o The SLNAT44 MAY require that the UDP, TCP, or ICMPv4 header be 375 completely contained within the fragment that contains fragment 376 offset equal to zero. 378 For incoming packets carrying TCP or UDP fragments with a non-zero 379 checksum, SLNAT44 MAY elect to queue the fragments as they arrive and 380 translate all fragments at the same time. In this case, the incoming 381 tuple is determined as documented above to the un-fragmented packets. 382 Alternatively, a SLNAT44 MAY translate the fragments as they arrive, 383 by storing information that allows it to compute the necessary port 384 number for fragments other than the first. In the latter case, 385 subsequent fragments may arrive before the first, and the rules (in 386 the bulleted list above) about how the SLNAT44 handles (out-of-order) 387 fragments apply. 389 Implementers of SLNAT44 should be aware that there are a number of 390 well-known attacks against IP fragmentation; see [RFC1858] and 391 [RFC3128]. Implementers should also be aware of additional issues 392 with reassembling packets at high rates, described in [RFC4963]. 394 9. Address Mapping Example 396 An operator has two public ranges of size /18 and /19 called foo and 397 bar respectively. It plans to use 10/8 as its internal address 398 prefix and PSID (port range) of length 5. Two prefixes of the 399 internal network 400 The internal prefixes lengths are: 402 o 32 - 18 - 5 = 13 (derived from foo) 404 o 32 - 19 - 5 = 14 (derived from bar) 406 This will give the following possible mappings: 408 o foo/18 <--> 10.0.0.0/13 410 o bar/19 <--> 10.128.0.0/14 412 Author note: Discuss the where internal prefixes are overlapping 414 10. Security Considerations 416 The security considerations related to IP address sharing documented 417 in RFC 6269 [RFC6269] and RFC 6056 [RFC6056] apply to SLNAT44. 419 11. Acknowledgements 421 Section 8.3 is adapted from [RFC6146]. 423 12. References 425 12.1. Normative References 427 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 428 Requirement Levels", BCP 14, RFC 2119, March 1997. 430 12.2. Informative References 432 [RFC1858] Ziemba, G., Reed, D., and P. Traina, "Security 433 Considerations for IP Fragment Filtering", RFC 1858, 434 October 1995. 436 [RFC3128] Miller, I., "Protection Against a Variant of the Tiny 437 Fragment Attack (RFC 1858)", RFC 3128, June 2001. 439 [RFC4963] Heffner, J., Mathis, M., and B. Chandler, "IPv4 Reassembly 440 Errors at High Data Rates", RFC 4963, July 2007. 442 [RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport- 443 Protocol Port Randomization", BCP 156, RFC 6056, 444 January 2011. 446 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 447 NAT64: Network Address and Protocol Translation from IPv6 448 Clients to IPv4 Servers", RFC 6146, April 2011. 450 [RFC6269] Ford, M., Boucadair, M., Durand, A., Levis, P., and P. 451 Roberts, "Issues with IP Address Sharing", RFC 6269, 452 June 2011. 454 Authors' Addresses 456 Tina Tsou 457 Huawei Technologies (USA) 458 2330 Central Expressway 459 Santa Clara, CA 95050 460 USA 462 Phone: +1 408 330 4424 463 Email: tina.tsou.zouting@huawei.com 465 Will Liu 466 Huawei Technologies 467 Bantian, Longgang District 468 Shenzhen 518129 469 P.R. China 471 Email: liushucheng@huawei.com 473 Simon Perreault 474 Viagenie 475 246 Aberdeen 476 Quebec, QC G1R 2E1 477 Canada 479 Email: simon.perreault@viagenie.ca 481 Reinaldo Penno 482 Cisco Systems, Inc. 483 170 West Tasman Drivee 484 San Jose, California 95134 485 USA 487 Email: repenno@cisco.com 488 Maoke Chen 489 FreeBit 490 3-6 Maruyama-cho 491 Shibuya-ku, Tokyo 150-0044 492 Japan 494 Email: fibrib@gmail.com