how to set a fixed global unicast prefix for a thread network? (TZ-459)

[briansuyu]

My intention is to create several different thread networks, each network has one BR and all BRs are connected to the same ETH local network(for cases like 1000 lights in a building). As i don't have a global ipv6 address and i intend to use everything in local, i prefer to set everything fixed in advance to make the system more stable and easy to deploy, for example i could add several permanent routes to the local server according to the BR's link local ipv6 address in advance and all FTD devices stores the same dataset as it in the BR which they needs to be connected. Should i use domain unicast address feature? I tried some openthread DUA apis to add domain name and domain iid for all devices before enabling thread network, but it seems the exposed ipv6 address still not making any sense.
I experimented this with 2 BR boards(esp32+esp32h2) and 4 esp32h2devkit.
Or should i use other thread features to achieve this?

[briansuyu]

idf version 5.1.2 and esp-thread-br version 1.0

[zwx1995esp]

Hi, @briansuyu I think you might want to generate your own global prefix address, for implementing that you can use the function otNetDataPublishOnMeshPrefix on the BR to publish a configured prefix. But for the Address generated from the configured prefix, the OT stack will call an internal generating function(the related logic you can get here) There are some logics to generating a unique IID according to the RFC 7217(which you can refer to here). This ULA is generated by OT stack internal.

For your requirement, I think you can add another address with the prefix you just published. You can call the function otIp6AddUnicastAddress to add a slacc address on the thread node(not BR), and then call the function esp_event_post(OPENTHREAD_EVENT, OPENTHREAD_EVENT_GOT_IP6, add_addr, sizeof(*add_addr), portMAX_DELAY); to post the adding event to lwip, then the address will be added can can ping form ETH.

The following cmd can help you to run a test(first you need to form a thread network and join a Thread node in it.):

After forming the thread network, on the BR node, using this command to publish a customed prefix:

> netdata publish prefix 2002::/64 paros low

then you can see OT stack will generated a ULA of that prefix(using command ipaddr to print the address on the OT netif)

> ipaddr

2002:0:0:0:371e:47ea:fc3:7d74
fda7:48e9:d176:2:dd2f:fdd2:3c0:c21e
fd27:59bb:24c1:553:0:ff:fe00:fc10
fd27:59bb:24c1:553:0:ff:fe00:fc00
fd27:59bb:24c1:553:0:ff:fe00:4400
fd27:59bb:24c1:553:cdf2:e6a2:48e0:ab47
fe80:0:0:0:18f7:31bd:e384:f762

and for the Thread node(not BR) youcan also see a ULA with the prefix 2002:0:0:0::/64

> ipaddr

2002:0:0:0:fa89:3c32:dd44:eeb5
fda7:48e9:d176:2:c344:fd02:e12e:51d6
fd27:59bb:24c1:553:0:ff:fe00:2000
fd27:59bb:24c1:553:1c37:cbfd:fe79:865c
fe80:0:0:0:c0f3:5d82:b3d:9f7a

On the Thread node(not BR), you can add a ULA like 2002:0:0:0:0:0:0:1 by using these commands:

> ipaddr add 2002:0:0:0::1

Done
> ip add ot 2002:0:0:0:0:0:0:1

Done
> ipaddr

2002:0:0:0:0:0:0:1
2002:0:0:0:fa89:3c32:dd44:eeb5
fda7:48e9:d176:2:c344:fd02:e12e:51d6
fd27:59bb:24c1:553:0:ff:fe00:2000
fd27:59bb:24c1:553:1c37:cbfd:fe79:865c
fe80:0:0:0:c0f3:5d82:b3d:9f7a

Then you can ping this address on the ETH(for example, I ping this address on my linux host):

$ ping 2002:0:0:0:0:0:0:1            
PING 2002:0:0:0:0:0:0:1(2002::1) 56 data bytes
64 bytes from 2002::1: icmp_seq=1 ttl=254 time=102 ms
64 bytes from 2002::1: icmp_seq=2 ttl=254 time=73.4 ms
^C
--- 2002:0:0:0:0:0:0:1 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 73.424/87.879/102.335/14.455 ms

[briansuyu]

Hi, @briansuyu I think you might want to generate your own global prefix address, for implementing that you can use the function otNetDataPublishOnMeshPrefix on the BR to publish a configured prefix. But for the Address generated from the configured prefix, the OT stack will call an internal generating function(the related logic you can get here) There are some logics to generating a unique IID according to the RFC 7217(which you can refer to here). This ULA is generated by OT stack internal.

For your requirement, I think you can add another address with the prefix you just published. You can call the function otIp6AddUnicastAddress to add a slacc address on the thread node(not BR), and then call the function esp_event_post(OPENTHREAD_EVENT, OPENTHREAD_EVENT_GOT_IP6, add_addr, sizeof(*add_addr), portMAX_DELAY); to post the adding event to lwip, then the address will be added can can ping form ETH.

The following cmd can help you to run a test(first you need to form a thread network and join a Thread node in it.):

After forming the thread network, on the BR node, using this command to publish a customed prefix:

> netdata publish prefix 2002::/64 paros low

then you can see OT stack will generated a ULA of that prefix(using command ipaddr to print the address on the OT netif)

> ipaddr

2002:0:0:0:371e:47ea:fc3:7d74
fda7:48e9:d176:2:dd2f:fdd2:3c0:c21e
fd27:59bb:24c1:553:0:ff:fe00:fc10
fd27:59bb:24c1:553:0:ff:fe00:fc00
fd27:59bb:24c1:553:0:ff:fe00:4400
fd27:59bb:24c1:553:cdf2:e6a2:48e0:ab47
fe80:0:0:0:18f7:31bd:e384:f762

and for the Thread node(not BR) youcan also see a ULA with the prefix 2002:0:0:0::/64

> ipaddr

2002:0:0:0:fa89:3c32:dd44:eeb5
fda7:48e9:d176:2:c344:fd02:e12e:51d6
fd27:59bb:24c1:553:0:ff:fe00:2000
fd27:59bb:24c1:553:1c37:cbfd:fe79:865c
fe80:0:0:0:c0f3:5d82:b3d:9f7a

On the Thread node(not BR), you can add a ULA like 2002:0:0:0:0:0:0:1 by using these commands:

> ipaddr add 2002:0:0:0::1

Done
> ip add ot 2002:0:0:0:0:0:0:1

Done
> ipaddr

2002:0:0:0:0:0:0:1
2002:0:0:0:fa89:3c32:dd44:eeb5
fda7:48e9:d176:2:c344:fd02:e12e:51d6
fd27:59bb:24c1:553:0:ff:fe00:2000
fd27:59bb:24c1:553:1c37:cbfd:fe79:865c
fe80:0:0:0:c0f3:5d82:b3d:9f7a

Then you can ping this address on the ETH(for example, I ping this address on my linux host):

$ ping 2002:0:0:0:0:0:0:1            
PING 2002:0:0:0:0:0:0:1(2002::1) 56 data bytes
64 bytes from 2002::1: icmp_seq=1 ttl=254 time=102 ms
64 bytes from 2002::1: icmp_seq=2 ttl=254 time=73.4 ms
^C
--- 2002:0:0:0:0:0:0:1 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 73.424/87.879/102.335/14.455 ms

thanks, it helps a lot.

[briansuyu]

the multicast forwarding was working fine before i published a customed prefix from BR > netdata publish prefix 2002::/64 paros low after that the multicast group which all other FTD devices joined can not be reached from Linux host machine and i see some packets lost logs from BR output right after i started to ping the multicast group

Could i ask is there anything else need to be set to make multicast forwarding feature working when using customed prefix?

[zwx1995esp]

Hi, @briansuyu We will try to reproduce this issue then investigate it.

[zwx1995esp]

Hi @briansuyu , could you please try this way: let's publish a ULA prefix rather than a global prefix, please use netdata publish prefix fd02::/64 paros low and have a try.

[briansuyu]

Hi, by publishing a ULA prefix fd02::/64, the multicast forwarding feature works again, and each device can be reached from the linux host using both the new ip or the multicast group ip. But a new issue comes out, after changing the prefix, some device's registered services are missing. The srp is set to AUTO. Before publishing a new ULA prefix

After

[zwx1995esp]

Hi @briansuyu Per reproducing this issue on my side, I found it was too strange after pubilshing a new prefix in netdata, the OMR prefix address was disappeard. I investigated and tried to find the root cause of that. So please give me some time and I will sync to you later when I have some processes on this issue.

[briansuyu]

yes, it's the same device, after the address is changed it updated the address in the service. And the other device's service just disappeard.

[zwx1995esp]

Hi, @briansuyu , sorry for delay, please try this command to add the prefix: netdata publish prefix 2002::/64 aos low, this command should be OK, I check the source code, we may not set the p config for this prefix(P means prefered prefix).

[briansuyu]

ok thanks