You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Next »

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
  • ipv6 super cidr will be optional parameter 
  • When deploying a network, admin will optionally provide a "sub cidr" for ipv6, as is currently done for ipv4
    • 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
  • ipv6 DNS settings already exist for zones
  • ipv6 ip allocation already exists for shared networks, assuming we can leverage that code (or at least the properties in the DB/VO).
  • vpc router wlll run dhcp6 and 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
  • 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
    • 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:

Appendix B:

  • No labels