doc: document missing IPv6 subnet types

[ajmyyra]

doc: missing IPv6 subnet types to networking config v1 docs

Added some missing IPv6 subnet configuration types (ipv6_dhcpv6-stateful, ipv6_dhcpv6-stateless, ipv6_slaac) to Networking config v1 documentation.

[OddBloke]

Thanks for this submission @ajmyyra! I've got one minor inline suggestion, to retain consistency.

A broader question I have though (which I'll likely need to poke other cloud-init devs to get the answer to) is whether or not we support these fully, or if we need to add a disclaimer. The reason I ask is that when we render this config:

version: 1
config:
  - type: physical
    name: slaac0
    subnets:
      - type: ipv6_slaac
  - type: physical
    name: stateful0
    subnets:
      - type: ipv6_dhcpv6-stateful
  - type: physical
    name: stateless0
    subnets:
      - type: ipv6_dhcpv6-stateless
  - type: physical
    name: dhcp0
    subnets:
      - type: dhcp6

(using cloud-init devel net-convert -p n1.yaml -k yaml -d out -O netplan -D ubuntu), this is the netplan configuration that is generated (with static header removed):

network:
    version: 2
    ethernets:
        dhcp0:
            dhcp6: true
        slaac0:
            dhcp6: true
        stateful0:
            dhcp6: true
        stateless0:
            dhcp6: true

I haven't done enough with netplan and/or IPv6 exactly sure what configuration we should expect, but all these definitions being identical doesn't look right to me. Perhaps it's somehow the case that this is correct, but I'd like confirmation of that before we start advertising this in our documentation.

For comparison, the various generated sysconfig files are different:

$ cat out/etc/sysconfig/network-scripts/ifcfg-*
# Created by cloud-init on instance boot automatically, do not edit.
#
BOOTPROTO=none
DEVICE=dhcp0
DHCPV6C=yes
IPV6INIT=yes
NM_CONTROLLED=no
ONBOOT=yes
TYPE=Ethernet
USERCTL=no
# Created by cloud-init on instance boot automatically, do not edit.
#
BOOTPROTO=none
DEVICE=slaac0
IPV6INIT=yes
IPV6_AUTOCONF=yes
NM_CONTROLLED=no
ONBOOT=yes
TYPE=Ethernet
USERCTL=no
# Created by cloud-init on instance boot automatically, do not edit.
#
BOOTPROTO=dhcp
DEVICE=stateful0
DHCPV6C=yes
IPV6INIT=yes
NM_CONTROLLED=no
ONBOOT=yes
TYPE=Ethernet
USERCTL=no
# Created by cloud-init on instance boot automatically, do not edit.
#
BOOTPROTO=none
DEVICE=stateless0
DHCPV6C=yes
DHCPV6C_OPTIONS=-S
IPV6INIT=yes
IPV6_AUTOCONF=yes
NM_CONTROLLED=no
ONBOOT=yes
TYPE=Ethernet
USERCTL=no

as are the ENI stanzas:

auto lo
iface lo inet loopback

auto dhcp0
iface dhcp0 inet6 dhcp

auto slaac0
iface slaac0 inet6 auto
    dhcp 0

auto stateful0
iface stateful0 inet6 dhcp

auto stateless0
iface stateless0 inet6 auto
    dhcp 1

[raharper]

I haven't done enough with netplan and/or IPv6 exactly sure what
configuration we should expect, but all these definitions being identical
doesn't look right to me. Perhaps it's somehow the case that this is
correct, but I'd like confirmation of that before we start advertising this
in our documentation.

Oddly enough, for netplan all of those configs are correct for netplan; In the netplan docs, it has this section:

dhcp6 (bool)

    Enable DHCP for IPv6. Off by default. This covers both stateless DHCP -
    where the DHCP server supplies information like DNS nameservers but not the
    IP address - and stateful DHCP, where the server provides both the address
    and the other information.

    If you are in an IPv6-only environment with completely stateless
    autoconfiguration (SLAAC with RDNSS), this option can be set to cause the
    interface to be brought up. (Setting accept-ra alone is not sufficient.)
    Autoconfiguration will still honour the contents of the router advertisement
    and only use DHCP if requested in the RA.

    Note that rdnssd(8) is required to use RDNSS with networkd. No extra
    software is required for NetworkManager.

[1] https://netplan.io/reference/

The only other critical flag for netplan is 'accept-ra' which is independent from SLAAC, DHCPv6 statefull/stateless

We have in-tree unittests for these subnet types in where else but tests/unittest/test_net.py

[OddBloke]

Thanks for the clarification, Ryan! This LGTM in that case, I'll apply my minor fix and land it.