TREL peer set IPv6 address choice

[Cristib05]

Hello,
I save seen that in Thread spec, in section 15.6.3.3 TREL Message Transmission, it is stated that if there are multiple Host IPv6 addresses in a TREL peer set, one of the entries with the highest IPv6 address scope must be selected. Can you please let me know if there is any particular reason for this approach?
Given that trel peer structure only contains an otSockAddr and not a list, should platform code choose the IPv6 address with the highest scope before notifying OpenThread about a new peer?
Thanks!

[jwhui]

The original intent of selecting the highest IPv6 address scope is to enable TREL links that may go across multiple IPv6 subnets. However, there has since been discussions within Thread Group to update that behavior. For example, to align with RFC 6724.

Relevant JIRAs:

• SPEC-1336
• SPEC-1341
• SPEC-1342
• SPEC-1343

As for maintaining a set of IPv6 addresses, @abtink is planning to add support for that to OpenThread in the near future.

[abtink]

The original idea has been that mDNS would be the (main/only) way to discover and update peer information. And, of course, platforms can choose their own mDNS library. The TREL platform abstraction therefore defined otPlatTrelPeerInfo with a single otSockAddr and documented the expected/specified behavior (from the Thread specification) in the otPlatTrelEnable() documentation, essentially delegating the IPv6 address selection to the platform layer.

As Jonathan said, there have been some recent proposed changes to this (mainly to address issues seen with not being able to reliably detect address/port changes on peers with mDNS). We recently merged #10869), which covers SPEC-1261.

I'd like to change the code (in future) to move more of the peer detection/updates into the common OT core code, including the possibility of tracking multiple addresses per TREL peer (within OT core itself).

[Cristib05]

Thanks for the answer! I have completely missed that comment from otPlatTrelEnable().