Can equipment work with non static IP?

Setup, Configuration and Use Migration
1

Hi everyone,

I am new to openHab coming from HomeAssistant. I ran into some issues over there between and breaking updates and other weirdness made me wanna try something else. I only have a few matter devices and some WIFI LEDS (MagicHome) so migrating should be easy enough. I could get all of my devices connected in openHAB but after a power loss realized that the bindings assumed static IP addresses for the WIFI LEDs. Unfortunately, they get their IP via DHCP though since my router can only set a very limited amount that wouldn’t cover all of them.

Is there a way to keep the bindings in openHAB assigned by their MAC address instead ? In HomeAssistant I didn’t have to worry about changing IP addresses for the Wi-Fi devices after they were added. If there isn’t an easy way, what would be the best approach to assign fixed IPs if I cant configure the LEDs to request an static IP nor have enough range on my router ?

Thanks

2

Welcome to the openHAB community!

For devices you control directly (i.e. not through some sort of gateway), you will need an IP for every device and so obviously need a range of (free) addresses that is large enough to cover all devices. No matter what home automation you’re using.
A real shortage of (DHCP) IPs to assign also is pretty uncommon, so as the first step, please make sure you are not attempting to solve an X-Y type of problem: take a closer look at the router capabilities. Usually there’s ways to get more, e.g. by extending the netmask.
Only if that really is a hard limit you need to assign static IP addresses on the Wi-Fi LED devices themselves.
That being said, the recommended way to cope with this is to use semi-static IP addresses, i.e. keep using dynamic assignment via DHCP but have the router always assign the same IP address for a particular MAC address. About any modern router has such a feature, usually you need to tick a checkbox for every device you want to apply this to.

Hope this helps you enjoy openHAB.

1 Like
3

Agreed, but, just to temper expectations, I currently have 60+ devices on my lan, and if I were to be using my ISP router still, which has a hard coded limit of 50 devices (and another limit of 30 devices limit on the WiFi believe it or not!) I’d also be having issues.

So:

This is 100% the real way forward.

4

Welcome to the community!

The only thing I’ll add is you could possibly get around this issue through DNS. But a lot of things need to be in place to make it work right and when you throw IPv6 into the mix (required by Matter) it becomes a major PITA.

But it’s going to depend on the capabilities of your router and whether it has a DNS server built in like Unbound and that service can connect to your DHCP server. In that scenario, when a client registers for an IP address, the hostname and IP address are also registered with the DNS server and you’d then use the DNS name instead of the IP address in your Things.

If your router doesn’t support that, you could go down the route @Pedro_Liberal describes and move the DHCP and DNS off your ISP provided gateway to something else. I personally use opnSense. pfSense is also popular. But these are really heavy weight with lots of capability but lots of complexity as a result. It would look something like:

Internet  <--> ISP Gateway <--> opnSense <--> Wired connections <--> WiFi set to AP mode

But you could also set up PiHole or AdGuardHome as your local DNS server. I know for a fact that AdGuardHome has a built in DHCP server and suspect PiHole has the same. In this scenario you’d turn off your DHCP on your current router and let AdGuardHome/PiHole take on that role. These already have the DNS linked to DHCP leases so they will already know which IPs go with which hostnames.

The latter has the advantage that you can then implement network level ad/tracker/malicious blocking and parental controls (if you need that).

I personally run a combo of the two with opnSense providing DHCP and local DNS and AdGuardHome providing ad blocking. Dnsmasq registers IPv4 leases with Unbound. Unbound provides a second tier DNS lookup. This is where I configure 8.8.8.8, 1.1.1.1, etc. AdGuardHome uses Unbound as it’s upstream DNS server. So a DNS lookup from a client looks like:

nslookup google.com -> AdGuardHome (not on blocked list) -> Unbound (not local) -> 1.1.1.1 (returns IP address)
nslookup argus.koshak.lan -> AdGuardHome (not on blocked list) -> Unbound (loca) -> Dnsmasq (returns IP address)
nsloopup baddomain.com -> AdGuardHome (on blocked list, returns not found)

