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:
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.
[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
/proc/sys/net/ipv6/conf/all/forwarding:1
/proc/sys/net/ipv6/conf/default/forwarding:1
/proc/sys/net/ipv6/conf/enp3s0/forwarding:1
/proc/sys/net/ipv6/conf/enp5s0/forwarding:1
/proc/sys/net/ipv6/conf/lo/forwarding:1
/proc/sys/net/ipv6/conf/tun0/forwarding:1
/proc/sys/net/ipv6/conf/virbr0/forwarding:1
/proc/sys/net/ipv6/conf/virbr1/forwarding:1
/proc/sys/net/ipv6/conf/wlo1/forwarding:1
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 127.0.0.1/8 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 192.168.43.1/24 brd 192.168.43.255 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.
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.
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.
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
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
