canonical / canonical/cloud-init
[enhancement]: Support IPv6 metaserver and IPv6-only NIC for AliYun datasource
- Dominant language
- Python
- Stars
- 3.8k
- Forks
- 1.1k
- Avg merge
- 2d 23h
- Merged PRs (30d)
- 18
Description
# [enhancement]: Support IPv6 metaserver and IPv6-only NIC for AliYun datasource
## Background
Alibaba Cloud ECS provides metadata services over both IPv4 (`100.100.100.200`) and IPv6 (`fd00:100::100:200`).
Currently the AliYun datasource only configures the IPv4 endpoint, which prevents IPv6-only instances from reaching IMDS.
In addition, ECS now allows attaching IPv6-only ENIs (NICs without any IPv4 address). The current `convert_ecs_metadata_network_config()` always emits `dhcp4: true` for every NIC, which causes DHCPv4 to be attempted on IPv6-only interfaces and results in long boot delays / netplan apply failures.
## Proposed Enhancements
1. **Add IPv6 metadata endpoint** to `DataSourceAliYun.metadata_urls`:
```python
metadata_urls = ["http://100.100.100.200", "http://[fd00:100::100:200]"]
```
`wait_for_url` will try both endpoints, so dual-stack and IPv6-only instances are both supported with no behaviour change for IPv4 instances.
2. **Make DHCP rendering metadata-driven** in
`cloudinit/sources/helpers/aliyun.py::convert_ecs_metadata_network_config`:
- If `ipv6s` is present on a NIC → enable `dhcp6` (existing behaviour).
- If `private-ipv4s` is **absent** on a NIC → set `dhcp4: false` and drop `dhcp4-overrides`, so DHCPv4 is not attempted on IPv6-only NICs.
## Use Cases
| NIC metadata | dhcp4 | dhcp6 |
| --------------------------------------- | :---: | :---: |
| `private-ipv4s` only | true | false |
| `private-ipv4s` + `ipv6s` (dual-stack) | true | true |
| `ipv6s` only (IPv6-only ENI) | false | true |
## Related Files
- `cloudinit/sources/DataSourceAliYun.py`
- `cloudinit/sources/helpers/aliyun.py`
- `tests/unittests/sources/test_aliyun.py`
## Backwards Compatibility
- IPv4-only existing instances are unaffected (their NIC metadata always contains `private-ipv4s`).
- Adding a second URL to `metadata_urls` does not change which endpoint is used when IPv4 IMDS responds successfully.
I have a working patch and unit tests covering all three scenarios above.
Happy to open a PR if the maintainers agree with the direction.
Contributor guide
Assessment
This issue has not been assessed yet.