I’m still working with this to make it work with IPv6 (Dnsmasq doesn’t support assigning IPv6 addresses to MAC to it’s hard to identify clients). But the overall settings I use with opnSense are (I’m only posting the DNS related stuff, there is more requires to set these up):

  • DNSMASQ

    • enabled
    • DNS port 53053 (don’t use 5353 which has another purpose, don’t use 53)
    • do not forward to system defined DNS
    • DHCP default domain (I use koshak.lan but set this up before .local became official)
    • Register ISC Domain Mappings and Register static mappings (this is what @mstormi was talking about with assigning the mapping between MAC and address on the DHCP server)
    • You can do those static IPv4 mappings under the “hosts” tab

  • UNBOUND DNS

    • enabled
    • DNS port 5253 (don’t use 5353, don’t use 53)
    • Register ISC Domain Mappings and Register static mappings
    • Query Forwarding (this queries DNSMASQ for local addresses)
      • domain “lan” (as in “koshak.lan”, use what ever is the last part of your chosen domain), host 127.0.0.1, port 53053
      • DNS over TLS (your preferred DNS servers)

  • AdGuardHome DNS

    • Upstream DNS servers 127.0.0.1:5253
    • Private DNS Lookup Servers 127.0.0.1:53053
    • Use private reverse DNS servers enabled
    • Enable reverse resolving of client’s IP address

DHCP will serve out the IP address of the router with port 53 as the DNS server. So all DHCP clients will use 192.168.1.1:53 (or what ever your IP ranges are) which is where AdGuardHome is running.

AdGuardHome will first check to see if the domain is on the disallow list (there are tons of maintained lists of ad servers, trackers, malware, etc that can be automatically downloaded by AdGuardHome). If it passes the filters, it will query 127.0.0.1:5253 which is the UNBOUND server.

If the domain name ends in .lan UNBOUND will forward the query to 127.0.0.1:53053 to resolve local addresses. Note that DHCP will assign all its leasees to your default domain so if the DSN lookup is just a host name, your default local domain will be assumed.

If the domain name is anything else, UNBOUND will send the requests to your configured internet DNS servers (e.g. 1.1.1.1).

In AdGuardHome it is convenient to see hostnames instead of just IP addresses to identify clients. This is what those reverse lookups provide. If AdGuard does a reverse lookup using a BOGON (i.e. internal IP addresses which do not exist on the Internet, such as 192.168.1.23) it will query 127.0.0.1:53053 which is DNSMASQ, our DHCP server. Otherwise, it will send the query to UNBOUND which will forward it to the internet DNS servers.

Now this all kind of breaks down for IPv6 because clients do not usually register their hostname when they get an IPv6 lease, don’t always use a leased IPv6 address, and often change their address. I’m currently working through addressing that problem by forcing all DNS lookups to go through IPv4 so clients can be correctly tracked but haven’t finished that (it’s one of the things that has taken away my OH support time recently, the boy turned 13, and I need to beef up my parental controls game).

Note, to do parental controls through AdGuardHome, you would set up the most strict controls by default. Then on a client by client basis you can relax those controls. However, that requires the reverse lookups to work, hence the IPv6 problems.

