idnits 2.17.1 draft-zhou-sunset4-scenarios-01.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 6) being 62 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (July 16, 2012) is 4301 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC6431' is mentioned on line 133, but not defined Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force C. Zhou 3 Internet-Draft Huawei Technologies 4 Intended status: Informational T. Tsou 5 Expires: January 10, 2013 Huawei Technologies (USA) 6 C. Grundemann 7 Cablelabs 8 July 16, 2012 10 Scenarios of IPv4 sunsetting 11 draft-zhou-sunset4-scenarios-01 13 Abstract 15 This document describes scenarios at subscriber, carrier and 16 enterprise sites during IPv4 sunsetting. In each site, there may be 17 different requirements and issues. The aim of this document is to 18 put forward some issues in these scenarios and to identify whether 19 further specifications are needed to solve these issues to facilitate 20 IPv4 sunsetting. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on January 10, 2013. 39 Copyright Notice 41 Copyright (c) 2012 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3. Subscriber Site Scenario . . . . . . . . . . . . . . . . . . . 3 59 4. Carrier Site Scenario . . . . . . . . . . . . . . . . . . . . . 3 60 4.1. Traceback . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 4.2. Stateless CGN . . . . . . . . . . . . . . . . . . . . . . . 4 62 4.3. High Availability . . . . . . . . . . . . . . . . . . . . . 4 63 4.4. ALG . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 5. Enterprise Site Scenario . . . . . . . . . . . . . . . . . . . 5 65 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 66 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 67 8. Normative References . . . . . . . . . . . . . . . . . . . . . 7 69 1. Introduction 71 There are already a set of documents in IETF which to some extent 72 facilitate IPv6 transition. For example, 73 [I-D.ietf-behave-lsn-requirements] describes the common requirements 74 of CGN (NAT44). For devices which implement NAT, MIB module is 75 introduced in [I-D.ietf-behave-nat-mib]. However, there are many 76 scenarios and issues encountered at subscriber, carrier and 77 enterprise sites, e.g., source trace, high availability, and ALG 78 issues at carrier site scenario. In this document, these scenarios 79 will be proposed in detail and some issues in these scenarios will be 80 discussed. 82 2. Conventions 84 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 85 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 86 document are to be interpreted as described in RFC 2119. 88 3. Subscriber Site Scenario 90 Some subscribers have the need to run some servers at home, for 91 example, web server, webcam, FTP server, etc. Sometimes when a 92 subscriber equipment reboots it may be assigned a new IP address 93 which is different from the previous one. To accomadate this IP 94 address change, DDNS is used. If NAT is used in subscribe premise, 95 static port-forwarding can be configured for a specific service so 96 that DDNS can continue to work. But if CGN is deployed in the 97 operator's network, one CGN will serve a lot of users, static port- 98 forwarding configuration will require a lot of operational work, and 99 there will be IP address and port conflict if multiple subscribers 100 require a same purlic IP address and / or port. A traditional 101 solution is to assign public IP address to scribers who needs to run 102 a server at home, but this will also require extra operational work, 103 make the network more complicated. In such a case, a possible 104 solution is that DDNS system works together with some dynamic NAT 105 traversal technologies, e.g. UPnP/PCP, or the CGN provide DDNS 106 proxy. 108 4. Carrier Site Scenario 110 For carrier site case, we provide some scenarios and issues as below 111 for the working group discussion. 113 4.1. Traceback 115 Before CGN is introduced, the servers use the source IPv4 address as 116 an identifier to treat incoming packets differently. When the 117 address sharing scheme is proposed, the server could not identify 118 which host sends the packet because the packets are from the same 119 source address. [I-D.boucadair-intarea-nat-reveal-analysis] proposed 120 solutions to identify each host sharing the same IP address with a 121 unique host identifier. But there are at least two issues existing 122 in the traceback solutions: logging architecture and port allocation 123 algorithm. 125 As described in section 4 of [I-D.ietf-behave-lsn-requirements], the 126 destination addresses or ports should not be logged in CGN in order 127 to reduce the logs in CGN. [RFC6302]provides recommendations for 128 Internet-facing servers logging incoming connections. But it does 129 not provide any recommendations about logging on carrier-grade NAT. 130 So, a logging architecture in CGN to maintain records of the relation 131 between a customer's identity and IP/port resources is needed. 133 [RFC6431] provides port set options for port range allocation: 134 contiguous, non-contiguous and random. In the random-based solution, 135 the algorithm should be reversible in order to trace the host. But 136 this may bring some security problems. 138 4.2. Stateless CGN 140 Carrier-grade NAT44 is one of the solutions to deal with the IPv4 141 address shortage problem. But the current NAT44 CGN(Carrier-grade 142 NAT) is stateful and TCP/UDP session based, which makes the CGN 143 complex. There have been a number of efforts at IETF moving the NAT 144 function from a stateful carrier grade NAT to the CPEs by allocating 145 port sets to each customer, e.g., MAP/4RD-U, LAFT6, and etc. There 146 is also a requirement for NAT44 CGN to become completely stateless. 148 4.3. High Availability 150 In most ISP networks, one CGN device may serve large number of 151 customers. For stateful NAT, if there is a single point of failure 152 in the CGN, the service may be interrupted or degraded. Therefore, 153 redundancy capabilities (including hot and cold standby) of the CGN 154 devices are strongly needed to deliver highly available services to 155 customers. [I-D.xu-behave-stateful-nat-standby] may be a possible 156 way to solve this problem. In addition, pre-configuring a pool of 157 public IPv4 addresses to the CGN device when it is in failure may 158 also be a candidate solution. 160 4.4. ALG 162 Carrier-grade NAT44 performs NAT-44 and inherits the limitations of 163 NAT. Some protocols require ALGs in the CGN to traverse through the 164 NAT, e.g., FTP, RTP. However, in most ISP's network, CGN is a shared 165 network device which needs to support a large number of sessions. It 166 is a huge work load for CGN to implement every ALGs, which will 167 obviously bring bad performance for CGN. How to make CGN more 168 efficiency under the pressure of ALG becomes an issue. One possible 169 solution is to let the CPE or host implement ALG instead of CGN, or a 170 flexible way to make ALG at either CPE or CGN is needed. 172 5. Enterprise Site Scenario 174 NAT is a basic feature of enterprise network. The firewall/NAT 175 device is deployed at the entrance of the enterprise network, 176 following by the web server and the terminal. Part of the web 177 servers are required to open publically to provide one domian name 178 and corresponding IP address (Two ways: the enterprise has its own 179 DNS server; the enterprise has no DNS server and needs to publicize 180 one public address). NAT device is required to support this specific 181 case. In addition, the terminal or the web server following NAT 182 device need to access Internet. There are requirements for the 183 enterprise users to record the NAT translation information. 185 Some basic requirements of NAT device are also valid in enterprise 186 scenarios, e.g., NAT traceback, port range allocation and NAT 187 standby. NAT device needs to record the NAT translation log in 188 traceback solutions. NAT server is required to support port range 189 allocation. Two NAT devices should store the information of each 190 other to guarantee normal operation when one device is in failure in 191 enterprise scenarios. 193 6. IANA Considerations 195 No request to IANA. 197 7. Security Considerations 199 TBD 201 Authors' Addresses 203 Cathy Zhou 204 Huawei Technologies 205 Bantian, Longgang District 206 Shenzhen 518129 207 P.R. China 209 Phone: 210 EMail: cathy.zhou@huawei.com 211 Tina Tsou 212 Huawei Technologies (USA) 213 2330 Central Expressway 214 Santa Clara, CA 95050 215 USA 217 Phone: +1 408 330 4424 218 EMail: tina.tsou.zouting@huawei.com 220 Chris Grundemann 221 CableLabs 222 858 Coal Creek Circle 223 Louisville, CO 80027 224 USA 226 Phone: 303.661.3779 227 Email: c.grundemann@cablelabs.com 229 8. Normative References 231 [I-D.ietf-behave-lsn-requirements] Perreault, S., Yamagata, 232 I., Miyakawa, S., 233 Nakagawa, A., and H. 234 Ashida, "Common 235 requirements for Carrier 236 Grade NATs (CGNs)", 237 May 2012. 239 [I-D.ietf-behave-nat-mib] Perreault, S., Tsou, I., 240 and S. Sivakumar, 241 "Additional Definitions 242 of Managed Objects for 243 Network Address 244 Translators (NAT)", 245 April 2012. 247 [I-D.boucadair-intarea-nat-reveal-analysis] Boucadair, M., Touch, 248 J., Levis, P., and R. 249 Penno, "Analysis of 250 Solution Candidates to 251 Reveal a Host Identifier 252 in Shared Address 253 Deployments", 254 September 2011. 256 [I-D.xu-behave-stateful-nat-standby] Xu, X., Boucadair, M., 257 Lee, Y., and G. Chen, 258 "Redundancy Requirements 259 and Framework for 260 Stateful Network Address 261 Translators (NAT)", 262 October 2010.