idnits 2.17.1 draft-zhou-softwire-b4-nat-04.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: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 60 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 138 instances of too long lines in the document, the longest one being 5 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 156 has weird spacing: '... itself falls...' == Line 184 has weird spacing: '...sioning effic...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (October 31, 2011) is 4560 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) == Missing Reference: 'I-D.ietf-softwire-dual-stack-lite' is mentioned on line 175, but not defined == Missing Reference: 'I-D.tsou-pcp-natcoord' is mentioned on line 205, but not defined == Missing Reference: 'I-D.ietf-intarea-shared-addressing-issues' is mentioned on line 228, but not defined == Missing Reference: 'I-D.ymbk-aplusp' is mentioned on line 439, but not defined == Unused Reference: 'RFC2119' is defined on line 358, but no explicit reference was found in the text == Unused Reference: 'I-D.bsd-softwire-stateless-port-index-analysis' is defined on line 376, but no explicit reference was found in the text == Unused Reference: 'I-D.cui-softwire-dhcp-over-tunnel' is defined on line 386, but no explicit reference was found in the text == Unused Reference: 'I-D.cui-softwire-host-4over6' is defined on line 394, but no explicit reference was found in the text == Unused Reference: 'I-D.murakami-softwire-4rd' is defined on line 404, but no explicit reference was found in the text == Unused Reference: 'I-D.sun-v6ops-laft6' is defined on line 414, but no explicit reference was found in the text Summary: 1 error (**), 0 flaws (~~), 15 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Xiaohong Deng 3 Internet Draft M. Boucadair 4 Intended status: Standards Track France Telecom 5 Expires: May 2012 C. Zhou 6 Huawei Technologies 7 October 31, 2011 9 NAT offload extension to Dual-Stack lite 10 draft-zhou-softwire-b4-nat-04 12 Abstract 14 Dual-Stack Lite, combining IPv4-in-IPv6 tunnel and Carrier Grade NAT 15 technologies, provides an approach that offers IPv4 service via IPv6 16 network by sharing IPv4 addresses among customers during IPv6 17 transition period. Dual-stack lite, however, requires CGN to maintain 18 active NAT sessions, which means processing performance, memory size 19 and log abilities for NAT sessions should scale with number of 20 sessions of subscribers; Hence increasing in CAPEX for operators 21 would be resulted in when traffic increase. 23 This document propose the NAT offload extensions to DS-Lite, which 24 allows offloading NAT translation function from centralized network 25 side (AFTR) to distributed customer equipments (B4), thereby offering 26 a trade-off between CAPEX (e.g. less performance requirements on AFTR 27 device) and OPEX (e.g., easy and fast deployment of Dual-Stack Lite) 28 for operators. The ability of easily co-deploying with basic Dual- 29 Stack Lite is essential to NAT offload extension to DS-Lite. 31 Status of this Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on April 26, 2012. 47 Copyright Notice 49 Copyright (c) 2011 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Background........................................................3 65 2. NAT offload extended DS-Lite Overview and terminologies...........3 66 3. NATed B4 Behavior.................................................5 67 3.1. Plain IPv4 Address...........................................5 68 3.2. Restricted IPv4 Address and port set provisioning............5 69 3.2.1. Restricted port allocation strategies and requirements..5 70 3.2.2. Restricted IPv4 Address and port set provisioning method 71 ..............................................................6 72 3.3. Outgoing Packets Processing..................................6 73 3.4. Incoming Packets Processing..................................6 74 3.4.1. Incoming Ports considerations on a given restricted IPv4 75 address........................................................6 76 4. NAT offload AFTR Behaviour........................................7 77 4.1. Outgoing Packets Processing..................................7 78 4.2. Incoming Packets Processing..................................7 79 5. Fragmentation and Reassembly and DNS..............................7 80 6. Security Considerations...........................................8 81 7. IANA Considerations..............................................10 82 8. References.......................................................10 83 8.1. Normative References........................................10 84 8.2. Informative References......................................10 85 9. Acknowledgments..................................................12 87 1. Background 89 The basic idea of NAT offload extension to DS-lite, is to reuse the 90 basic DS-Lite infrastructure, including tunneling transport and 91 provisioning method, and ICMP and fragmentation processing as well. 93 The NAT offload extension makes the AFTR table scales with customer 94 number other than traffic sessions. Based on this NAT offload 95 extension, log entries for per subscriber instead of per session is 96 achievable. IPv4 address utilization efficiency depends on port 97 allocation strategies, e.g., per port on demand, or a buck of ports 98 pre-allocation, which would be elaborated in Section 5. 100 Besides, this method allows unique IPv6 address for delivery both 101 IPv4 over IPv6 traffic and native IPv6 traffic without introduce any 102 IPv4 addressing/rouging into IPv6 address/routing, as it reuses Dual 103 Stack Lite tunneling transport infrastructure, unlike stateless 104 solutions with port set allocation such as aplusp and 4rd, that 105 either requires two IPv6 addresses separately for either IPv4 traffic 106 over IPv6 or native IPv6 traffic, or require carefully design to 107 avoid introduce IPv4 routing to IPv6 routing when using unique IPv6 108 address to transport both IPv4 over IPv6 traffic and native IPv6 109 traffic. 111 2. NAT offload extended DS-Lite Overview and terminologies 113 Figure 1 provides an overview of the NAT offload extended DS-Lite. 115 +-------------------------+ 116 | IPv6 ISP Network | 117 | | 118 | | 119 +-------------------------+ 120 | 121 | +-----------+ +----------+ 122 | |NAT offload| | IPv4 | 123 +--------+ | IPv4-in-IPv6 |AFTR |---| Internet | 124 | | +---------+ | | | | 125 |IPv4 LAN|--|NATed |===============+-----------+ +----------+ 126 | | |B4 |CPE/HOST | 127 +--------+ +---------+ | 128 | | 129 | | 130 +-------------------------+ 132 Figure 1 : NAT offload extended DS-Lite Overview 134 NATed B4: A NAT offload extended B4 which is called NATed B4 in this 135 document can be either an IPv6 hosts or a CPE. NATed B4 performs IP 136 address and port translation function, besides establishment of IPv4 137 in IPv6 tunnel with AFTR. 139 NAT offload AFTR: A NAT offload extended AFTR which is called NAT 140 offload AFTR is responsible for establishing IPv4 in IPv6 tunneling 141 with NATed B4 to transport IPv4 over IPv6 while the NAT translation 142 function is offloaded to NATed B4. 144 A NATed B4 uses IPv4 address with a restricted port set for this IPv4 145 connectivity, which may be provisioned via either DHCPv4 with the 146 AFTR, or via PCP with the PCP server. The AFTR keeps the mapping 147 between B4's IPv6 address, allocated IPv4 address, and a restricted 148 port set ID on a per customer basis. 150 For host NATed B4 case, the host gets public address directly. It is 151 also suggested that the host run a local NAT to map randomly 152 generated ports into the restricted port set. Private to public 153 address translation would not be needed in this NAT. Another 154 solution is to have the IP stack to only assign ports within the 155 restricted port set to applications. Either way the host guarantees 156 that every port number in the packets sent out by itself falls into 157 the allocated port set. 159 3. NATed B4 Behavior 161 The NATed B4 is responsible for performing NAT and/ALG functions, 162 basic B4 functions, as well as supporting NAT Traversal mechanisms 163 (e.g., UPnP or NAT-PMP). 165 The tunneling provisioning of the B4 element should reuse what has 166 defined in [I-D.ietf-softwire-dual-stack-lite]. 168 3.1. Plain IPv4 Address 170 A NATed B4 MAY be assigned with a plain IPv4 address. 172 When a plain, IPv4 address is assigned, the NAT operations are 173 enforced as per current legacy CPEs. The NAT in the AFTR is disabled 174 for that user.IPv4 datagrams are encapsulated in IPv6 as specified in 175 [I-D.ietf-softwire-dual-stack-lite]. 177 3.2. Restricted IPv4 Address and port set provisioning 179 3.2.1. Restricted port allocation strategies and requirements 181 Restricted port allocation strategies for this approach could either 182 be allocating per port on demand, or be pre-allocating a port set (no 183 matter a continuous port range, or multiple non-continuous sub port 184 sets),which leads to trade-off between provisioning efficiency and 185 IPv4 utilization efficiency. 187 Note that efficiency on log is reported by operators as a practical 188 requirement for AFTR, hence port set decoding should take this 189 requirement into account, no matter which port allocation strategy is 190 adopt. 192 Unlike stateless 4over6 solutions such as [I-D.murakami-softwire- 193 4rd], the restricted port sets allocation for NAT offload extended 194 DS-Lite has no requires on careful planning of the IPv6 and IPv4 195 addressing together. It therefore offers more flexibility for ISPs, 196 when it comes to managing the IPv6 access network, and introduces no 197 impact on IPv6 routing. 199 3.2.2. Restricted IPv4 Address and port set provisioning method 201 Either DHCP for example, [I-D.bajko-pripaddrassign] or PCP would be 202 candidate for delivery Restricted IPv4 and port set. 204 With PCP, The basic PCP protocol allows per port on demand allocation, 205 while an extension to PCP [I-D.tsou-pcp-natcoord] supports pre- 206 allocate bulk of ports. 208 3.3. Outgoing Packets Processing 210 Upon receiving an IPv4 packet, the B4 performs NAT using the public 211 IPv4 address and port set assigned to it. Then B4 encapsulates the 212 resulting IPv4 packet into an IPv6 packet, and delivers it through 213 IPv6 connectivity to AFTR which will then decapsulate the 214 encapsulated packet and forward it through IPv4. The destination 215 IPv6 address used for encapsulation should be the AFTR's address. 217 3.4. Incoming Packets Processing 219 Upon receipt of IPv4-in-IPv6 packet from AFTR, B4 will decapsulate 220 the packet and translate the public IPv4 address to the private IPv4 221 address. Finally, it delivers the packet to the host using the 222 translated IPv4 address. The source IPv6 address used for 223 encapsulation at AFTR is the AFTR's address, and the destination 224 address is set to the external address of B4. 226 3.4.1. Incoming Ports considerations on a given restricted IPv4 address 228 As described in [I-D.ietf-intarea-shared-addressing-issues], a bulk 229 of incoming ports can be reserved as a centralized resource shared by 230 all subscribers using a given restricted IPv4 address. In order to 231 distribute incoming ports as fair as possible among subscribers 232 sharing a given restricted IPv4 address, other than allocating a 233 continuous range of ports to each, a solution to distribute bulks of 234 non-continuous ports among subscribers, which also takes port 235 randomization into account, is elaborated in Section 3.1. 237 4. NAT offload AFTR Behaviour 239 The NAT offload AFTR may be co-located with IP and /or restricted 240 port set allocation server (e.g., a DHCP server, or a PCP server). 242 The AFTR only maintains a static mapping entry per customer consist 243 of IPv6 address, IPv4 address and port set ID, other than maintains 244 NAT entries per session. 246 4.1. Outgoing Packets Processing 248 For outgoing packets, the NAT offload AFTR simply decapsulates it and 249 forwards it to IPv4 Internet. 251 4.2. Incoming Packets Processing 253 For inbound traffic, NAT offload AFTR would use the IPv4 destination 254 address and port as the index to retrieve mapping table in order to 255 find a destination IPv6 address, and then encapsulates it into IPv6, 256 so that native IPv6 routing could be used to forward the IPv4 in IPv6 257 traffic. 259 5. Fragmentation and Reassembly and DNS 261 No change to Section 5.3 of [I-D.ietf-softwire-dual-stack-lite. The 262 DNS behavior is the same as described in [I-D.ietf-softwire-dual- 263 stack-lite]. 265 6. Security Considerations 267 As port randomization is one protection among others against blind 268 attacks, a simple non-contiguous port sets distribution mechanism is 269 therefore proposed to distribute bulks of non-continuous ports among 270 subscribers, and to enable subscribers operating port randomized NAT. 272 In this section, a non-continuous restricted port set 273 encoding/decoding and an algorithm of random ephemeral port selection 274 within the allocated restricted port set example proves that port 275 randomization is applicable this approach. 277 On every external IPv4 address, according to port set size N, log2(N) 278 bits are randomly choosing by NAT offload AFTR as subscribers 279 identification bits(s bit) among 1st and 16th bits. Take a sharing 280 ration 1:32 for example, Figure 1 shows an example of 5 random 281 selected bits of s bits. 283 |1st |2nd |3rd |4th |5th |6th |7th | 8th| 284 +----+----+----+----+----+----+----+----+ 285 | 0 | s | 0 | 0 | s | 0 | s | 0 | 286 +----+----+----+----+----+----+----+----+ 287 |9th |10th|11th|12th|13th|14th|15th|16th| 288 +----+----+----+----+----+----+----+----+ 289 | s | 0 | s | 0 | 0 | 0 | 0 | 0 | 290 +----+----+----+----+----+----+----+----+ 292 Figure 2 : A s bit selection example (on a sharing ration 1:32 293 address). 295 Subscriber ID pattern is formed by setting all the s bits to 1 and 296 other trivial bits to 0. Figure 2 illustrates an example of 297 subscriber ID pattern on a sharing ration 1:32 address. Note that 298 the subscriber ID pattern will be different, guaranteed by the random 299 s bit selection, on every restricted IP address no matter whether the 300 sharing ratio varies.The NAT offload AFTR can use subscriber ID 301 pattern as port set ID on a per restricted IPv4 address basis, which 302 allows log entries scale on a subscriber basis, hence meets the log 303 efficiency requirements described in Section 3.1.2. 305 |1st |2nd |3rd |4th |5th |6th |7th | 8th| 306 +----+----+----+----+----+----+----+----+ 307 | 0 | 1 | 0 | 0 | 1 | 0 | 1 | 0 | 308 +----+----+----+----+----+----+----+----+ 309 |9th |10th|11th|12th|13th|14th|15th|16th| 310 +----+----+----+----+----+----+----+----+ 311 | 1 | 0 | 1 | 0 | 0 | 0 | 0 | 0 | 312 +----+----+----+----+----+----+----+----+ 314 Figure 3 : A subscriber ID pattern example (on a sharing ration 1:32 315 address). 317 Subscribers ID value is then assigned by setting subscriber ID 318 pattern bits (s bits shown in the following example) according to a 319 customer value and setting other trivial bits to 1. 321 |1st |2nd |3rd |4th |5th |6th |7th | 8th| 322 +----+----+----+----+----+----+----+----+ 323 | 1 | s | 1 | 1 | s | 1 | s | 1 | 324 +----+----+----+----+----+----+----+----+ 325 |9th |10th|11th|12th|13th|14th|15th|16th| 326 +----+----+----+----+----+----+----+----+ 327 | s | 1 | s | 1 | 1 | 1 | 1 | 1 | 328 +----+----+----+----+----+----+----+----+ 330 Figure 4 : A subscriber ID value example (0# subscriber on this 331 restricted address). 333 Subscriber ID pattern and subscriber ID value together uniquely 334 defines a non-overlapping port set on a restricted IP address. 336 Pseudo-code shown in the Figure 4 describe how to use subscriber ID 337 pattern and subscriber ID value to implement a random ephemeral port 338 selection function in a restricted port set. 340 do{ 341 restricted_next_ephemeral = (random()| customer_ID_pattern) 342 & customer_ID_value; 343 if(five-tuple is unique) 344 return restricted_next_ephemeral; 345 } 347 Figure 5 : Random ephemeral port selection of restricted port set 348 algorithm. 350 7. IANA Considerations 352 TBD. 354 8. References 356 8.1. Normative References 358 [RFC2119] 360 Bradner, S., "Key words for use in RFCs to Indicate 362 Requirement Levels", BCP 14, RFC 2119, March 1997. 364 8.2. Informative References 366 [I-D.bajko-pripaddrassign] 368 Bajko, G., Savolainen, T., Boucadair, M., and P. Levis, 370 "Port Restricted IP Address Assignment", 372 draft-bajko-pripaddrassign-03 (work in progress), 374 September 2010. 376 [I-D.bsd-softwire-stateless-port-index-analysis] 378 Boucadair, M., Skoberne, N., and W. Dec, "Analysis of 380 Port Indexing Algorithms", 382 draft-bsd-softwire-stateless-port-index-analysis-00 384 (work in progress), September 2011. 386 [I-D.cui-softwire-dhcp-over-tunnel] 388 Cui, Y., Wu, P., and J. Wu, "DHCPv4 Behavior over IP-IP 390 tunnel", draft-cui-softwire-dhcp-over-tunnel-01 (work 392 in progress), July 2011. 394 [I-D.cui-softwire-host-4over6] 396 Cui, Y., Wu, J., Wu, P., Metz, C., Vautrin, O., and Y. 398 Lee, "Public IPv4 over Access IPv6 Network", 400 draft-cui-softwire-host-4over6-06 (work in progress), 402 July 2011. 404 [I-D.murakami-softwire-4rd] 406 Murakami, T., Troan, O., and S. Matsushima, "IPv4 408 Residual Deployment on IPv6 infrastructure - protocol 410 specification", draft-murakami-softwire-4rd-01 (work in 412 progress), September 2011. 414 [I-D.sun-v6ops-laft6] 416 Sun, Q. and C. Xie, "LAFT6: NAT offload address family 418 transition for IPv6", draft-sun-v6ops-laft6-01 (work in 420 progress), March 2011. 422 9. Acknowledgments 424 Thank Alain Durand, Ole Troan and Ralph Dorm for their valuable 425 feedback and discussion to this appraoch, and thanks to Qiong Sun for 426 a discussion from operators needs' perspective. 428 Appendix A. Variants of this approach 430 A.1. Introduction 432 This section defines variants of deployment for this NAT offload DS- 433 Lite approach. A.2 describes its combination with stateless 434 encapsulation. 436 A.2 Stateless Encapsulation 438 B4 may implement the stateless encapsulation specified in Section 4.4 439 of [I-D.ymbk-aplusp]. 441 Authors' Addresses 443 Xiaohong Deng 444 France Telecom 445 Email: xiaohong.deng@orange.com 447 Mohamed Boucadair 448 France Telecom 449 Rennes, 35000 450 France 452 Email: mohamed.boucadair@orange.com 454 Cathy Zhou 455 Huawei Technologies 456 Bantian, Longgang District 457 Shenzhen 518129 458 P.R. China 460 Phone: 461 Email: cathyzhou@huawei.com 463 Tina Tsou 464 Huawei Technologies (USA) 465 2330 Central Expressway 466 Santa Clara, CA 95050 467 USA 469 Phone: +1 408 330 4424 470 Email: tena@huawei.com 472 Gabor Bajko 473 Nokia 475 Email: gabor.bajko@nokia.com