# [SOLVED] IPV6 autoconfig sudden address change weirdness?

## eccerr0r

I don't know if this is just an artifact of SLAAC or other stateless configuration, but what's happening:

Initially I get an ipv6 address PREFIX::X000 ... This does not look like a SLAAC address.

However a few minutes later, I get PREFIX:SLAAC ... This does look like a SLAAC address.

However several minutes occur between these two occurrences, and if I open a connection between when I get a true SLAAC address, it will be lost because that address is now gone.  I can "fix" it by putting that PREFIX::2000 address back by re-adding it to the interface, but I wonder

- why is this occurring?  Is this due to DHCPv6 or something with SLAAC enabled?

- can this be stopped?  Ideally I'd like one or the other, DON'T CHANGE the IPV6 address!

---

I think the problem is now solved.  It was Networkmanager somehow generating an extra address, deleting the old profile and creating a new one stopped it.

----------

## wswartzendruber

This sounds like SLAAC privacy extensions.  If you want a fixed address, you need to assign one manually.  Otherwise, with privacy extensions, your address will routinely change as your specific host will eventually become easily identifiable on the Internet.  Your machine should still acknowledge old addresses, but new packets leaving will originate from the newest address.

In IPv6, there is nothing wrong with an interfacing have more than one address on it, or even more than one address from multiple subnets.

----------

## NeddySeagoon

wswartzendruber,

The privacy extensions do not change the IPv6 prefix, so provide an illusion of privacy at best.

I use dhcpcd and radvd on my router, for IPv6.

Together, that gets my /48 from my provider and allocates a different /64 to each downstream interface in the router.

The autoblackmagic then makes up IPv6 addresses for the leaf hosts based ot the MAC addres.   

```
$ ifconfig

eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500

        inet 192.168.100.20  netmask 255.255.255.0  broadcast 192.168.100.255

        inet6 2a02:8010:xxxx:3:2e0:4cff:fe69:1509  prefixlen 64  scopeid 0x0<global>

        inet6 fe80::2e0:4cff:fe69:1509  prefixlen 64  scopeid 0x20<link>

        ether 00:e0:4c:69:15:09  txqueuelen 1000  (Ethernet)

        RX packets 70030  bytes 96085016 (91.6 MiB)

        RX errors 0  dropped 0  overruns 0  frame 0

        TX packets 46058  bytes 8804506 (8.3 MiB)

        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
```

I've removed my prefix there.

----------

## wswartzendruber

If you want that kind of anonymity you need Tor.  The purpose of privacy extensions is to obscure which specific device you're using.

Still, I didn't notice before that the old address had been removed.  That sounds like something else.

----------

## eccerr0r

Okay:

Yeah this isn't specifically an anonymity issue, it's more of a convenience issue - if it changes addresses, all existing connections stop working, and this is what I want to prevent.

I think I might have found a clue - When I ip -6 addr after a fresh boot, I see this:

```
    inet6 PREFIX::2000/128 scope global dynamic 

       valid_lft 7178sec preferred_lft 4478sec

    inet6 PREFIX:SLAAC/64 scope global noprefixroute dynamic 

       valid_lft 86393sec preferred_lft 14393sec

```

where PREFIX is my 6rd prefix and SLAAC is a random jumble of bits that's virtually static.  So I now have two IPV6 addresses in my block.

The problem is that this indicates in 7178 seconds (apparently 2 hours from creation), the first address is gone as its lifetime expires.

However since the PREFIX::2000 address is first, the machine uses this address to open new connections and in 7178 seconds, all of these connections are now hung as the interface is no longer listening to the expired address.  It looks like the second address expires in a day, which is fine.

Now the question is, what's generating that first address?  Do some DHCPv6 servers generate this address?  Also it's weird this is a /128.

----------

## wswartzendruber

For a privacy address to expire in a day is about right.  Windows, for example, cycles them every 48 hours.  But that first address you have seems to be something else entirely.

But what did you mean by "virtually static?"

----------

## eccerr0r

"virtually static" as in, I rarely if ever see it change.  Not a terrible deal but I'd expect it to somewhat change if it truly is SLAAC with privacy extensions enabled.

At least it does not outright dump the MAC address of the interface there though some of my machines do have the MAC there, I'll need to double check their config...

==============

So far I found two machines that exhibit this issue.  These machines are all on the same collision domain.