You should be able to do all of this with PiHole too. I use AdGuardHome because there’s a plugin for opnSense and it has a way to block services (e.g. I can put a checkbox next to “Facebook” and it will block all access to Facebook without needing to maintain it in the filter lists. PiHole didn’t have that last time I looked at it.

With this configuration, I’ve removed all my overrides in AdGuard mapping my hostnames to their IP addresses (which is how I used to handle it). Eventually I might remove the static IP addresses from DNSMASQ too and let DHCP and DNS work the way they were always supposed to. However, that will explode the number of DNS queries (depending on the binding OH will make 100-200k dns requests a day) which can make it hard to track what’s going on with the DNS queries I really care about.

I know this is way more than needed, but it’s what I’ve been working on this past few weeks so it’s all fresh. Maybe when I get the IPv6 stuff working I’ll post a full tutorial. I know a lot of folks use opnSense on the forum. And the general approach should apply to other systems like tangled, pfSense, etc.

2 Likes
5

Thanks for the welcome and info. My router has a hard limit of 16 static IPs ←> MAC adresses i can define the rest is DHCP and random. The pihole/adguard idea sounds like the easiest to quickly try out. I don’t know if I can setup opensense/pfsense easily with what I have, I think the cable modem router combo i have is pretty limited for that. I feel I would need a dedicated opensense box with multiple nics and a dedicated wifi router.

For the Pihole/AdGuard approach:

  • i would turn off the DHCP on my router and give a static IP to the Pihole
  • then turn on the DCHP on Pihole/AdGuard and set static IP addresses based on MAC there
  • a local DNS name to bind it to an IP, i didn’t see the option to bind it to the host name in the documentation, only ip

What is the benefit of the last step, isn’t the static IP based on MAC enough ? I can see the appeal for services I want to reach and having a nice address vs “difficult” IP to remember but I would assume I do that once for IoT things and then never look at it once its running.

6

You would not put that on the cable modem/router. You’d put that on a machine that is just after that.

Right now you probably have the following configuration:

Internet <--> Cable Modem/Router <--> All wired and wireless LAN devices

With pfSense you would have at least one new device.

Internet <--> Cable Modem/Router with WiFi turned off <--> opnSense <--> All wired and wireless LAN devices

The only thing your Cable Modem/Router needs to do is be able to provide access to the internet for opnSense. Everything else concerning your LAN is handled by opnSense. In fact, as far as your LAN is concerned, the Cable Model/Router isn’t even part of your LAN anymore.

My configuration is

Internet <--> ISP provided fiber to ethernet media adapter <--> opnSense <--> Mesh WiFi in AP mode <--> All LAN devices

They make little machines purpose built for this sort of thing (e.g. Amazon.com : opnSense mini pc) which usually have at least four ethernet ports and often sport WiFi antennae as well. If you have 1 GB or less internet service the cheaper models will do the job, though I’d choose one with at least 2.5 GB ports in case you need to expand your internet service later.

But if you don’t have a separate WiFi router you need to plan on either having opnSense do that job or get a separate one.

It’s definitely a lot more work and hardware, but limitations of your ISP provided cable modem/router are irrelevant. All it needs to be able to do is connect to the internet and allow exactly one machine access to the internet.

I’d do it the other way around. But essentially yes, you’ll give a static IP to the PiHole and enable the DHCP server there and then disable it on the router. But you’ll probably want to do some configuration with the PiHole DHCP first, setting up address pools, subnet, domain, etc.

Any time you change the DHCP settings, you’ll need to have all your devices release/renew their leases to pick up the changes (or restart). You probably want to do that as few times as necessary.

Correct.

You shouldn’t need to do this. When the machines request an IP from the DHCP server, they will usually provide their hostname. Because you are using PiHole for both DNS and DHCP, those hostnames will automatically be mapped to the provided IP address. Only if this registration fails would you need to add a DNS override to map a hostname to an IP address.

In fact, if this hostname to IP address mapping works correctly, you don’t even need to create the static IP to MAC mapping. It doesn’t matter what IP address is assigned to because they can always be found by DNS. You’d just configure the domain name everywhere instead of IP address.

The point of DNS is not just to provide a “nice address”, but to manage that it’s really supposed to be the DHCP server which is responsible for assigning IP addresses and those IP addresses are not usually permanently assigned to a given device (i.e. subject to change).

But like I said, this isn’t a step you need to do manually. It happens automatically when the clients request a lease. It’s only if that didn’t happen (e.g. a client did not supply it’s hostname when it registered, that hostname is already in use on the DHCP server, or you want to use a different hostname. In my experience, even ESP8266’s will register a hostname so it should be very rare that this doesn’t happen (on IPv4 at least).

7

Let me just add completely off-topic that Matter’s requirement for IPv6 is stupid and a reason that I at least won’t use Matter devices. IPv6 just has too many shortcomings, and the lack of NAT makes tracking you so much easier from the outside. Also, I don’t get why people use the ISP provided routers, it gives the ISP full control over and insight into your local network. I don’t have that level of trust, and would never do that. I want to have a firewall, controlled by me, between my local network and the ISP.

On-topic: Does anybody know how HA manages to “follow” these devices without needing a fixed IP. It sounds likely that mDNS is used. OH has mDNS capabilities too, so it might be something for the Matter binding to focus on. This sounds like a problem that might apply to a lot of people being force to use IPv6 because of Matter.

It might also be worth mentioning the “obscure feature” OH has that lets mDNS update the device IP automatically, but only if you use the ThingUID suggested by discovery. I don’t know how you created the Things, but if you let discovery find them and then accept the suggested UID, they just might update the IP automatically.

1 Like
8


 and a reason that I at least won’t use Matter devices. IPv6 just has too many shortcomings, and the lack of NAT makes tracking you so much easier from the outside.

Good to hear that someone else is staying away from Matter for that very reason, that all Matter devices can phone home, without any possibility of prohibiting that, so their status can be tracked by the manufacturers all the time.

Just as I do not allow any cloud reliant devices in my setup, I’m not going to start now with Matter :wink:

1 Like
9

I don’t think the problem OP expressed had to do with Matter. It had to do with other IOT devices on IPv4. The IPv6 stuff kind of just works when it comes to Matter. I don’t know how but something in the protocol is able to find the devices even when/if they change their IPv6 address.

But it becomes somewhat of a pain for everything else on the LAN, particularly if you want to implement parental controls through the DNS server like I do.

I’m unaware of any firewall in common usage these days that cannot block IPv6 traffic. I don’t allow any IPv6 traffic out of my LAN with one simple firewall rule. It’s not too hard.

10

It’s not hard to block, but it’s not hard for the manufacturer to make sure that the device doesn’t work without internet access either. So, often you have no choice, and that’s deliberate in my view. Just take Chromecasts, they are hardcoded to use Google’s DNS servers and don’t respect what DHCP tells them, and the “apps” are stored online so you can’t “launch” anything on the device if it’s blocked.

11

AFAIK it’s not so much the actual individual IPv6 traffic, but the the traffic through any border router in the same network. Short from blocking any such border router, usually killing their other fictionality, I am not aware of blocking individual Matter devices within the border router setting, nor that the traffic can be individually filtered at the WAN level.

12

Matter devices do not require internet access to work. Thread Border Routers sometimes require internet access to work, but not all of them and in those cases the internet is to provide other functionality outside of Matter. There is nothing inherent in Matter that required Internet. It’s kind of the whole point.

If you don’t trust commercial TBRs, make your own. ESP Thread Border Router  |  OpenThread. It costs $20 and there are open source firmware to drive it.

Again, there is nothing inherent in Matter that requires internet.

If you have a device that only does TBR, you lose nothing by blocking its access to the internet, though this firmware doesn’t really “phone home” as far as I can tell anyway.

13

I wasn’t addressing Matter in particular. I know to little about it. But I can’t see any “legitimate” reasons why they would require IPv6 for Matter. It makes tracking easier, unless you really know what you’re doing (and most people don’t). There are no “benefits” with IPv6 that I’m aware of except that you have a bigger address space, but for home networks that’s not really an issue, the 10.0.0.0/8 subnet alone contains 16777216 IP addresses, which should be sufficient for most home networks.

Also, it has become very clear that Google’s core business is selling your information, and everything they do has collecting information about you deeply integrated. While I don’t know the technical details of Matter, I don’t want to touch it because of Google’s involvement alone, with the forced IPv6 being “the icing on the cake”.

14

As I do have commercial TBRs, which I also want in my network for their other functionalities, they would always pick up the Matter devices. Suffice to say though, that currently I have not had the need to add any Matter device, as all functionalities I want can be nice;y achieved with non-Matter devices :wink:

But not wanting to hijack @HomeAutomationNoob’s thread.

How about flashing your Magic Hime devices with Tasmota firmware, which should allow static IP address setting directly on the LED controllers, not needing assignment through your router?

Or alternatively use Bluetooth to control them, AFAIK they also support Bluetooth along with WiFI.

Or see which other DHCP devices in your network allow for static IP setting themselves, like all your desktop and laptop computers, TVs etc. to free up the limited static slots on your router.

15

Not unless you joined them to the same mesh network. Matter devices don’t just automatically join every TBR they see. You have to pair them which involves putting the device into pairing mode and scanning a QR code or entering a code manually into the TBR. You can have a Thread network that your commercial devices are completely unaware of.

16

Not unless you joined them to the same mesh network 


Might be something for me to look into if and when I think that I should or possibly have to move to Matter. My reluctancy persists though, for much the same reasons as @Nadahar’s. I do believe that this phoning home capability was put in place on purpose, only being able to prevent it by jumping thoirughn hoops.

Maybe this could be discussed in details in some separate thread, about Matter ins and outs, as for the time being 



 not wanting to hijack @HomeAutomationNoob’s thread.

17

Wow so much that I have to look into. Thanks everyone !

If its possible that I can maintain DHCP with reserved addresses based on IP that would be my preferred method. I know I can manually set the IP on the laptop, 
 but for everything except a fixed server or something immobile I would like to avoid it. At least as long Windows does not allow me to have configurations between static/automatic for each Wi-Fi network and just one per network adapter. It’s just convenience and having everything in one place like my router or PiHole/Adguard DHCP server that manages my home makes sense to me. So I will try this first. For security I can just keep blocking whole ip ranges on my rotuer, currently I had my phone, laptop, ..(things I care about that they have internet on my limited number of static ips given by the router) and everything else blocked but more static addresses handed out by PiHole/AdGurads DHCP will not affect that.

How about flashing your Magic Hime devices with Tasmota firmware, which should allow static IP address setting directly on the LED controllers, not needing assignment through your router?

https://templates.blakadder.c​om/light.html

Or alternatively use Bluetooth to control them, AFAIK they also support Bluetooth along with WiFI.

Or see which other DHCP devices in your network allow for static IP setting themselves, like all your desktop and laptop computers, TVs etc. to free up the limited static slots on your router.

I looked at Tasmota at one point and did that for a door sensor but the LEDs are not listed and I bricked one already messing around with it. I completely forgot about Bluetooth and have to look into that.

I don’t think the problem OP expressed had to do with Matter. It had to do with other IOT devices on IPv4. The IPv6 stuff kind of just works when it comes to Matter. I don’t know how but something in the protocol is able to find the devices even when/if they change their IPv6 address.

Yes the matter devices just work and I think its cause of the ipv6 that has the MAC inside the address but not 100% sure. And I kind of like that, it makes it easy to deal with. I also liked that its 1 standard and I don’t have to deal with several integrations / add-ons for different device manufactures.


 and a reason that I at least won’t use Matter devices. IPv6 just has too many shortcomings, and the lack of NAT makes tracking you so much easier from the outside.

Good to hear that someone else is staying away from Matter for that very reason, that all Matter devices can phone home, without any possibility of prohibiting that, so their status can be tracked by the manufacturers all the time.

Just as I do not allow any cloud reliant devices in my setup, I’m not going to start now with Matter :wink:

Can someone explain to me how this is different from IPv4 devices ? As long it’s connected to a network it should be able to phone home if it wanted to, at least that’s always my assumption. I don’t see how NAT prevents tracking in this case. If the device phones home it will be automatically associated with your home’s IP. Tracking the on/off or whatever functionality can then also just track where they are and potentially what they are (Living room lights switch off at night, Bedroom lights go on shortly after, 
) . NAT doesn’t prevent anything here.

It’s not hard to block, but it’s not hard for the manufacturer to make sure that the device doesn’t work without internet access either. So, often you have no choice, and that’s deliberate in my view. Just take Chromecasts, they are hardcoded to use Google’s DNS servers and don’t respect what DHCP tells them, and the “apps” are stored online so you can’t “launch” anything on the device if it’s blocked.

Isn’t this than the same as for an IPv4 device too ?

AFAIK it’s not so much the actual individual IPv6 traffic, but the the traffic through any border router in the same network. Short from blocking any such border router, usually killing their other fictionality, I am not aware of blocking individual Matter devices within the border router setting, nor that the traffic can be individually filtered at the WAN level.

Can an IPv6 device route traffic for another IPv6 device out of the network ? But there is no NAT so shouldn’t I be able to block the device individually on the gateway ?

18

We’ve talked about different aspects here, and they can’t all be mixed into one :wink: All devices with Internet access can “call home”. If the firmware is proprietary and the communication encrypted, you’ll never know for sure - you can’t really tell warranted traffic from them uploading data it has stolen from you. So, it ends up being a matter of trusting the manufacturer or firmware author, and very few companies have earned any such trust these days. That fact that governments sometimes force them to spy for them doesn’t help either.

When I talk about IPv6 and NAT, it’s not about the “calling home” functionality, but about the fact that your IP address basically contains the “serial number” of the device sending the packet. It’s like if you sent a letter and had to write your social security number on the outside of the envelope. Anybody that sees the packet on its way to the destination and the recipient will know this “serial number” of the sender. It will be recorded in all logs along the way.

With IPv4 and NAT, the packet is transformed to look like it originates from the router when it traverses the router. The router then keeps an internal table where it keeps track of what it has send out, so that when it gets replies, it forwards them to the correct local device. It means that any outsider can’t tell which device the packet came from, only which router sent it out on the Internet. It’s a huge difference, and going to IPv6 without “solving” this is just a terrible idea.

IPv4 has 32 bits, which sadly leaves us with a too small pool of addresses globally (but not locally). IPv6 has 128 bits, which is way, way overkill. With 128 bits, you can have 340282366920938463463374607431768211455 unique IP addresses. It’s a number so huge that it’s meaningless. 64 bits would have been more than sufficient, and is what IPv6 should have used, and in a way it’s what it uses. Because, the first 64 bits is the only part that is “routable”, the last 64 bits are just the “device identifier”.

They have since realized that using the MAC address as the “device identifier” is too stupid, and they not “recommend” that a random ID is generated instead. But it only help so much, yes now you mark you envelope with a “fake social security number”, but you’ll use the same number for every letter, so it’s still super-easy to tell different devices apart. The anonymization of IPv4 is gone. On top of that, you’re left to trust that each and every device manager actually follows the recommendation to not use the MAC address, even though it’s much easier for them (for small, resource-starved devices) to just use that instead of dealing with random generation, conflict resolution etc.

To me, the last 64 bits must be replaced with something that is the same for all local devices when the packet traverses the router, so that you break the “built-in tracking” of IPv6. I’ve heard some say that it’s possible, I’ve not dug into IPv6 enough to know, but it would basically be NAT (the router would have to keep the same table to handle incoming packets), and it’s unclear to me if this functionality is generally available in most routers. In fact, I doubt it. I also doubt that most people will have any idea about this or how to do it. Which is why I say that IPv6 will just make all kind of tracking magnitudes worse than it already is.

Yes, these are different issues - Chromecasts very much do their spying using IPv4. It doesn’t change the fact that forcing IPv6 will leave a lot more tracking info “everywhere” out on the Internet.

Basically, if you can’t trust the firmware/software (if it’s proprietary), you can’t know what it does with your info. A device doesn’t have to route traffic for the other device, it can just report any information it gets from the other device locally to its “corporate overlord” in its own encrypted connection. I really doubt they would route packets for other devices, that’s way too transparent.

19

This isn’t correct in all cases. Yes, some devices do this but they are supposed to periodically randomly generate a new IPv6 address. Windows, Linux, and Mac (based on my observations) do this. I’m not certain about Android yet (IPv6 is kind of half-assed on Android). Many of the larger IoT devices on my network also do this (including the chromecasts). But I’ve not assessed the smaller ones yet.

In fact, this is the source of my pain to impose parental controls on the network. I cannot easily map an IPv6 address to a specific device to provide exceptions to the controls (i.e. make the restrictions more or less strict for specific devices). Their addresses only seem to last a day or so and for some reason using the MAC address isn’t working as an ID in AGH (probably because Dnsmasq is the DHCP server instead so AGH doesn’t see them in the DNS requests). I’m currently working out how to force DNS to only occur over IPv4 which is possible, but it requires manually editing config files for Dnsmasq and Unbound and I can’t afford to break my network right now.

To summarize:

  1. Matter requires IPv6
  2. Matter does not require internet to work
  3. It’s very easy to block all IPv6 traffic at the firewall. Basically “deny all outbound IPv6”. You can block all inbound too if you want though you should probably be blocking all inbound traffic anyway by default.
  4. It only breaks the commercial TBRs other functionality if those TBRs don’t also use IPv4. I can’t imagine such a device exists. (I’m not sure if I made myself clear on this previously.) When IPv6 is blocked they will fall back to IPv4.
  5. If you don’t trust the commercial TBRs, you can make your own for $20 and some change.

Privacy concerns are not inherent in Matter. If you have such concerns it is relatively easy to use Matter privately and safely.

IPv6 on your LAN does not create a privacy concern by itself. You can and should just prevent IPv6 from exiting your LAN. Half the internet doesn’t support IPv6 anyway (e.g. github,.com is IPv4 only) so there really is no point in letting IPv6 out of your LAN. And anything that does need to communicate to the Internet will fall back to IPv4 if IPv6 is blocked and all the usual IPv4 stuff will then apply.

However, if you decide to go full IPv6 instead of dual stack it becomes much more complicated. Don’t do that. It is a bad idea.

I’m not trying to convince anyone for or against using Matter or IPv6 or whatever. But for those whose risk calculation (choosing not to do something also comes with costs) comes down on the side of using Matter, it is neither complicated nor expensive to do so and maintain privacy.

20

I also said that - but the randomly generated “fake MACs” don’t help that much. The outside can still easily track individual devices if you let the IPv6 traffic out.

MAC addresses originally only exist on layer 2, and the should remain on layer 2. IP is layer 3. IPv6 still work with layer 2 via NDP (instead of ARP). Are you saying that there aren’t tools to lookup the layer 2 information for IPv6, or that the devices also fake the layer 2 address? If they fake the layer 2 addresses, there will be confusion in switches etc. when they change, but perhaps they have found a way around that.

My main point is that an actual MAC address (layer 2) still isn’t the same as the last 64 bits of an IPv6 address (layer 3), even if they are the same in some/many cases. And, that even though the last 64 bits are randomly generated, it’s an excellent way to track individual devices. Also, originally for IPv6, the last 64 bit was supposed to be the same as the MAC address, and I think it’s hard to get fully rid of such a legacy.

That may be true, but it requires that I: 1) Trust the people behind it and take their word for it 2) Dive down into all the details of the protocols, read and verify the source code of devices. You can say that this is true for many things, but when you have a standard founded by Amazon, Apple and Google, three of the biggest “surveillance companies” out there, there’s no reason to base any assumptions of trust. “Open source” is only worth so much, we’ve seen it all before, they use their “market share power” to enforce their way regardless. Look at Android, still supposedly open source. Users cannot install the version they want, users aren’t allowed to control permissions on their own devices, and soon they can’t even install software that’s “approved by Google”. They put a layer of proprietary code “on top of” the open source that does all the spying “Google Play Services”, and effectively force you to use it if you want anything at all to work. For example, at one stage they removed the possibility for push-notifications if you don’t use “Google Play Services”. Before that, it worked just fine. There are endless examples of similar behavior. What makes you think Matter will be any different? They typically start out quite reasonable, and then they increasingly restrict things as people “become more dependent” on the product or service.

To me, it’s just way easier to steer away from those that you know have bad intentions, then to try to keep up with every detail in every change that you know will come over time.

That is true, but it’s not that simple. If you enable IPv6, many things will resolve names to IPv6 addresses, and if you block IPv6, the result is that the resource won’t work. How do you prevent OSes and devices from picking the IPv6 address if a name resolution returns both an IPv6 and an IPv4 address?