IPv6 Prefix Delegation Request Size

Thank you. I got the packet capture.

Looking at the Router Advertisement, I did see the M flag (Managed address configuration) was set, and the A flag (Autonomous address-configuration) was not set (for all prefixes advertised), hence you only saw a single /128 address on your network interface.

For the DHCPv6 PD part, there’s no Prefix Delegation request in your DHCPv6 Solicit, so you may want to double-check your router’s configuration. Below is a sample DHCPv6 PD for your reference:


compared to yours:


I have no idea what to check in my “router” configuration. It’s whatever NetworkManager is doing for DHCP6. The only configuration override I’ve made is to set ipv6.dhcp-duid to a new value to ensure that I get a fresh lease and not one left over from a previous unsuccessful attempt.

I think the only setting required is to set the shared method on the LAN interface, as @nazunalika already suggested, and also from these two blog posts:


You mentioned that setting made your LAN interface didn’t come up. Could you try set it again and do tcpdump on the WAN interface? We want to verify if your router indeed sends a DHCPv6 PD with that option enabled.

I tried again setting the IPv6 method to “Shared” on the LAN interface. In sequence:

  1. Tell NetworkManager to disconnect both interfaces,
  2. Change both configurations
  3. Run "systemctl restart NetworkManager

The LAN interface does come up and works for IPv4. The RA packets sent on the WAN interface still have M=1 and A=0, and I have just a /128 prefix.

Is it hurting if my IPv4 configuration on the LAN is set to “Manual”? I hope not.

What about the DHCPv6 Solicit? Do you see the PD request there? You can check my screenshot above.

And no, IPv4 should not have any impact, since the configuration option is for IPv6.

The DHCPv6 Solicit packet still looks the same as the “compared to yours” packet above.

Just to make sure, can you do nmcli connection show <your_lan_connection> | grep ipv6.method ? Please do the same on your WAN connection also.

You may also want to use nmcli device to verify the correct LAN interface is attached to <your_lan_connection> in the command above.

[omega-3x ~]# nmcli connection show 'omega-3 LAN' | grep ipv6.method
ipv6.method:                            shared
[omega-3x ~]# nmcli connection show enp3s0 | grep ipv6.method
ipv6.method:                            auto
[omega-3x ~]# nmcli device
DEVICE  TYPE      STATE                   CONNECTION  
enp5s0  ethernet  connected               omega-3 LAN 
enp3s0  ethernet  connected               enp3s0      
tun0    tun       connected (externally)  tun0        
virbr0  bridge    connected (externally)  virbr0      
virbr1  bridge    connected (externally)  virbr1      
wlo1    wifi      unavailable             --          
lo      loopback  unmanaged               --
[omega-3x ~]# grep . /proc/sys/net/ipv6/conf/*/forwarding

I can assure you that if I had the WAN and LAN cables reversed absolutely nothing would work. That would connect my manually-configured LAN interface to my cable modem and trying to talk to the world with a 192.168.x.y reserved IP address, and connect my WAN interface to my local network with no DHCP server.

Just double-check the enp5s0 interface and I don’t see any IPv6 link-local (fe80::/10) assigned to it. Could you verify if it indeed has IPv6 enabled? My thought is if this LAN interface doesn’t have IPv6 enabled, NetworkManager will not even bother to request Prefix Delegation either (as seen in the packet capture), because it will then not be able to assign that prefix to the LAN interface.

Apart from that, the configuration looks good to me. You may want to search for keyword ipv6-pd in your logs, and see if there’s any indication of error there. Otherwise, you may want to try a different DHCPv6 client which supports Prefix Delegation option (like wide-dhcpv6).

That old “ip addr” output was, as stated, with IPv6 disabled on the LAN. Here’s what I see with IPv6 enabled on both interfaces:

# ip addr
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 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: enp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether fc:aa:14:21:c4:24 brd ff:ff:ff:ff:ff:ff permaddr d8:5e:d3:8a:11:0d
    inet xx.xx.xx.xx/21 brd xx.xx.yy.255 scope global dynamic noprefixroute enp3s0
       valid_lft 301472sec preferred_lft 301472sec
    inet6 2001:558:6033:45:1d50:c285:277b:afa2/128 scope global dynamic noprefixroute 
       valid_lft 263199sec preferred_lft 263199sec
    inet6 fe80::9a9e:9a2c:2963:fa4c/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever
3: enp5s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 68:1c:a2:12:b0:ea brd ff:ff:ff:ff:ff:ff
    inet brd scope global noprefixroute enp5s0
       valid_lft forever preferred_lft forever
    inet6 2601:243:2200:793::1/64 scope global dynamic noprefixroute 
       valid_lft 263200sec preferred_lft 263200sec
    inet6 fe80::bcab:9456:4469:6a6e/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever

Trying wide-dhcpv6 was something I had been considering. Why I would have to resort to that in what I think should be a pretty common configuration is beyond my understanding. It shouldn’t be this hard. Right now I have this urge to mark your deleted post as the “Solution” and just forget about IPv6.

I’m in the midst of getting Fedora 37 set up on the old CentOS 6 machine which had been acting as my router and VM host. I’ll see if that behaves any differently.

Just curious where does that /64 on the LAN interface come from? Did you assign it or did it come from the DHCPv6 PD?

No idea. There is nothing on the LAN configured to answer to router solicitations or advertisements. It’s whatever NetworkManager managed to set up for “Shared with other computers”.