```

fuXXXXXX systemd networkmanager - Extra IPV6 Address (PREFIX::2000)

mikXXXXX systemd networkmanager - Extra IPV6 Address (PREFIX::1736, IIRC; different than the other machine)

yuXXXXXX systemd networkmanager - No extra address

chXXXXXX openrc  networkmanager - No extra address

liXXXXXX systemd networkmanager - No extra address (Test VM)

mipXXXXX openrc  udhcpc         - No extra address (Test VM)

```

I have a few more boxes to check to see if they exhibit this weird issue and I'm not including my servers for now, just the ones I can safely reboot randomly. 

Also another observation: disconnecting and reconnecting the network does not get the other IP address.

And another theory that has yet to be tested: The machines that exhibit the problem have libvirt running on them while others do not.  I have two other machines that I have yet to test to see if they exhibit this behavior (one systemd - PVR, one openrc - network server) to see if these also do it.  However the network server I don't want to reboot, the PVR I can do when there's no recordings going on...

=========================

Okay I found out how to disable the second address, but now my computer is completely deaf to the LAN on ipv6 address.

Based on deduction, NETWORKMANAGER decided to add that IP address.  When I deleted the networkmanager profile and readded a new one for ethernet, the new one no longer has that weird ::2000 address.  Also the interface picked up a new SLAAC address courtesy privacy additions.

However now I've lost ipv6 network connectivity to machines on my LAN.  Hosts outside of my LAN still work(!!!)

----------

## UberLord

 *eccerr0r wrote:*   

> Now the question is, what's generating that first address?  Do some DHCPv6 servers generate this address?  Also it's weird this is a /128.

 

To help narrow it down, DHCPv6 servers generate /128 addresses for IA_NA (default address type) and IA_TA addresses.

But in all likely hood, it is a DHCPv6 IA_NA address.

Is your IPv6 router advertising with the M flag set? If so, then this is expected behaviour.

If you not adverse to killing NetworkManager temporarily (assuming it's not also in charge of link setup and you have a relatively recent dhcpcd version) you could run `dhcpcd -dB` on the console and you'll get so much debug you should see where this address is coming from.

Or you can trawl your system logs to see if NetworkManager logs anything useful.

----------

## eccerr0r

I can't seem to get NM to get that :2000 address anymore, but ipv6 is no longer working for LAN addresses at all anymore (but working outside of the LAN).

I installed dhcpcd anyway and killed networkmanager for a bit.  I get this address and flags:

```
    inet6 PREFIX:SLAAC/64 scope global mngtmpaddr noprefixroute dynamic 
```

ip -6 route reports:

```
PREFIX::/64 dev enp4s0  proto kernel  metric 202  mtu 1500 pref medium

fe80::/64 dev enp4s0  proto kernel  metric 256  pref medium

ff00::/8 dev enp4s0  metric 256  pref medium

default via fe80::1:1 dev enp4s0  metric 202  mtu 1500 pref medium
```

My working machine (dhclient):

```
    inet6 PREFIX:SLAAC2/64 scope global noprefixroute dynamic 

PREFIX::/64 dev eth0  proto ra  metric 100  pref medium

fe80::1:1 dev eth0  proto static  metric 100  pref medium

fe80::/64 dev eth0  proto kernel  metric 256  pref medium

ff00::/8 dev eth0  metric 256  pref medium

default via fe80::1:1 dev eth0  proto static  metric 100  pref medium
```

My RA server is currently pfSense (currently trying to see if I can build a Linux one), so I'll need to study it more though I do have machines that work on the subnet so it's probably working.

===============================

EDIT:

I figured it out.  Was something dumb.

I had known my pfSense bridge does not pass same-LAN ipv6 packets properly (but bridges IPV6 RA, IPV6 out of network, and all dhcp/ipv4 packets fine) and I had inadvertently plugged in my in-question machine into the bridge instead of the switch that had run out of free ports .  Plugging the client machine back into the switch with the rest of the ipv6 capable hosts restored operation.  I had intended to segregate more of the 100Mbit segment to the pfSense bridge as it had all 10/100 ports, but unplugged the wrong one.

However the initial question was due to NetworkManager and not from the IPV6 RA - dhcpcd showed no such address being passed/created.

===============================

Offtopic EDIT:

And I fixed my pfSense bridge to pass IPV6.  Apparently each bridge leg needs to have a pass rule for this to work along side the IPV4 rule.  Adding this rule allowed IPV6 to bridged and all is fine once more.

----------

