Page History

...

Functional specification for ipv6 support in VPC router and associated networks (Work in progress)

References

• relevant links

Feature Specifications

• When creating VPC router , admin will assign support a public block of IPv6 space, a "super cidrCIDR" 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.
    
• IPv6 super cidr would be optional parameter 
• , similar to the IPv4 private space. A /60, for example, might be assigned to the VPC, from which prefixes are carved for tiers.
• Admin can assign prefixes from within the super CIDR space to the individual tiers in that VPC.
  • Address space can be smallest /64, largest == super CIDR.
  • IPv6 prefix will be optional for tier
  • Admin can choose a type for their prefix, SLAAC or DHCP. SLAAC requires /64 sized prefix, and is simple auto-assignment, whereas DHCP can accommodate multiple IPs per instance
  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.
• 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.
    
• 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.

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:

• have a public interface, this network will have IPv6 space assigned to it as well. Router will get an IPv6 address for its public interface from this network, just like it currently does for IPv4.
• When a VPC is started/restarted, the super CIDR and public IP of the router are published via event bus.  We also call a plugin system, such that the admin and network equipment providers have options to program the super CIDR routes to the VPCs via SDN, API, or admin scripts. iBGP route publishing scales quadratically, and eBGP requires dealing with ASN assignments.
• Also, when VPC is started or prefix is added to network, we need to configure the VPC router.
• Work on IPv6 can be broken into stages
  • Basic connectivity
    • Public IPv6 space and IP allocation for VPC router public interfaces (the public network traffic type)
    • Assign super CIDRs to VPCs
    • Assign prefixes to network tiers of type SLAAC
    • publish super CIDR route upon VPC router startup
    • configure SLAAC to network tiers upon VPC router startup
  • Advanced features
    • ip6tables ACLs at VPC router
    • public load balancing via assignment of extra IP on router public interface and haproxy
    • prefixes of type DHCPv6
    • NAT66 service provided by VPC router, allows prefixes of type 'private', that don't require a super CIDR (or require a private one)

Architecture and Design description

Modify table containing VPC info to accomodate ip6 super CIDR information

create new table to track ip6 prefixes to network tiers

Web Services APIs

createNetwork: existing parameters ip6cidr, ip6gateway, startipv6, endipv6 can be leveraged for type dhcpv6, need ip6prefix for slaac and ip6type to choose dhcp,slaac for network

createVpc: add optional IPv6 parameter to assign super CIDR 'ip6cidr'

addIP6RangeToNetwork: Add an IPv6 prefix to tier, given same parameters necessary for createNetwork

updateVpc: Add/remove super CIDR to existing VPC router by adding optional ip6cidr parameterAppendix B: