Internet DRAFT - draft-chen-v6ops-nfv-ipv6
draft-chen-v6ops-nfv-ipv6
Network Working Group G. Chen
Internet-Draft H. Deng
Intended status: Informational China Mobile
Expires: April 30, 2015 October 27, 2014
IPv6 Considerations for Network Function Virtualization (NFV)
draft-chen-v6ops-nfv-ipv6-00
Abstract
NFV adoption is gaining significant momentum, driven largely by the
need to improve service agility and reduce operational cost. IPv6 is
a fundamental feature should be enabled. This memo desribes the
layered NFV components and typical implementations. The IPv6
considerations have been elaborated to each component in order to
consoliate IPv6 demands across entire NFV system.
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 30, 2015.
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
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
Chen & Deng Expires April 30, 2015 [Page 1]
Internet-Draft NFV-IPv6 October 2014
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Overview on IPv6 Considerations in the NFV Architecture . . . 3
3. IPv6 Considerations on VIM . . . . . . . . . . . . . . . . . 4
4. IPv6 Considerations on Vitrual Network . . . . . . . . . . . 5
5. IPv6 considerations on Virtualisation Layer . . . . . . . . . 6
5.1. IPv6-enable Libvirt . . . . . . . . . . . . . . . . . . . 7
5.2. IPv6-enable KVM . . . . . . . . . . . . . . . . . . . . . 7
5.3. IPv6-enable Linux . . . . . . . . . . . . . . . . . . . . 7
6. IPv6 Considerations on Network Hardware . . . . . . . . . . . 7
7. IPv6 Considerations on VNF . . . . . . . . . . . . . . . . . 8
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
9. Security Considerations . . . . . . . . . . . . . . . . . . . 8
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
10.1. Normative References . . . . . . . . . . . . . . . . . . 8
10.2. Informative References . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction
Network Virtualization Function (NFV) is a new trend for the telcom
industry revolution. It leverages IT infrastructure to take over the
telcom functions. Driven largely by the need to improve service
agility and reduce operational cost, virtualization has been adopted
in the NFV architecture. Server, storage, and network resources are
abstracted from their physical functions, e.g. processor, memory, I/O
controllers, disks, network and storage switches, etc, into pools of
functionality which can be managed functionally regardless of their
implementation or location. In other words, all servers, storage,
and network devices can be aggregated into independent pools of
resources to be used as needed, regardless of the actual
implementation of those resources.
Depending on the virtualization, NFV system gains good scalability.
However, this expansion also can't survive on the exhaunsting IPv4
address space. IPv6 is definitely the only way out to this pressing
needs, because the larger IP address space makes it easier to manage
large cloud infrastructures. The memo intends to enumurate IPv6
considerations regarding to the different components in the NFV
architecture. It's expected early adopters could reconsider the way
they design NFV cloud network so as to get more scalable and
manageable infrastructure.
Chen & Deng Expires April 30, 2015 [Page 2]
Internet-Draft NFV-IPv6 October 2014
2. Overview on IPv6 Considerations in the NFV Architecture
European Telecommunications Standards Institute (ETSI) has defined
the NFV architecure framework [GS_NFV_002]. NFV system has been
structured from three main working domain in the high-level framework
as shown in the Figure 1.
+-------------------------------------+ +---------+
| Virtualised Network Functions(VNFs) | | NFV |
| +------+ +------+ +------+ | |Managment|
| | VNF | | VNF | ..... | VNF | | | and |
| +------+ +------+ +------+ | |Orchest |
+-------------------------------------+ |-ration |
+-------------------------------------+ | |
| NFV Infrastructure(NFVI) | | |
| +-------+ +-------+ +-------+ | | |
| |Virtual| |Virtual| |Virtual| | | |
| |Compute| |Storage| |Network| | | |
| +-------+ +-------+ +-------+ | | |
| +-------------------------------+ | | |
| | Virtualisation Layer | | | |
| +-------------------------------+ | | |
| Hardware Resource | |
| +--------+ +--------+ +--------+ | | |
| |Compute | |Storage | |Network | | | |
| |Hardware| |Hardware| |Hardware| | | |
| +--------+ +--------+ +--------+ | | |
+-------------------------------------+ +---------+
Figure 1: High-Level NFV Framework
We try to document the effort made to enable IPv6 across all
components as illustrated in the overall NFV architecture. The
Figure 2 lists components, which should take specific considerations
to perform IPv6 functions. For each component, a typical
implementation has been exemplified. Those implementations are
leveraged towards the realization of IPv6-capable NFV system.
Chen & Deng Expires April 30, 2015 [Page 3]
Internet-Draft NFV-IPv6 October 2014
+---------------------------+--------------------------+
| NFV Components |Implementations Instance |
+---------------------------+--------------------------+
| VI Management | Openstack |
+---------------------------+--------------------------+
| Virtual Network |OpenDayLight, OpenVSwitch |
+---------------------------+--------------------------+
| Virtualisation Layer |KVM, Librvirt,Linux Kernel|
+---------------------------+--------------------------+
| Network Hardware | DPDK |
+---------------------------+--------------------------+
| VNF | OpenEPC |
+---------------------------+--------------------------+
Figure 2: IPv6 Relevant NFV Components
3. IPv6 Considerations on VIM
Virtualised Infrastructure Management (VIM) comprises the
functionalities that are used to control and manage the interation of
a VNF with computing , storage and network resources under its
authority, as well as their virtualisation. We can clearly see
OpenStack gaining more and more traction. Openstack is comprosed by
several core projects, e.g., Compute (Nova), Network (Neutron), Image
(Glance), Object Storage (Swift) and Block Storage (Cinder) and etc.
The major concerns of IPv6 capability should be implemented into the
Neutron project. Neutron could offers sophisticated networking
functionality to coordinate network resources. Numerous IPv6
features could be merged into Neutron.
In general, Neutron is responsible for all topologies work in a
multi-tenant environment. IPv6 enable Neutron is able to allow IPv6
address static configuration and auto assignment. The internal IPv6
communications between Virtual Machines (VMs) and external IPv6
interconnection via Neutron and external router/border gateway should
be supported. The following considerations faciliate the IPv6
communications goals:
o Address Management: several IPv6 configuration modes such as SLAAC
[RFC4862] , DHCPv6 Stateless [RFC3736] and DHCPv6 Stateful
[RFC3315] are recommended to be supported. It includes the
ability for a user to create a port on a IPv6 subnet and assign a
specific IPv6 address or muliple IPv6 addresses to the port and
have it taken out the DHCP address pool. Prefix delegation is
also expected to be used to automatically configure neutron
routers with prefixes so that IPv6 prefixes are obtained and
renumbering can be done automatically.
Chen & Deng Expires April 30, 2015 [Page 4]
Internet-Draft NFV-IPv6 October 2014
o External IPv6 Interconnections: IPv6 subnet could be routed via
Layer 3 (L3) agent to an external IPv6 network. Both VLAN and
overlay (e.g. GRE, VXLAN) subnet attached to VMs can be used to
support multiple L3 agents for a given external network to support
scaling. Neutron scheduler could be used to assign virtual
routers to the L3 agents. Openstack takes the concept of floating
IP to allow internal servers to be accessed from external
networks. That is the normal cases in IPv4. Given the large
address space that IPv6 offers, the floating IP may be
unnecessary. End-to-end native IPv6 is more desirable than any of
the transition solutions.
o Floating IP: Floating IP is used in Openstack to make internal
servers to be accessible from external Internet. Floating IP
support for IPv6 Addresses could be used for internal IPv6
connecting to external IPv6.
o Security Group: security group is set to interrogate and/or
disallow IP flows. Full support for IPv6 TCP/UDP/ICMP in IPv6
security groups are necessary in a IPv6 environment.
o User Interfece and Command Line (CLI): it's important for users to
manipulate networks with IPv6 features. During the network,
subnet, router creation, it should have the option to allow user
to specify the type of address management they would like. This
includes the supports via Neutron API (Restful and CLI) as well as
via Openstack UI (i.e., Horizon). It's also esstential to enable
that feature to be able to specify Floating IPs via Neutron API
(restful and CLI) and control and manage all IPv6 security group
capabilities via Neutron/Nova API (restful and CLI) .
4. IPv6 Considerations on Vitrual Network
Virtual Networks is used to isolate resources and network overlays.
It could be orchestrated by Openstack Neutron to lign network
resources to be able to better address the requirements of rich
multi-tenant environments. In order to make system more scaleable,
Neutron adopts a plug-in model for various 3rd party components to
provide the networking service. New technologies (e.g., software-
defined networking (SDN)) are emerging to increase the flexibility
and agility of the network, decoupling the control from the
forwarding plane to make it easier to provision, automate and
orchestrate network services. The OpenDaylight provides a plugin and
a corresponding agent to enable integration with Neutron. IPv6
demands should also be considered in OpenDaylight softwares including
a pluggable controller, interfaces and applications.
Chen & Deng Expires April 30, 2015 [Page 5]
Internet-Draft NFV-IPv6 October 2014
The target of IPv6-enable OpenDaylight is to make the overlay and
underlay networks in the cloud architecture both being developed with
IPv6. The OpenDaylight project, like OpenFlow, is a good initiative
to accelarate the IPv6 transition. OpenFlow v1.3 could dynamically
learn the Layer 3 IPv6 hosts. This can be facilitated by supporting
the IPv6 Neighbor Discovery Protocol (NDP) or supporting DHCPv6. In
this case, the OpenDaylight controller should has the ability to
perform matching on IPv6 packets and pushes down a flow-table entry
to each of the edge devices enabling the forwarding of these packets
up to the controller or application to process.
Each of the underlay devices would need to support the optional IPv6
features of OpenFlow and support the required combinations of match/
action on the IPv6 header. This also includes the ability to support
masking of address fields. Open vSwitch (OVS) is a typical effort to
enable the IPv6 process with the overwhelming superiority, such as
flexible controller in user-space and fast datapath in kernel. A
IPv6-enable vSwitch should be able to support IPv6 flows via
OpenFlow. The flow could be identified by the combination of any
IPv6 features, such as IPv6 ND target, IPv6 source address or IPv6
destination address. The implementation of OVS would the dedicated
IPv6 module to enable IPv6 forwarding.
5. IPv6 considerations on Virtualisation Layer
The virtualisation layer abstracts the hardware resources and
decouples the VNF software from the underlying harware. It enables
the software that implements the VNF to use the underlying
virtualised infrasturecture. Typically, this type of functionality
is provided for computing and storage resources in the form of
hypervisors. In order to facilitate the management of different
kinds of hypervisors, libvirt virtualization API is created to
provide management tool for managing platform virtualization. The
Figure 3 elaborates the relations of different components in
virtualisation layer. The sub-section will describe the detailed
consideration for each one.
+--------------------------------------+
| VIM(e.g., Openstack) |
+--------------------------------------+
| Libvirt API |
+--------------------------------------+
| KVM | Xen | ESX | others... |
+--------------------------------------+
| Linux OS | Others .... |
+--------------------------------------+
Figure 3: Virtualisation Layer Components
Chen & Deng Expires April 30, 2015 [Page 6]
Internet-Draft NFV-IPv6 October 2014
5.1. IPv6-enable Libvirt
Libvirt could provide a common and stable layer sufficient to
securely manage VNF instances. libvirt provides all APIs needed to do
the management, such as provision, create, modify, monitor, control,
migrate and stop the instances. IPv6 network configurations can be
enabled by the libvirt networking APIs, which is formulated by
network XML format. Libvirt define network profile from different
elements including general metadata, connectivity and addressing. To
enable IPv6, each attributes shoule be configured properly. For the
IPv6 addressing, Libvirt could take SLAAC as default and optionally
enable DHCP services. Libvirt could configure static routes for IPv6
forwarding, but lack of supports for dynamic routing protocol.
5.2. IPv6-enable KVM
KVM should provied same operations cooresponding to Libvirt. It may
be straight forward to enable IPv6 on KVM guests by configure the
host machine and interfaces with IPv6 address. The necessary
firewall rules could be also added to ip6tables on the host machine.
NDIS driver in KVM also should be able to handle the IPv6 packages.
5.3. IPv6-enable Linux
Linux system should have to enable the IPv6 support in the kernel.
Some interface configuration file should add IPv6 address information
and restart the networking. Other consideration is the MTU setting.
The MTU size of the NIC on Linxu defaults to 1500 bytes. It may be
good to support Jumbo frames in the cloud infrastructure. Large MTU
size not only gives you better network performance, but also provides
you with workaround for software issues. It has been observed that
many IPv6 packeges may exceed 1500-bytes. Therefore, it's very
important to enable jumbo frames to avoid the corruption.
6. IPv6 Considerations on Network Hardware
Network hardware is capable of high-performance packet processing.
There are optimized data plane solutions for the IP package
processing. The Intel Data Plane Development Kit (DPDK) is a set of
optimized software libraries and drivers, that enable high-
performance data plane on network elements. The IPv6 demands to DPDK
are targeted to support IPv6 forwarding, including IPv6 fragmentation
reassembly. For the fast path, it would support IPv6 exact match
flow classification.
Chen & Deng Expires April 30, 2015 [Page 7]
Internet-Draft NFV-IPv6 October 2014
7. IPv6 Considerations on VNF
The traditional mobile node functions would gradually be migrated to
Vitrual Network Function (VNF). Examples of VNF are 3GPP Evolved
Packet Core (EPC) network elements, e.g., Mobility Managment Entity
(MME), Serving Gateway (SGW), Packet Data Network Gateway (PGW). VNF
may remodel the network node functions into the different instances.
For examples, the IPv6 relevant functions of SGW/PGW include PDN
signaling processing, IPv6 data-plane filtering, classification,
forwarding and IPv6 Charging control. Those IPv6 processing should
also be supported in the new-built VNF instances.
8. IANA Considerations
This document makes no request of IANA.
9. Security Considerations
TBD
10. References
10.1. Normative References
[GS_NFV_002]
European Telecommunications Standards Institute, ETSI.,
"Network Functions Virtualisation (NFV); Architectural
Framework", March 2009.
10.2. Informative References
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
and M. Carney, "Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol
(DHCP) Service for IPv6", RFC 3736, April 2004.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862, September 2007.
Authors' Addresses
Chen & Deng Expires April 30, 2015 [Page 8]
Internet-Draft NFV-IPv6 October 2014
Gang Chen
China Mobile
53A,Xibianmennei Ave.,
Xuanwu District,
Beijing 100053
China
Email: phdgang@gmail.com
Hui Deng
China Mobile
53A,Xibianmennei Ave.,
Xuanwu District,
Beijing 100053
China
Email: denghui@chinamobile.com
Chen & Deng Expires April 30, 2015 [Page 9]
