DHCPv6-PD provisioned prefix does not get added to mesh prefix list

[stevew817]

Describe the bug When a GUA IPv6 prefix is delegated to the wpan0 interface through DHCPv6-PD, the expectation is that this prefix is automatically added to the on-mesh prefix, and that nodes on the mesh learn their GUA from this prefix. This does not seem to happen. The wpan0 interface gains a GUA address (::1 from the assigned prefix), but does not configure the Thread network to let nodes configure their own GUA address from the assigned prefix, and does not add a route for internet connectivity either.

To Reproduce

• OTBR posix commit 6672fe30f
• platform: Raspberry Pi 3B+ connected to an EFR32MG12 BRD4166 RCP (built from openthread commit 54f24c607)
• network environment: local DHCPv6 server distributing both individual addresses from a /64 pool, and prefixes (default /56) from a /48 pool. Both pools are routed and have internet access.

Steps:

• Install ot-br-posix using default config, configure serial port in config file, reboot RPi
• Form Thread network through web GUI with default parameters
• Attach second Thread node using manual dataset configuring over CLI (as indicated in the OpenThread Border Router Getting Started docs)

Expected behavior When the border router gets assigned a globally routable prefix through DHCPv6, it adds that prefix to the mesh and adds it as a route, such that nodes on the mesh gain native IPv6 connectivity.

Console/log output On raspberry: ifconfig wpan0

wpan0: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST>  mtu 1500
        inet6 2001:<private>:<private>:5801::1  prefixlen 64  scopeid 0x0<global>
        inet6 fd11:1111:1122::ff:fe00:bc00  prefixlen 64  scopeid 0x0<global>
        inet6 fe80::a492:6af0:b056:c529  prefixlen 64  scopeid 0x20<link>
        inet6 fd11:1111:1122:0:f486:68ef:c138:baa1  prefixlen 64  scopeid 0x0<global>
        inet6 fd11:1111:1122::ff:fe00:fc00  prefixlen 64  scopeid 0x0<global>
        unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  txqueuelen 500  (UNSPEC)
        RX packets 914  bytes 83173 (81.2 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 50  bytes 8648 (8.4 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

ot-ctl ipaddr

fd11:1111:1122:0:0:ff:fe00:fc00
fd11:1111:1122:0:0:ff:fe00:bc00
2001:<private>:<private>:5801:0:0:0:1
fd11:1111:1122:0:f486:68ef:c138:baa1
fe80:0:0:0:a492:6af0:b056:c529
Done

ot-ctl prefix

Done

ot-ctl state

leader
Done

From dhcpcd log:

Jun 11 02:46:16 otbr-pi dhcpcd[464]: eth0: soliciting an IPv6 router
Jun 11 02:46:16 otbr-pi dhcpcd[464]: eth0: rebinding lease of 192.168.3.18
Jun 11 02:46:17 otbr-pi dhcpcd[464]: eth0: carrier lost
Jun 11 02:46:17 otbr-pi dhcpcd[464]: eth0: deleting address fe80::ba27:ebff:fe09:a87b
Jun 11 02:46:17 otbr-pi dhcpcd[464]: eth0: carrier acquired
Jun 11 02:46:17 otbr-pi dhcpcd[464]: eth0: IAID 00:00:00:01
Jun 11 02:46:17 otbr-pi dhcpcd[464]: eth0: IAID 00:00:00:02
Jun 11 02:46:17 otbr-pi dhcpcd[464]: eth0: IAID 00:00:00:03
Jun 11 02:46:17 otbr-pi dhcpcd[464]: eth0: adding address fe80::ba27:ebff:fe09:a87b
Jun 11 02:46:17 otbr-pi dhcpcd[464]: eth0: rebinding lease of 192.168.3.18
Jun 11 02:46:17 otbr-pi dhcpcd[464]: eth0: probing address 192.168.3.18/24
Jun 11 02:46:18 otbr-pi dhcpcd[464]: eth0: soliciting an IPv6 router
Jun 11 02:46:19 otbr-pi dhcpcd[464]: eth0: rebinding prior DHCPv6 lease
Jun 11 02:46:19 otbr-pi dhcpcd[464]: eth0: Router Advertisement from fe80::7a8a:20ff:fe0b:d2ab
Jun 11 02:46:19 otbr-pi dhcpcd[464]: eth0: REPLY6 received from fe80::7a8a:20ff:fe0b:d2ab
Jun 11 02:46:19 otbr-pi dhcpcd[464]: eth0: adding address 2001:<private>:<private>:2e4::d2a/128
Jun 11 02:46:19 otbr-pi dhcpcd[464]: eth0: renew in 2000, rebind in 3000, expire in 7200 seconds
Jun 11 02:46:19 otbr-pi dhcpcd[464]: lo: adding reject route to 2001:<private>:<private>:5800::/56 via ::1
Jun 11 02:46:19 otbr-pi dhcpcd[464]: eth0: delegated prefix 2001:<private>:<private>:5800::/56
Jun 11 02:46:19 otbr-pi dhcpcd[464]: wpan0: adding address 2001:<private>:<private>:5801::1/64
Jun 11 02:46:19 otbr-pi dhcpcd[464]: wpan0: adding route to 2001:<private>:<private>:5801::/64
Jun 11 02:46:20 otbr-pi dhcpcd[464]: wlan0: new hardware address: 4e:a6:a4:9c:f0:28
Jun 11 02:46:23 otbr-pi dhcpcd[464]: eth0: leased 192.168.3.18 for 86400 seconds
Jun 11 02:46:23 otbr-pi dhcpcd[464]: eth0: adding route to 192.168.3.0/24
Jun 11 02:46:23 otbr-pi dhcpcd[464]: eth0: adding default route via 192.168.3.1

CLI ipaddr on attached second thread node:

> ipaddr
fd11:1111:1122:0:0:ff:fe00:fc00
fd11:1111:1122:0:0:ff:fe00:f800
fd11:1111:1122:0:c807:4f1c:6698:b876
fe80:0:0:0:a0e1:6241:2aeb:bb41
Done

[gjc13]

Can you paste the otbr-agent log? Thanks.

[bukepo]

@stevew817 This is a missing feature. This requires converting the router advertisement to Thread network data. I agree this is very useful but I think it requires some time to add it.

[stevew817]

@bukepo It's been a while since I last looked at OTBR, but wasn't this implemented in wpantund already?

[stevew817]

@gjc13 This might be of interest too?

Jun 11 13:12:13 otbr-pi otbr-agent[399]: [INFO]-PLAT----: processNetifAddrEvent: OK
Jun 11 13:12:13 otbr-pi otbr-agent[399]: [INFO]-PLAT----: processNetifAddrEvent: OK
Jun 11 13:12:13 otbr-pi otbr-agent[399]: [INFO]-PLAT----: processNetifAddrEvent: OK
Jun 11 13:12:15 otbr-pi otbr-agent[399]: [INFO]-PLAT----: processNetifAddrEvent: OK
Jun 11 13:12:15 otbr-pi otbr-agent[399]: [NOTE]-PLAT----: ADD [U] 2001:<private>:<private>:5801::1
Jun 11 13:12:15 otbr-pi otbr-agent[399]: [WARN]-PLAT----: unexpected address type (6).
Jun 11 13:12:15 otbr-pi otbr-agent[399]: [WARN]-PLAT----: unexpected address type (8).
Jun 11 13:12:15 otbr-pi otbr-agent[399]: [INFO]-PLAT----: processNetifAddrEvent: OK
Jun 11 13:12:15 otbr-pi otbr-agent[399]: [INFO]-CORE----: Notifier: StateChanged (0x00000001) [Ip6+]
Jun 11 13:12:15 otbr-pi otbr-agent[399]: [NOTE]-PLAT----: ADD [U] 2001:<private>:<private>:5801::1
Jun 11 13:12:15 otbr-pi otbr-agent[399]: [WARN]-PLAT----: unexpected address type (6).
Jun 11 13:12:15 otbr-pi otbr-agent[399]: [WARN]-PLAT----: unexpected address type (8).
Jun 11 13:12:15 otbr-pi otbr-agent[399]: [INFO]-PLAT----: processNetifAddrEvent: OK
Jun 11 13:12:15 otbr-pi otbr-agent[399]: [INFO]-PLAT----: processTransmit: OK

[bukepo]

Yes, but it seems it didn't detect what kind of prefix is added. We'll add the feature soon.

[stevew817]

@bukepo I'm circling back to this issue here. Is there any update re. adding support for auto-assigning delegated prefixes?

Upon re-reading your comments and the linked PR, I think we might've been talking about different things. Your PR was about doing RA across the router, but my issue is rather with DHCPv6-PD.

The current otbr dhcpcd.conf specifically requests a prefix to be delegated to the wpan0 interface. As far as I'm aware, this feature is still broken, since the DHCP-assigned prefix gets overridden by otbr-agent (which gets started after DHCP assignment). At least that's the behaviour I'm seeing on the latest ot-br-posix on raspbian.

What's the point of requesting a prefix to be delegated to wpan0 in this way, if that prefix isn't going to be on-mesh? If ot-br isn't going to do this, then what is the preferred way of handling PD?

[ssenthu]

HI, I am interested to know about this too. If i have dhcpv6 server and and if that offers the prefix-delegation, will that be used in the sensor network? I see always OTBR picks its own ULA prefix not form DHCPv6-PD @jwhui @bukepo

[jwhui]

HI, I am interested to know about this too. If i have dhcpv6 server and and if that offers the prefix-delegation, will that be used in the sensor network? I see always OTBR picks its own ULA prefix not form DHCPv6-PD @jwhui @bukepo

@ssenthu , while OpenThread does not currently integrate with DHCPv6 Prefix Delegation, we are currently working to support this.

[jwhui]

Closing stale issue.