# 20210514 Network Manager initrd defaults
initrd: mixed ipv4,ipv6 slight network behavior change from network-legacy
In `network-legacy` dracut module just supplying `rd.neednet=1` on the kernel
command line equates to `ip=dhcp` where DHCP4 is tried on all interaces. In the
`network-manager` dracut module `rd.neednet=1` equates to `ip=dhcp,dhcp6` where
DHCP4 and DHCP6 are tried, and the first address obtained will win. NM moves
on, closes out the process (run as part of dracut initqueue).
What this means is that in a mixed ipv4/ipv6 network you could end up with:
- both an ipv4 and ipv6 address
- only an ipv6 address
- only an ipv4 address
So the behavior change here is specifically:
- network-legacy: `rd.neednet=1` => guaranteed ipv4 address
- network-manager: `rd.neednet=1` => might get an ipv6 address only
Now, I think the NM default *should* keep being to try ipv4 and ipv6,
but we don't want to artificially add a timeout for *EVERY* machine bootup.
What we could do is introduce compat code to smooth over the behavior change
to smooth over the behavior change between `network-legacy` and `network-manager`.
Scenarios:
1. ip=dhcp,dhcp6: network only ipv6:
- proceed as soon as ipv4 address is obtained
- no added wait on ipv4 only networks (vast majority most likely)
- maintains behavior compatibility with network-legacy
2. ip=dhcp,dhcp6: network mixed ipv4, ipv6:
- will proceed with only ipv6 adress only after configured timeout
- hopefully has been enough time to also get ipv4 addr
3. ip=dhcp,dhcp6: network only ipv6:
- proceed with only ipv6 address after configured timeout for ipv4
- unfortunately, introduced wait for ipv6 only networks
- avoid by specifying `ip=dhcp6` instead
Unfortunately there is currently no way to do this with existing connection
profile options. We'd need something like:
```
ipv4.may-fail="yes, but not before $x seconds"
```
NOTE: Moving NM in the initrd to run as a systemd unit instead as part of
initqueue should help here because NM will continue to run instead
of being taken down, but might not actually resolve all issues
because initramfs networking code is not likely to sufficiently retry.
Also we're probably not likely to move to the new initramfs systemd
code until RHEL9.