Thread Border Router 1.0.0. Global IPv6 prefix /64 size

[mvataleu]

Hi there!

I am running the Thread Border Router example and have successfully loaded RaspPi_OT_Border_Router_Demo_v1.0.0-1.alpha.img into the RaspberryPi 3B+.

The problem is that devices in my Thread network don't reach the global prefix (2a00:xxxx:xxxx:xxx::/64) from eth0. But the eth0 itself get this prefix and get reachable from the internet.

I need to make a setup when the Thread devices (FTD) is reachable from the internet via public ipv6 addresses.

I've noticed the warning in dhcdpcd logs: "wpan0[430] unsupported interface family 00".  Is it ok? 

If the border router requires /62 prefixes on eth0, could you please describe the possible workarounds? In my country, the ISP provides only /64 prefixes for home subnets. I tried to use ipv6 tunnel brokers from different providers (sixx6, HE) they also provide /64 prefix delegation. How can I decrease the Thread subnet size to fit into /64 public subnets? Should I customize NCP firmware? 

Thanks in advance.

[Piotr Szkotak]

Hi mvataleu,

Thank you in your interest in the Thread Border Router.

The warning does not to impact us as we do not use DHCP for wpan0, I think it can be safely ignored.

I am not aware of any successful attempts to achieve your goal.

Therefore rest of this post will be very theoretical, sorry for that.

At this moment SLAAC is used at each node to configure it's IPv6 address. The point is that it requires /64 prefix to work.

In theory you could delegate another /64 prefix and map it to the global prefix using NAT66. It would need to be done on the Border Router itself.

Other case is using DHCPv6 mentioned in the Thread Specification 1.1.1 section 5.3.3.

DHCPv6 can be used to assign/request shorter prefixes.

Support from the wpantund (deamon running on the Border Router) and the firmware is required to get it working as P_dhcp instead of P_slaac needs to be set in the Valid Prefix Set as per Specification section 5.3.3.

As I have never worked with this particular use case I cannot confirm what is the current status and what needs to be exactly configured or implemented. At least some part is present in the OpenThread stack we use, maybe there is no work to be done there. Another question is the (wpantund daemon running on the Border Router providing wpan0 interface), it needs to be able to configure NCP properly.

 

You may also want to consult Thread Border Router Best Practices document freely available at the Thread Group Portal.

Kind regards,

Piotr Szkotak