idnits 2.17.1 draft-baker-openstack-ipv6-model-02.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 : ---------------------------------------------------------------------------- == There are 1 instance of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (February 8, 2015) is 3363 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) == Outdated reference: A later version (-01) exists of draft-baker-ipv6-isis-dst-flowlabel-routing-00 == Outdated reference: A later version (-03) exists of draft-baker-ipv6-ospf-dst-flowlabel-routing-02 == Outdated reference: A later version (-16) exists of draft-ietf-6man-default-iids-01 == Outdated reference: A later version (-23) exists of draft-ietf-ospf-ospfv3-lsa-extend-03 == Outdated reference: A later version (-34) exists of draft-ietf-savi-dhcp-26 == Outdated reference: A later version (-03) exists of draft-ietf-v6ops-siit-dc-00 == Outdated reference: A later version (-08) exists of draft-previdi-6man-segment-routing-header-04 -- Obsolete informational reference (is this intentional?): RFC 1981 (Obsoleted by RFC 8201) -- Obsolete informational reference (is this intentional?): RFC 3697 (Obsoleted by RFC 6437) -- Obsolete informational reference (is this intentional?): RFC 4601 (Obsoleted by RFC 7761) -- Obsolete informational reference (is this intentional?): RFC 4941 (Obsoleted by RFC 8981) -- Obsolete informational reference (is this intentional?): RFC 6145 (Obsoleted by RFC 7915) Summary: 1 error (**), 0 flaws (~~), 10 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group F. Baker, Ed. 3 Internet-Draft C. Marino 4 Intended status: Informational I. Wells 5 Expires: August 12, 2015 R. Agarwalla 6 S. Jeuk 7 G. Salgueiro 8 Cisco Systems 9 February 8, 2015 11 A Model for IPv6 Operation in OpenStack 12 draft-baker-openstack-ipv6-model-02 14 Abstract 16 This is an overview of a network model for OpenStack, designed to 17 dramatically simplify scalable network deployment and operations. 19 Requirements Language 21 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 22 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 'OPTIONAL' in this 23 document are to be interpreted as described in [RFC2119]. 25 Design Principle 27 Perfection is achieved, not when there is nothing more to add, but 28 when there is nothing left to take away. 30 Antoine de Saint-Exupery 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at http://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on August 12, 2015. 49 Copyright Notice 51 Copyright (c) 2015 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 67 1.1. What is OpenStack? . . . . . . . . . . . . . . . . . . . 3 68 1.2. OpenStack Scaling Issues . . . . . . . . . . . . . . . . 4 69 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 5 70 2.1. Design approach . . . . . . . . . . . . . . . . . . . . . 5 71 2.2. Multiple Data Centers . . . . . . . . . . . . . . . . . . 6 72 2.3. Large Data Centers . . . . . . . . . . . . . . . . . . . 6 73 2.4. Multi-tenancy . . . . . . . . . . . . . . . . . . . . . . 6 74 2.5. Isolation . . . . . . . . . . . . . . . . . . . . . . . . 6 75 2.5.1. Inter-tenant isolation . . . . . . . . . . . . . . . 6 76 2.5.2. Intra-tenant isolation . . . . . . . . . . . . . . . 7 77 2.6. Operational Simplicity . . . . . . . . . . . . . . . . . 7 78 2.7. Address space . . . . . . . . . . . . . . . . . . . . . . 7 79 2.8. Data Center Federation . . . . . . . . . . . . . . . . . 7 80 2.9. Path MTU Issues . . . . . . . . . . . . . . . . . . . . . 7 81 3. Models . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 82 3.1. Configuration Model . . . . . . . . . . . . . . . . . . . 8 83 3.2. Data Center Model . . . . . . . . . . . . . . . . . . . . 8 84 3.2.1. Tenant Address Model . . . . . . . . . . . . . . . . 9 85 3.2.2. Use of Global Addresses by the Data Center . . . . . 13 86 3.3. Inter-tenant security services . . . . . . . . . . . . . 13 87 3.4. IPv6 Tenant Isolation using the Label . . . . . . . . . . 14 88 3.5. Isolation in Routing . . . . . . . . . . . . . . . . . . 14 89 4. BCP 38 Ingress Filtering . . . . . . . . . . . . . . . . . . 15 90 5. Moving virtual machines . . . . . . . . . . . . . . . . . . . 15 91 5.1. Recreation of the VM . . . . . . . . . . . . . . . . . . 16 92 5.2. Live Migration of a Running Virtual Machine . . . . . . . 16 93 6. OpenStack implications . . . . . . . . . . . . . . . . . . . 18 94 6.1. Configuration implications . . . . . . . . . . . . . . . 18 95 6.2. vSwitch implications . . . . . . . . . . . . . . . . . . 18 96 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 97 8. Security Considerations . . . . . . . . . . . . . . . . . . . 19 98 9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 19 99 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 100 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 20 101 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 102 12.1. Normative References . . . . . . . . . . . . . . . . . . 20 103 12.2. Informative References . . . . . . . . . . . . . . . . . 20 104 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 24 105 Appendix B. Alternative Labels considered . . . . . . . . . . . 24 106 B.1. IPv6 Flow Label . . . . . . . . . . . . . . . . . . . . . 24 107 B.1.1. Metaconsiderations . . . . . . . . . . . . . . . . . 25 108 B.2. Federated Identity . . . . . . . . . . . . . . . . . . . 25 109 B.2.1. Introduction . . . . . . . . . . . . . . . . . . . . 25 110 B.2.2. Federated identity Option . . . . . . . . . . . . . . 26 111 B.2.3. Metaconsiderations . . . . . . . . . . . . . . . . . 28 112 B.3. Universal Cloud Classification . . . . . . . . . . . . . 29 113 B.3.1. Introduction . . . . . . . . . . . . . . . . . . . . 29 114 B.3.2. Universal Cloud Classification Options . . . . . . . 30 115 B.3.3. UCC Extension Header . . . . . . . . . . . . . . . . 30 116 B.4. Policy List in Segment Routing Header . . . . . . . . . . 31 117 B.4.1. Metaconsiderations . . . . . . . . . . . . . . . . . 31 118 B.5. RFC 4291 Interface Identifier (IID) . . . . . . . . . . . 32 119 B.5.1. Address Format . . . . . . . . . . . . . . . . . . . 32 120 B.5.2. Metaconsiderations . . . . . . . . . . . . . . . . . 34 121 B.6. Modified IID using modified Privacy Extension . . . . . . 36 122 B.6.1. Metaconsiderations . . . . . . . . . . . . . . . . . 36 123 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37 125 1. Introduction 127 OpenStack, and its issues. 129 1.1. What is OpenStack? 131 OpenStack is a cloud computing orchestration solution developed using 132 an open source community process. It consists of a collection of 133 'projects', each implementing the creation, control, and 134 administration of tenant resources. There are separate OpenStack 135 projects for managing compute, storage and network resources. 137 Neutron is the project that manages OpenStack networking. It exposes 138 a northbound API to the other OpenStack projects for programmatic 139 control over tenant network connectivity. The southbound interface 140 is implemented as one or more device driver plugins that are built to 141 interact with specific devices in the network. This approach 142 provides the flexibility to deploy OpenStack networking using a range 143 of alternative techniques. 145 An OpenStack tenant, in the Kilo and earlier releases, is required to 146 create what OpenStack identifies as a 'Neutron Network' connecting 147 their virtual machines. This Network is instantiated via the plugins 148 as either a layer 2 network, a layer 3 network, or as an overlay 149 network. The actual implementation is unknown to the tenant. The 150 technology used to provide these networks is selected by the 151 OpenStack operator based upon the requirements of the cloud 152 deployment. 154 The tenant also is required, in the Kilo and earlier releases, to 155 specify an 'IP Subnet' for each Network. This specification is made 156 by providing a CIDR prefix for IPv4 address allocation via DHCP or 157 for IPv6 address allocation via DHCP or SLAAC. This address range 158 may be from within the address range of the datacenter (non- 159 overlapping), or overlapping [RFC1918] addresses. Tenants may create 160 multiple Networks, each with its own Subnet. 162 An OpenStack Subnet is a logical layer 2 network and requires layer 3 163 routing for packets to exit the Subnet. This is achieved by 164 attaching the Subnet to a Neutron Router. The Neutron router 165 implements Network Address Translation for external traffic from 166 tenant networks as well for providing connectivity to tenant networks 167 from the outside. Using Linux utilities, OpenStack can support 168 overlapping RFC 1918 addresses between tenants. 170 OpenStack Subnets are typically implemented as VLANs in a datacenter. 171 When tenant scalability requirement grow large, an overlay approach 172 is typically used. Because of the difficulties in scaling and 173 administering large layer 2 and/or overlay networks, some OpenStack 174 integrations chose not to provide isolated Subnets and simply offer 175 tenants a layer 3 based network alternative. 177 OpenStack uses Layer 3 and Layer 2 Linux utilities on hosts to 178 provide protection against IP/MAC spoofing and ARP poisoning. 180 1.2. OpenStack Scaling Issues 182 One of the fundamental requirements of OpenStack Networking (Neutron) 183 is to provide scalable, isolated tenant networks. Today this is 184 achieved via L2 segmentation using either a) standard 802.1Q VLANs or 185 b) an overlay approach based on one of several L2 over L3 186 encapsulation techniques available today such as 802.1ad, VXLAN, STT 187 or NVGRE. 189 However, these approaches still struggle to provide scalable, 190 transparent, manageable, high performance, isolated tenant networks. 191 VLAN's don't scale beyond 4096 (2^12) networks and have complex 192 trunking requirements when tenants span host and racks. IEEE 802.1ad 193 (QinQ) partially solves that, but adds another limit - at most 2^12 194 tenants, each of which may have 2^12 VLANs. IP Encapsulation 195 introduces additional complexity on host computers running 196 hypervisors as well as impact performance of tenant applications 197 running on virtual machines. Overlay based isolation techniques may 198 also impair traditional network monitoring and performance management 199 tools. Moreover, when these isolated (L2) networks require external 200 access to other networks or the public Internet, they require even 201 more complex solutions to accommodate overlapping IP prefixes and 202 network address translation (NAT). 204 As more capabilities are built on to these layer 2 based 'virtual' 205 networks, complexity continues to grow. 207 This draft presents a new Layer 3 based approach to OpenStack 208 networking using IPv6 that can be deployed natively on IPv6 networks. 209 It will be shown that this approach can provide tenant isolation 210 without the limitations of existing alternatives, as well as deliver 211 high performance networks transparently using a simplified tenant 212 network connectivity model, without the overhead of encapsulation or 213 managing overlapping IP addresses and address translations. We note 214 that some large content providers, notably Google and Facebook 215 [FaceBook-IPv6], are going in exactly this direction. 217 2. Requirements 219 In this section, we attempt to list critical requirements. 221 2.1. Design approach 223 As a design approach, we presume an IPv6-only data center in a world 224 that might have IPv4 or IPv6 clients outside of it. This design 225 explicitly does not depend on VLANs, QinQ, VXLAN, MPLS, Segment 226 Routing, LISP, IP/IP or GRE tunnels, or any other supporting 227 encapsulation. Data center operators remain free to use any of those 228 tools, but they are not required. If we can do everything required 229 for OpenStack networking with IPv6 alone, these other networking 230 technologies may be used as optimizations. If we are unable to 231 satisfy the OpenStack requirements that also is something we wish to 232 know and understand. 234 OpenStack is designed to be used by many cloud users or 'tenants'. 235 Scalable, secure and isolated tenant networks are a requirement for 236 building a multi-tenant cloud datacenter. The OpenStack 237 administrator/operator can design and configure a cloud environment 238 to provide network isolation using the approach described in this 239 document, alone, or in combination with any of the above network 240 technologies . However, all the details of the underlying technology 241 and implementation details are completely transparent to the tenant 242 itself. 244 2.2. Multiple Data Centers 246 A common requirement in network and data center operations is 247 reliability, serviceability, and maintainability of their operations 248 in the presence of an outage. At minimum, this implies multihoming 249 in the sense of having multiple upstream ISPs; in many cases, it also 250 implies multiple and at times duplicate data centers, and tenants 251 stretched or able to be readily moved or recreated across multiple 252 data centers. 254 2.3. Large Data Centers 256 Microsoft Azure [Microsoft-Azure] has purchased a 100 acre piece of 257 land for the construction of a single data center. In terms of 258 physical space, that is enough for a data center with about half a 259 million 19' RETMA racks. 261 With even modest virtual machine density, infrastructure at this 262 scale easily exhausts the 16M available RFC 1918 private addresses 263 (i.e. 10.0.0.0/8) and explains the recent efforts by webscale cloud 264 providers to deploy IPv6 throughout their new datacenters. 266 2.4. Multi-tenancy 268 While it is possible that a single tenant would require a 100 acre 269 data center, it would be unusual. In most such data centers, one 270 would expect a large number of tenants. 272 2.5. Isolation 274 Isolation is required between tenants, and at times between tenants 275 hierarchically related to larger tenants. 277 2.5.1. Inter-tenant isolation 279 A 'tenant' is defined as a set of resources under common 280 administrative control. It may be appropriate for tenants to 281 communicate with each other within the context of an application or 282 relationships among their owners or operators. However, unless 283 specified otherwise, tenants are intended to operate as if they were 284 on their own company's premises and be isolated from one another. 286 2.5.2. Intra-tenant isolation 288 There are often security compartments within a corporate network, 289 just as there are security barriers between companies. As a result, 290 there is a recursive isolation requirement: it must be possible to 291 isolate an identified part of a tenant (which we also think of as a 292 tenant) from another part of the same tenant. 294 2.6. Operational Simplicity 296 To the extent possible (and, for operators, the concept will bring a 297 smile), operation of a multi-location multi-tenant data center, and 298 the design of an application that runs in one, should be simple and 299 uncoupled. 301 As discussed in [RFC3439], this requires that the operational model 302 required to support a tenant with only two physical machines, or 303 virtual machines in the same physical chassis, should be the same as 304 that required to support a tenant running a million machines in a 305 federated multiple data center application. Additionally, this same 306 operational model should scale from running a single tenant up to 307 many thousands of tenants. 309 2.7. Address space 311 As described in Section 1.1, currently, an OpenStack tenant is 312 required to specify a Subnet's CIDR prefix for IP address allocation. 313 With this proposal, this is no longer required. 315 2.8. Data Center Federation 317 It must be possible to extend the architecture across multiple data 318 centers. These data centers may be operated by distinct entities, 319 with security policies that apply to their interconnection. 321 2.9. Path MTU Issues 323 An issue in virtualized data center architectures is Path MTU 324 Discovery [RFC1981] implementation. Implementing Path MTU requires 325 the ICMPv6 [RFC4443] Packet Too Big message to get from the 326 originating router or middleware to the indicated host, which is in 327 this case virtual and potentially hidden within a tunnel. This is a 328 special case of the issues raised in [RFC2923]. 330 3. Models 332 3.1. Configuration Model 334 In the OpenStack model, the cloud computing user, or tenant, is 335 building something Edward Yourdon might call a 'structured design' 336 for the application they are building. In the 1960's, when Yourdon 337 started specifying process and data flow diagrams, these were job 338 steps in a deck of Job Control Language cards; in OpenStack, they are 339 multiple, individual machines, virtual or physical, running parts of 340 a structured application. 342 In these, one might find a load balancer that receives and 343 distributes requests to request processors, a set of stored data 344 processing applications, and the storage they depend on. What is 345 important to the OpenStack tenant is that 'this' and 'that' 346 communicate, potentially using or not using multicast communications, 347 and don't communicate with 'the other'. Typically unnecessary is any 348 and all information regarding how this communication actually needs 349 to occur (i.e. placement of routers, switches, and IP subnets, 350 prefixes, etc.). 352 An IPv6 based networking model simplifies the configuration of tenant 353 connectivity requirements. Global reachability eliminates the need 354 for network address translation devices as well as tenant-specified 355 Subnet prefixes (Section 2.7), although tenant-specified ULA prefixes 356 or prefixes from the owner of the tenant's address space are usable 357 with it. With the exception of network security functions, no 358 network devices need to be specified or configured to provide 359 connectivity. 361 3.2. Data Center Model 363 The premises of the routing and addressing models are that 365 o The address tells the routing system what topological location to 366 deliver a packet to, and within that, what interface to deliver it 367 to, and 369 o The routing system should deliver traffic to a resource if and 370 only if the sender is authorized to communicate with that 371 resource. 373 o Contrary to the OpenStack Neutron Networking Model, tunnels are 374 not necessary to provide tenant network isolation; we include 375 resources in a tenant network by a Role-based Access Control 376 model, but address the tenant resources within the data center in 377 a manner that scales for the data center. 379 We expect to find the data center to be composed of some minimal unit 380 of connectivity and maintenance, such as a rack or row, and equipped 381 with one or more Top-of-Rack or End-of-Row switch(es); each 382 configured with at least one subnet prefix, perhaps one per such 383 switch. For the purposes of this note, these will be called Racks 384 and Top-of-Rack switches, and when applied to other architectures the 385 appropriate translation needs to be imposed. 387 Figure 1 describes a relatively typical rack design. It is a simple 388 fat-tree architecture, with every device in a pair, so that any 389 failure has an immediate hot backup. There are other common designs, 390 such as those that consider each rack to be in a 'row' and in a 391 'column', with one or more distribution switches in each. 393 Distribution Switches connecting 394 / Layer / racks in a pod, and 395 / / connecting pods 396 / / 397 +-+-+ +-+-+ Mutual backup TOR 398 +-+TOR+---+TOR+-+ switches 399 | +---+ +---+ | 400 | +-----------+ | 401 +-+ host +-+ Each host has two 402 | +-----------+ | Ethernet interfaces 403 +-+ host +-+ with separate subnets 404 | +-----------+ | 405 | . . | 406 | . . | 407 | . . | Design premise: complete 408 | +-----------+ | redundancy, with every 409 +-+ host +-+ switch and every cable 410 | +-----------+ | backed up by a doppelganger 411 +-+ host +-+ 412 +-----------+ 414 Figure 1: Typical Rack Design 416 3.2.1. Tenant Address Model 418 Tenant resources need to be told, by configuration or naming, the 419 addresses of resources they communicate with. This is true 420 regardless of their location or relationship to a given tenant. In 421 environments with well-known addresses, this becomes complex and 422 unscalable. This was learned very early with Internet hostnames; a 423 single 'hostfile' was maintained by a central entity and updated 424 daily, which quickly became unwieldy. The result was the development 425 of the Domain Name System; the level of indirection between names and 426 addresses improved scalability. It also facilitated ongoing 427 maintenance. If a service needed multiple servers, or a server 428 needed to change its address, that was trivially solved by changing 429 the DNS Resource Record; every resource that needed the new address 430 would obtain it the next time it queried the DNS. It has also 431 facilitated the IPv4/IPv6 transition; a resource that has an IPv6 432 address is given a AAAA record in addition to, or to replace, its 433 IPv4 A record. 435 Similarly, today's reliance on NAPT technology frequently limits the 436 capabilities of an application. It works reasonably well for a 437 client accessing a client/server application when the protocol does 438 not carry addressing information. If there is an expectation that 439 one resource's private address will be meaningful to a peer, such as 440 when an SIP client presents its address in SDP or an HTTP server 441 presents an address in a redirection, either the resource needs to 442 understand the difference between an 'inside' and an 'outside' 443 address and know which is which, or it needs a traversal algorithm 444 that changes the addresses. For peer-to-peer applications, this 445 ultimately means providing a network design in which those issues 446 don't apply. 448 IPv6 provides global addresses, enough of them that there is no real 449 expectation of running out any time soon, making these issues go 450 away. In addition, with the IPv4 address space running out, both 451 globally and within today's large datacenters, there aren't 452 necessarily addresses available for an IPv4 application to use, even 453 as a floating IP address. 455 Hence, the model we propose is that a resource in a tenant is told 456 the addresses of the other resources with which it communicates. 457 They are IPv6 addresses, and the data center takes care to ensure 458 that inappropriate communications do not take place. 460 3.2.1.1. Use of Global Unicast Addresses by Tenants 462 A unicast address in an IP network identifies a topological location, 463 by association with an IP prefix (which might be for a subnet or any 464 aggregate of subnets). It also identifies a single interface located 465 within that subnet, which may or may not be instantiated at the time. 466 We assume that there is a subnet associated with a top-of-rack switch 467 or whatever its counterpart would be in a given network design, and 468 that the physical and virtual machines located in that rack have 469 addresses in that subnet. This is the same prefix that is used by 470 the datacenter administrator. 472 3.2.1.2. Unique Local Addresses 474 A common requirement is that tenants have the use of some form of 475 private address space. In an IPv6 network, a Unique Local IPv6 476 Unicast Address [RFC4193] may be used to accomplish this. In this 477 case, however, the addresses will need to be explicitly assigned to 478 physical or virtual machines used by the tenant, perhaps using DHCP 479 or YANG, where a standard IPv6 address could be allocated using 480 SLAAC, DHCPv6, or other technologies. 482 The value of this is that the distinction between a Global Address 483 and a Unique Local Address is a corner case in the data center; a ULA 484 will not generally be useful when communicating outside the data 485 center, but within the data center it is rational. Tenants have no 486 routing information or other awareness of the prefix. This is not 487 intended for use behind a NAPT; resources that need accessibility to 488 or from resources outside the tenant, and especially outside the data 489 center, need global addresses. 491 3.2.1.3. Multicast Domains 493 Multicast capability is a capability enjoyed by some groups of 494 resources, that enables them to send a single message and have it 495 delivered to multiple destinations roughly simultaneously. At the 496 link layer, this means sending a message once that is received by a 497 specified set of recipient resources using hardware capabilities. IP 498 multicast can be implemented on a LAN as specified in [RFC4291], and 499 can also cross multiple subnets directly, using routing protocols 500 such as Protocol Independent Multicast [RFC4601] [RFC4602] [RFC4604] 501 [RFC4605] [RFC4607]. In IPv6, the model would be that when a group 502 of resources is created with a multicast capability, it is allocated 503 one or more source-specific transient group addresses as defined in 504 section 2.7 of that RFC. 506 3.2.1.4. IPv4 Interaction Model 508 OpenStack IPv4 Neutron uses "floating IPv4 addresses" - global or 509 public IPv4 addresses and Network Address Translation - to enable 510 remote resources to connect to tenant private network endpoints. 511 Tenant end points can connect out to remote resources through an 512 "External Default Gateway". Both of these depend on NAPT (DNAT/SNAT) 513 [RFC2391] to ensure that IPv4 end points are able communicate and at 514 the same time ensure tenant isolation. 516 If IPv6 is deployed in a data center, there are fundamentally two 517 ways a tenant can interact with IPv4 peers: 519 o it can run existing IPv4 OpenStack technology in parallel with the 520 IPv6 deployment, or 522 o It can have a translator at the data center edge (such as 523 described in [I-D.ietf-v6ops-siit-dc]) that associates an IPv4 524 address or address plus port with an IPv6 address or address plus 525 port. The IPv4 address, in this model, becomes a floating IPv4 526 address attached to an internal IPv6 address. The 'data center 527 edge' is, by definition, a system that has IPv4 reachability to at 528 least the data center's upstream ISP and all IPv4 systems in the 529 data center, IPv6 connectivity to all of the IPv6 systems in the 530 data center, and (if the upstream offers IPv6 service) IPv6 531 connectivity to the upstream as well. 533 The first model is complex, if for no other reason than that there 534 are two fundamental models in use, one with various encapsulations 535 hiding overlapping address space and one with non-overlapping address 536 space. 538 To simplify the network, as noted in Section 2.1, we suggest that the 539 data center be internally IPv6-only, and IPv4 be translated to IPv6 540 at the data center edge. The advantage is that it enables IPv4 541 access while that remains in use, and as IPv6 takes over, it reduces 542 the impact of vestigial support for IPv4. 544 The SIIT Translation model in [I-D.ietf-v6ops-siit-dc] has IPv4 545 traffic come to an translator [RFC6145][RFC6146] having a pre- 546 configured translation, resulting in an IPv6 packet indistinguishable 547 from the packet the remote resource might have sent had it been 548 IPv6-capable, with one exception. The IPv6 destination address is 549 that of the endpoint (the same address advertised in a AAAA record), 550 but the source address is an IPv4-Embedded IPv6 Address [RFC6052] 551 with the IPv4 address of the sender embedded in a prefix used by the 552 translator. 554 Access to external IPv4 resources is provided in the same way: an 555 DNS64 [RFC6147] server is implemented that contains AAAA records with 556 an IPv4-Embedded IPv6 Address [RFC6052] with the IPv4 address of the 557 remote resource embedded in a prefix used by the translator. 559 This follows the Framework for IPv4/IPv6 Translation [RFC6144], 560 making the internal IPv4 address a floating IP address attached to an 561 internal IPv6 address, and the external 'dial-out' address 562 indistinguishable from a native IPv6 address. 564 3.2.1.5. Legacy IPv4 OpenStack 566 The other possible model, applicable to IPv4-only devices, is to run 567 a legacy OpenStack environment inside IPv6 tunnels. This preserves 568 the data center IPv6-only, and enables IPv4-only applications, 569 notably those whose licenses tie them to IPv4 addresses, to run. 570 However, it adds significant overhead in terms of encapsulation size 571 and network management complexity. 573 3.2.2. Use of Global Addresses by the Data Center 575 Every rack and physical host requires an IP prefix that is reachable 576 by the OpenStack operator. This will normally be a global IPv6 577 unicast address. For scalability purposes, as isolation is handled 578 separately, this is normally the same prefix as is used by tenants in 579 the rack. 581 3.3. Inter-tenant security services 583 In this model, the a label is used to identify a set of virtual or 584 physical systems under common ownership and administration that are 585 authorized to communicate freely among themselves - a tenant. 586 Tenants are not generally authorized to communicate with each other, 587 but interactions between specified tenants may be authorized, and 588 specific systems may be authorized to communicate generally. 590 The fundamental premise is that the vSwitch can determine whether a 591 VM is authorized to send or receive a given message. It does so by 592 finding the label in a message being sent or received and comparing 593 it to a locally-held authorization policy. This policy would 594 indicate that the VM is permitted to send or receive messages 595 containing one of a small list of labels. In the case of a label 596 contained in the IID of an IPv6 address, it would also need to verify 597 the prefix used in the address, as this type of policy would be 598 specific to an IPv6 prefix. 600 A set of possible choices that were considered is to be found in 601 Appendix B. The key questions are a list of considerations, presented 602 in no particular order: 604 o In what way does the approach the IPv6 Path MTU? 606 o How does the address come into being? 608 o What security implications apply? For example, how hard would it 609 be for a VM to spoof the source address or attack a random 610 destination? 612 o What is the service offered? Can, for example, policy be applied 613 at 615 * The sender of a datagram? 617 * The receiver of a datagram? 619 * An arbitrary point between the sender and receiver? 621 * At the data center edge, on arriving or departing traffic other 622 data centers? 624 * At the data center edge, on arriving or departing traffic 625 random locations? 627 o In what way does the approach the IPv6 Path MTU? 629 3.4. IPv6 Tenant Isolation using the Label 631 Neutron today already implements a form of Network Ingress Filtering 632 [RFC2827]. It prevents the VM from emitting traffic with an 633 unauthorized MAC, IPv4, or IPv6 source address. 635 In addition to this, in this model Neutron prevents the VM from 636 transmitting a network packet with an unauthorized label value. The 637 VM MAY be configured with and authorized to use one of a short list 638 of authorized label values, as opposed to simply having its choice 639 overridden; in that case, Neutron verifies the value and overwrites 640 one not in the list. 642 When a hypervisor is about to deliver an IPv6 packet to a VM, it 643 checks the label value against a list of values that the VM is 644 permitted to receive. If it contains an unauthorized value, the 645 hypervisor discards the packet rather than deliver it. If the Flow 646 Label is in use, Neutron zeros the label prior to delivery. 648 The intention is to hide the label value from malware potentially 649 found in the VM, and enable the label to be used as a form of first 650 and last hop security. This provides basic tenant isolation, if the 651 label is assigned as a tenant identifier, and may be used more 652 creatively such as to identify a network management application as 653 separate from a managed resource. 655 3.5. Isolation in Routing 657 This concept has the weakness that if a packet is not dropped at its 658 source, it is dropped at its destination. It would be preferable for 659 the packet to be dropped in flight, such as at the top-of-rack switch 660 or an aggregation router. 662 Concepts discussed in IS-IS LSP Extendibility 663 [I-D.baker-ipv6-isis-dst-flowlabel-routing][RFC5120][RFC5308] and 664 OSPFv3 LSA Extendibility [I-D.baker-ipv6-ospf-dst-flowlabel-routing] 665 [I-D.ietf-ospf-ospfv3-lsa-extend][RFC5340] may be used to isolate 666 tenants in the routing of the data center backbone. This is not 667 strictly necessary, if Section 3.4 is uniformly and correctly 668 implemented. It does, however, present a second defense against 669 misconfiguration, as the filter becomes ubiquitous in the data center 670 and as scalable as routing. 672 4. BCP 38 Ingress Filtering 674 As noted in Section 3.4, Neutron today implements a form of Network 675 Ingress Filtering [RFC2827]. It prevents the VM from emitting 676 traffic with an unauthorized MAC, IPv4, or IPv6 source address. 678 In IPv6, this is readily handled when the address or addresses used 679 by a VM are selected by the OpenStack operator. It may then 680 configure a per-VM filter with the addresses it has chosen, following 681 logic similar to the Source Address Validation Solution for DHCP 682 [I-D.ietf-savi-dhcp] or SEND [RFC7219]. This is also true of IPv6 683 Stateless Address Autoconfiguration (SLAAC) [RFC4862] when the MAC 684 address is known and not shared. 686 However, when SLAAC is in use and either the MAC address is unknown 687 or SLAAC's Privacy Extensions [RFC4941][RFC7217], are in use, Neutron 688 will need to implement the provisions of FCFS SAVI: First-Come, 689 First-Served Source Address Validation [RFC6620] in order to learn 690 the addresses that a VM is using and include them in the per-VM 691 filter. 693 5. Moving virtual machines 695 This design supports these kinds of required layer 2 networks with 696 the additional use of a layer 2 over layer 3 encapsulation and 697 tunneling protocol, such as VXLAN [RFC7348]. The important point 698 here being that these overlays are used to address specific tenant 699 network requirements and NOT deployed to remove the scalability 700 limitations of OpenStack networking. 702 There are at least three ways VM movement can be accomplished: 704 o Recreation of the VM 706 o VLAN Modification 707 o Live Migration of a Running Virtual Machine 709 5.1. Recreation of the VM 711 The simplest and most reliable is to 713 1. Create a new VM in the new location, 715 2. Add its address to the DNS Resource Record for the name, allowing 716 new references to the name to send transactions there, 718 3. Remove the old address from the DNS Resource Record (including 719 the SIIT translation, if one exists), ending the use of the old 720 VM for new transactions, 722 4. Wait for the period of the DNS Resource Record's lifetime 723 (including the SIIT translation, if one exists), as it will get 724 new requests throughout that interval, 726 5. Wait for the for the old VM to finish any outstanding 727 transactions, and then 729 6. Kill the old VM. 731 This is obviously not movement of an existing VM, but preservation of 732 the same number and function of VMs by creation of a new VM and 733 killing the old. 735 5.2. Live Migration of a Running Virtual Machine 737 At http://blogs.vmware.com/vsphere/2011/02/vmotion-whats-going-on- 738 under-the-covers.html, VMWare describes its capability, called 739 vMotion, in the following terms: 741 1. Shadow VM created on the destination host. 743 2. Copy each memory page from the source to the destination via the 744 vMotion network. This is known as preCopy. 746 3. Perform another pass over the VM's memory, copying any pages that 747 changed during the last preCopy iteration. 749 4. Continue this iterative memory copying until no changed pages 750 (outstanding to be-copied pages) remain or 100 seconds elapse. 752 5. Stun the VM on the source and resume it on the destination. 754 In a native-address environment, we add three steps: 756 1. Shadow VM created on the destination host. 758 2. Copy each memory page from the source to the destination via the 759 vMotion network. This is known as preCopy. 761 3. Perform another pass over the VM's memory, copying any pages that 762 changed during the last preCopy iteration. 764 4. Continue this iterative memory copying until no changed pages 765 (outstanding to be-copied pages) remain or 100 seconds elapse. 767 5. Stitch routing for the old address. 769 6. Stun the VM on the source and resume it on the destination. 771 7. Renumber the VM as instructed in [RFC4192]. 773 8. Unstitch routing for the old address. 775 If the VM is moved within the same subnet (which usually implies the 776 same rack), there is no stitching or renumbering apart from ensuring 777 that the MAC address moves with the VM. When the VM moves to a 778 different subnet, however, we need to restitch routing, at least 779 temporarily. This obviously calls for some definitions. 781 Stitching Routing: The VM is potentially in communication with two 782 sets of peers: VMs in the same subnet, and VMs in different 783 subnets. 785 * The router in the new subnet is instructed to advertise a host 786 route (/128) to the moved VM, and to install a static route to 787 the old address with the VM's address in the new subnet as its 788 next hop address. Traffic from VMs from other subnets will now 789 follow the host route to the VM in its new location. 791 * The router in the old subnet is instructed to direct LAN 792 traffic to the VM's MAC Address to its IPv6 forwarding logic. 793 Traffic from other VMs in the old subnet will now follow the 794 host route to the moved VM. 796 Renumbering: This step is optional, but is good hygiene if the VM 797 will be there a while. If the VM will reside in its new location 798 only temporarily, it can be skipped. 800 Note that every IPv6 address, unlike an IPv4 address, has a 801 lifetime. At least in theory, when the lifetime expires, neighbor 802 relationships with the address must be extended or the address 803 removed from the system. The Neighbor Discovery [RFC4861] process 804 in the subnet router will periodically emit a Router 805 Advertisement; the VM will gain an IPv6 address in the new subnet 806 at that time if not earlier. As described in [RFC4192], DNS 807 should be changed to report the new address instead of the old. 808 The DNS lifetime and any ambient sessions using the old address 809 are now allowed to expire. That this point, any new sessions will 810 be using the new address, and the old is vestigial. 812 Waiting for sessions using the address to expire can take an 813 arbitrarily long interval, because the session generally has no 814 knowledge of the lifetime of the IPv6 address. 816 Unstitching Routing: This is the reverse process of stitching. If 817 the VM is renumbered, when the old address becomes vestigial, the 818 address will be discarded by the VM; if the VM is subsequently 819 taken out of service, it has the same effect. At that point, the 820 host route is withdrawn, and the MAC address in the old subnet 821 router's tables is removed. 823 6. OpenStack implications 825 6.1. Configuration implications 827 1. Neutron MUST be configured with a pre-determined default label 828 value for each tenant virtual network Section 3.4. 830 2. Neutron MAY be configured with a set of authorized label values 831 for each tenant virtual network Section 3.4. 833 3. A virtual tenant network MAY be configured with a set of 834 authorized label values Section 3.4. 836 4. Neutron MUST be configured with one or more label values per 837 virtual tenant network that the network is permitted to receive 838 Section 3.4. 840 6.2. vSwitch implications 842 On messages transmitted by a virtual machine 844 Label Correctness: As described in Section 3.3, ensure that the 845 label in the packet is one that the VM is authorized to use. 846 Exactly what label is in view is a deferred, and potentially 847 configurable, option. Again Depending on configuration, the 848 vSwitch may overwrite whatever value is there, or may ratify that 849 the value there is as specified in a VM-specific list. 851 Source Address Validation: As described in Section 4, force the 852 source address to be among those the VM is authorized to use. The 853 VM may simultaneously be authorized to use several addresses. 855 Destination Address Validation: OpenStack for IPv4 permits a NAT 856 translation, called a 'floating IP address', to enable a VM to 857 communicate outside the domain; without that, it cannot. For 858 IPv6, the destination address should be permitted by some access 859 list, which may permit all addresses, or addresses matching one or 860 more CIDR prefixes such as permitted multicast addresses, and the 861 prefix of the data center. 863 On messages received for delivery to a virtual machine 865 Label Authorization: As described in Section 3.4, the vSwitch only 866 delivers a packet to a VM if the VM is authorized to receive it. 867 The VM may have been authorized to receive several such labels. 869 Each approach in the appendix discusses filtering. 871 7. IANA Considerations 873 This document does not ask IANA to do anything. 875 8. Security Considerations 877 In Section 2.5 and Section 3.3, this specification considers inter- 878 tenant and intra-tenant network isolation. It is intended to 879 contribute to the security of a network, much like encapsulation in a 880 maze of tunnels or VLANs might, but without the complexities and 881 overhead of the management of such resources. This does not replace 882 the use of IPSec, SSH, or TLS encryption or the use authentication 883 technologies; if these would be appropriate in an on-premises 884 corporate data center, they remain appropriate in a multi-tenant data 885 center regardless of the isolation technology. However, one can 886 think of this as a simple inter-tenant firewall based on the concepts 887 of role-based access control; if it can be readily determined that a 888 sender is not authorized to communicate with a receiver, such a 889 transmission is prevented. 891 9. Privacy Considerations 893 This specification places no personally identifying information in an 894 unencrypted part of a packet. 896 10. Acknowledgements 898 This document grew out of a discussion among the authors and 899 contributors. 901 11. Contributors 903 Puneet Konghot 904 Cisco Systems 905 San Jose, California 95134 906 USA 907 Email: pkonghot@cisco.com 909 Shannon McFarland 910 Cisco Systems 911 Boulder, Colorado 80301 912 USA 913 Email: shmcfarl@cisco.com 915 Figure 2 917 12. References 919 12.1. Normative References 921 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 922 Requirement Levels", BCP 14, RFC 2119, March 1997. 924 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 925 (IPv6) Specification", RFC 2460, December 1998. 927 12.2. Informative References 929 [FaceBook-IPv6] 930 Pepelnjak, I., "Facebook Is Close to Having an IPv6-only 931 Data Center http://blog.ipspace.net/2014/03/ 932 facebook-is-close-to-having-ipv6-only.html", March 2014. 934 [I-D.baker-ipv6-isis-dst-flowlabel-routing] 935 Baker, F., "Using IS-IS with Role-Based Access Control", 936 draft-baker-ipv6-isis-dst-flowlabel-routing-00 (work in 937 progress), February 2013. 939 [I-D.baker-ipv6-ospf-dst-flowlabel-routing] 940 Baker, F., "Using OSPFv3 with Role-Based Access Control", 941 draft-baker-ipv6-ospf-dst-flowlabel-routing-02 (work in 942 progress), May 2013. 944 [I-D.ietf-6man-default-iids] 945 Gont, F., Cooper, A., Thaler, D., and W. Will, 946 "Recommendation on Stable IPv6 Interface Identifiers", 947 draft-ietf-6man-default-iids-01 (work in progress), 948 October 2014. 950 [I-D.ietf-ospf-ospfv3-lsa-extend] 951 Lindem, A., Mirtorabi, S., Roy, A., and F. Baker, "OSPFv3 952 LSA Extendibility", draft-ietf-ospf-ospfv3-lsa-extend-03 953 (work in progress), May 2014. 955 [I-D.ietf-savi-dhcp] 956 Bi, J., Wu, J., Yao, G., and F. Baker, "SAVI Solution for 957 DHCP", draft-ietf-savi-dhcp-26 (work in progress), May 958 2014. 960 [I-D.ietf-v6ops-siit-dc] 961 tore, t., "SIIT-DC: Stateless IP/ICMP Translation for IPv6 962 Data Centre Environments", draft-ietf-v6ops-siit-dc-00 963 (work in progress), December 2014. 965 [I-D.previdi-6man-segment-routing-header] 966 Previdi, S., Filsfils, C., Field, B., and I. Leung, "IPv6 967 Segment Routing Header (SRH)", draft-previdi-6man-segment- 968 routing-header-04 (work in progress), November 2014. 970 [Microsoft-Azure] 971 Sverdlik, Y., "Report: Microsoft Buys 100 Acres of Iowa 972 land for Data Center http://www.datacenterknowledge.com/ 973 archives/2014/08/01/ 974 report-microsoft-buys-100-acres-iowa-land-data-center/", 975 August 2014. 977 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 978 E. Lear, "Address Allocation for Private Internets", BCP 979 5, RFC 1918, February 1996. 981 [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery 982 for IP version 6", RFC 1981, August 1996. 984 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 985 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 986 Functional Specification", RFC 2205, September 1997. 988 [RFC2391] Srisuresh, P. and D. Gan, "Load Sharing using IP Network 989 Address Translation (LSNAT)", RFC 2391, August 1998. 991 [RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast 992 Listener Discovery (MLD) for IPv6", RFC 2710, October 993 1999. 995 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 996 Defeating Denial of Service Attacks which employ IP Source 997 Address Spoofing", BCP 38, RFC 2827, May 2000. 999 [RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery", RFC 1000 2923, September 2000. 1002 [RFC3439] Bush, R. and D. Meyer, "Some Internet Architectural 1003 Guidelines and Philosophy", RFC 3439, December 2002. 1005 [RFC3697] Rajahalme, J., Conta, A., Carpenter, B., and S. Deering, 1006 "IPv6 Flow Label Specification", RFC 3697, March 2004. 1008 [RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for 1009 Renumbering an IPv6 Network without a Flag Day", RFC 4192, 1010 September 2005. 1012 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 1013 Addresses", RFC 4193, October 2005. 1015 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 1016 Architecture", RFC 4291, February 2006. 1018 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 1019 Message Protocol (ICMPv6) for the Internet Protocol 1020 Version 6 (IPv6) Specification", RFC 4443, March 2006. 1022 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 1023 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 1024 Protocol Specification (Revised)", RFC 4601, August 2006. 1026 [RFC4602] Pusateri, T., "Protocol Independent Multicast - Sparse 1027 Mode (PIM-SM) IETF Proposed Standard Requirements 1028 Analysis", RFC 4602, August 2006. 1030 [RFC4604] Holbrook, H., Cain, B., and B. Haberman, "Using Internet 1031 Group Management Protocol Version 3 (IGMPv3) and Multicast 1032 Listener Discovery Protocol Version 2 (MLDv2) for Source- 1033 Specific Multicast", RFC 4604, August 2006. 1035 [RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick, 1036 "Internet Group Management Protocol (IGMP) / Multicast 1037 Listener Discovery (MLD)-Based Multicast Forwarding ("IGMP 1038 /MLD Proxying")", RFC 4605, August 2006. 1040 [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for 1041 IP", RFC 4607, August 2006. 1043 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 1044 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 1045 September 2007. 1047 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 1048 Address Autoconfiguration", RFC 4862, September 2007. 1050 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 1051 Extensions for Stateless Address Autoconfiguration in 1052 IPv6", RFC 4941, September 2007. 1054 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 1055 Topology (MT) Routing in Intermediate System to 1056 Intermediate Systems (IS-ISs)", RFC 5120, February 2008. 1058 [RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, October 1059 2008. 1061 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 1062 for IPv6", RFC 5340, July 2008. 1064 [RFC5548] Dohler, M., Watteyne, T., Winter, T., and D. Barthel, 1065 "Routing Requirements for Urban Low-Power and Lossy 1066 Networks", RFC 5548, May 2009. 1068 [RFC5673] Pister, K., Thubert, P., Dwars, S., and T. Phinney, 1069 "Industrial Routing Requirements in Low-Power and Lossy 1070 Networks", RFC 5673, October 2009. 1072 [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 1073 Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, 1074 October 2010. 1076 [RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for 1077 IPv4/IPv6 Translation", RFC 6144, April 2011. 1079 [RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation 1080 Algorithm", RFC 6145, April 2011. 1082 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 1083 NAT64: Network Address and Protocol Translation from IPv6 1084 Clients to IPv4 Servers", RFC 6146, April 2011. 1086 [RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van 1087 Beijnum, "DNS64: DNS Extensions for Network Address 1088 Translation from IPv6 Clients to IPv4 Servers", RFC 6147, 1089 April 2011. 1091 [RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, 1092 "IPv6 Flow Label Specification", RFC 6437, November 2011. 1094 [RFC6620] Nordmark, E., Bagnulo, M., and E. Levy-Abegnoli, "FCFS 1095 SAVI: First-Come, First-Served Source Address Validation 1096 Improvement for Locally Assigned IPv6 Addresses", RFC 1097 6620, May 2012. 1099 [RFC7217] Gont, F., "A Method for Generating Semantically Opaque 1100 Interface Identifiers with IPv6 Stateless Address 1101 Autoconfiguration (SLAAC)", RFC 7217, April 2014. 1103 [RFC7219] Bagnulo, M. and A. Garcia-Martinez, "SEcure Neighbor 1104 Discovery (SEND) Source Address Validation Improvement 1105 (SAVI)", RFC 7219, May 2014. 1107 [RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, 1108 L., Sridhar, T., Bursell, M., and C. Wright, "Virtual 1109 eXtensible Local Area Network (VXLAN): A Framework for 1110 Overlaying Virtualized Layer 2 Networks over Layer 3 1111 Networks", RFC 7348, August 2014. 1113 [UCC] Jeuk, S., Szefer, J., and S. Zhou, "Towards Cloud, Service 1114 and Tenant Classification for Cloud Computing", IEEE 1115 Xplore Digital Library: Cluster, Cloud and Grid Computing 1116 (CCGrid), 2014 14th IEEE/ACM International Symposium, May 1117 2014. 1119 Appendix A. Change Log 1121 Initial Version: October 2014 1123 First update: January 2015 1125 Appendix B. Alternative Labels considered 1127 B.1. IPv6 Flow Label 1129 The IPv6 flow label may be used to identify a tenant or part of a 1130 tenant, and to facilitate access control based on the flow label 1131 value. The flow label is a flat 20 bits, facilitating the 1132 designation of 2^20 (1,048,576) tenants without regard to their 1133 location. 1,048,576 is less than infinity, but compared to current 1134 data centers is large, and much simpler to manage. 1136 Note that this usage differs from the current IPv6 Flow Label 1137 Specification [RFC6437]. It also differs from the use of a flow 1138 label recommended by the IPv6 Specification [RFC2460], and the 1139 respective usages of the flow label in the Resource ReSerVation 1140 Protocol [RFC2205] and the previous IPv6 Flow Label Specification 1141 [RFC3697], and the projected usage in Low-Power and Lossy Networks 1142 [RFC5548][RFC5673]. Within a target domain, the usage may be 1143 specified by the domain. That is the viewpoint taken in this 1144 specification. 1146 B.1.1. Metaconsiderations 1148 B.1.1.1. Service offered 1150 To Be Supplied 1152 B.1.1.2. Pros and Cons 1154 B.1.1.2.1. The case in favor of this approach 1156 To Be Supplied 1158 B.1.1.2.2. The case against 1160 To Be Supplied 1162 B.1.1.3. Filtering considerations 1164 To Be Supplied 1166 B.2. Federated Identity 1168 B.2.1. Introduction 1170 In the course of developing draft-baker-ipv6-openstack-model, it was 1171 determined that a way was needed to encode a federated identity for 1172 use in Role-Based Access Control. This appendix describes an IPv6 1173 [RFC2460] option that could be carried in the Hop-by-Hop or 1174 Destination Options Header. The format of an option is defined in 1175 section 4.2 of that document, and the Hop-by-Hop and Destination 1176 Options are defined in sections 4.3 and 4.6 of that document 1177 respectively. 1179 A 'Federated Identity', in the words of the Wikipedia, 'is the means 1180 of linking an electronic identity and attributes, stored across 1181 multiple distinct identity management systems.' In this context, it 1182 is a fairly weak form of that; it is intended for quick 1183 interpretation in an access list at the Internet layer as opposed to 1184 deep analysis for login or other security purposes at the application 1185 layer, and rather than identifying an individual or a system, it 1186 identifies a set of systems whose members are authorized to 1187 communicate freely among themselves and may also be authorized to 1188 communicate with other identified sets of systems. Either two 1189 systems are authorized to communicate or they are not, and 1190 unauthorized traffic can be summarily discarded. The identifier is 1191 defined in a hierarchical fashion, for flexibility and scalability. 1193 'Role-Based Access Control', in this context, applies to groups of 1194 virtual or physical hosts, not individuals. In the simplest case, 1195 the several tenants of a multi-tenant data center might be 1196 identified, and authorized to communicate only with other systems 1197 within the same 'tenant' or with identified systems in other tenants 1198 that manage external access. One could imagine a company purchasing 1199 cloud services from multiple data center operators, and as a result 1200 wanting to identify the systems in its tenant in one cloud service as 1201 being authorized to communicate with the systems its tenant of the 1202 other. One could further imagine a given department within that 1203 company being authorized to speak only with itself and an identified 1204 set of other departments within the same company. To that end, when 1205 a datagram is sent, it is tagged with the federated identify of the 1206 sender (e.g., {datacenter, client, department}), and the receiving 1207 system filters traffic it receives to limit itself to a specific set 1208 of authorized communicants. 1210 B.2.2. Federated identity Option 1212 The option is defined as a sequence of numbers that identify relevant 1213 parties hierarchically. The specific semantics (as in, what number 1214 identifies what party) are beyond the scope of this specification, 1215 but they may be interpreted as being successively more specific; as 1216 shown in Figure 3, the first might identify a cloud operator, the 1217 second, if present, might identify a client of that operator, and the 1218 third, if present, might identify a subset of that client's systems. 1219 In an application entirely used by Company A, there might be only one 1220 number, and it would identify sets of systems important to Company A 1221 such as business units. If Company A uses the services of a multi- 1222 tenant data center #1, it might require that there be two numbers, 1223 identifying Company A and its internal structure. If Company A uses 1224 the services of both multi-tenant data centers #1 and #2, and they 1225 are federated, the identifier might need to identify the data center, 1226 the client, and the structure of the client. 1228 _.----------------------. 1229 _.----'' `------. 1230 ,--'' `---. 1231 ,-' DataCenter .---------------------. `-. 1232 ,' Company #2,---'' Unauthorized `----. `. 1233 ; ,' ,-----+-----. ,--+--------.`. : 1234 | ( ( Department 1)--//--( Department 2) ) | 1235 ; `. `-----+----+' `-----------',' | 1236 `. `----. | X Company A _.---' ,' 1237 '-. A|------X------------'' ,-' 1238 `---. u| X _.--' 1239 `------. t| X _.----'' 1240 `---h|---------X-------'' 1241 o| X 1242 _.--r+-----------X------. 1243 _.----'' i| X `------. 1244 ,--'' z| X `---. 1245 ,-' DataCenter e|--------------X-----. `-. 1246 ,' Company #2,---''d| X `----. `. 1247 ; ,' ,-----+-----. ,-+---------.`. : 1248 | ( ( Department 1) ( Department 2) ) | 1249 ; `. `-----------' `-----------',' | 1250 `. `----. Company A _.---' ,' 1251 '-. `--------------------'' ,-' 1252 `---. _.--' 1253 `------. _.----'' 1254 `----------------------'' 1256 Figure 3: Use case: Identifying authorized communicatants in an RBAC 1257 environment 1259 B.2.2.1. Option Format 1261 A number (Figure 4) is represented as a base 128 number whose 1262 coefficients are stored in the lower 7 bits of a string of bytes. 1263 The upper bit of each byte is zero, except in the final byte, in 1264 which case it is 1. The most significant coefficient of a non-zero 1265 number is never zero. 1267 8 = 8*128^0 1268 +-+------+ 1269 |1| 8 | 1270 +-+------+ 1272 987 = 7*128^1 + 91*128^0 1273 +-+------+-+------+ 1274 |0| 7 |1| 91 | 1275 +-+------+-+------+ 1277 121393 = 7*128^2 + 52*128^1 + 49*128^0 1278 +-+------+-+------+-+------+ 1279 |0| 7 |0| 52 |1| 49 | 1280 +-+------+-+------+-+------+ 1282 Figure 4: Sample numbers 1284 The identifier {8, 987, 121393} looks like 1286 +-------+-------+-+-----+-+-----+-+-----+-+-----+-+-----+-+-----+ 1287 | type | len=6 |1| 8 |0| 7 |1| 91 |0| 7 |0| 52 |1| 49 | 1288 +-------+-------+-+-----+-+-----+-+-----+-+-----+-+-----+-+-----+ 1290 Figure 5 1292 B.2.2.1.1. Use in the Destination Options Header 1294 In an environment in which the validation of the option only occurs 1295 in the receiving system or its hypervisor, this option is best placed 1296 in the Destination Options Header. 1298 B.2.2.1.2. Use in the Hop-by-Hop Header 1300 In an environment in which the validation of the option occurs in 1301 transit, such as in a firewall or other router, this option is best 1302 placed in the Hop-by-Hop Header. 1304 B.2.3. Metaconsiderations 1306 B.2.3.1. Service offered 1308 To Be Supplied 1310 B.2.3.2. Pros and Cons 1311 B.2.3.2.1. The case in favor of this approach 1313 To Be Supplied 1315 B.2.3.2.2. The case against 1317 To Be Supplied 1319 B.2.3.3. Filtering considerations 1321 To Be Supplied 1323 B.3. Universal Cloud Classification 1325 B.3.1. Introduction 1327 Cloud environments suffer from ambiguity in identifying their 1328 services and tenants. Traffic from different cloud providers cannot 1329 be distinguished easily on the Internet. Filters are simply not able 1330 to obtain the provider, service and tenant identities from network 1331 packets without leveraging other more latency intense inspection 1332 methods. This appendix describes the Universal Cloud Classification 1333 (UCC) [UCC] approach as a way to identify cloud providers, their 1334 services and tenants on the network layer. It introduces a Cloud-ID, 1335 Service-ID and Tenant-ID. The IDs are incorporated into an IPv6 1336 extension header and can be used for different use-cases both within 1337 and outside a Cloud Environment. The format of the IDs and their 1338 characteristics are defined in Appendix B.3.2 of the document and the 1339 extension header is defined in Appendix B.3.3. 1341 Applications and users are defined in many different ways in cloud 1342 environments, therefore ambiguity is multifold: 1344 1. The first ambiguity is described by how a service is defined in 1345 cloud environments. Here, an application within a Cloud Provider 1346 is called a service. However, the cloud providers network can 1347 not distinguish services from services run on top of other 1348 services. Distinguishing sub-services hosted by a service 1349 becomes critical when applying network services to specific sub- 1350 services. 1352 2. Secondly, a tenant in a cloud provider can have different 1353 meanings. Here, tenant is used to define a consumer of a cloud 1354 service. At the same time a service run on top of another 1355 service can be considered a tenant of that particular service. 1356 These ambiguities make it extremely difficult to uniquely 1357 identify services and their tenants in cloud environments. This 1358 multi-layered service and tenant relationship is one of the most 1359 complex tasks to handle using existing technologies. 1361 A service can be defined as a group of entities offering a specific 1362 function to a tenant within a Cloud Provider. 1364 B.3.2. Universal Cloud Classification Options 1366 Three IDs are defined that classify a Tenant specific to the service 1367 used within a certain Cloud Provider. The Cloud-ID, Service-ID and 1368 Tenant-ID are defined hierarchically and support service-stacking. 1369 The IDs are based on the 'Digital Object Identifier' scheme and 1370 support incorporating metadata per ID. The ID can be of variable 1371 length but Cloud-ID, Service-ID and Tenant-ID are proposed within a 4 1372 byte, 6 byte and 6 byte tuple respectively. 1374 B.3.2.1. Cloud ID 1376 The Cloud ID is a globally unique ID that is managed by a registrar 1377 similar to DNS. It is 4 bytes in sizes and defined with a 10 bit 1378 location part and a 22 bit provider ID. 1380 B.3.2.2. Service ID 1382 The Service ID is used to identify a service both within and outside 1383 a cloud environment. It is a 6 byte long ID that is separated into 1384 several sub-IDs defining the data center, service and an option 1385 field. The Data Center location is defined by 8 bits, the Service is 1386 32 bits long and the Option field provides another 8 bits. The 1387 option bits can be used to incorporate information used for en-route 1388 or destination tasks. 1390 B.3.2.3. Tenant ID 1392 The Tenant-ID is classifying consumers (tenants) of Cloud Services. 1393 It is a 6 byte long ID that is defined and managed by the Cloud 1394 Provider. Similar to the Service-ID the Tenant-ID incorporates 1395 metadata specific to that tenant. The MetaData field is of variable 1396 length and can be defined by the Cloud Provider as needed. 1398 B.3.3. UCC Extension Header 1400 The UCC proposal [UCC] defines an IPv6 hop-by-hop extension header to 1401 incorporate the Cloud-ID, Service-ID and Tenant-ID. Each ID area 1402 also includes bits to define enroute behavior for devices 1403 understanding/not-understanding the newly defined hop-by-hop 1404 extension header. This is useful for legacy devices on the Internet 1405 to avoid drops the packet but forward it without processing the added 1406 IPv6 extension header. 1408 0 8 16 24 32 40 48 56 64 1409 +-------+-------+-------+-------+-------+-------+-------+-------+ 1410 | FLAG | SIZE | CLOUD-ID | FLAG | SIZE | 1411 +-------+-------+-------+-------+-------+-------+-------+-------+ 1412 | SERVICE-ID | FLAG | SIZE | 1413 +-------+-------+-------+-------+-------+-------+-------+-------+ 1414 | TENANT-ID | 1415 +-------+-------+-------+-------+-------+-------+ 1417 Figure 6: UCC IPv6 hop-by-hop extension header 1419 The overall extension header size is 22 bytes. 1421 B.4. Policy List in Segment Routing Header 1423 The model here suggests using the Policy List described in the IPv6 1424 Segment Routing Header [I-D.previdi-6man-segment-routing-header]. 1425 Technically, it would violate that specification, as the Policy List 1426 is described as containing a set of optional addresses representing 1427 specific nodes in the SR path, where in this case it would be a 128 1428 bit number identifying the tenant or other set of communicating 1429 nodes. 1431 B.4.1. Metaconsiderations 1433 B.4.1.1. Service offered 1435 To Be Supplied 1437 B.4.1.2. Pros and Cons 1439 B.4.1.2.1. The case in favor of this approach 1441 To Be Supplied 1443 B.4.1.2.2. The case against 1445 To Be Supplied 1447 B.4.1.3. Filtering considerations 1449 To Be Supplied 1451 B.5. RFC 4291 Interface Identifier (IID) 1453 The approach starts from the observation that Openstack assigns the 1454 MAC address used by a VM, and can assign it according to any 1455 algorithm it chooses. A desire has been expressed to put the tenant 1456 identifier into the IPv6 address. This would put it into the IID in 1457 that address without modifying the VM OS or the virtual switch. 1459 B.5.1. Address Format 1461 The proposed address format is identical to the IPv6 EUI-48 based 1462 Address [RFC4291], and is derived from the MAC address space 1463 specified in SLAAC [RFC4862]. However, the MAC address provided by 1464 the OpenStack Controller differs from an IEEE 802.3 MAC Address. 1466 Walking through the details, an IEEE 802.3 MAC Address (Figure 7) 1467 consists of two single bit fields, a 22 bit Organizationally Unique 1468 Identifier (OUI), and a serial number or other NIC-specific 1469 identifier. The intention is to create a globally unique address, so 1470 that the NIC may be used on any LAN in the world without colliding 1471 with other addresses. 1473 0 8 16 24 32 40 1474 +-------+-------+-------+-------+-------+-------+ 1475 |Organizationally Unique| NIC Specific Number | 1476 | Identifier (OUI) | | 1477 +-------+-------+-------+-------+-------+-------+ 1478 AA 1479 |+--- 0=Unicast/1=Multicast 1480 +---- 1=Local/0=Global 1482 Figure 7: Ethernet MAC Address as specified by IEEE 802.3 1484 [RFC4291] describes a transformation from that address (which it 1485 refers to as an EUI-48 address) to the IID of an IPv6 Address 1486 (Figure 8). 1488 0 8 16 24 32 40 48 56 1489 +-------+-------+-------+-------+-------+-------+-------+-------+ 1490 |Organizationally Unique| Fixed Value | NIC Specific Number | 1491 | Identifier (OUI) | | | 1492 +-------+-------+-------+-------+-------+-------+-------+-------+ 1493 AA 1494 |+--- Reserved 1495 +---- 0=Local/1=Global 1497 Figure 8: RFC 4291 IPv6 Address 1499 OpenStack today specifies a local IEEE 802.3 address (bit 6 is one). 1500 IPv6 addresses are either installed using DHCP or derived from the 1501 MAC address via SLAAC. 1503 One could imagine the MAC address used in an OpenStack environment 1504 including both a tenant identifier and a system number on a LAN. If 1505 the tenant identifier is 24 bits (it could be longer or shorter, but 1506 for this document it is treated as 24 bits), as in common in VxLAN 1507 and QinQ implementations, that would allow for a 22 bit system 1508 number, plus two magic bits specifying a locally defined unicast 1509 address, as shown in Figure 9. Alternatively, the first byte could 1510 be some specified values such as 0xFA (as is common with current 1511 OpenStack implementations), followed by a 16 bit system number within 1512 the subnet. 1514 0 8 16 24 32 40 47 1515 +-------+-------+-------+-------+-------+-------+ 1516 |System Number within | Openstack Tenant | 1517 | LAN | Identifier | 1518 +-------+-------+-------+-------+-------+-------+ 1519 AA 1520 |+--- 0=Unicast/1=Multicast 1521 +---- 1=Local/0=Global 1523 Figure 9: Ethernet MAC Address as installed by OpenStack 1525 After being passed through SLAAC, that results in an IID that 1526 contains the Tenant ID in bits 48..63, has bit 6 zero as a locally- 1527 specified unicast address, and a 22 bit system number, as in 1528 Figure 10. 1530 0 8 16 24 32 40 48 56 63 1531 +-------+-------+-------+-------+-------+-------+-------+-------+ 1532 |system number within | Fixed Value | 24 bit OpenStack | 1533 | LAN | | Tenant Identifier | 1534 +-------+-------+-------+-------+-------+-------+-------+-------+ 1535 AA 1536 |+--- Reserved 1537 +---- 0=Local/1=Global 1539 Figure 10: RFC 4291 IPv6 IID Derived from OpenStack MAC Address 1541 More generally, if SLAAC is not in use and addresses are conveyed 1542 using DHCPv6 or another technology, the IID would be as described in 1543 Figure 11. 1545 0 8 16 24 32 40 48 56 63 1546 +-------+-------+-------+-------+-------+-------+-------+-------+ 1547 | system number within LAN | 24 bit OpenStack | 1548 | | Tenant Identifier | 1549 +-------+-------+-------+-------+-------+-------+-------+-------+ 1550 AA 1551 |+--- Reserved 1552 +---- 0=Local/1=Global 1554 Figure 11: Generalized Tenant IID 1556 As noted, the Tenant Identifier might be longer or shorter in a given 1557 implementation. Specifically in Figure 11, a 32 bit Tenant ID would 1558 occupy bit positions 32..63, and a 16 bit Tenant ID would occupy 1559 positions 48..63. 1561 Following the same model, IPv6 Multicast Addresses can be associated 1562 with a tenant identifier by placing the tenant identifier in the same 1563 set of bits and using the remaining bits of the Multicast Group ID as 1564 the ID within the tenant as show in Figure 12. Flags and scope are 1565 as specified in [RFC4291] section 2.7. To avoid clashes with 1566 multicast addresses specified in ibid 2.7.1 and future allocations, 1567 The Tenant Group ID MUST NOT be zero. 1569 | 8 | 4 | 4 | 88 bits 24 bits | 1570 +------ -+----+----+-----------------------------+---------------+ 1571 |11111111|flgs|scop| Tenant Group ID | Tenant ID | 1572 +--------+----+----+-----------------------------+---------------+ 1574 Figure 12: RFC 4291 Multicast Address with Tenant ID 1576 B.5.2. Metaconsiderations 1578 B.5.2.1. Service offered 1580 The fundamental seervice offered in this model is that the key policy 1581 parameter, the Tenant ID, is encoded in every datagram for both 1582 sender and receiver, and can therefore be tested by sender, receiver, 1583 or any other party. It is secure in the sense that it cannot be 1584 directly spoofed; in the sender vSwitch, the vSwitch prevents the 1585 sender from sending another address as discussed in Section 4, and if 1586 the recipient address is a randomly chosen address, even if it meets 1587 inter-tenant communication policy, there is unlikely to be a matching 1588 destination to deliver it to. Where this breaks down is if a valid 1589 and acceptable destination is discovered and used; that is the 1590 argument for further protection via TLS. 1592 B.5.2.2. Pros and Cons 1594 B.5.2.2.1. The case in favor of this approach 1596 The case in favor of this approach consists of several observations: 1598 o Many Cisco customers are using and prefer SLAAC for IPv6 clients 1599 in OpenStack environments. 1601 o It is easy to configure this IID from the Neutron Controller 1602 without modifying the VM, or it even knowing it happened. 1604 o From a security perspective, the tenant ID cannot be spoofed per 1605 se; the sender of a message is not permitted to send a message 1606 from the wrong address or to an unauthorized address. 1608 o Since it requires no extension headers or other encapsulations, it 1609 has no impact on Path MTU. 1611 o Filters can be applied anywhere, and notably at the sender and the 1612 receiver of a message. 1614 B.5.2.2.2. The case against 1616 In [I-D.ietf-6man-default-iids], the IETF is moving toward 1617 deprecating [RFC4291]'s Modified EUI-64 IID. 1619 B.5.2.3. Filtering considerations 1621 In this model, the vSwitch needs, for each VM it manages, two access 1622 control lists: 1624 o Zero or more {IPv6 prefix, tenant ID} pairs; these may be read as 1625 'if the IPv6 prefix matches {prefix}, the IID contains a tenant 1626 ID, and it may be {tenant ID}.' 1628 o Zero or more IPv6 prefixes that the VM is authorized to 1629 communicate without regard to tenant ID. 1631 Generally speaking, one would expect at least one of those three 1632 lists to contain an entry - at minimum, the VM would be authorized to 1633 communicate with ::/0, which is to say 'anyone'. 1635 Among the generic IPv6 prefixes that may be communicated with, there 1636 may be zero or more IPv4-embedded IPv6 prefix [RFC6052] prefixes that 1637 the VM is permitted to communicate with. For example, if the 1638 [I-D.ietf-v6ops-siit-dc] translation prefix is 2001:db8:0:1::/96, and 1639 the enterprise is using 192.0.2.0/24 as its IPv4 address, the filter 1640 would contain the prefix 2001:db8:0:1:0:0:c000:0200/120. 1642 Note that the lists may also include multicast prefixes as specified 1643 in Appendix B.5.1, such as locally-scoped multicast ff01::/104 or 1644 locally-scoped multicast within the tenant {ff01::/16, tenant id} . 1645 While these access lists are applied in both directions (as a sender, 1646 what prefixes may the destination address contain, and as a receiver, 1647 what prefixes may the source address contain), only the destination 1648 address may contain multicast addresses. For multicast, therefore, 1649 the vSwitch should filter Multicast Listener Discovery [RFC2710] 1650 using the multicast subset, permitting the VM to only join relevant 1651 multicast groups. 1653 B.6. Modified IID using modified Privacy Extension 1655 This variant reflects and builds on the IPv6 Addressing Architecture 1656 [RFC4291] Stateless Address Autoconfiguration [RFC4862], and the 1657 associated Privacy Extensions [RFC4941]. The address format is 1658 identical to that of Appendix B.5, with the exception that The 1659 'System Number within the LAN' is a random number determined by the 1660 host rather than being specified by the controller. 1662 It does have implications, however. It will require 1664 o a modification to [RFC4941] to have the host include the Tenant ID 1665 in the IID, 1667 o a means to inform the host of the Tenant ID, 1669 o a means to inform the vSwitch of the Tenant ID, 1671 o a the vSwitch to follow FCFS SAVI [RFC6620] to learn the addresses 1672 being used by the host, and 1674 o a filter to prevent FCFS SAVI from learning addresses that have 1675 the wrong Tenant ID. 1677 B.6.1. Metaconsiderations 1679 B.6.1.1. Service offered 1681 To Be Supplied 1683 B.6.1.2. Pros and Cons 1685 B.6.1.2.1. The case in favor of this approach 1687 To Be Supplied 1689 B.6.1.2.2. The case against 1691 To Be Supplied 1693 B.6.1.3. Filtering considerations 1695 To Be Supplied 1697 Authors' Addresses 1699 Fred Baker (editor) 1700 Cisco Systems 1701 Santa Barbara, California 93117 1702 USA 1704 Email: fred@cisco.com 1706 Chris Marino 1707 Cisco Systems 1708 San Jose, California 95134 1709 USA 1711 Email: chrmarin@cisco.com 1713 Ian Wells 1714 Cisco Systems 1715 San Jose, California 95134 1716 USA 1718 Email: iawells@cisco.com 1720 Rohit Agarwalla 1721 Cisco Systems 1722 San Jose, California 95134 1723 USA 1725 Email: roagarwa@cisco.com 1726 Sebastian Jeuk 1727 Cisco Systems 1728 San Jose, California 95134 1729 USA 1731 Email: sjeuk@cisco.com 1733 Gonzalo Salgueiro 1734 Cisco Systems 1735 Research Triangle Park, NC 27709 1736 US 1738 Email: gsalguei@cisco.com