IPv6 Addressing

Oakestra makes use of the reserved private IPv6 subnet fc00::/7 for its service addressing and uses the following network split for IPv6 networking

SubnetSubnet descriptionTag
fc00::/7full Oakestra networkall
fc00::/120 - fdfd:ffff:ffff:ffff:ffff:ffff:ffff:0/120Worker subnetsworker
fdfe::/16reserved for future usereserved
fdff::/16Service IP subnetservice
fdff:0000::/21Instance IP subnet 1instance
fdff:1000::/21reserved for Closest balancing policybalance
fdff:2000::/21Round Robin balancingbalance
balance
fdff:f000::/21Balancing 15balance
fdff:0800::/21Instance IP subnet 2instance
fdff:1800::/21Balancing 16balance
fdff:2800::/21Balancing 17balance
balance
fdff:f800::/21Balancing 30balance

In the following we give a short meaning for each tag.

  • all : entire Oakestra platform
  • worker : subnet assigned to a single worker node associated with a cluster inside Oakestra
  • service : semantic service address subnet
  • instance : single semantic service address mapped to a service instance throughout the lifetime of the instance
  • balance : semantic service address, addressing all multiple instance addresses of a service in order to enable semantic addressing for balance policies

Exhausted Address Space

Oakestra makes use of the whole IPv6 address space available. This may cause issues with other applications requiring an IPv6 address from the fc00::/7 address space in order to function, as we make changes to the iptables local firewall, as well as the host routing tables, that may influence any third-party application’s functionality.

Example Application

If we deploy an example application A with Service S and two instances (S1 and S2) on the same worker node W, an example address configuration can be the following:

App AAddresses / Subnets assigned
Worker Wfc00::c0:ffee:/120
SRound Robin: fdff:2000::30
S1Instance IP: fdff::2f
Namespace IP: fc00::c0:ffee:2
S2Instance IP: fdff::30
Namespace IP: fc00::c0:ffee:3

Limited IPv6 Capabilities

The Oakestra platform currently only supports a very basic form of IPv6 addressing in the sense that there is a strict 1-to-1 mapping between IPv4 and IPv6 addresses. The limiting factor remains the IPv4 address space and there currently is no support for standalone IPv6 networking.

Extending the Network Capabilities

Extending the network capabilities by a new IPv6 service IP follows the same steps as in our IPv4 documentation in general, with the need of a special database handling for each network address space.

Since the IPv6 service address space is hard-split into their distinct networks, a reservation for such a split needs to be done. In the best case you should create an issue for that on the official GitHub repository, in order to let the maintainers, and everyone else know, that a part of the network split is reserved for your upcoming new routing policy.

From an implementation standpoint, in addition to the steps described in our IPv4 documentation, special database handling is needed to be implemented in the root-service-manager, who does the bookkeeping of available service IP addresses in the network.

You can base your implementation on the already existing functions in place, which you can find in the root-service-manager, more specifically in network/subnetwork_management.py.