General Thread Spec question—how to implement CPE device that plays nice with OpenThread and other border router implementations

[lucasec]

Hi all,

I'm working on trying to make a CPE device (based on an open source project I contribute to) behave more in line with the document "Thread Border Router Best Practices" (https://www.threadgroup.org/Portals/0/documents/support/ThreadBorderRouterBestPractices_2530_1.pdf). I had a few questions about the spec, particularly around IPv6 Prefix Allocation and Delegation. Perhaps folks can help me here by clarifying what OpenThread expects from the network, which I would assume largely falls in line with what other commercial implementations are doing.

As for what I have today, the existing CPE devices allow clients on the LAN to assign individual addresses using SLAAC from both a global unicast prefix (usually assigned dynamically by the ISP) and a ULA prefix.

From the best practices document, it's pretty clear we should be offering prefix delegation to the LAN, as a Thread Border Router will generally want to request a prefix, and I'm also seeing this out in the field with some commercial devices on the market that hitting the DHCPv6 server with prefix requests on a regular interval.

So we need to implement prefix delegation on the LAN, which begs (question 1) what prefix length, in general, is the minimum length needed to be useful to a Thread Border Router? If an ISP only gives us a limited supply of /64s, is there any point in trying to carve them up into anything smaller in order to be able to serve more routers requesting prefixes?

The next question (question 2) is what type of prefixes to offer to Thread Border Routers over DHCPv6-PD. The document talks a lot about ULA prefixes, but also presumably Thread devices want a globally-routable address to access Internet resources. If I have both types of prefixes available, which one should I hand out when a Thread Border Router requests a prefix?

Of course there are other protocols mentioned such as HNCP, but as mentioned these are still in the early stages of deployment. I suppose my last question (question 3) is what happens in the do-nothing scenario, e.g. a CPE does not delegate any prefixes to the Thread Border Router? I know from observation that the Border Router allocates its own ULA prefix. If I understand correctly, the suggested solution for Border Routers is to fall back to ND Proxy at expense of some performance?

Thanks for any input people can offer,
Lucas

[jwhui]

The Thread Border Router Best Practices document is no longer valid and should no longer be discoverable on the Thread Group website. If you found a link on the website, can you point us to it so that we can take it down?

Thread 1.3 and later specifies Thread Border Router functionality and covers the questions that you raised here.

So we need to implement prefix delegation on the LAN, which begs (question 1) what prefix length, in general, is the minimum length needed to be useful to a Thread Border Router? If an ISP only gives us a limited supply of /64s, is there any point in trying to carve them up into anything smaller in order to be able to serve more routers requesting prefixes?

Thread requires any prefix assigned to a Thread network to have length 64.

The next question (question 2) is what type of prefixes to offer to Thread Border Routers over DHCPv6-PD. The document talks a lot about ULA prefixes, but also presumably Thread devices want a globally-routable address to access Internet resources. If I have both types of prefixes available, which one should I hand out when a Thread Border Router requests a prefix?

This is really an administrator option. By default, it should provide a global prefix, as it allows Thread devices to reach cloud services. However, a user or administrator may choose not to provide global addressing and instead provide a ULA.

Of course there are other protocols mentioned such as HNCP, but as mentioned these are still in the early stages of deployment. I suppose my last question (question 3) is what happens in the do-nothing scenario, e.g. a CPE does not delegate any prefixes to the Thread Border Router? I know from observation that the Border Router allocates its own ULA prefix. If I understand correctly, the suggested solution for Border Routers is to fall back to ND Proxy at expense of some performance?

Thread Border Routers will locally generate a ULA.

See the Thread 1.3 Specification for more details.

[lucasec]

Thanks for your reply and engagement on my questions.

I found the link via a Google query, I think the exact terms used were "thread border router sends dhcpv6-pd request". I'll grab the latest spec which I assume will my curiosity around the last question.

re: question 2—one follow-up (only if this is a quick answer, otherwise please bounce me to the spec):

This is really an administrator option. By default, it should provide a global prefix, as it allows Thread devices to reach cloud services. However, a user or administrator may choose not to provide global addressing and instead provide a ULA.

In our current environment we issue clients on LAN networks both a global address and a ULA. The global address is used for internet destinations and the ULA to access internal network resources such as the DNS resolver (it is much easier to hand out a stable ULA for the resolver rather than a GUA that may change during a renumbering event). However, I assume a border router will only ever send out a single request for a prefix, and as such, Thread network devices will only ever receive a global address or a ULA, never both simultaneously?

(section 9.2.4 seems to leave open the possibility of assigning multiple ULAs from different "supplemental prefixes", though from my first read of section 9.6 I couldn't discern a clear mechanism for how the external network could instruct a border router to do so)

[jwhui]

With DHCPv6 Prefix Delegation, it is possible to communicate multiple IA_PD Prefix options. Would that address your use case?