1

At first, the system runs OK and successfully negotiates an IPv6 address and operates as intended.

After some time the system stops sending DHCP requests and IPv6 fails after the lease times out, but IPv4 continues to operate. The system can be recovered by restarting the wide-dhcpv6-client service. This suggests that the issue is with this service, but my internet searches have not yet found a root cause. The following message is logged:

dhcp6c[]: client6_send: transmit failed: Network is unreachable

I have not yet found any other relevant error message.

While the error message suggests the network layer is at fault, the restart of the service clearing the issue would suggest otherwise. As IPv4 continues to operate, it is not yet clear how often this happens as almost all IPv6 services are dual stacked. It was manually recovered today and it was last recovered 2 weeks ago, but logs suggest it failed in just short of 5 days.

System Description:    Debian GNU/Linux 11 (bullseye)
DHCPc6 version: wide-dhcpv6-client/stable,now 20080615-23 amd64 

It appears that the root cause of this issue is if the network layer becomes unready then the service cannot cope and it errors out. The issue can be worked around by restarting the service, after which normal operational resumes:

systemctl restart wide-dhcpv6-client.service

There seems to be very little reports of this on the web.

Additionally, if the service starts before the network is ready, a different error is seen that's a bit more terminal and attracts more attention and a more obvious fix:

wide-dhcpv6-client[]:  failed!
systemd[1]: wide-dhcpv6-client.service: Control process exited, code=exited, status=1/FAILURE
systemd[1]: wide-dhcpv6-client.service: Failed with result 'exit-code'.
1
  • I just bumped into the same problem. After setting up DHCPv6 over PPPoE last night I found that everything had lost it's IPv6 address this morning with the Network is Unreachable message in the logs. Checking my other logs I noted that the PPP connection had dropped and been re-established (with a new Link-Local Address) about three minutes prior. I'm guessing the two may be connected. I've just added a script to /etc/ppp/ip-up.d to restart (not just start) the wide-dhcpv6-client daemon after PPP comes up. I'll see what happens. Feb 6 at 8:34

2 Answers 2

0

Whilst not a fix, here's a workaround I have implemented until such times as the maintainer fixes this problem. It's very rudimentary, but it'll do for the time being. I run this script as a service at system startup.

import time
import subprocess
import select

filename="/var/log/syslog"

action_map = {
    "client6_send: transmit failed: Network is unreachable": {"action": "sudo systemctl restart wide-dhcpv6-client.service",
                                                              "cooldown": 5},
    "wide-dhcpv6-client.service: Control process exited, code=exited, status=1/FAILURE": {"action": "sudo systemctl start wide-dhcpv6-client.service",
                                                              "cooldown": 5}
}


def monitor(filename):
        f = subprocess.Popen(['tail','-F',filename],\
                        stdout=subprocess.PIPE,stderr=subprocess.PIPE)
        p = select.poll()
        p.register(f.stdout)
        while True:
                if p.poll(1):
                        check_output(str(f.stdout.readline()))


def check_output(syslog_line):
    for action_key in action_map.keys():
        if action_key in syslog_line:
            subprocess.Popen([action_map[action_key]['action'].split()],\
            stdout=subprocess.PIPE,stderr=subprocess.PIPE)
            time.sleep(action_map[action_key]['cooldown'])
            print("Ran:", action_map[action_key]['action'])

print("Starting syslog_actioner")
monitor(filename)
0

If there is no network reachability for IPv6, then there may be an issue with it's Link-local address, because even if there is no Global unicast or Unique local address assigned yet, the host should have connection with the router by using it's Link-local address (auto configured by the host mostly using EUI-64)

When you see the mentioned error message:

  1. Is there a Link-local address of the host (FE80::/10)?

  2. Can you also check the address in question is in the right format as per EUI-64 (split mac + fffe + 7th bit flipped)? reference

  3. Can you ping6 the router's and host's (ping itself) Link-local address?

  4. Have you tried to use static Link-local addresses?

If it's still unclear what's wrong then check if the Stateless Address Auto-configuration (SLAAC) is not set, just to be sure it doesn't interrupt with DHCP6 client:

  • If you use netctl, would you be sure there is not stateless parameter configured?
  • Can you check the interface config of the host if there is no iface eth0 inet6 auto set?

Optional:

  • What do you see in the router's logs in terms of IPv6 messages? Is there any communication that reflects on the host's Link-local or Global/Local Unicast address?
  • Would you share Wireshark capture what your host is trying to actually send that relates to IPv6?

Although there is another way to use IPv6 address configuration on host which is called SLAAC, so you don't need to use DHCP at all, and by using it you also reduce the network utilisation when it comes to address configuration (nice to have for networks with load of hosts). However if you need to get DHCP option values like DNS, you still need a DHCP server.

1
  • Thanks for your analysis; it is very welcome. It turns out that it is an as yet unresolved bug. I have a script in place to automagically recover until such time as the bug is addressed.
    – fileinsert
    Jun 1, 2023 at 13:05

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .