Very interesting, maybe that’s the reason I had so many issues adding my first Matter device. I have IPV6 disabled on my router and all of my access points. The device is working on IPV4 so now I’m confused.
I don’t remember where I saw it, but I saw the ipV6 note somewhere a month or so ago and enabled it on my Deco routers at that time. I don’t know if it’s helped anything with Matter or not
The problem with the SmartThjngs iOS app and onboarding a Matter device seems to be the “handoff” between iOS Matter keychain and the ST app. The iOS keychain steps work fine, but then when it comes back to the SmartThings App the screen is no longer “thinking” and is just frozen at the waiting for iOS keychain step.
Every Matter device has a unique address which is how messages can find it, whether you are on the internet or just running locally. That address is using IPv6.
That is how a thread device like a motion sensor and a WiFi device like a light switch can, using matter format, send messages directly to each other locally (via a thread border router) Each has an IPv6 address as an identifier.
Some (not all) Thread Border Routers are capable of connecting IPv6 thread devices to an IPv4 Wi-Fi router, but This sometimes loses multicast messages. So it gets complicated.
Jd, I understand having IPV6 running on my internal network for Matter devices to talk to each other but why would my Matter device need to be able to talk to a device on the internet? Software updates or something ?
It doesn’t have to. It can, either for updates or to enable advanced features. And in the case of multi admin, it may be needed at the time of onboarding so that the two matter controllers can talk to each other, which is I believe what is causing the iCloud message referenced above.
Ok, thanks, I guess I’m going to actually have to read more on the subject. I avoid IPV6 like the plague at work. I was hoping that it wouldn’t catch on until long after I retired.
I haven’t looked into the Thread documentation all that deeply, but from the architecture overview I thought it was like ZigBee (I think Matter is basically a second gen of ZigBee, same consortium I thought) and that the network is locked down to local only. I’m pretty sure you MUST use a thread border router to get any traffic outside of the thread network, just not sure if the border router allows outbound traffic to non-local addresses. From what I read in Matter things like software updates are always done with the thread boarder router involved - can be started with the Matter controller, but only route to the thread device is thru a boarder router. Thread talking to thread has to be done using the network key that a matter controller has managed and confirmed thru getting public certificates via the internet - I think the Matter devices never get certificates themselves, the Matter controller always does the internet part.
For Matter wifi there are no limits to internet traffic of course, so I’m sure your statement about advanced service is completely correct for them.
I’ll keep looking at the Thread and Matter documentation and see how open a thread border router is to outbound internet traffic.
I left a remark to @JDRoberts below - but from reading the Matter docs it looked to me like Matter controllers (and maybe thread boarder routers) provide software updates. Not sure if a Thread device can do it’s own update. Matter wifi for SURE can do its own updates.
On an earlier thread:
Let me preface by saying I haven’t tried Wifi Matter on a IPV4 only network. I turned on IPv6 before using Matter so I don’t know if Wifi Matter will work with just v4. I thought Thread will NOT work with V4 except in the special case of a V4 Thread boarder router (but that may not work with multiple thread sub nets) - @JDRoberts provided a link about that in one of his threads.
All IPV6 networks are fully backward compatible with IPV4 - so most (maybe all?) devices will have BOTH an IPV4 address and an IPV6 address on the network. When I enabled IPV6 in order to try out Matter I saw that on all of my devices.
What I haven’t looked into is whether a device can have an IPV6 address only and NOT be visible to an IPV4 device - though in the case of Thread I wonder if Thread devices only have IPV6 addresses by design.
I think you MUST have an IPV6 capable DHCP service to be an IPV6 network. I’ve heard that one issue with enabling IPV6 is if you have an internet provider who is your DHCP server and they don’t have IPV6 enabled (or enabled for your account perhaps).
Because Thread/Matter uses IPV6 multicast messages to discover devices and reconnect after devices get new addresses. Thread devices do keep the address of any device that they are communicating to, but will try to rediscover address if communication is lost. Many Matter devices only talk to their controller, but there is a case for Matter-to-Matter (just like ZigBee had) for things like a wall switch talking directly to a light bulb.
Yes, as I mentioned earlier ALL of your IPV4 devices will get BOTH V4 and V6 addresses.
I’m not at home to pull another trace, but when I set up the ThirdReality Night Light Wi-Fi on my IPv4 and IPv6 enabled network, it first got an IPv4 address before obtaining a IPv6 address. It would seem to imply that Matter over Wi-Fi devices may be IPv4 only. I haven’t read all the Matter specs to see if you can have a Wi-Fi IPv4 only, but clearly for Thread devices to communicate with Wi-Fi devices, IPv6 is necessary.
Also, DHCPv6 is not necessarily a requirement for an IPv6 network. SLAAC can do address assignments as well as its role in providing router advertisements. DHCPv6 can also be used for address assignment in addition to providing DNS servers and other information not available via SLAAC. If your IPv6 router supports RDNSS, you can actually provide DNS server information in RA messages and run a completely SLAAC enabled network.
Thanks for all of the explanations. I have IPV6 enabled now. It works internally I can ping from my hardwired server to my tablet using the IPV6 address. However I couldn’t get it to work externally by using the Meross link that JD provided. I looked at my router and it is configured correctly. A quick call to Frontier, my fiber provider and they said they don’t support IPv6 and don’t plan on doing it anytime soon. A quick Google search turned up results that very few ISP’s support it at the current time. If Matter or Thread requires IPV6 to route outside your local lan, then a lot of people will be out of luck!
It was in the serial output from the debug board for the device. I haven’t found any place in the ST environment to see it. I’ll check the JSON output of the CLI when I get home to see if it reveals anything.
AT&T and Comcast both support IPv6 on their networks. Spectrum also supports IPv6 in most of their locations. Those 3 comprise a big chunk of Internet access in the U.S.
Comcast and AT&T only support it in select markets. I have Comcast cable modems I use in my warehouses all over the US. I also have AT&T T1’s for backup. I’ve been down that road with them before. Im not familaer with Spectrums IPV6
As of March 2022, according to Google, the IPv6 adoption rate globally is around 34%, but in the U.S. it’s at about 46%.
.
Carrier networks and ISPs have been the first group to start deploying IPv6 on their networks, with mobile networks leading the charge. For example, T-Mobile USA has more than 90% of its traffic going over IPv6 as of March 2002, with Verizon Wireless close behind at 82.63%. Comcast and AT&T have their networks at 70% and 73%, respectively, according to the industry group World Ipv6 Launch.
We are three housemates and have multiple internet accounts in the house, including one from AT&T and one from Comcast. Both have IPv6 support. But we’re in the San Francisco Bay Area.
I’m sure in the major cities it will work but a lot of the infrastructure in middle America just wont support it. The ISP’s have an attitude of why should they spend money for the infrastructure if it works fine as is. A lot of users don’t even have access to broadband and are still using DSL and satellite.
