Page History

...

Feature Specifications

• When creating vpc VPC router, admin will assign a block "super cidr" for ipv6, as is currently done for ipv4IPv4
  • 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.
    
• IPv6 super cidr would ipv6 super cidr will be optional parameter 
• When deploying a network, admin will would optionally provide a "sub cidr" for ipv6IPv6, as is currently done for ipv4IPv4
  • One could potentially assign multiple blocks to a network, say one stateless autoconfig cidr and one dhcp cidr
• Example: user issues a /60 ipv6 block to vpc, and each network is a /64. This allows for standard stateless autoconfig support and up to 16 networks for the vpc
• • , or multiple cidrs that are manually managed on instances. Blocks would need to be marked as SLAAC, DHCP, or Manual.
    
• IPv6 ipv6 DNS settings already exist for zones, but instances could also leverage existing IPv4 VPC router DNS resolver.
• IPv6 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 VPC router wlll run dhcp6 DHCPv6 and/or stateless autoconfig, admins can choose which to use in their guests 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 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 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.
    
    

...