cloud-init

accept_ra dropped in network config conversion

Bug #1912545 reported by Antti Myyrä on 2021-01-20

This bug affects 1 person

Affects		Status	Importance	Assigned to	Milestone
	cloud-init	Invalid	Undecided	Antti Myyrä

Bug Description

Hi!

Cloud-init's eni renderer converts version 2 network config to version 1 before rendering. This is eventually done by the _v2_to_v1_ipcfg function within net/network_state.py. When version 2's dhcp6 is set to True, it proceeds to add possible dhcp6-overrides and then continues, disregarding the accept_ra option. This makes specifying the stateless DHCPv6 (ipv6_dhcpv6-stateless in v1 config's subnet type) impossible. Following shortened log shows the issue:

2021-01-19 17:57:02,769 - stages.py[DEBUG]: applying net config names for {'version': 2, 'ethernets': {'ens5': {'match': {'macaddress': '3a:d6:ba:4a:67:23'}, 'dhcp6': True, 'accept_ra': True}}}
2021-01-19 17:57:02,770 - __init__.py[DEBUG]: no interfaces to rename
2021-01-19 17:57:02,770 - stages.py[INFO]: Applying network configuration from ds bringup=False: {'version': 2, 'ethernets': {'ens5': {'match': {'macaddress': '3a:d6:ba:4a:67:23'}, 'dhcp6': True, 'accept_ra': True}}}
2021-01-19 17:57:02,770 - __init__.py[DEBUG]: Selected renderer 'eni' from priority list: None
2021-01-19 17:57:02,774 - network_state.py[DEBUG]: v2(ethernets) -> v1(physical):
{'type': 'physical', 'name': 'ens5', 'mac_address': '3a:d6:ba:4a:67:23', 'match': {'macaddress': '3a:d6:ba:4a:67:23'}, 'subnets': [{'type': 'dhcp6'}]}

(For some reason, converted v1 config also contains v2's match part, which v1 doesn't need, but it shouldn't affect anything.)

My suggested fix would be to have _v2_to_v1_ipcfg use the "ipv6_dhcpv6-stateless" as type when both dhcp6 and accept_ra are present. There's also another SLAAC mode (ipv6_slaac in v1) that uses accept_ra without DHCP, so it should be handled in the same function when accept_ra is set to True but dhcp6 isn't.

I can make a PR to cloud-init's Github repo for this, but would like to hear if anyone sees problems with the suggested approach. Thank you!

Best regards,
Antti Myyrä