wido opened a new pull request, #13795:
URL: https://github.com/apache/cloudstack/pull/13795

   ### Description
   
   This PR enables IPv6 link-local addressing on the control (link-local) 
network of system VMs, alongside the existing 169.254.0.0/16 IPv4 addressing. 
With IPv6 explicitly enabled on the control network we can move our SSH 
commands (on at least KVM) to link local IPv6 and remove the 169.254.0.0/16 
addressing in the future. That can significantly reduce the code-base inside 
CloudStack. That's not part of this PR yet.
   
   The existing issue #9957 talks about this and this PR should be groundwork 
for that to be done in the future.
   
   **System VM** (`common.sh`):
   - The control NIC gets an IPv6 link-local address generated with EUI-64 
(`addr_gen_mode=0`), so the address is deterministic and can be calculated from 
the NIC's MAC address
   - Router Advertisements and SLAAC are disabled on the interface 
(`accept_ra=0`, `autoconf=0`); only the link-local address is configured
   - `setup_sshd()` waits for Duplicate Address Detection to complete and adds 
a `ListenAddress fe80::...%ethX` entry to `sshd_config`, so sshd listens on 
both the IPv4 and IPv6 link-local addresses. The sed expressions are idempotent 
across reboots
   - This works for all system VM types, as `setup_sshd()` is always handed the 
control interface (eth0 for CPVM/SSVM on KVM, eth1 for routers)
   
   **Management Server / API**:
   - `listSystemVms` now returns `linklocalip6`: the EUI-64 IPv6 link-local 
address calculated from the control NIC's MAC address using the existing 
(unit-tested) `NetUtils.ipv6LinkLocal()`. This performs the same U/L-bit flip + 
`ff:fe` expansion the kernel does, so the reported address always matches what 
the system VM configures
   - New response field on `SystemVmResponse` (`since 4.23.0`)
   
   **KVM agent**:
   - When the control network is set up, the agent now enables IPv6 (link-local 
only, no RA/SLAAC) on the control bridge (`cloud0`) via a shared 
`enableBridgeIpv6LinkLocal()` helper in `VifDriverBase`, called from 
`BridgeVifDriver`, `OvsVifDriver` and `IvsVifDriver`
   - This runs unconditionally on agent start, so hosts with a pre-existing 
`cloud0` bridge also get IPv6 enabled on it
   - With this, the host can reach system VMs over the control network with 
e.g. `ssh -6 -p 3922 fe80::...%cloud0`
   
   **UI**:
   - The System VMs list and detail views show the new "Link-local/Control IPv6 
address" field
   
   This is a first step towards using IPv6 link-local instead of 169.254.0.0/16 
on the control network. The Management Server still provisions system VMs over 
IPv4; nothing changes for existing deployments.
   
   ### Types of changes
   
   - [ ] Breaking change (fix or feature that would cause existing 
functionality to change)
   - [x] New feature (non-breaking change which adds functionality)
   - [ ] Bug fix (non-breaking change which fixes an issue)
   - [ ] Enhancement (improves an existing feature and functionality)
   - [ ] Cleanup (Code refactoring and cleanup, that may add test cases)
   - [ ] build/CI
   - [ ] test (unit or integration test code)
   
   ### Feature/Enhancement Scale or Bug Severity
   
   #### Feature/Enhancement Scale
   
   - [ ] Major
   - [x] Minor
   
   ### How Has This Been Tested?
   
   - `api`, `server` and `plugins/hypervisors/kvm` compile cleanly
   - `bash -n` on `common.sh`
   - `NetUtils.ipv6LinkLocal()` is covered by existing unit tests in 
`NetUtilsTest` (`testIpv6LinkLocal`), verifying the EUI-64 calculation matches 
the kernel's


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to