Is EUI-64 safe?

explorer · November 22, 2025, 1:28pm

I may have messed up my config, clients now can only get public ipv6 address from slaac, they used to get another public ipv6 address from DHCPv6 too.
If EUI-64 is safe and doesn't have privacy concern, I can fix the config later when I'm alone. But if no, .

I create a zone for homelab with ipv4 only, because my ISP only give me a 64 length prefix. And I'm using dnsmasq-full, and odhcpd-ipv6only is gone.

/etc/config/network

config interface 'loopback'
        option proto 'static'
        option ipaddr '127.0.0.1'
        option netmask '255.0.0.0'
        option device 'lo'

config globals 'globals'
        option ula_prefix 'fd0c:2f7a:4c96::/48'
        option packet_steering '1'

config interface 'lan'
        option proto 'static'
        option device 'eth1'
        option ipaddr '192.168.1.1'
        option netmask '255.255.255.0'
        option defaultroute '0'
        option ip6assign '64'
        option ip6hint '1'
        option ip6ifaceid '::1'
        list ip6class 'wan6'
        list ip6class 'local'

config interface 'lab'
        option proto 'static'
        option device 'eth2'
        option ipaddr '192.168.2.1'
        option netmask '255.255.255.0'
        option delegate '0'
        option ipv6 '0'

config device
        option name 'eth2'
        option ipv6 '0'

config interface 'wan'
        option device 'eth0'
        option proto 'pppoe'
        option username '****'
        option password '****'
        option ipv6 '0'

config interface 'wan6'
        option device '@wan'
        option proto 'dhcpv6'
        option norelease '1'
        option reqaddress 'try'
        option ip6assign '64'
        option ip6ifaceid 'random'
        option reqprefix '48'
        list ip6class 'wan6'

/etc/config/dhcp

config dnsmasq
        option domainneeded '1'
        option localise_queries '1'
        option rebind_protection '1'
        option rebind_localhost '1'
        option local '/lan/'
        option domain 'lan'
        option expandhosts '1'
        option cachesize '1000'
        option authoritative '1'
        option readethers '1'
        option leasefile '/tmp/dhcp.leases'
        option resolvfile '/tmp/resolv.conf.d/resolv.conf.auto'
        option localservice '1'
        option ednspacket_max '1232'

config dhcp 'lan'
        option interface 'lan'
        option start '50'
        option limit '200'
        option leasetime '3h'
        option dhcpv4 'server'
        option ra 'hybrid'
        option dhcpv6 'server'
        list ra_flags 'managed-config'
        list ra_flags 'other-config'
        option dhcpv6_pd_min_len '62'

config dhcp 'wan'
        option interface 'wan'
        option ignore '1'

config dhcp 'lab'
        option interface 'lab'
        option start '100'
        option limit '150'
        option leasetime '3h'
        option dhcpv6 'ignore'

brada4 · November 22, 2025, 1:42pm

EUI64 is directly derived from MAC address.

lleachii · November 22, 2025, 1:46pm

Did you update to SNAPSHOT?

I understand that random is no longer valid.

Interesting.

Was this some kind of workaround?

goetz · November 22, 2025, 2:20pm

Please read RFC7721 for security and privacy considerations why not to use EUI64 addresses.

moeller0 · November 22, 2025, 2:37pm

I note that you typically can change the MAC address under Linux, so leaking an EUI-64 interface identifier is not without remedies, but I agree that this is not perfect either.

explorer · November 23, 2025, 4:07am

Thank you very much for answering my question.

Yes, I know, that why I'm concerned.

No, it's for if I messed up, only homelab network will be affected, and lan will not be affected, so no one will yell at me.

Thank you that's what I'm looking for.

And my network restored after openwrt reboot, weird. Lan dhcp config should be this:

        option ra 'server'
        option dhcpv6 'server'
        list ra_flags 'managed-config'
        list ra_flags 'other-config'

timur.davletshin · November 23, 2025, 4:40am

Correct me if I'm wrong but default suffix is ::1 which is widely used by other routers. Yeah, it is useless for tracking like UEI-64 but nevertheless predictable.

Have you tried making router IPv6 address random? Does it work reliably in case of router reboot? I guess it should... But who knows?

lleachii · November 23, 2025, 8:48am

This part:

The user didn't say what version of OpenWrt they're running.

You're correct.

It was never [clearly] explained in the previous thread why random was removed. The other user was under the impression that random never worked, yet I'd been using it successfully for years. In fact, it still works on non-DHCPv6 interfaces.

Sid · November 25, 2025, 9:28am

In fact, it still works on non-DHCPv6 interfaces

Can you elaborate on what the issue really is?
On v24.10.4 I’ve been updating the stable secret for my wan6 interface using a cronjob along with the ip6ifaceid as random under wan6 and it is working even on a dhcpv6 interface

anon6639214 · November 25, 2025, 12:22pm

