---
# System prepended metadata

title: 'Networking WG, 30th March 2023'
tags: [' oakestra', networking]

---

---
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 

