RasPi IPv6 Address Only Taking /128 Subnet

Question

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 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: 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 10.0.0.254/24 brd 10.0.0.255 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
    link/none 
    inet 10.8.0.1/24 brd 10.8.0.255 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

Answer 1

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.