idnits 2.17.1 draft-liu-openv6-architecture-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: ---------------------------------------------------------------------------- No issues found here. 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 date (February 14, 2014) is 3723 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 243, but no explicit reference was found in the text == Unused Reference: 'RFC6674' is defined on line 252, but no explicit reference was found in the text == Unused Reference: 'RFC6888' is defined on line 256, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group W. Liu 3 Internet-Draft C. Zhou 4 Intended status: Informational Huawei Technologies 5 Expires: August 18, 2014 Q. Sun 6 China Telecom 7 G. Leclanche 8 Viagenie 9 February 14, 2014 11 Openv6 Architecture for IPv6 Deployment 12 draft-liu-openv6-architecture-01 14 Abstract 16 IPv6 transition leads to costly end-to-end network upgrades and poses 17 new challenges in terms of device management with a variety of 18 transitional protocols. 20 This document provides a cost-effective and flexible unified IPv6 21 deployment by describing an architecture of a standard and 22 programmatic manner for IPv6 deployment. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on August 18, 2014. 41 Copyright Notice 43 Copyright (c) 2014 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Motivation for OpenV6 Architecture . . . . . . . . . . . . . 3 61 4. Overview of the OpenV6 Architecture . . . . . . . . . . . . . 4 62 5. OpenV6 Considerations . . . . . . . . . . . . . . . . . . . . 5 63 6. Manageability Considerations . . . . . . . . . . . . . . . . 5 64 7. Security Considerations . . . . . . . . . . . . . . . . . . . 5 65 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 66 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 67 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 68 10.1. Normative References . . . . . . . . . . . . . . . . . . 6 69 10.2. Informative References . . . . . . . . . . . . . . . . . 6 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 72 1. Introduction 74 The exhaustion of the IPv4 address space has been a practical problem 75 that network carriers are facing today. Existing solutions such as 76 IPv4 re-addressing and address reusing fail to fundamentally solve 77 this problem. Instead, IPv6 is regarded as a complete and thorough 78 solution to this problem. 80 To date, the adoption of IPv6 is progressing slowly. 81 [Google-IPv6-Statistics] shows the statistics of IPv6 adoption. On 82 one hand, IPv6 lacks support from applications. As a result, end 83 users are reluctant to transition to IPv6 due to lack of attractive 84 applications and competitive prices on IPv6. On the other hand, a 85 large-scale IPv6 network as well as a stable and large IPv6 user 86 group are the fundamental driving forces for evolving to IPv6. 88 The key to the above deadlock is that network carriers should take 89 the initiative in constructing and developing an IPv6-friendly 90 infrastructure, thus providing IPv6-based service access capabilities 91 and actively nurturing the IPv6 adoption. The Openv6 and this 92 document are focused on flexibly unifying the IPv6 transition 93 mechanisms. The Openv6 provides an IPv6-friendly infrastructure to 94 let the users decide for themselves when and how to start the IPv6 95 transition. 97 2. Terminology 99 3. Motivation for OpenV6 Architecture 101 Several motivations for the Openv6 are listed below. This list is 102 not meant to be exhaustive and is provided for the sake of 103 illustration. 105 It should be highlighted that the aim of this section is to provide 106 some application examples for which the OpenV6 may be suitable: this 107 also clearly states that such a model does not aim to replace 108 existing IPv6 transition mechanisms but would apply to specific 109 existing or future situations. 111 The Openv6 does not replace the existing IPv6 transition mechanisms 112 in the network. Instead, it is compatible (or accommodate) existing 113 and future IPv6 transition mechanisms. 115 Not all networks, servers and users will upgrade to IPv6 at the same 116 pace along IPv6 transition. There will be many different scenarios, 117 among which we can highlight the following ones: 119 Some regions will stay as IPv4-only networks (whenever transition 120 is too costly or there are compelling technical reasons for not 121 upgrading), and some regions will start as IPv6-only networks. 123 IPv6 end users accessing the IPv6 Internet via a service 124 provider's IPv4 network infrastructure. 126 IPv4 end users accessing the IPv4 Internet via a service 127 provider's IPv6 network infrastructure. 129 IPv6 end users accessing the IPv4 Internet. 131 According to these (and many others) different scenarios, and to the 132 current status of network infrastructure, a number of different IPv6 133 transition technologies have been defined. For any device it becomes 134 extremely hard to support them all at the same time, so addressing 135 all the potential situations can become extremely costly, both in 136 terms of CAPEX and OPEX. 138 The Openv6 provides an opportunity to build a unified approach to the 139 different IPv6 transition technologies. With unified devices on the 140 forwarding plane, packets are processed according to flow tables, in 141 a way completely oblivious to the transition technology particular 142 aspects. 144 4. Overview of the OpenV6 Architecture 146 This section gives an overview of the architecture of the Openv6. 148 The figure in Figure 1 shows the basic architecture of Openv6. 150 +------------------------+ 151 | Applications | 152 | (OSS,3rd-APPs, | 153 | security service, | 154 | v6 trans service,etc.)| 155 | +----------------+ | 156 | | Openv6 Agent | | 157 | +----------------+ | 158 +----------- ^ ----------+ 159 | 160 | 161 | 162 +----------- v ----------+ 163 | +---------------+ | 164 | | | | 165 | +-----+ +-----+ | 166 | |Agent| ... |Agent| | 167 +-------+ | +-----+ +-----+ | 168 | | | | | | 169 +----+ +-----------+ | | | +---------------+ | 170 |Host|--|Unified |--| | | ^ | 171 +----+ |v6Trans CPE| | | | | | +--------+ 172 +-----------+ | | | v | | | 173 |IPv4/ | | +--------------+ | |IPv4/ | 174 |IPv6 |--| | | |--|IPv6 | 175 |Network| | | Unified | | |Internet| 176 +----+ +-----------+ | | | | Flow Table | | | | 177 |Host|--|Unified |--| | | | | | +--------+ 178 +----+ |v6Trans CPE| | | | +--------------+ | 179 +-----------+ | | | | 180 | | |Unified Forwarding Node | 181 +-------+ +------------------------+ 183 Figure 1: Architecture of OpenV6 185 Unified Forwarding Node: A forwarding node that handles incoming 186 packets basing on the flow table. Examples of Forwarding Nodes can 187 include: 189 A router that has an extended function module. The extended module 190 handles incoming packets basing on the flow table of the module. 192 A server that runs vRouter or vSwitch. 194 A CGN that runs NAT, Tunnel En/De-capsulation functions. 196 A Forwarding Node may be locally managed, whether via CLI, SNMP, or 197 NETCONF. 199 Unified Flow Table: The flow table is used for handling incoming 200 packets of the forwarding node. The flow table can be updated by the 201 application. If an incoming packet does not match any entry of the 202 flow table, the packet will be delivered to the agent for generating 203 new entries. 205 OpenV6 Agent: The OpenV6 agent interacts with the forwarding node to 206 provide specified behavior for incoming packets via the flow table. 208 Applications: A network application that needs to manipulate the 209 network to achieve its service requirements. Various IPv6 related 210 services can be enabled by corresponding Applications such as: 212 OSS: can be considered as an application; 214 3rd-party APPs: IPv6 based 3rd-party applications; 216 Network security service: security related services such as savi 218 IPv6 transition service: transition mechanisms are are considered 219 to be a variety of applications in OpenV6. The application can 220 communicate with multiple forwarding node. 222 Agent: The agent interacts with the applications and the forwarding 223 nodes. It can be implemented in the forwarding node for policies 224 driven provisioning. There may be multiple agents in an forwarding 225 node. Each agent executes a specific policy(for example, one agent 226 for App-Lw4over6, one agent for NAT64, etc.) 228 5. OpenV6 Considerations 230 6. Manageability Considerations 232 7. Security Considerations 234 8. IANA Considerations 235 9. Acknowledgements 237 N/A. 239 10. References 241 10.1. Normative References 243 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 244 Requirement Levels", BCP 14, RFC 2119, March 1997. 246 10.2. Informative References 248 [Google-IPv6-Statistics] 249 Google, "Google IPv6 Statistics", . 252 [RFC6674] Brockners, F., Gundavelli, S., Speicher, S., and D. Ward, 253 "Gateway-Initiated Dual-Stack Lite Deployment", RFC 6674, 254 July 2012. 256 [RFC6888] Perreault, S., Yamagata, I., Miyakawa, S., Nakagawa, A., 257 and H. Ashida, "Common Requirements for Carrier-Grade NATs 258 (CGNs)", BCP 127, RFC 6888, April 2013. 260 Authors' Addresses 262 Will(Shucheng) Liu 263 Huawei Technologies 264 Bantian, Longgang District 265 Shenzhen 518129 266 P.R. China 268 Email: liushucheng@huawei.com 270 Cathy Zhou 271 Huawei Technologies 272 Bantian, Longgang District 273 Shenzhen 518129 274 P.R. China 276 Email: cathy.zhou@huawei.com 277 Qiong Sun 278 China Telecom 279 No.118 Xizhimennei street, Xicheng District 280 Beijing 100035 281 P.R. China 283 Email: sunqiong@ctbri.com.cn 285 Guillaume Leclanche 286 Viagenie 287 246 Aberdeen 288 Quebec, QC G1R 2E1 289 Canada 291 Phone: +1 418 656 9254 292 Email: guillaume.leclanche@viagenie.ca