Re:_ DHCPv6_IA_PD_-_how-to

[Long message, apologies.  Thoughts mostly after the log output.]

> On Jul 24, 2024, at 04:12, Roy Marples <roy@marples.name> wrote:
> dhcpcd can indeed setup the internal networks within the PD for you.
> If my answer to Kar's question is not enough, then please let me know.

Alright.  Time passes, and I have a new system (FreeBSD 14.1) reach to
slot in in place of my old router (FreeBSD 11.4).  With Roy’s help
off-list, I have a config that I think will work:

duid
persistent
vendorclassid
option classless_static_routes
option rapid_commit
require dhcp_server_identifier
slaac private
noipv6rs
interface vlan0
  ipv6only
  noipv4
  noipv4ll
  ia_pd 0/::/56 vlan1/32 vlan2/42 vlan3/52 vlan4/62 vlan5/72 vlan6/82 vlan7/92

I brought the system up as an IPv4 router with no IPv6 configured,
then ran “dhcpcd --noconfigure -d -B”. Output is long, but select
bits (including top and bottom) show:

——8<——8<——8<——8<----
main: control_open: Connection refused
dhcpcd-10.0.8 starting
spawned privileged proxy on PID 43738
spawned network proxy on PID 43930
spawned controller proxy on PID 44915
DUID 00:01:00:01:2e:3e:5e:7f:a4:53:0e:79:b9:82
sandbox unavailable: capsicum
lo0: ignoring due to interface type and no config
pflog0: unsupported interface type 0xf6
ix0: executing: /usr/local/libexec/dhcpcd-run-hooks PREINIT
ix0: executing: /usr/local/libexec/dhcpcd-run-hooks CARRIER
ix1: executing: /usr/local/libexec/dhcpcd-run-hooks PREINIT
vlan0: executing: /usr/local/libexec/dhcpcd-run-hooks PREINIT
vlan0: executing: /usr/local/libexec/dhcpcd-run-hooks CARRIER
vlan1: executing: /usr/local/libexec/dhcpcd-run-hooks PREINIT
vlan1: executing: /usr/local/libexec/dhcpcd-run-hooks CARRIER
vlan2: executing: /usr/local/libexec/dhcpcd-run-hooks PREINIT
vlan2: executing: /usr/local/libexec/dhcpcd-run-hooks CARRIER
vlan3: executing: /usr/local/libexec/dhcpcd-run-hooks PREINIT
[…]
vlan0: IAID ff:00:00:06
vlan0: IA type 25 IAID 00:00:00:00
vlan0: reading lease: /var/db/dhcpcd/vlan0.lease6
vlan0: rebinding prior DHCPv6 lease
vlan0: delaying REBIND6 (xid 0x329d93), next in 1.0 seconds
vlan0: multicasting REBIND6 (xid 0x329d93), next in 1.1 seconds
vlan0: REPLY6 received from fe80::3e8a:b0ff:fe3e:4dce
vlan0: renew in 3600, rebind in 5760, expire in 7200 seconds
vlan0: writing lease: /var/db/dhcpcd/vlan0.lease6
vlan0: executing: /usr/local/libexec/dhcpcd-run-hooks REBIND6
[…]
vlan6: executing: /usr/local/libexec/dhcpcd-run-hooks BOUND
vlan5: DAD completed for 192.168.123.46
vlan5: leased 192.168.123.46 for 3105 seconds
vlan5: renew in 1552 seconds, rebind in 2716 seconds
vlan5: writing lease: /var/db/dhcpcd/vlan5.lease
vlan5: executing: /usr/local/libexec/dhcpcd-run-hooks BOUND
vlan2: DAD completed for 172.31.83.42
vlan2: leased 172.31.83.42 for 755 seconds
vlan2: renew in 377 seconds, rebind in 660 seconds
vlan2: writing lease: /var/db/dhcpcd/vlan2.lease
vlan2: executing: /usr/local/libexec/dhcpcd-run-hooks BOUND
ix0: ARP probing 169.254.156.162 (2 of 3), next in 1.8 seconds
ix1: ARP probing 169.254.188.53 (2 of 3), next in 1.7 seconds
ps_bpf_recvmsg: Network is down
vlan1: ARP probing 169.254.156.162 (3 of 3), next in 2.0 seconds
ix0: ARP probing 169.254.156.162 (3 of 3), next in 2.0 seconds
ix1: ARP probing 169.254.188.53 (3 of 3), next in 2.0 seconds
ps_bpf_recvmsg: Network is down
vlan1: using IPv4LL address 169.254.156.162
zsh: segmvlan3ation fault  sudo dhcpcd --noconfigure -d -B
———8<———8<—-—8<----

I’m sure there are “stupid user tricks” here.  I think the
primary problem is that it’s using more than the one interface
I want it to.  It also looks like it’s picking up IPv4 addresses
from the local ISC dhcpd on all of the other interfaces.  I’m
glad it wasn’t trying to configure them!

Then, of course, the SEGV.  So, first I guess I need to tell
it to not try interfaces other than the one I want.  For my
case.  However there are a few things I think may want to
be worked on:

1. The SEGV, obviously
2. It seems to be trying things on ix1, despite no carrier.
I understand keeping an eye on it, but not sending DISCOVER
and ARP et al.
3. It seems it shouldn’t accept a DHCP address from it’s
local address.  I question if it should try to _get_ an
address if there’s already an address, but.  Maybe this
is a dhcpd problem, where it shouldn’t respond to requests
from the local address?

Thanks all, sorry for the long message.

                      - Chris