And, after much fiddling, Fedora 37 behaves exactly the same way as does Rocky 8.7. What this says to me about Linux, NetworkManager, and IPv6 cannot be repeated in this forum.

All that’s left to try is wide-dhcp6v6. That the version available on EPEL for el8 appears to be based on a WIDE project release in 2008 is not encouraging. IPv6 barely existed in 2008.

Doesn’t that mean DHCPv6 PD is working as expected? After enabling IPv6 on LAN interface, NetworkManager starts sending DHCPv6 PD request to your ISP, receiving a /56 back, then sharing that with the LAN interface. That’s what I thought. Can you do a tcpdump on WAN interface to confirm this? Or simply check for keyword ipv6-pd in your NetworkManager logs.

Well, something seems to be working. With the LAN interface now up for IPv6, I can see ipvd6-pd messages in the log:

Mar 19 12:04:10 omega-3x.local NetworkManager[320675]: <info>  [1679245450.1203] policy: ipv6-pd: none of 0 prefixes of enp3s0 can be shared on enp5s0
Mar 19 12:04:11 omega-3x.local NetworkManager[320675]: <info>  [1679245451.1828] policy: ipv6-pd: received a prefix 2601:243:2200:793::/64 from enp3s0

and basic IPv6 seems to be working in a LAN client. I don’t know where you are seeing a /56 prefix. The only global prefix I see is a /64.

Is there a chicken-and-egg problem here? I don’t see a PD request on the WAN unless IPv6 is up on the LAN, but the LAN can’t be fully up on IPv6 until the prefix is known.

I guess now I have to figure out how to set up dns and a firewall when I can’t subnet and each client is grabbing a random 64-bit address within the random /64 prefix. And, eventually I’ll be putting the WiFi access point on a different interface. Will I be getting a different prefix for that?? I’ll worry about that when I get around to doing it.

Just double-check the enp5s0 interface and I don’t see any IPv6 link-local (fe80::/10) assigned to it. Could you verify if it indeed has IPv6 enabled? My thought is if this LAN interface doesn’t have IPv6 enabled, NetworkManager will not even bother to request Prefix Delegation either (as seen in the packet capture), because it will then not be able to assign that prefix to the LAN interface.

Here’s my previous post, and what I think the reasoning behind this behavior.

/56 is simply the standard for DHCPv6 PD. You receive this prefix from the ISP and allocate /64 from that.

At the moment, it’s actually working, and clients on the LAN are able to access the world via IPv6.x

# ifconfig
enp3s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet  netmask  broadcast
        inet6 2001:558:6033:45:1d50:c285:277b:afa2  prefixlen 128  scopeid 0x0<global>
        inet6 fe80::9a9e:9a2c:2963:fa4c  prefixlen 64  scopeid 0x20<link>
        ether fc:aa:14:21:c4:24  txqueuelen 1000  (Ethernet)
enp5s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet  netmask  broadcast
        inet6 2601:243:2200:793::1  prefixlen 64  scopeid 0x0<global>
        inet6 fe80::bcab:9456:4469:6a6e  prefixlen 64  scopeid 0x20<link>
        ether 68:1c:a2:12:b0:ea  txqueuelen 1000  (Ethernet)

I’ve not yet checked whether this survives a reboot. It looks like the whole problem might have been with my philosophy of, “Set up each stage and get it working before moving on to the next.” NetworkManager just won’t let me do that. Right now, I have this fear that it might not establish a prefix unless I have an actual client connected and online, and that would make it Hell to configure a firewall.

Perhaps /56 is a standard in most places, but not with Comcast/Xfinity, which offers only a /64 to residential customers. I’ve seen several complaints about that in the support forums. It looks like I’ll have to set up a DHCPv6 server with fixed-address6 assignments for the clients so that I can play some fairly ugly firewall games to at least filter WAN access for different client classes.

Here is the offered prefix:

Yeah, I now know why you didn’t enable IPv6 on LAN interface from the beginning, because you wanted to finish IPv6 setup on WAN interface first, right? Since DHCPv6 PD process involves both interfaces at the same time, we should treat it as a single stage, though. I think any IPv6-specific settings on an interface simply will not have any effect until we enable IPv6 on it (hence no DHCPv6 PD request sent out by NetworkManager, even though ipv6.method was set to shared).

It has put you through a bit of trouble, but still a good troubleshooting case imo :slight_smile:

The /56 is just a de-facto standard. Maybe Comcast does this because they don’t find the need for more than a /64 in residential network in most cases.

Yes. That. There is one thing, where FirewallD does “play nice”:
NetworkManager can bind connection to MAC address. That allows the name of interface device to be random; NM takes the current ifname and hands it to FirewallD, which creates appropriate “iifname” match into ruleset. “Dynamic”.

With fixed/persistent addresses and ifnames it might be easier to write a more static ruleset by hand,
without FirewallD. Lean and mean.

Even Red Hat says that firewalld is suitable only for simple firewall use cases**. My existing IPv4 firewall is anything but simple. Unless I can somehow convince firewalld to leave IPv4 alone and configure only IPv6, I’m stuck with doing it by hand.

I’m forced to use fixed-address6 assignments unless you can tell me a different way to apply different firewall rules to individual clients on my LAN.

** cf. RHEL 8 Configuring and managing networking p 323