Yes, multiple IPv6 addresses on a single interface are common. fe80 are link-local addresses, but they are typically not temporary. Unless you have a privacy mode enabled. Not sure what you mean with “fe2 for DNS lookups”. Any address can be used for DNS lookups, DNS is not related with IPv6 in that sense. If the router assigns a local network, this is typically from the ULA range (fc00::/7, so starting with fc or fe). These can be used for any communication within the network or adjacent networks (e.g. Thread networks). These are routable.
Not sure what you are missing exactly, but let’s move this discussion in a separate thread. I am happy to discuss IPv6 things.
I was meaning to type DHCP lookup, but typed DNS lookup for some reason.
FE2 seems to be used for general network auto-setup/configuration.
And I miss the opportunity to set IPv6 to DHCP-PD and at the same time set up a static link local address and have a temporary global address too assigned with autoconfiguration.
The DHCP-PD address will be the one for public incoming access.
The link local address will be for the IoT network that should not have internet access.
The temporary global address will be for outgoing connections, so tracking is limited.
I was having the same vnet issue but I think I have found a work around.
You will need to stand up a temporary HA server on the IOT vnet.
My main HA server lives on a trusted vnet. My IOT devices live on a IOT vnet.
I have been playing around with some linkind matter smart bulbs. I could add them if I use the trusted network, but that is not what I wanted. When I tried to add them to the IOT vnet it would fail, as others have found on this thread.
After reading this thread this seems to only be an issue with provisioning, not the day to day operation in HA. So I got thinking, could I provision on the IOT network and control this from the trusted network?
Here is what I have working so far. You milage may very.
I stood up a 2nd HA server on the IOT network. I use proxmox so this was simple, but I think any type of 2nd instance would work also.
I joined my iphone to the IOT network.
Switch your HA companion on your phone to the new IOT HA on the IOT vnet. (3 finger swipe up to add the 2nd server) Then add your matter device as normal. Your device will now shows up on the correct IOT network and is available to the IOT HA server. Open the matter device and under device info select share device. It will present you with a scan code with a number under it. Write the number down, as you will need it to add this matter device to your main HA instance.
Back on your main HA instance open devices, select your matter integrations under matter select your devices, then add a device. Select Its already in use, other controllers and then enter the number from above.
The matter device will now show up in your main HA instance, but its IP is still on the IOT vnet.
I was able to remove it from my IOT HA instance and it still functions, I was able to shutdown the IOT HA instance and it still functions.
Everything seems to be working as normal so far, will have to see how it functions over the next week.
Hope this helps anyone until this can be properly handled natively within HA.
Technically, both commissioning and operational use mDNS for discovery. Also, what you do when sharing the device between instance IoT and trusted net is another commission flow in the Matter sense. If this indeed worked in your case, you must have some mDNS reflector running or the trusted instance dual-homed.
I have a ubiquity UCG Ultra, and yes I do have mDNS set up between Trusted and IOT. Do not think it matters but my DNS is also forwarded to two PiHole servers on a completely separate network, although they all share the same Domain name.
Hm, ok from our end, there is no technical limitation why on-boarding via iOS app should be any different from adding a device via our share mechanism. In fact, the very same code flow is used. But we do rely on the Apple iOS SDK to do the network setup first and we don’t have any influence in that part. So it seems that in your setup this failed, so seems like Apple iOS somehow does not process these forwarded Ubiquity mDNS messages.
In general, mDNS is really not meant to be routed between network. The standard only defines the protocol in a link-local setup (via link-local multicasting). So any such forwarding is kinda out of spec, means YMMV…
I did reboot my Main HA instance with the IOT instance shutdown. The matter device is still there and functioning.
I also checked my UniFi network settings. I have IPv6 turned off on all my networks. Ubiquity does have a feature called “IoT Auto-Discovery nDNS” that I have enabled between my trusted and iot vlans. Bellow is their description of what this does.
Forwards multicast traffic between the selected networks so that IoT devices can discover and communicate with each other when connected to different networks. Learn more
With those two things, are you saying that the link-local that Matter is using is still happening under IPv6, after the provisioning? As I do not have IPv6 enabled on my UniFi Cloud Gateway it has to be talking on the local subnet/vlan only somehow. So the question would be how is it finding the finding the device on the other IPv4 vlan
Some more info to add here.
I also have some Tapo Matter bulbs L535E’s. I could not share them out at all trying the exact same thing. So maybe what is going on here is specific to the Linkind bulbs, I have shared 4 of the Linked bulbs with success.
I do not have any other matter devices to try this with.
Matter is always using link-local mDNS to find the devices (through operational discovery) and resolve their IP addresses. I am not a UniFi expert, but it is the first time I hear of “IoT Auto-Discovery mDNS”, maybe this is really a new (somewhat Matter) specific option they added? I guess it makes sure that the link-local mDNS discovery somehow works across the VLANs.
Technically, Matter can work without an IPv6 network at least on a single LAN (aka collision domain) through IPv6 link-local addressing. But accross VLANs that won’t work (unless IPv6 packets with link-local addressing would get forwarded too, but this would really start to defeats the whole point of VLANs ). I don’t think that this is what UniFi is doing. I assume you have some routable IPv6 addressing. Thread border router automatically assign a ULA IPv6 range to devices on the network. Maybe this helps to make things work.
For what it is worth, I am have connected a SwitchBot matter hub on my IOT vlan which home assistant in a separate vlan.
HomeAssistant is allowed to access the IOT VLAN and I have AVAHI running as a reflector on my router (with access to all VLANs). That setup is exactly the same that is needed to have HomeAssistant detect a Chromecast (or anything that relies on mDNS)
Everything is working perfectly. Thanks for the hard work on this @agners
@jfparis I am not a networking expert but have learned over the years by brute force trial and error and reading etc. I could never figure out how to set up the mDNS reflection in my network to allow people on my gues lan to cast to chromecasts that were on a different vlan, until I learned that I had to set up and include the Bonjour service:
_googlecast._tcp.local
Therefore I wanted to pick your brain rgarind my IOT vlan and Matter regarding mDNS (for reliability my IOT vlan is 2.4Ghz only but is pretty solid). in HA (whch is on a diffeent vlan) I actually also have IPv6 turned completely off - so even though they say Matter is only over IPv6 I have an issue with that statement, there must be some nuances to it. Matter with HA still works on the same vlan as HA - however, my Matter devices will still not work with HA unless they are on the same vlan as my HA instance. Is there a specific service I need to include for the Matter to work or am I still barking up the wrong tree? Here are couple of screenshots of my current configuration to illustrate my point:
So for matter I would alter the above mDNS rule or add a new one for the IOT VLAN of course, but is there any specific or additional Bonjour Service I would be missing - or some other mDNS (or other kind of) setting to be able to put my matter devices on the IOT vlan with all of my other sensors etc.?
(FYI I do have firewall rules blocking the vlans from each other and then only allowing each device (all have static IP’s) - to be allowd to talk to the HA IP - so I know I would need to add that as well of course but that hasn’t made any difference in the past either to resolve my Matter cross vlan issue…)
I am not sure what network gear you are using so it is difficult for me to tell you which button to click
Couple of observations about what I have and maybe it helps
My ISP does not provide iPV6 but I have it enabled internally on the router so each device have an iPV6 if they want it and the router pass then around. No big configuration required
The mDNS reflection is handled by avahi (standard kit for this on Linux - my router is Linux based). It runs on the router so it can see all interfaces / all vLANs and therefore hear of all the devices
Firewall
iot and guest only able to talk to the internet
safe net and hass net are allowed to talk to iot. In most cases it will be HA calling out. (Established connection need to be allowed so devices can respond to Hass once they have been called. You probably know that)
To set up he matter device I had to temporary connect my android to the IOT and allow it temporary access to HASS
To expand a bit more on this (for those who use dual homed/multi homed approach and Android): The Matter Server has an argument --primary-interface, which gets set to what Home Assistant OS/NetworkManager considers the primary interface. To force a particular interface, another --primary-interface <vlan-interface> can be added to the recently added configuration option “Extra Matter Server arguments” to force a particular VLAN to be used.
I guess it makes sure that the link-local mDNS discovery somehow works across the VLANs.
). I don’t think that this is what UniFi is doing. I assume you have some routable IPv6 addressing. Thread border router automatically assign a ULA IPv6 range to devices on the network. Maybe this helps to make things work. 
