systemvm: enable IPv6 link-local on the control network - #13795
Open
wido wants to merge 2 commits into
Open
Conversation
Bring up an EUI-64 based IPv6 link-local address on the control NIC of system VMs and make sshd listen on it, in addition to the existing 169.254.0.0/16 IPv4 address. Since the address is generated with EUI-64 it can be calculated from the MAC address of the control NIC. listSystemVms now returns it as 'linklocalip6', calculated by the Management Server using NetUtils.ipv6LinkLocal(), and the UI shows it in the System VMs view. On KVM the agent enables IPv6 (link-local only, no RA/SLAAC) on the control bridge (cloud0) when setting up the control network, so the host can reach system VMs over IPv6 once this is used.
The nftables ip6_firewall and ip6_acl tables created on VRs with IPv6 networking have an input hook chain with policy drop, which applies to all interfaces including the control NIC. Accept TCP 3922 between link-local addresses so sshd remains reachable on the IPv6 link-local address of the control interface. Restricting both saddr and daddr to fe80::/10 ensures no global address can reach sshd.
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## main #13795 +/- ##
=========================================
Coverage 19.65% 19.65%
Complexity 19792 19792
=========================================
Files 6368 6368
Lines 574881 574896 +15
Branches 70351 70352 +1
=========================================
+ Hits 112970 112975 +5
- Misses 449639 449648 +9
- Partials 12272 12273 +1
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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):addr_gen_mode=0), so the address is deterministic and can be calculated from the NIC's MAC addressaccept_ra=0,autoconf=0); only the link-local address is configuredsetup_sshd()waits for Duplicate Address Detection to complete and adds aListenAddress fe80::...%ethXentry tosshd_config, so sshd listens on both the IPv4 and IPv6 link-local addresses. The sed expressions are idempotent across rebootssetup_sshd()is always handed the control interface (eth0 for CPVM/SSVM on KVM, eth1 for routers)Management Server / API:
listSystemVmsnow returnslinklocalip6: 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:feexpansion the kernel does, so the reported address always matches what the system VM configuresSystemVmResponse(since 4.23.0)KVM agent:
cloud0) via a sharedenableBridgeIpv6LinkLocal()helper inVifDriverBase, called fromBridgeVifDriver,OvsVifDriverandIvsVifDrivercloud0bridge also get IPv6 enabled on itssh -6 -p 3922 fe80::...%cloud0UI:
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
Feature/Enhancement Scale or Bug Severity
Feature/Enhancement Scale
How Has This Been Tested?
api,serverandplugins/hypervisors/kvmcompile cleanlybash -noncommon.shNetUtils.ipv6LinkLocal()is covered by existing unit tests inNetUtilsTest(testIpv6LinkLocal), verifying the EUI-64 calculation matches the kernel's