After tumbelweed update, IPv6 no longer exists

English Network/Internet
1

ID=“opensuse-tumbleweed”
VERSION_ID=“20240808”
6.10.3-1-default x86_64

After the update and boot, all trace of IPv6 addressing has disappeared for the whole local network. The DHCP6 server shows no leases. The journals have no mention of dhcp6 whatsoever.

This was all fine 12 hours ago.

How do I diagnose such a bizarre condition?

2

@jimbobrae what does sysctl net.ipv6.conf.all.disable_ipv6 show?

3 
# sysctl net.ipv6.conf.all.disable_ipv6
net.ipv6.conf.all.disable_ipv6 = 0
4

And another bizarre side effect of losing IPv6: terminal windows connected to a remote host via SSH, time out.
If there is no data transfer for some amount of time (10 - 20 minutes) the terminal window goes catatonic. No message, no response to the keyboard, nothing, nichts, nil, nada, zip, zilch, bupkis.

Also, nothing in the journals.

5

You might try rebooting your router. Maybe the problem is there.

6

I already tried that. No change. In fact, I have booted all of the systems connected to the network.

7

Bizarre problem, yes.

I am also on VERSION_ID="20240808" and I am not using IPv6 AFAIK but still ip a is showing IPv6:

> ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host noprefixroute 
       valid_lft forever preferred_lft forever
2: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether c9:42:fe:5f:25:8f brd ff:ff:ff:ff:ff:ff
    altname enp0s31f6
    inet 172.20.2.9/24 brd 172.20.2.255 scope global dynamic noprefixroute eno1
       valid_lft 73017sec preferred_lft 73017sec

Can you try booting with an older kernel?

8

I note that DHCP4 works as always.
The IPv6 prefix for our network is fd2f:4760:521f:3f3c::/64.
The inet6 shown below is a default assignment of some sort.

>  ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host noprefixroute 
       valid_lft forever preferred_lft forever
2: enp8s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether fc:34:97:10:e9:0c brd ff:ff:ff:ff:ff:ff
    inet 192.168.69.115/24 brd 192.168.69.255 scope global enp8s0
       valid_lft forever preferred_lft forever
    inet6 fe80::fe34:97ff:fe10:e90c/64 scope link proto kernel_ll 
       valid_lft forever preferred_lft forever
9

Repeating “it does not work” over and over again is not going to solve anything. Start with providing real information. Beginning with what you are using for network management - wicked, NetworkManager or anything else.

10

Here is curiosity:

# ifstatus enp8s0
enp8s0          up
      link:     #2, state up, mtu 1500
      type:     ethernet, hwaddr fc:34:97:10:e9:0c
      config:   compat:suse:/etc/sysconfig/network/ifcfg-enp8s0
      leases:   ipv4 dhcp granted
      leases:   ipv6 dhcp requesting
      addr:     ipv4 192.168.69.115/24 [dhcp]
      route:    ipv4 default via 192.168.69.1 [dhcp]

This implies that the DHCP6 server is not responding although there is nothing in the journal about any requests.

11

I found a workaround. Since there are less than 10 hosts on the network, I disabled dhcp6 on each host’s network interface, and added a static ipv6 address for the host, the same one as was leased by the DHCP6 server. The local network is functioning smoothly again.

The problem with ssh going catatonic after some idle time has stopped happening.

I gotta say, troubleshooting DHCP6 is a serious PITA. There seems to be almost no tools to do so; all that I found are for DHCP4.

There is no explanation why DHCP6 simply quit working. It is as though the functioning server had shut down. It did not; it is still otherwise perfectly functional.

I have tried sporadically to get a DHCP6 service running on one of our hosts to not depend on the gateway server. I created the conf file with ranges and limits and options (oh my!). It started and ran without error. No other host could find that service. Ever. The firewall was opened for every possible dhcp option.

Apparently the same non-existence had come to haunt the formerly working service.

The issue persisted after booting to a previous kernel.

12

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.