Internet Engineering Task Force C. Zhou Internet-Draft Huawei Technologies Intended status: Informational T. Tsou Expires: January 10, 2013 Huawei Technologies (USA) C. Grundemann Cablelabs July 16, 2012 Scenarios of IPv4 sunsetting draft-zhou-sunset4-scenarios-01 Abstract This document describes scenarios at subscriber, carrier and enterprise sites during IPv4 sunsetting. In each site, there may be different requirements and issues. The aim of this document is to put forward some issues in these scenarios and to identify whether further specifications are needed to solve these issues to facilitate IPv4 sunsetting. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on January 10, 2013. Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://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 Zhou & Tsou Expires January 10, 2013 [Page 1] Internet-Draft IPv4 Sunsetting Scenarios July 2012 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Subscriber Site Scenario . . . . . . . . . . . . . . . . . . . 3 4. Carrier Site Scenario . . . . . . . . . . . . . . . . . . . . . 3 4.1. Traceback . . . . . . . . . . . . . . . . . . . . . . . . . 3 4.2. Stateless CGN . . . . . . . . . . . . . . . . . . . . . . . 4 4.3. High Availability . . . . . . . . . . . . . . . . . . . . . 4 4.4. ALG . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 5. Enterprise Site Scenario . . . . . . . . . . . . . . . . . . . 5 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 8. Normative References . . . . . . . . . . . . . . . . . . . . . 7 Zhou & Tsou Expires January 10, 2013 [Page 2] Internet-Draft IPv4 Sunsetting Scenarios July 2012 1. Introduction There are already a set of documents in IETF which to some extent facilitate IPv6 transition. For example, [I-D.ietf-behave-lsn-requirements] describes the common requirements of CGN (NAT44). For devices which implement NAT, MIB module is introduced in [I-D.ietf-behave-nat-mib]. However, there are many scenarios and issues encountered at subscriber, carrier and enterprise sites, e.g., source trace, high availability, and ALG issues at carrier site scenario. In this document, these scenarios will be proposed in detail and some issues in these scenarios will be discussed. 2. Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. 3. Subscriber Site Scenario Some subscribers have the need to run some servers at home, for example, web server, webcam, FTP server, etc. Sometimes when a subscriber equipment reboots it may be assigned a new IP address which is different from the previous one. To accomadate this IP address change, DDNS is used. If NAT is used in subscribe premise, static port-forwarding can be configured for a specific service so that DDNS can continue to work. But if CGN is deployed in the operator's network, one CGN will serve a lot of users, static port- forwarding configuration will require a lot of operational work, and there will be IP address and port conflict if multiple subscribers require a same purlic IP address and / or port. A traditional solution is to assign public IP address to scribers who needs to run a server at home, but this will also require extra operational work, make the network more complicated. In such a case, a possible solution is that DDNS system works together with some dynamic NAT traversal technologies, e.g. UPnP/PCP, or the CGN provide DDNS proxy. 4. Carrier Site Scenario For carrier site case, we provide some scenarios and issues as below for the working group discussion. 4.1. Traceback Before CGN is introduced, the servers use the source IPv4 address as an identifier to treat incoming packets differently. When the Zhou & Tsou Expires January 10, 2013 [Page 3] Internet-Draft IPv4 Sunsetting Scenarios July 2012 address sharing scheme is proposed, the server could not identify which host sends the packet because the packets are from the same source address. [I-D.boucadair-intarea-nat-reveal-analysis] proposed solutions to identify each host sharing the same IP address with a unique host identifier. But there are at least two issues existing in the traceback solutions: logging architecture and port allocation algorithm. As described in section 4 of [I-D.ietf-behave-lsn-requirements], the destination addresses or ports should not be logged in CGN in order to reduce the logs in CGN. [RFC6302]provides recommendations for Internet-facing servers logging incoming connections. But it does not provide any recommendations about logging on carrier-grade NAT. So, a logging architecture in CGN to maintain records of the relation between a customer's identity and IP/port resources is needed. [RFC6431] provides port set options for port range allocation: contiguous, non-contiguous and random. In the random-based solution, the algorithm should be reversible in order to trace the host. But this may bring some security problems. 4.2. Stateless CGN Carrier-grade NAT44 is one of the solutions to deal with the IPv4 address shortage problem. But the current NAT44 CGN(Carrier-grade NAT) is stateful and TCP/UDP session based, which makes the CGN complex. There have been a number of efforts at IETF moving the NAT function from a stateful carrier grade NAT to the CPEs by allocating port sets to each customer, e.g., MAP/4RD-U, LAFT6, and etc. There is also a requirement for NAT44 CGN to become completely stateless. 4.3. High Availability In most ISP networks, one CGN device may serve large number of customers. For stateful NAT, if there is a single point of failure in the CGN, the service may be interrupted or degraded. Therefore, redundancy capabilities (including hot and cold standby) of the CGN devices are strongly needed to deliver highly available services to customers. [I-D.xu-behave-stateful-nat-standby] may be a possible way to solve this problem. In addition, pre-configuring a pool of public IPv4 addresses to the CGN device when it is in failure may also be a candidate solution. 4.4. ALG Carrier-grade NAT44 performs NAT-44 and inherits the limitations of NAT. Some protocols require ALGs in the CGN to traverse through the NAT, e.g., FTP, RTP. However, in most ISP's network, CGN is a shared Zhou & Tsou Expires January 10, 2013 [Page 4] Internet-Draft IPv4 Sunsetting Scenarios July 2012 network device which needs to support a large number of sessions. It is a huge work load for CGN to implement every ALGs, which will obviously bring bad performance for CGN. How to make CGN more efficiency under the pressure of ALG becomes an issue. One possible solution is to let the CPE or host implement ALG instead of CGN, or a flexible way to make ALG at either CPE or CGN is needed. 5. Enterprise Site Scenario NAT is a basic feature of enterprise network. The firewall/NAT device is deployed at the entrance of the enterprise network, following by the web server and the terminal. Part of the web servers are required to open publically to provide one domian name and corresponding IP address (Two ways: the enterprise has its own DNS server; the enterprise has no DNS server and needs to publicize one public address). NAT device is required to support this specific case. In addition, the terminal or the web server following NAT device need to access Internet. There are requirements for the enterprise users to record the NAT translation information. Some basic requirements of NAT device are also valid in enterprise scenarios, e.g., NAT traceback, port range allocation and NAT standby. NAT device needs to record the NAT translation log in traceback solutions. NAT server is required to support port range allocation. Two NAT devices should store the information of each other to guarantee normal operation when one device is in failure in enterprise scenarios. 6. IANA Considerations No request to IANA. 7. Security Considerations TBD Authors' Addresses Cathy Zhou Huawei Technologies Bantian, Longgang District Shenzhen 518129 P.R. China Phone: EMail: cathy.zhou@huawei.com Zhou & Tsou Expires January 10, 2013 [Page 5] Internet-Draft IPv4 Sunsetting Scenarios July 2012 Tina Tsou Huawei Technologies (USA) 2330 Central Expressway Santa Clara, CA 95050 USA Phone: +1 408 330 4424 EMail: tina.tsou.zouting@huawei.com Chris Grundemann CableLabs 858 Coal Creek Circle Louisville, CO 80027 USA Phone: 303.661.3779 Email: c.grundemann@cablelabs.com Zhou & Tsou Expires January 10, 2013 [Page 6] Internet-Draft IPv4 Sunsetting Scenarios July 2012 8. Normative References [I-D.ietf-behave-lsn-requirements] Perreault, S., Yamagata, I., Miyakawa, S., Nakagawa, A., and H. Ashida, "Common requirements for Carrier Grade NATs (CGNs)", May 2012. [I-D.ietf-behave-nat-mib] Perreault, S., Tsou, I., and S. Sivakumar, "Additional Definitions of Managed Objects for Network Address Translators (NAT)", April 2012. [I-D.boucadair-intarea-nat-reveal-analysis] Boucadair, M., Touch, J., Levis, P., and R. Penno, "Analysis of Solution Candidates to Reveal a Host Identifier in Shared Address Deployments", September 2011. [I-D.xu-behave-stateful-nat-standby] Xu, X., Boucadair, M., Lee, Y., and G. Chen, "Redundancy Requirements and Framework for Stateful Network Address Translators (NAT)", October 2010.