PD is not being delegated even though DHCPv6 advertise is seen

[xhci]

My WAN interface is em0 & LAN is em1. I'm running OpenBSD 7.2 & have had this working with a different ISP. For some reason, dhcpcd is not assigning a prefix to my LAN interface on the new ISP.

dhcpcd.conf:

duid
persistent
option rapid_commit
require dhcp_server_identifier

script ""

noipv6rs
ipv6only
allowinterfaces em0 em1
interface em0
  ipv6rs
  ia_na 1 
  ia_pd 2/::/56 em1/1   # have also tried "ia_pd 2 em1/0"

/var/log/daemon:

Jan 17 22:58:58 aries dhcpcd[97610]: dhcpcd-9.4.1 starting
Jan 17 22:58:58 aries dhcpcd[44588]: DUID 00:01:00:01:2b:57:01:f8:00:0d:b9:43:58:00
Jan 17 22:58:58 aries dhcpcd[44588]: em0: IAID b9:43:58:00
Jan 17 22:58:58 aries dhcpcd[44588]: em0: IA type 3 IAID 00:00:00:01
Jan 17 22:58:58 aries dhcpcd[44588]: em0: IA type 25 IAID 00:00:00:02
Jan 17 22:58:58 aries dhcpcd[44588]: em0: soliciting a DHCPv6 lease
Jan 17 22:58:58 aries dhcpcd[44588]: em1: IAID b9:43:58:01
Jan 17 22:58:59 aries dhcpcd[44588]: em0: soliciting an IPv6 router
Jan 17 22:58:59 aries dhcpcd[44588]: em0: Router Advertisement from fe80::200:5eff:fe00:101
Jan 17 22:58:59 aries dhcpcd[44588]: em0: adding address 2605:59c8:5100:b99d:45e9:9285:ef9c:f666/64
Jan 17 22:58:59 aries dhcpcd[44588]: em0: adding route to 2605:59c8:5100:b99d::1/64
Jan 17 22:58:59 aries dhcpcd[44588]: em0: adding default route via fe80::200:5eff:fe00:101

advertisement capture:

Frame 544: 179 bytes on wire (1432 bits), 179 bytes captured (1432 bits)
Ethernet II, Src: IETF-VRRP-VRID_01 (00:00:5e:00:01:01), Dst: Broadcast (ff:ff:ff:ff:ff:ff)
Internet Protocol Version 6, Src: 2605:59c8:5100:b99d::1, Dst: fe80::20d:b9ff:fe43:5800
User Datagram Protocol, Src Port: 547, Dst Port: 546
DHCPv6
    Message type: Advertise (2)
    Transaction ID: 0x6169b1
    Client Identifier
        Option: Client Identifier (1)
        Length: 14
        DUID: 000100012b5701f8000db9435800
        DUID Type: link-layer address plus time (1)
        Hardware type: Ethernet (1)
        DUID Time: Jan 15, 2023 11:27:04.000000000 MST
        Link-layer address: 00:0d:b9:43:58:00
    Server Identifier
        Option: Server Identifier (2)
        Length: 10
        DUID: 00020000c71000000077
        DUID Type: assigned by vendor based on Enterprise number (2)
        Enterprise ID: Advanced Datacentre Systems Ltd (50960)
        Identifier: 00000077
    Identity Association for Prefix Delegation
        Option: Identity Association for Prefix Delegation (25)
        Length: 41
        IAID: 00000002
        T1: 300
        T2: 480
        IA Prefix
            Option: IA Prefix (26)
            Length: 25
            Preferred lifetime: 600
            Valid lifetime: 1200
            Prefix length: 56
            Prefix address: 2605:59c8:517a:2c00::
    DNS recursive name server
        Option: DNS recursive name server (23)
        Length: 32
         1 DNS server address: 2606:4700:4700::1111
         2 DNS server address: 2001:4860:4860::8888

based on the capture, it looks like I'm assigned a /56 corresponding to 2605:59c8:517a:2c00::, but it never gets assigned to em1.

[rsmarples]

Looks like dhcpcd didn't react to the DHCP6 advert at all. Try adding debug get any diagnostic? Does removing the ia_na directive help as you didn't get a NA address in the advert?

[xhci]

Looks like dhcpcd didn't react to the DHCP6 advert at all. Try adding debug get any diagnostic?

Does removing the ia_na directive help as you didn't get a NA address in the advert?

The "-d" flag seems to output pretty much the same thing, but I'll try again.

The ia_na advertisement comes in as an ICMPv6 packet separately, and does seem to be processed. I can post that in a bit if you'd like to see it.

Edit - it's early here, and I read your comment backwards :). Removing ia_na has the same behavior with regards to PD.

[rsmarples]

Could there be a firewall blocking the traffic? tcpdump listens below the firewall.

[xhci]

Could there be a firewall blocking the traffic? tcpdump listens below the firewall.

That's what I'm thinking as well, but curiously this worked fine with my other ISP. I've followed the OpenBSD recommendations for rules (in the pkg-readme) & have had dhcpcd chugging along happily for a couple years.

I'll post an update here after work. I'd like to get you quality debug info if the problem isn't on my end.

Thanks!

[xhci]

This did turn out to be a firewall rule.

From /usr/local/share/doc/pkg-readmes/dhcpcd (maintained by OpenBSD):

Also ensure that pf.conf(5) allows DHCPv6 traffic to pass, for example:

  pass in quick on pppoe0 proto udp from fe80::/10 port dhcpv6-server to fe80::/10 port dhcpv6-client

If you look at the packet dump from above, it's coming from a different range: Internet Protocol Version 6, Src: 2605:59c8:5100:b99d::1, Dst: fe80::20d:b9ff:fe43:5800

If I replace from fe80::/10 with from any, I get a prefix assigned to my LAN address 🎉.

So this looks like it's not a dhcpcd issue. My question to @rsmarples before I close the ticket: is the pkg-readme technically correct, or should I submit a patch to get it updated? I assume both Comcast and Charter send advertisements from fe80::/10 since I didn't have this issue before. It wouldn't surprise me if Starlink was doing something out of the ordinary since they've just turned on ipv6.

Thanks again!

[rsmarples]

Good question! DHCP6 typically only works on fe80::/10, but by default all packets from the client are multicast to AllDhcpServers address. We only unicast after the first REPLY if we are given an IP6 address to unicast to. This is generally not given and does rely on the address being reachable.

Also, there is nothing in the standard I know of that says we need to validate the packet came from fe80, especially do the the unicast option.

I would submit a patch to get it updated - what you see is unusual though for sure.

[xhci]

Thanks! I hope everything is going well - glad to see you active again 😃

[MikeOnTea]

For future reference, i had a similar problem, prefixes weren't delegated. Turns out the dhcp server sent delegations but they never reached dhcpcd – the firewall accepted the packets, but for whatever reason the kernel sent ICMP redirects instead of passing the packets to the listening application. I couldn't figure out what the cause for this was, but a reboot solved the issue.