---
title: "Networking WG, 30th March 2023"
tags: networking, oakestra
datetime: 2023-03-30T16:00UTC
location: Online, Discord, the `#voice-meeting` voice channel
teams:
- networkingWG
participants:
- Giovanni (GB)
- Simon (SZ)
---

## 📋 Agenda

- [ ] IPv4 to IPv6 load balancing
- [x] SZ: Revise IPv6 subnetworking for future-proofing (leave address spaces open for future)
- [ ] NM: Discuss about the proxy gateway solutions when cluster is within a private n/w
- [ ] NM: Security aspects
- [ ] GB & SZ: Create internal documentation for this IP blocks: Add detailed documentation to https://hackmd.io/@oakestra/HyxDGGBRj/edit
- [ ] SZ: Finalize the IPv6 addressing logic
- [ ] GB & SZ: Think about external facing services in Oakestra, especially concerning category 2 as discussed.
- [ ] GB: create an IPv4 network split like the IPv6 one.
- [ ] GB: create an issue about netcfg.json v2.0

## 📢 Discussions

SZ: future-proofing: remove one of reserved blocks for service IPs and we can reserve them for the future. Is it a good solution for orgs? We can remove one bit and split the network in half. Removing the fd00:: can partition the netwrk in half and reserve half of the addresses for other purposes.

SZ: solution proposal:

|Subnet |Subnet description |
|-----------------|--------------------------|
|`fc00::/7` |full Oakestra subnetwork |
|`fc00::/120 - fdfd:ffff:ffff:ffff:ffff:ffff:ffff:ff00/120`|Worker subnets|
|`fdfe::/16` |reserved | 2^112 -> flexible
|`fdff::/16` |Service IP subnet |
|`fdff:0000::/21` |Instance IP subnet 1 |
|`fdff:1000::/21` |Balancing 1 |
|`fdff:2000::/21` |Balancing 2 |
|... |... |
|`fdff:f000::/21` |Balancing 15 |
|`fdff:0800::/21` |Instance IP subnet 2 |
|`fdff:1800::/21` |Balancing 16 |
|`fdff:2800::/21` |Balancing 17 |
|... |... |
|`fdff:f800::/21` |Balancing 30 |

SZ: question:
The tunnel device has IP (arbitrarily selected) 10.19.254.1 -> 10.30.0.0/12 which is only on worker node, reaching the whole oakestra network. What is the network boundary of the tunnel? Cluster? Worker?

GB: The tunnel/proxy handles the outgoing traffic [here](https://github.com/oakestra/oakestra-net/blob/32eb067688fab020652ccc4e317e8931e71844a3/node-net-manager/proxy/ProxyTunnel.go#L186) calling the function implemented [here](https://github.com/oakestra/oakestra-net/blob/32eb067688fab020652ccc4e317e8931e71844a3/node-net-manager/proxy/ProxyTunnel.go#L499)
We check if packet destination is towards a service deployed in the local node subnetwork [here](https://github.com/oakestra/oakestra-net/blob/32eb067688fab020652ccc4e317e8931e71844a3/node-net-manager/proxy/ProxyTunnel.go#L508). In that case we forward the packet locally back to the node's bridge. Otherwise, we tunnel the traffic using UDP connection towards the external worker node.

SZ: at some point you have a worker node embedding this hard coded 10.19.254.1 address. Maybe use a fixed subnet from the reserved subnet or make it flexible.

GB: Yes, rn is hardcoded [here](https://github.com/oakestra/oakestra-net/blob/32eb067688fab020652ccc4e317e8931e71844a3/node-net-manager/proxy/ProxyTunnel.go#L99) and can be chosen dynamically instead.

GB: RN bridge is always first address of the subnetwork. The tunnel can be the second or the last. Routing towards fdff::/16 in IPv6.

## 🛠️ TODOs

- [ ] IPv4 to IPv6 load balancing
- [ ] SZ: Discuss about dual stack implementation and possible deprecation of IPv4
- [ ] NM: Discuss about the proxy gateway solutions when cluster is within a private n/w
- [ ] NM: Security aspects
- [ ] GB & SZ: Create internal documentation for this IP blocks: Add detailed documentation to https://hackmd.io/@oakestra/HyxDGGBRj/edit
- [ ] SZ: Finalize the IPv6 addressing logic
- [ ] GB & SZ: Think about external facing services in Oakestra, especially concerning category 2 as discussed.
- [ ] GB: create an IPv4 network split like the IPv6 one.
- [ ] GB: create an issue about netcfg.json v2.0