THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
Bug Reference
TBD
Branch
ipv6_vpc
Introduction
Purpose
Functional specification for ipv6 support in VPC router and associated networks
References
- relevant links
Feature Specifications
- When creating VPC router, admin will assign a block "super cidr" for ipv6, as is currently done for IPv4
- May consider skipping this, I can't really think of a reason to have a giant block assigned to VPC, it's not like the pub/private ip4 space. Instead we can just allow networks to be assigned IPv6 blocks. The main reason I could think of is if the admin needed to manually set a route upstream, it would be easier to send a /60 to a VPC once and then it could manage the whole block. One could do that anyway, without 'assigning' the block in cloudstack, although it might be nice to be able to see/list the assignment and sanity check it when an admin goes to add a new /64 to a network.
- May consider skipping this, I can't really think of a reason to have a giant block assigned to VPC, it's not like the pub/private ip4 space. Instead we can just allow networks to be assigned IPv6 blocks. The main reason I could think of is if the admin needed to manually set a route upstream, it would be easier to send a /60 to a VPC once and then it could manage the whole block. One could do that anyway, without 'assigning' the block in cloudstack, although it might be nice to be able to see/list the assignment and sanity check it when an admin goes to add a new /64 to a network.
- IPv6 super cidr would be optional parameter
- When deploying a network, admin would optionally provide a "sub cidr" for IPv6, as is currently done for IPv4
- One could potentially assign multiple blocks to a network, say one stateless autoconfig cidr and one dhcp cidr, or multiple cidrs that are manually managed on instances. Blocks would need to be marked as SLAAC, DHCP, or Manual.
- One could potentially assign multiple blocks to a network, say one stateless autoconfig cidr and one dhcp cidr, or multiple cidrs that are manually managed on instances. Blocks would need to be marked as SLAAC, DHCP, or Manual.
- IPv6 DNS settings already exist for zones, but instances could also leverage existing IPv4 VPC router DNS resolver.
- IPv6 ip allocation already exists for shared networks, assuming we can leverage that code (or at least the properties in the DB/VO) if/when we get to instance allocation.
- VPC router wlll run DHCPv6 and/or stateless autoconfig, some options would include:
- stateless autoconfig addr/gw + DHCPv6 for DNS
- stateless autoconfig addr/gw/dns (linux, freebsd guests only)
- stateless autoconfig addr/gw + DNS via DHCPv4 addr
- DHCPv6 ip/gw/dns
- both stateless autoconfig and DHCPv6 ips on an instance
- Routers themselves need IPv6 addresses, so we need to add support for it in public ip ranges.
- Would VPCs be SLAAC, or would they be assigned from pool by CS, as in existing IPv4 public NAT IP? Probably the latter.
- Would VPCs be SLAAC, or would they be assigned from pool by CS, as in existing IPv4 public NAT IP? Probably the latter.
- Need some way to get the routes upstream so that traffic for blocks ends up at VPC. I think BGP or similar might be too messy or require too much setup (quadratic scaling of iBGP peers, autoconfig of the service). We could leave a hook for SDN vendors (or router vendors who have an API-enabled router) to provide plugins so that when a router is started and/or a new range is assigned/removed it could contact the upstream routers and apply the routes.
- Deployment could be broken into stages potentially
- could support just SLAAC block first + DNS via IPv4 private gw for first phase
- This would consist of adding the columns and/or table to track the blocks for vpc/network, and a Command to send the details for VPC, but no dealing with ip assignments to guests or DHCPv6 changes.
- Could add a DHCP block per network in second phase. This would handle the individual ip assignments and programming DHCP on the router for each.
- could add ability to edit/upgrade existing VPCs to add SLAAC and/or DHCP blocks in another phase (although adding SLAAC block may be simple enough to combine in an existing phase)
- IPv6 ACLs could also be done separately, or at the same time but a separate feature. This may require the caveat that adding an IPv6 config to a VPC opens it up to the world (for IPv6), if the separate feature doesn't make it into the same release.
- could support just SLAAC block first + DNS via IPv4 private gw for first phase
Architecture and Design description
- discussion of alternatives amongst design ideas, their resources/time tradeoffs and limitations. Explain why a certain design idea is chosen over others
- highlight architectural patterns being used (queues, async/sync, state machines, etc)
- talk about main algorithms used
- explain what components are being changed and what the dependent components are
- regarding database: talk about tables being added/modified
- performance implications: what are the improvements or risks introduced to capacity, response time, resources usage and other relevant KPIs
- preferably show class diagrams, sequence diagrams and state diagrams
- if possible, publish signatures of all methods classes and interfaces implement, and the explain the object information of different classes
Web Services APIs
list changes to existing web services APIs and new APIs introduced with signatures and throughout documentation
UI flow
- either demonstrate it visually here or link to relevant mockups
IP Clearance
- what dependencies will you be adding to the project?
- are you expecting to include any code developed outside the Apache CloudStack project?
Appendix
Appendix A:
Appendix B:
Overview
Content Tools
Apps