My Problem

I'm just now enabling IPv6 on my network, and already my phone works with it as expected (confirmed with a "What's my IP" search showing an IPv6 address with the proper prefix. RasPi is able to also ping the IPv6 phone address).

However, while my RasPi is being assigned an IPv6 address by my router, and shows the expected address in the following ip -a command (censored), notice that the subnet is showing as /128. This is wrong for obvious reasons, and using Termux on my phone I verified my subnet should be /64. My phone is not able to ping the RasPi IPv6 address.

Any ideas as to how I can proceed to fix this? I've considered using static assignment, but I'd much rather it pull the correct information from DHCP.

Output of ip -a

Please note that the first censored address that ends with /128 is the one my router shows as the assigned IP. It also displays as my IPv6 when checking my public IP from this RasPi.

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: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether dc:a6:32:bc:5a:4e brd ff:ff:ff:ff:ff:ff
    inet brd scope global noprefixroute eth0
       valid_lft forever preferred_lft forever
    inet6 <censored>:<censored>:<censored>:<censored>::254/128 scope global dynamic noprefixroute 
       valid_lft 337355sec preferred_lft 337355sec
    inet6 <censored>:<censored>:<censored>:<censored>:f544:1c3f:98bf:30e9/64 scope global dynamic mngtmpaddr noprefixroute 
       valid_lft 337355sec preferred_lft 337355sec
    inet6 fe80::e40f:1972:aa7f:dce9/64 scope link 
       valid_lft forever preferred_lft forever
3: wlan0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether dc:a6:32:bc:5a:4f brd ff:ff:ff:ff:ff:ff
4: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 100
    inet brd scope global tun0
       valid_lft forever preferred_lft forever
    inet6 fe80::4cc8:c9c6:a599:fa40/64 scope link stable-privacy 
       valid_lft forever preferred_lft forever
  • Maybe serverfault.com/questions/918472/… could be relevant? – Dirk Feb 6 at 23:17
  • ::254/128 scope global dynamic noprefixroute is correct, why do you think this should be a /64 address like the :f544:1c3f:98bf:30e9/64 scope global dynamic mngtmpaddr noprefixroute address – Jaromanda X Feb 7 at 2:30
  • @JaromandaX Because that's how it's reflected on my phone, as I have a 64 bit subnet. It should be <censored>:<censored>:<censored>:<censored>::254/64 to work properly (or at least I'm assuming, based on the fact it's the only IPv6 on the LAN I can't ping). I also just realized I forgot to list my OS version, etc. so I'll get that up now. – z7r1k3 Feb 7 at 21:30
  • @Dirk That is very relevant. Looks like it should be working properly anyway. I'll have to deep dive this further. And to further answer Jaromanda X's question, I made the assumption as the only IPv6 I couldn't ping on my LAN was also the only IPv6 that ended with a /128. Looks like that assumption was incorrect. – z7r1k3 Feb 7 at 21:39
  • Heh, turns out I remembered incorrectly. No IPv6 pings work, and everything else is operating now as it should. I'll close this, then. – z7r1k3 Feb 7 at 21:47

As it turns out, I merely misunderstood how IPv6's work. I'll reference the ServerFault question mentioned by Dirk: https://serverfault.com/questions/918472/why-is-a-128-ipv6-address-assigned-via-dhcpv6-in-ubuntu

To quote:

Yes, this is the normal behaviour. DHCPv6 servers give out addresses (with the IA_NA option) but don't tell the client anything about the subnet. The client therefore just configures the separate address on the interface. Any routes to the subnet are provided by RA. If the RA would announce the prefix without the auto-configure option then the client wouldn't configure an address automatically, but it would add the route for the local subnet.

This separation of responsibilities is intentional. DHCPv6 servers have the authority to assign addresses (amongst other things) but don't have the authority to speak about the network status. Often DHCPv6 servers are not even on the local subnet and communicate with the client via relays. The devices that the client does talk directly to are the routers. Therefore in IPv6 the routers tell clients about the status of the network (prefix, default gateway, routes etc) using RA. Extra configuration options and optionally address assignments are done form the DHCP server.

That way the client can respond quickly to changes in the network, while still receiving more long-lived information from DHCPv6.

Everything is working now, so it seems like my router was just having a fit temporarily. I'd like to thank everyone for their time.

  • Do you really need a DHCP6 server? If you don't have special settings not provided by Router Advertisements I would avoid using it. – Ingo Feb 7 at 22:37
  • @Ingo I don't really need it, I just like the idea of adopting it. Besides, it'll give me a chance to get used to it, like exploring special settings provided by RA. Since it seems to be working well now I'll probably just keep it. – z7r1k3 Feb 7 at 23:49

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.