Dhcpv6 client setup


I'm an OpenWRT AND an ipv6 noob and I'm trying to understand the differences between the default OpenWRT and Ubuntu network setups.

Basically, xbuntu assigns global and link local ipv6 addresses with the default setup

OpenWRT only assigns a link local address (option proto dhcpv6 is enabled for the interface).

why? any quick hints?

In a nutshell, Ubuntu and generally any host not having the role of router in the network will listen to Router Advertisements in order to form the SLAAC address or use DHCPv6 to acquire address and other settings.

Every node that has ipv6 activated will create a link local address, both hosts and routers.

The protocol dhcpv6 option in WAN6 interface basically instructs the router to acquire settings for ipv6 over DHCPv6. If your provider doesn't offer that, then it is useless.

If the router doesn't get a global prefix from your provider, then the hosts will not install a global address, but they will install a ULA address (something in the range fc00-fdff) which is configured by default on the OpenWrt.

1 Like

Turns out things are a bit more interesting. DHCPv6 is disabled for the network, but there is another tool running:

To ease the routing the Z/IP Gateway will send out RFC 4191 router announcements. Clients who support RFC4191 will be able to communicate with the PAN nodes via IPv6 without special routes.

Turns out the other hosts (Ubuntu, Mac) are auto-assigning IPv6 addresses based on those announcements.

OpenWRT doesn't seem to do that.

How do I make it do that? :wink:

Your router isn't a client, that's why it's statically addressed on LAN.

The OpenWrt should be doing that; you can verify by seeing if the clients are getting the ULA address.

  • Are you talking about on LAN or WAN?
    • If on LAN, were you assigned a PD?
    • If on WAN, what does this have to do with clients?

What is this!?!?

I'm talking about the WAN port. I'm actually using OpenWRT as a LAN client, not as a router. Sorry for not making that clear.

I'd expect it to work the same way other clients do.


It basically creates a bunch of virtual IP clients using the Linux TAP / TUN driver.

On boot the Z/IP gateway will create a TAP interface which is used to send and receive IP packages. The application has its own IPv4 and IPv6 stack.

I'm totally lost.

  • I won't be browsing to a web server in China
  • I researched what the Z/IP is; but what does this device have to do with OpenWrt?
  • Perhaps you think something is wrong with you config, when it's not

I'm not sure what the quote about Z/IP means in relation to OpenWrt setup as a DHCPv6 client.

If you simply want to add a link local IP to WAN as well, add:

# in /etc/config/network under WAN

        option ip6class 'local'

Z/IP Gateway sends out RFC 4191 announcements. They seem to be ignored by (some component of) OpenWRT. The behavior is different than i.e. Mac or Ubuntu. That's the problem.

In this case, the router advertisements are probably getting ignored because they have a local source address (Z/IP Gateway is a daemon running on the OpenWRT device).

Anyway, I fixed the problem by adding the route manually with ip -6 route add.


Now your problem makes a lot more sense!

You probably should have noted that the OpenWrt was running this non-official package...that would have been a good clue. You never noted that the OpenWrt software isn't handling normal stuff. And that was quite confusing when you then state that OpenWrt doesn't do what other Linux distros do. Nonetheless, glad you figured it out.


(The announcements are probably not ignored; it's more so because it never gets an announcement - as it's the sender of them.)

Works as expected after adding


to /etc/sysctl.conf

In this case tap0 is the source, and the RAs get picked up correctly by the wan interface with this change.

Shouldn't /lib/netifd/dhcpv6.script handle that?

I think you answered yourself that earlier.

1 Like

Not really, according to this

Also, the script does seem to handle RAs on 19.07


odhcp6c only receives and interprets RAs. It does not make any changes to system, ips, routes,... For this it calls /lib/netifd/dhcpv6.script.

odhcp6c is the dhcp client for ipv6. You don't have any dhcp6 server. Moreover the default setup for routers (that is with routing enabled) is to disregard the RAs. The valid setups for the upstream interface are static or dhcp6. You are not using any of them, so no wonder it doesn't work out of the box.

odhcp6c also handles RAs

The OpenWrt embedded DHCPv6-client odhcp6c is a minimal DHCPv6 and RA-client for use in embedded Linux systems.

So I think it should handle RAs in my case.

Doesn't matter, it's fine if the kernel handles RAs instead. I'm just wondering if there are any potential conflicts between the kernel and odhcp6c.

Seems like using accept_ra is deprecated in OpenWRT, and is disabled by default:
https://openwrt.org/docs/guide-user/network/ucicheatsheet (search accept_ra)

accept_ra is set to 0 on OpenWRT by default. Other distros usually set it to 1.


Many distributions and users prefer to handle router advertisements in
userspace; one example is OpenWrt, which includes a combined RA and DHCPv6
client. For such configurations, accept_ra should not be enabled by

This would indicate the RAs should be handled by odhcp6c without tinkering with accept_ra.

I'll try adding some debug prints to the odhcp6c script to see what's really going on.

OpenWrt is a router distribution, normally you don't want a router autoconfiguring itself. remember anything can send a router advertisement... it's just a packet on the wire. if you have your router listening to them then any malicious or misconfigured device can DOS your entire network by advertising itself as an invalid route

Ok, but the default dhcpv6.script shipped with OpenWRT DOES perform at least SOME autoconfiguration based on RAs, as can be seen here (case ra-updated on line 230):


I guess I'll just disable that case in the default script and let the kernel handle RAs instead. Should be good enough in my case.

DHCPv6 doesn't provide route information so you have to either have static routes, or listen for RA on the upstream interface, so yes you want RA on WAN