idnits 2.17.1 draft-chen-v6ops-nfv-ipv6-00.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 (October 27, 2014) is 3470 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 3315 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 3736 (Obsoleted by RFC 8415) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group G. Chen 3 Internet-Draft H. Deng 4 Intended status: Informational China Mobile 5 Expires: April 30, 2015 October 27, 2014 7 IPv6 Considerations for Network Function Virtualization (NFV) 8 draft-chen-v6ops-nfv-ipv6-00 10 Abstract 12 NFV adoption is gaining significant momentum, driven largely by the 13 need to improve service agility and reduce operational cost. IPv6 is 14 a fundamental feature should be enabled. This memo desribes the 15 layered NFV components and typical implementations. The IPv6 16 considerations have been elaborated to each component in order to 17 consoliate IPv6 demands across entire NFV system. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on April 30, 2015. 36 Copyright Notice 38 Copyright (c) 2014 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Overview on IPv6 Considerations in the NFV Architecture . . . 3 55 3. IPv6 Considerations on VIM . . . . . . . . . . . . . . . . . 4 56 4. IPv6 Considerations on Vitrual Network . . . . . . . . . . . 5 57 5. IPv6 considerations on Virtualisation Layer . . . . . . . . . 6 58 5.1. IPv6-enable Libvirt . . . . . . . . . . . . . . . . . . . 7 59 5.2. IPv6-enable KVM . . . . . . . . . . . . . . . . . . . . . 7 60 5.3. IPv6-enable Linux . . . . . . . . . . . . . . . . . . . . 7 61 6. IPv6 Considerations on Network Hardware . . . . . . . . . . . 7 62 7. IPv6 Considerations on VNF . . . . . . . . . . . . . . . . . 8 63 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 64 9. Security Considerations . . . . . . . . . . . . . . . . . . . 8 65 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 66 10.1. Normative References . . . . . . . . . . . . . . . . . . 8 67 10.2. Informative References . . . . . . . . . . . . . . . . . 8 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 70 1. Introduction 72 Network Virtualization Function (NFV) is a new trend for the telcom 73 industry revolution. It leverages IT infrastructure to take over the 74 telcom functions. Driven largely by the need to improve service 75 agility and reduce operational cost, virtualization has been adopted 76 in the NFV architecture. Server, storage, and network resources are 77 abstracted from their physical functions, e.g. processor, memory, I/O 78 controllers, disks, network and storage switches, etc, into pools of 79 functionality which can be managed functionally regardless of their 80 implementation or location. In other words, all servers, storage, 81 and network devices can be aggregated into independent pools of 82 resources to be used as needed, regardless of the actual 83 implementation of those resources. 85 Depending on the virtualization, NFV system gains good scalability. 86 However, this expansion also can't survive on the exhaunsting IPv4 87 address space. IPv6 is definitely the only way out to this pressing 88 needs, because the larger IP address space makes it easier to manage 89 large cloud infrastructures. The memo intends to enumurate IPv6 90 considerations regarding to the different components in the NFV 91 architecture. It's expected early adopters could reconsider the way 92 they design NFV cloud network so as to get more scalable and 93 manageable infrastructure. 95 2. Overview on IPv6 Considerations in the NFV Architecture 97 European Telecommunications Standards Institute (ETSI) has defined 98 the NFV architecure framework [GS_NFV_002]. NFV system has been 99 structured from three main working domain in the high-level framework 100 as shown in the Figure 1. 102 +-------------------------------------+ +---------+ 103 | Virtualised Network Functions(VNFs) | | NFV | 104 | +------+ +------+ +------+ | |Managment| 105 | | VNF | | VNF | ..... | VNF | | | and | 106 | +------+ +------+ +------+ | |Orchest | 107 +-------------------------------------+ |-ration | 108 +-------------------------------------+ | | 109 | NFV Infrastructure(NFVI) | | | 110 | +-------+ +-------+ +-------+ | | | 111 | |Virtual| |Virtual| |Virtual| | | | 112 | |Compute| |Storage| |Network| | | | 113 | +-------+ +-------+ +-------+ | | | 114 | +-------------------------------+ | | | 115 | | Virtualisation Layer | | | | 116 | +-------------------------------+ | | | 117 | Hardware Resource | | 118 | +--------+ +--------+ +--------+ | | | 119 | |Compute | |Storage | |Network | | | | 120 | |Hardware| |Hardware| |Hardware| | | | 121 | +--------+ +--------+ +--------+ | | | 122 +-------------------------------------+ +---------+ 124 Figure 1: High-Level NFV Framework 126 We try to document the effort made to enable IPv6 across all 127 components as illustrated in the overall NFV architecture. The 128 Figure 2 lists components, which should take specific considerations 129 to perform IPv6 functions. For each component, a typical 130 implementation has been exemplified. Those implementations are 131 leveraged towards the realization of IPv6-capable NFV system. 133 +---------------------------+--------------------------+ 134 | NFV Components |Implementations Instance | 135 +---------------------------+--------------------------+ 136 | VI Management | Openstack | 137 +---------------------------+--------------------------+ 138 | Virtual Network |OpenDayLight, OpenVSwitch | 139 +---------------------------+--------------------------+ 140 | Virtualisation Layer |KVM, Librvirt,Linux Kernel| 141 +---------------------------+--------------------------+ 142 | Network Hardware | DPDK | 143 +---------------------------+--------------------------+ 144 | VNF | OpenEPC | 145 +---------------------------+--------------------------+ 147 Figure 2: IPv6 Relevant NFV Components 149 3. IPv6 Considerations on VIM 151 Virtualised Infrastructure Management (VIM) comprises the 152 functionalities that are used to control and manage the interation of 153 a VNF with computing , storage and network resources under its 154 authority, as well as their virtualisation. We can clearly see 155 OpenStack gaining more and more traction. Openstack is comprosed by 156 several core projects, e.g., Compute (Nova), Network (Neutron), Image 157 (Glance), Object Storage (Swift) and Block Storage (Cinder) and etc. 158 The major concerns of IPv6 capability should be implemented into the 159 Neutron project. Neutron could offers sophisticated networking 160 functionality to coordinate network resources. Numerous IPv6 161 features could be merged into Neutron. 163 In general, Neutron is responsible for all topologies work in a 164 multi-tenant environment. IPv6 enable Neutron is able to allow IPv6 165 address static configuration and auto assignment. The internal IPv6 166 communications between Virtual Machines (VMs) and external IPv6 167 interconnection via Neutron and external router/border gateway should 168 be supported. The following considerations faciliate the IPv6 169 communications goals: 171 o Address Management: several IPv6 configuration modes such as SLAAC 172 [RFC4862] , DHCPv6 Stateless [RFC3736] and DHCPv6 Stateful 173 [RFC3315] are recommended to be supported. It includes the 174 ability for a user to create a port on a IPv6 subnet and assign a 175 specific IPv6 address or muliple IPv6 addresses to the port and 176 have it taken out the DHCP address pool. Prefix delegation is 177 also expected to be used to automatically configure neutron 178 routers with prefixes so that IPv6 prefixes are obtained and 179 renumbering can be done automatically. 181 o External IPv6 Interconnections: IPv6 subnet could be routed via 182 Layer 3 (L3) agent to an external IPv6 network. Both VLAN and 183 overlay (e.g. GRE, VXLAN) subnet attached to VMs can be used to 184 support multiple L3 agents for a given external network to support 185 scaling. Neutron scheduler could be used to assign virtual 186 routers to the L3 agents. Openstack takes the concept of floating 187 IP to allow internal servers to be accessed from external 188 networks. That is the normal cases in IPv4. Given the large 189 address space that IPv6 offers, the floating IP may be 190 unnecessary. End-to-end native IPv6 is more desirable than any of 191 the transition solutions. 193 o Floating IP: Floating IP is used in Openstack to make internal 194 servers to be accessible from external Internet. Floating IP 195 support for IPv6 Addresses could be used for internal IPv6 196 connecting to external IPv6. 198 o Security Group: security group is set to interrogate and/or 199 disallow IP flows. Full support for IPv6 TCP/UDP/ICMP in IPv6 200 security groups are necessary in a IPv6 environment. 202 o User Interfece and Command Line (CLI): it's important for users to 203 manipulate networks with IPv6 features. During the network, 204 subnet, router creation, it should have the option to allow user 205 to specify the type of address management they would like. This 206 includes the supports via Neutron API (Restful and CLI) as well as 207 via Openstack UI (i.e., Horizon). It's also esstential to enable 208 that feature to be able to specify Floating IPs via Neutron API 209 (restful and CLI) and control and manage all IPv6 security group 210 capabilities via Neutron/Nova API (restful and CLI) . 212 4. IPv6 Considerations on Vitrual Network 214 Virtual Networks is used to isolate resources and network overlays. 215 It could be orchestrated by Openstack Neutron to lign network 216 resources to be able to better address the requirements of rich 217 multi-tenant environments. In order to make system more scaleable, 218 Neutron adopts a plug-in model for various 3rd party components to 219 provide the networking service. New technologies (e.g., software- 220 defined networking (SDN)) are emerging to increase the flexibility 221 and agility of the network, decoupling the control from the 222 forwarding plane to make it easier to provision, automate and 223 orchestrate network services. The OpenDaylight provides a plugin and 224 a corresponding agent to enable integration with Neutron. IPv6 225 demands should also be considered in OpenDaylight softwares including 226 a pluggable controller, interfaces and applications. 228 The target of IPv6-enable OpenDaylight is to make the overlay and 229 underlay networks in the cloud architecture both being developed with 230 IPv6. The OpenDaylight project, like OpenFlow, is a good initiative 231 to accelarate the IPv6 transition. OpenFlow v1.3 could dynamically 232 learn the Layer 3 IPv6 hosts. This can be facilitated by supporting 233 the IPv6 Neighbor Discovery Protocol (NDP) or supporting DHCPv6. In 234 this case, the OpenDaylight controller should has the ability to 235 perform matching on IPv6 packets and pushes down a flow-table entry 236 to each of the edge devices enabling the forwarding of these packets 237 up to the controller or application to process. 239 Each of the underlay devices would need to support the optional IPv6 240 features of OpenFlow and support the required combinations of match/ 241 action on the IPv6 header. This also includes the ability to support 242 masking of address fields. Open vSwitch (OVS) is a typical effort to 243 enable the IPv6 process with the overwhelming superiority, such as 244 flexible controller in user-space and fast datapath in kernel. A 245 IPv6-enable vSwitch should be able to support IPv6 flows via 246 OpenFlow. The flow could be identified by the combination of any 247 IPv6 features, such as IPv6 ND target, IPv6 source address or IPv6 248 destination address. The implementation of OVS would the dedicated 249 IPv6 module to enable IPv6 forwarding. 251 5. IPv6 considerations on Virtualisation Layer 253 The virtualisation layer abstracts the hardware resources and 254 decouples the VNF software from the underlying harware. It enables 255 the software that implements the VNF to use the underlying 256 virtualised infrasturecture. Typically, this type of functionality 257 is provided for computing and storage resources in the form of 258 hypervisors. In order to facilitate the management of different 259 kinds of hypervisors, libvirt virtualization API is created to 260 provide management tool for managing platform virtualization. The 261 Figure 3 elaborates the relations of different components in 262 virtualisation layer. The sub-section will describe the detailed 263 consideration for each one. 265 +--------------------------------------+ 266 | VIM(e.g., Openstack) | 267 +--------------------------------------+ 268 | Libvirt API | 269 +--------------------------------------+ 270 | KVM | Xen | ESX | others... | 271 +--------------------------------------+ 272 | Linux OS | Others .... | 273 +--------------------------------------+ 275 Figure 3: Virtualisation Layer Components 277 5.1. IPv6-enable Libvirt 279 Libvirt could provide a common and stable layer sufficient to 280 securely manage VNF instances. libvirt provides all APIs needed to do 281 the management, such as provision, create, modify, monitor, control, 282 migrate and stop the instances. IPv6 network configurations can be 283 enabled by the libvirt networking APIs, which is formulated by 284 network XML format. Libvirt define network profile from different 285 elements including general metadata, connectivity and addressing. To 286 enable IPv6, each attributes shoule be configured properly. For the 287 IPv6 addressing, Libvirt could take SLAAC as default and optionally 288 enable DHCP services. Libvirt could configure static routes for IPv6 289 forwarding, but lack of supports for dynamic routing protocol. 291 5.2. IPv6-enable KVM 293 KVM should provied same operations cooresponding to Libvirt. It may 294 be straight forward to enable IPv6 on KVM guests by configure the 295 host machine and interfaces with IPv6 address. The necessary 296 firewall rules could be also added to ip6tables on the host machine. 297 NDIS driver in KVM also should be able to handle the IPv6 packages. 299 5.3. IPv6-enable Linux 301 Linux system should have to enable the IPv6 support in the kernel. 302 Some interface configuration file should add IPv6 address information 303 and restart the networking. Other consideration is the MTU setting. 304 The MTU size of the NIC on Linxu defaults to 1500 bytes. It may be 305 good to support Jumbo frames in the cloud infrastructure. Large MTU 306 size not only gives you better network performance, but also provides 307 you with workaround for software issues. It has been observed that 308 many IPv6 packeges may exceed 1500-bytes. Therefore, it's very 309 important to enable jumbo frames to avoid the corruption. 311 6. IPv6 Considerations on Network Hardware 313 Network hardware is capable of high-performance packet processing. 314 There are optimized data plane solutions for the IP package 315 processing. The Intel Data Plane Development Kit (DPDK) is a set of 316 optimized software libraries and drivers, that enable high- 317 performance data plane on network elements. The IPv6 demands to DPDK 318 are targeted to support IPv6 forwarding, including IPv6 fragmentation 319 reassembly. For the fast path, it would support IPv6 exact match 320 flow classification. 322 7. IPv6 Considerations on VNF 324 The traditional mobile node functions would gradually be migrated to 325 Vitrual Network Function (VNF). Examples of VNF are 3GPP Evolved 326 Packet Core (EPC) network elements, e.g., Mobility Managment Entity 327 (MME), Serving Gateway (SGW), Packet Data Network Gateway (PGW). VNF 328 may remodel the network node functions into the different instances. 329 For examples, the IPv6 relevant functions of SGW/PGW include PDN 330 signaling processing, IPv6 data-plane filtering, classification, 331 forwarding and IPv6 Charging control. Those IPv6 processing should 332 also be supported in the new-built VNF instances. 334 8. IANA Considerations 336 This document makes no request of IANA. 338 9. Security Considerations 340 TBD 342 10. References 344 10.1. Normative References 346 [GS_NFV_002] 347 European Telecommunications Standards Institute, ETSI., 348 "Network Functions Virtualisation (NFV); Architectural 349 Framework", March 2009. 351 10.2. Informative References 353 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 354 and M. Carney, "Dynamic Host Configuration Protocol for 355 IPv6 (DHCPv6)", RFC 3315, July 2003. 357 [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol 358 (DHCP) Service for IPv6", RFC 3736, April 2004. 360 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 361 Address Autoconfiguration", RFC 4862, September 2007. 363 Authors' Addresses 364 Gang Chen 365 China Mobile 366 53A,Xibianmennei Ave., 367 Xuanwu District, 368 Beijing 100053 369 China 371 Email: phdgang@gmail.com 373 Hui Deng 374 China Mobile 375 53A,Xibianmennei Ave., 376 Xuanwu District, 377 Beijing 100053 378 China 380 Email: denghui@chinamobile.com