Starting at Odhcp6c issues in SNAPSHOT? - #14 by Cthulhu88 I've written some details on why ifaceid/ip6ifaceid set to "random" won't work with odhcp6c. It's either ignored or errors out, depending on the version of dhcpv6.sh.
The address obtained from DHCPv6 is not generated by you and the one obtained through SLAAC cannot be randomized by odhcp6c, it's either the 64-bit suffix from your wan interface's link scope address or the 64-bit suffix from the static address passed via the -i option (which can be specified via ifaceid or ip6ifaceid, depending on the version of dhcpv6.sh).

lleachii · November 25, 2025, 12:44pm

The issue is:

Other users said that setting random on wan6 doesn't work (as I stated, I also did the same as you've described in version 24.10.4) - in particular, they said it's ignored, but that wasn't my experience
In snapshot, configuring the interface as random causes it not to work, that prompted me to create another recent thread

Edit:

To be clear, they say that setting random actually had the effect of making the interface EUI64.

Sid · November 25, 2025, 3:53pm

Would setting a new stable_secret also not work in this case and be ignored by odhcp6c?

anon6639214 · November 25, 2025, 5:15pm

As explained, if the -i option is not present, odhcp6c will take the 64-bit suffix from the interface's link scope address. If a system conf caused the kernel to assign a non-EUI64 suffix, then that's what it will be used.

Kernel managed privacy extensions (addresses with the mngtmpaddr and temporary flags) is not supported by netifd either.

EDIT:

github.com/openwrt/netifd

interface.c

777f5942f


      
          		if (!strcmp(ifaceid, "random")) {
          			iface->assignment_iface_id_selection = IFID_RANDOM;
          		}

github.com/openwrt/netifd

interface-ip.c

777f5942f


      
          	list_for_each_entry(c, &prefixes, head)
          		list_for_each_entry(a, &c->assignments, head)
          			if (!strcmp(a->name, ip->iface->name))
          				interface_set_prefix_address(a, c, ip->iface, enabled);

github.com/openwrt/netifd

interface-ip.c

777f5942f


      
          			if (!generate_ifaceid(iface, &addr.addr.in6))
          				return;

github.com/openwrt/netifd

interface-ip.c

777f5942f


      
          	case IFID_RANDOM:
          		/* randomize last 64 bits */
          		random_ifaceid(addr);
          		break;

github.com/openwrt/netifd

interface-ip.c

777f5942f


      
          	addr->s6_addr32[2] = (uint32_t)mrand48();
          	addr->s6_addr32[3] = (uint32_t)mrand48();

As you can see from above, ip6ifaceid "random" applies to a delegated prefix being managed by netifd, not to an already formed address generated by odhcp6c and passed to netifd via dhcpv6.script.

_bernd · November 25, 2025, 6:34pm

Even they may are use cases where a user what's extra privacy/protection with using a random MAC on wan, but it should be only be random at boot.
For the whole uptime the router should not drop and change addresses on its interfaces.
From a net op perspective....

anon6639214 · November 25, 2025, 7:32pm

When a temporary address becomes deprecated, a new one MUST be
generated.

The frequency at which temporary addresses changes depends on how a
device is being used (e.g., how frequently it initiates new
communication) and the concerns of the end user.

Because the precise frequency at which it is appropriate to generate
new addresses varies from one environment to another, implementations
SHOULD provide end users with the ability to change the frequency at
which addresses are regenerated. The default value is given in
TEMP_PREFERRED_LIFETIME and is one day. In addition, the exact time
at which to invalidate a temporary address depends on how
applications are used by end users. Thus, the suggested default
value of one week (TEMP_VALID_LIFETIME) may not be appropriate in all
environments. Implementations SHOULD provide end users with the
ability to override both of these default values.

Temporary addresses as part of SLAAC privacy extensions are based on lifetime.

Stable private/randomized addresses are implemented according to https://datatracker.ietf.org/doc/html/rfc7217#section-5
They are not based on boot either.

RID = F(Prefix, Net_Iface, Network_ID, DAD_Counter, secret_key)

_bernd · November 25, 2025, 8:56pm

Yes I know (all) these RFC and more or less how privacy extension should work.
But the point I try to make: why does a ROUTER needs to change its addresses?
Yes ok still some wanky VPN setups.... But from normal network operations view... Still. Why change them during RUNTIME?
My reasoning is that one principle in the beginning of v6 was: hopefully never ever need for renumber!
If you renumber you introduce issues you would not have in the first place.
I'm simply curious what benefit this serves besides the usecases of a snodenstyldle VPN setup.

lleachii · November 25, 2025, 8:59pm

Just to be clear since both threads are experiencing drift of the topic - EUI64 (and what was assumed to be "random") IPv6 addresses on WAN6 don't change during runtime.

I'm not sure who introduced the notion of temporary addresses into the discussion (I'll have to re-review).

anon6639214 · November 25, 2025, 9:42pm

it's all so tiresome.

_bernd · November 25, 2025, 10:03pm

Thanks for the recap and point of view.

Sid · November 26, 2025, 11:48am

why does a ROUTER needs to change its addresses?

As you already mentioned vpns, my router acts as a Wireguard server and client devices expose its wan6 ip while connected to it, having a single ip which never changes makes it a privacy issue.

This is why I use a cronjob to update the stable_secret every Sunday and reboot the router to refresh the ip.