This gives me a bit of repudiability in case someone decides to point
someunsavorydomain.net at my server -- I don't want to automatically
respond indicating "yep, this is mine!"
Don't write documentation tired, kids! I thought I was missing this, so
I had added it…to the wrong file, while similar notes were already
present in the file where they belonged!
It looks like this was CLOSED WONTFIX: How can we _possibly_ know that
upon an error, the developer might want us to send an indication of that
error??!!1! Snark aside (mine and his): it looks like there's not a
great way to enable sane error behavior globally :/
https://caddy.community/t/handling-errors-globally/17174/2
In the future, I should probably make this a snippet or something.
When `ip=dhcp` is passed as a kernel param (which I assume, but don't
know for sure, just gets passed to systemd and probably then to
systemd-networkd or NetworkManager or whatever does the networking in
the initrd?), IPv6 doesn't come up. With the param, bad IPv6:
```text
2: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 3c:52:82:00:46:d6 brd ff:ff:ff:ff:ff:ff
altname enp0s31f6
inet 192.168.1.20/24 brd 192.168.1.255 scope global eno1
valid_lft forever preferred_lft forever
inet6 2601:441:8301:8af7:94e1:4d4c:73c2:ac31/64 scope global temporary dynamic
valid_lft 322763sec preferred_lft 86330sec
inet6 fd0a:8f9f:6f83:0:3e52:82ff:fe00:46d6/64 scope global dynamic mngtmpaddr proto kernel_ra
valid_lft forever preferred_lft forever
inet6 2601:441:8301:8af7:3e52:82ff:fe00:46d6/64 scope global dynamic mngtmpaddr proto kernel_ra
valid_lft 322763sec preferred_lft 322763sec
inet6 fe80::3e52:82ff:fe00:46d6/64 scope link proto kernel_ll
valid_lft forever preferred_lft forever
```
whereas without the param I get good (whatever that means) addresses:
```text
2: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether 3c:52:82:00:46:d6 brd ff:ff:ff:ff:ff:ff
altname enp0s31f6
inet 192.168.1.20/24 brd 192.168.1.255 scope global dynamic noprefixroute eno1
valid_lft 43188sec preferred_lft 43188sec
inet6 fd0a:8f9f:6f83::33b/128 scope global dynamic noprefixroute
valid_lft 43190sec preferred_lft 43190sec
inet6 2601:441:8301:8af7::33b/128 scope global dynamic noprefixroute
valid_lft 43190sec preferred_lft 43190sec
inet6 2601:441:8301:8af7:b572:fc6c:ba27:dcdb/64 scope global temporary dynamic
valid_lft 322965sec preferred_lft 86235sec
inet6 2601:441:8301:8af7:f3f0:df23:a6bb:7d25/64 scope global dynamic mngtmpaddr noprefixroute
valid_lft 322965sec preferred_lft 322965sec
inet6 fd0a:8f9f:6f83:0:485e:f55d:fa1d:cef4/64 scope global temporary dynamic
valid_lft 604790sec preferred_lft 86235sec
inet6 fd0a:8f9f:6f83:0:7851:1417:807:f017/64 scope global mngtmpaddr noprefixroute
valid_lft forever preferred_lft forever
inet6 fe80::eb0c:1983:24a5:3e42/64 scope link noprefixroute
valid_lft forever preferred_lft forever
```
I'm honestly not entirely sure what this _should_ look like, but what I
_do_ know is that in the "bad" configuration, SSH takes an extra ~10s to
connect as it has to wait for two ~5s `No route to host` timeouts:
```console
[chandler@oscar:~]$ ssh -v root@bert
OpenSSH_9.8p1, OpenSSL 3.0.14 4 Jun 2024
debug1: Reading configuration data /home/chandler/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 5: Applying options for *
debug1: Connecting to bert [fd0a:8f9f:6f83::33b] port 22.
debug1: connect to address fd0a:8f9f:6f83::33b port 22: No route to host
debug1: Connecting to bert [2601:441:8301:8af7::33b] port 22.
debug1: connect to address 2601:441:8301:8af7::33b port 22: No route to host
debug1: Connecting to bert [192.168.1.20] port 22.
debug1: Connection established.
```
Future work: What _should_ my IPv6 config look like? Is there any way I
can keep network config stable between the initrd and the booted system?
Why is this recommended against?
> The default is false when systemd is enabled in initrd, because the
> systemd-networkd documentation suggests it.
Chandler Swift