Versions Compared

Old Version 1

changes.mady.by.user Marcus Sorensen

Saved on

compared with

New Version 2

changes.mady.by.user Marcus Sorensen

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Bug Reference

The Jira issue associated with this design specTBD

Branch

What branch is this work being done inipv6_vpc

Introduction

Purpose

State the purpose of the document; something like: this is functional specificationS of feature "..." which has Jira ID CS-xyzwFunctional specification for ipv6 support in VPC router and associated networks

References

  • relevant links

...

Glossary

Feature Specifications

  • put a summary or a brief description of the feature in question 
  • list what is deliberately not supported or what the feature will not offer - to clear any prospective ambiguities
  • list all open items or unresolved issues the developer is unable to decide about without further discussion
  • quality risks (test guidelines)
    • functional
    • non functional: performance, scalability, stability, overload scenarios, etc
    • corner cases and boundary conditions
    • negative usage scenarios
  • specify supportability characteristics:
    • what new logging (or at least the important one) is introduced
    • how to debug and troubleshoot
    • what are the audit events 
    • list JMX interfaces
    • graceful failure and recovery scenarios
    • possible fallback or work around route if feature does not work as expected, if those workarounds do exist ofcourse.
    • if feature depends other run-time environment related requirements, provide sanity check list for support people to run
  • explain configuration characteristics:
    • configuration parameters or files introduced/changed
    • branding parameters or files introduced/changed
    • highlight parameters for performance tweaking
    • highlight how installation/upgrade scenarios change
  • deployment requirements (fresh install vs. upgrade) if any
  • system requirements: memory, CPU, desk space, etc
  • interoperability and compatibility requirements:
    • OS
    • xenserver, hypervisors
    • storage, networks, other
  • list localization and internationalization specifications 
  • explain the impact and possible upgrade/migration solution introduced by the feature 
  • explain performance & scalability implications when feature is used from small scale to large scale
  • explain security specifications
    • list your evaluation of possible security attacks against the feature and the answers in your design* *
  • explain marketing specifications
  • explain levels or types of users communities of this feature (e.g. admin, user, etc)

Use cases

...

  • 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

...