Internet DRAFT - draft-liu-openv6-architecture
draft-liu-openv6-architecture
Network Working Group W. Liu
Internet-Draft C. Zhou
Intended status: Informational Huawei Technologies
Expires: August 18, 2014 Q. Sun
China Telecom
G. Leclanche
Viagenie
February 14, 2014
Openv6 Architecture for IPv6 Deployment
draft-liu-openv6-architecture-01
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 August 18, 2014.
Copyright Notice
Copyright (c) 2014 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
Liu, et al. Expires August 18, 2014 [Page 1]
Internet-Draft Openv6 Architecture for IPv6 Deployment February 2014
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
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 . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Motivation for OpenV6 Architecture . . . . . . . . . . . . . 3
4. Overview of the OpenV6 Architecture . . . . . . . . . . . . . 4
5. OpenV6 Considerations . . . . . . . . . . . . . . . . . . . . 5
6. Manageability Considerations . . . . . . . . . . . . . . . . 5
7. Security Considerations . . . . . . . . . . . . . . . . . . . 5
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
10.1. Normative References . . . . . . . . . . . . . . . . . . 6
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.
Liu, et al. Expires August 18, 2014 [Page 2]
Internet-Draft Openv6 Architecture for IPv6 Deployment February 2014
2. Terminology
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.
Liu, et al. Expires August 18, 2014 [Page 3]
Internet-Draft Openv6 Architecture for IPv6 Deployment February 2014
4. Overview of the OpenV6 Architecture
This section gives an overview of the architecture of the Openv6.
The figure in Figure 1 shows the basic architecture of Openv6.
+------------------------+
| Applications |
| (OSS,3rd-APPs, |
| security service, |
| v6 trans service,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.
Liu, et al. Expires August 18, 2014 [Page 4]
Internet-Draft Openv6 Architecture for IPv6 Deployment February 2014
A server that runs vRouter or vSwitch.
A CGN that runs NAT, Tunnel En/De-capsulation functions.
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.
Applications: A network application that needs to manipulate the
network to achieve its service requirements. Various IPv6 related
services can be enabled by corresponding Applications such as:
OSS: can be considered as an application;
3rd-party APPs: IPv6 based 3rd-party applications;
Network security service: security related services such as savi
IPv6 transition service: 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
Liu, et al. Expires August 18, 2014 [Page 5]
Internet-Draft Openv6 Architecture for IPv6 Deployment February 2014
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.
10.2. Informative References
[Google-IPv6-Statistics]
Google, "Google IPv6 Statistics", <http://www.google.com/
ipv6/statistics.html#tab=ipv6-adoption>.
[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
Liu, et al. Expires August 18, 2014 [Page 6]
Internet-Draft Openv6 Architecture for IPv6 Deployment February 2014
Qiong Sun
China Telecom
No.118 Xizhimennei street, Xicheng District
Beijing 100035
P.R. China
Email: sunqiong@ctbri.com.cn
Guillaume Leclanche
Viagenie
246 Aberdeen
Quebec, QC G1R 2E1
Canada
Phone: +1 418 656 9254
Email: guillaume.leclanche@viagenie.ca
Liu, et al. Expires August 18, 2014 [Page 7]