Network Working Group W. Liu Internet-Draft C. Zhou Intended status: Informational Huawei Technologies Expires: April 24, 2014 Q. Sun China Telecom October 21, 2013 Openv6 Architecture for IPv6 Deployment draft-liu-openv6-architecture-00 Abstract IPv6 transition leads to costly end-to-end network upgrades and poses new challenges in terms of device management with a variety of transitional protocols. This document provides a cost-effective and flexible unified IPv6 deployment by describing an architecture of a standard and programmatic manner for IPv6 deployment. 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 April 24, 2014. Copyright Notice Copyright (c) 2013 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 Liu, et al. Expires April 24, 2014 [Page 1] Internet-Draft Openv6 Architecture for IPv6 Deployment October 2013 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 3. Motivation for OpenV6 Architecture . . . . . . . . . . . . . 3 4. Overview of the OpenV6 Architecture . . . . . . . . . . . . . 3 5. OpenV6 Considerations . . . . . . . . . . . . . . . . . . . . 5 6. Manageability Considerations . . . . . . . . . . . . . . . . 5 7. Security Considerations . . . . . . . . . . . . . . . . . . . 5 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 10.1. Normative References . . . . . . . . . . . . . . . . . . 5 10.2. Informative References . . . . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 1. Introduction The exhaustion of the IPv4 address space has been a practical problem that network carriers are facing today. Existing solutions such as IPv4 re-addressing and address reusing fail to fundamentally solve this problem. Instead, IPv6 is regarded as a complete and thorough solution to this problem. To date, the adoption of IPv6 is progressing slowly. [Google-IPv6-Statistics] shows the statistics of IPv6 adoption. On one hand, IPv6 lacks support from applications. As a result, end users are reluctant to transition to IPv6 due to lack of attractive applications and competitive prices on IPv6. On the other hand, a large-scale IPv6 network as well as a stable and large IPv6 user group are the fundamental driving forces for evolving to IPv6. The key to the above deadlock is that network carriers should take the initiative in constructing and developing an IPv6-friendly infrastructure, thus providing IPv6-based service access capabilities and actively nurturing the IPv6 adoption. The Openv6 and this document are focused on flexibly unifying the IPv6 transition mechanisms. The Openv6 provides an IPv6-friendly infrastructure to let the users decide for themselves when and how to start the IPv6 transition. 2. Terminology Liu, et al. Expires April 24, 2014 [Page 2] Internet-Draft Openv6 Architecture for IPv6 Deployment October 2013 3. Motivation for OpenV6 Architecture Several motivations for the Openv6 are listed below. This list is not meant to be exhaustive and is provided for the sake of illustration. It should be highlighted that the aim of this section is to provide some application examples for which the OpenV6 may be suitable: this also clearly states that such a model does not aim to replace existing IPv6 transition mechanisms but would apply to specific existing or future situations. The Openv6 does not replace the existing IPv6 transition mechanisms in the network. Instead, it is compatible (or accommodate) existing and future IPv6 transition mechanisms. Not all networks, servers and users will upgrade to IPv6 at the same pace along IPv6 transition. There will be many different scenarios, among which we can highlight the following ones: Some regions will stay as IPv4-only networks (whenever transition is too costly or there are compelling technical reasons for not upgrading), and some regions will start as IPv6-only networks. IPv6 end users accessing the IPv6 Internet via a service provider's IPv4 network infrastructure. IPv4 end users accessing the IPv4 Internet via a service provider's IPv6 network infrastructure. IPv6 end users accessing the IPv4 Internet. According to these (and many others) different scenarios, and to the current status of network infrastructure, a number of different IPv6 transition technologies have been defined. For any device it becomes extremely hard to support them all at the same time, so addressing all the potential situations can become extremely costly, both in terms of CAPEX and OPEX. The Openv6 provides an opportunity to build a unified approach to the different IPv6 transition technologies. With unified devices on the forwarding plane, packets are processed according to flow tables, in a way completely oblivious to the transition technology particular aspects. 4. Overview of the OpenV6 Architecture This section gives an overview of the architecture of the Openv6. Liu, et al. Expires April 24, 2014 [Page 3] Internet-Draft Openv6 Architecture for IPv6 Deployment October 2013 The figure in Figure 1 shows the basic architecture of Openv6. +------------------------+ | Applications | | (Lw4over6, NAT64, etc.)| | | | +----------------+ | | | Openv6 Agent | | | +----------------+ | +----------- ^ ----------+ | | | +----------- v ----------+ | +---------------+ | | | | | | +-----+ +-----+ | | |Agent| ... |Agent| | +-------+ | +-----+ +-----+ | | | | | | | +----+ +-----------+ | | | +---------------+ | |Host|--|Unified |--| | | ^ | +----+ |v6Trans CPE| | | | | | +--------+ +-----------+ | | | v | | | |IPv4/ | | +--------------+ | |IPv4/ | |IPv6 |--| | | |--|IPv6 | |Network| | | Unified | | |Internet| +----+ +-----------+ | | | | Flow Table | | | | |Host|--|Unified |--| | | | | | +--------+ +----+ |v6Trans CPE| | | | +--------------+ | +-----------+ | | | | | | |Unified Forwarding Node | +-------+ +------------------------+ Figure 1: Architecture of OpenV6 Unified Forwarding Node: A forwarding node that handles incoming packets basing on the flow table. Examples of Forwarding Nodes can include: A router that has an extended function module. The extended module handles incoming packets basing on the flow table of the module. A server that runs vRouter or vSwitch. A CGN that runs NAT, Tunnel En/De-capsulation functions. Liu, et al. Expires April 24, 2014 [Page 4] Internet-Draft Openv6 Architecture for IPv6 Deployment October 2013 A Forwarding Node may be locally managed, whether via CLI, SNMP, or NETCONF. Unified Flow Table: The flow table is used for handling incoming packets of the forwarding node. The flow table can be updated by the application. If an incoming packet does not match any entry of the flow table, the packet will be delivered to the agent for generating new entries. OpenV6 Agent: The OpenV6 agent interacts with the forwarding node to provide specified behavior for incoming packets via the flow table. Application: A network application that needs to manipulate the network to achieve its service requirements. Various IPv6 transition mechanisms are are considered to be a variety of applications in OpenV6. The application can communicate with multiple forwarding node. Agent: The agent interacts with the applications and the forwarding nodes. It can be implemented in the forwarding node for policies driven provisioning. There may be multiple agents in an forwarding node. Each agent executes a specific policy(for example, one agent for App-Lw4over6, one agent for NAT64, etc.) 5. OpenV6 Considerations 6. Manageability Considerations 7. Security Considerations 8. IANA Considerations 9. Acknowledgements N/A. 10. References 10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Liu, et al. Expires April 24, 2014 [Page 5] Internet-Draft Openv6 Architecture for IPv6 Deployment October 2013 10.2. Informative References [Google-IPv6-Statistics] Google, "Google IPv6 Statistics", , . [RFC6674] Brockners, F., Gundavelli, S., Speicher, S., and D. Ward, "Gateway-Initiated Dual-Stack Lite Deployment", RFC 6674, July 2012. [RFC6888] Perreault, S., Yamagata, I., Miyakawa, S., Nakagawa, A., and H. Ashida, "Common Requirements for Carrier-Grade NATs (CGNs)", BCP 127, RFC 6888, April 2013. Authors' Addresses Will(Shucheng) Liu Huawei Technologies Bantian, Longgang District Shenzhen 518129 P.R. China Email: liushucheng@huawei.com Cathy Zhou Huawei Technologies Bantian, Longgang District Shenzhen 518129 P.R. China Email: cathy.zhou@huawei.com Qiong Sun China Telecom No.118 Xizhimennei street, Xicheng District Beijing 100035 P.R. China Email: sunqiong@ctbri.com.cn Liu, et al. Expires April 24, 2014 [Page 6]