I'm having no IPv6 connection (due to the host not letting me change the default route because of the router advertizement of an interfering router)

Help Community Help
1

I changed the router. Pihole hates moving to a different subnet. At first I had no IPv4 connection instead. Nomatter how many times I tried to reconfigure the IP settings with pihole -r, it stuck with the old gateway adress. I fixed that with removing the default gateway.

sudo route del default

and then add the new gateway address.

sudo route add default -net 192.168.xx.0/24 gw 192.168.xx.1 netmask 255.255.255.0 dev eth0

I don't remember if that's the exact command, but it should look something like this. Pihole got back online with IPv4

Now I'm having no IPv6 connection for some reason.
So I tried the same thing with IPv6. I don't know what sudo route -6 expects of me. So I tried it the ip -6 route way. I entered:

sudo ip -6 route del default

sudo ip -6 route add default via gateway_link-local-address dev eth0

That brings me IPv6 internet connection.

Expected behavior: That that the routing table keeps my changes.

Actual behavior: It doesn't keep my changes. I have IPv6 internet connection for a while, but sooner or later or at reboot, ip route erases my default gateway and brings back the default gateway with the obsolete link-local-address which eliminates my IPv6 internet connection. Especially when I traceroute with IPv4 it overwrites my change with the obsolete gateway.

I entered

sudo ip -6 route del default

and

sudo ip -6 route add default via gateway_link-local-address dev eth0

so many times.
Why does it not leave my changes be? Why does it have to remove it and bring back the old gateway address? How can I permanently remove the old default gateway and add the new one? Or how can I permanently change the default gateway? Do I need route -6 instead? Then how? Nothing I entered was right for route -6. I'd appreciate clear instructions and examples for route -6.

Notable about the ip -6 route show entry for the persistent default gateway are the notes proto and ra:
<default via fe80::c6ad:34ff:fe40:c5bd dev eth0 proto ra metric 202 pref medium

Why is that gateway being such a nuisance?

The operating system is the Raspian.

Debug token https://tricorder.pi-hole.net/1jy1527vu2

2

That is an OS level issue.
As a DNS server, Pi-hole is not involved in routing at all.

From your description, the underlying issue seems to be a change of your local network introduced by a new router. Reconfiguring Pi-hole via pihole -r should work, as long as you get rid of your previous network settings.

pihole -r may add a new interface section; it will never touch or alter existing configuration sections.

Check your /etc/dhcpcd.conf on your Pi-hole machine for multiple definitions for the same interface. Remove any unwanted/deprecated sections as needed.

EDIT: You may want to run sudo dhcpcd --rebind or to reboot your Pi-hole machine to activate those configuration changes.

3

This is so close to not needing a fresh install. I think it is in favor of the users to have a solution on this. Moves are common. Occasionaly someone would change the net address. A router could break. A fresh install anytime for any of these changes is too bothersome. With a solution for this issue, we could make instructions/tutorial on how to make the pihole adapt to the changes instead of starting from scratch. All it takes is to change each routing table. The only thing that's left for the solution is to make the ipv6 route obey you and how to prevent ipv6 route to become disobedient. Surely the community will welcome this. That'll save them a lot of nerves and time. It would be a shame to leave it just as an OS issue. As I said, moves are common and frustrations are big if you have to start all over again. I'm just not sure the teleport thing really is enough to compensate the restart.

As for /etc/dhcpcd.conf, It has nothing other than the stuff I added in the end. The rest is just comments and some stuff inbetween.

[quote]

# A sample configuration for dhcpcd.
# See dhcpcd.conf(5) for details.

# Allow users of this group to interact with dhcpcd via the control socket.
#controlgroup wheel

# Inform the DHCP server of our hostname for DDNS.
hostname

# Use the hardware address of the interface for the Client ID.
clientid
# or
# Use the same DUID + IAID as set in DHCPv6 for DHCPv4 ClientID as per RFC4361.
# Some non-RFC compliant DHCP servers do not reply with this set.
# In this case, comment out duid and enable clientid above.
#duid

# Persist interface configuration when dhcpcd exits.
persistent

# Rapid commit support.
# Safe to enable by default because it requires the equivalent option set
# on the server to actually work.
option rapid_commit

# A list of options to request from the DHCP server.
option domain_name_servers, domain_name, domain_search, host_name
option classless_static_routes
# Respect the network MTU. This is applied to DHCP routes.
option interface_mtu

# Most distributions have NTP support.
#option ntp_servers

# A ServerID is required by RFC2131.
require dhcp_server_identifier

# Generate SLAAC address using the Hardware Address of the interface
#slaac hwaddr
# OR generate Stable Private IPv6 Addresses based from the DUID
slaac private

# Example static IP configuration:
#interface eth0
#static ip_address=192.168.0.10/24
#static ip6_address=fd51:42f8:caae:d92e::ff/64
#static routers=192.168.0.1
#static domain_name_servers=192.168.0.1 8.8.8.8 fd51:42f8:caae:d92e::1

# It is possible to fall back to a static IP if DHCP fails:
# define static profile
#profile static_eth0
#static ip_address=192.168.1.23/24
#static routers=192.168.1.1
#static domain_name_servers=192.168.1.1

# fallback to static profile on eth0
#interface eth0
#fallback static_eth0
interface eth0
        static ip_address=192.168.x.2/24
        static routers=192.168.xx.1
        static domain_name_servers=84.200.69.80 84.200.70.40

Although the persistent has caught my suspicion. But if it had something to do with this, why only IPv6?

4

There is absolutely no need to manipulate routing tables by hand.

You chose to configure a static IP address on your device when installing Pi-hole.
Accordingly, Pi-hole's installation script added a respective interface section to dhcpcd.conf.
If your new router operates on a different subnet than your previous one, all you have to do is adopt that configuration and change your static IP address so that it matches the new subnet.

Alternatively, you may choose to configure a DHCP lease reservation for Pi-hole on your router to ensure Pi-hole gets a fixed IP. That way, your router's DHCP server would provide the necessary network information to your Pi-hole.

In both cases, a reboot may be required to have your machine use or request the new settings respectively.

5

dhcpcd.conf doesn't show me an example for an ipv6 router address.
Is it meant to be like that?
Do you know what the IPv6 equivalent to static routers= is?
Is it static ip6_routers=?
Or does static routers= support IPv4 and IPv6 alike?
Or is there no such option for the IPv6 address of the router?

6

You may want to check out

Summary:

IPv6 works in many ways differently from IPv4. It is not simply an enlarged address space.
DHCPv6 does not support options to set routers/gateways.

7

You haven't provided specifics for your IPv6 connectivity issue so far.

Again, Pi-hole is not involved with IPv6 connectivity itself.
Even if it had an IPv4 address only, Pi-hole would still be able to provide both IPv4 as well as IPv6 address answers for a requested domain.

What are the current IPv6 addresses for your Pi-hole?
Run from your Pi-hole machine, what's the output of

ip -6 address
8

I'm not sure if it's a good idea to share my IPs. Not even my ULAs.

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 state UNKNOWN qlen 1000
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
inet6 2001:xyz/128 scope global dynamic noprefixroute
valid_lft 6508sec preferred_lft 2908sec
inet6 fd00::102b:602b:e6e1:7be4/64 scope global dynamic mngtmpaddr noprefixroute
valid_lft 2591791sec preferred_lft 604591sec
inet6 2001:xyz/64 scope global dynamic mngtmpaddr noprefixroute
valid_lft 6851sec preferred_lft 3251sec
inet6 2001:xyz/64 scope global dynamic mngtmpaddr noprefixroute
valid_lft 2591901sec preferred_lft 604701sec
inet6 fd00:beef::ecce:beefecke/128 scope global noprefixroute
valid_lft forever preferred_lft forever
inet6 fe80::4cab:73de:512a:7601/64 scope link
valid_lft forever preferred_lft forever

The bold one is suspicious to me. I changed the prefix to fd00:beef::. So I don't know where the fd00:: comes from. (And the reason why I showed it in full.
More importantly, this is my routing table according to ip -6 route:

::1 dev lo proto kernel metric 256 pref medium
2001:xyz:1::/64 dev eth0 proto ra metric 202 mtu 1492 pref medium
2001:xyz:80::/64 dev eth0 proto ra metric 202 pref medium
fd00::/64 dev eth0 proto ra metric 202 pref medium
fd00:beef::/64 dev eth0 proto ra metric 202 mtu 1492 pref medium
fe80::/64 dev eth0 proto kernel metric 256 pref medium
default via fe80::c6ad:34ff:fed5:3741 dev eth0 proto ra metric 202 pref medium

The thick one os the obsolete one. That entry just doesn't want to go and keeps returning and overwriting my changes.

This is my routing table according to route -6:

Kernel IPv6 routing table
Destination Next Hop Flag Met Ref Use If
localhost/128 [::] U 256 2 0 lo
2001-xyz.ipv6dyn.netcologne.de/64 [::] U 202 1 0 eth0
2001-xyz.ipv6dyn.netcologne.de/64 [::] U 202 2 0 eth0
fd00::/64 [::] U 202 1 0 eth0
fd00:beef::/64 [::] U 202 3 0 eth0
fe80::/64 [::] U 256 2 0 eth0
[::]/0 fe80::c6ad:34ff:fed5:3741 UG 202 2 0 eth0
localhost/128 [::] Un 0 4 0 lo
2001-xyz.ipv6dyn.netcologne.de/128 [::] Un 0 2 0 eth0
2001-xyz.ipv6dyn.netcologne.de/128 [::] Un 0 3 0 eth0
2001-xyz.ipv6dyn.netcologne.de/128 [::] Un 0 3 0 eth0
fd00::102b:602b:e6e1:7be4/128 [::] Un 0 2 0 eth0
fd00:beef::ecce:beef-ecke/128 [::] Un 0 4 0 eth0
fe80::4cab:73de:512a:7601/128 [::] Un 0 3 0 eth0
ff00::/8 [::] U 256 4 0 eth0
[::]/0 [::] !n -1 1 0 lo

I have no idea what the bottom one means. The bold one definitely needs to go.
I'm suspicious about fd00::102b:602b:e6e1:7be4/128 [::] Un 0 2 0 eth0,
as I changed the subnet to fd00:beef:: (excuse the repetition).
As for those adresses with ipv6dyn, I have no idea. They show up when I IPv6 traceroute an address. Not sure if exactly those same.

If you'd show me how to remove the ::/0 entry with the obsolete link-local-address with sudo route -A(?) -6(/inet6??), I'd be very thankful.
sudo route -6 help didn't help. Instructions on the web didn't work.

9

(For link-local and ULA IPv6 addresses, sharing is usually safe, at least as long as none of them is a EUI-64/EUI-48 address (edit: and yours from ip -6 address are not). With public GUA addresses, obfuscating the prefix is advisable if you want to keep your address private.)

Your output does not indicate you have an IPv6 connectivity issue:
Your Pi-hole machine had no difficulties acquiring link-local, ULA and public IP addresses.

It's unclear to me what your issue is and how that would be related to Pi-hole.

10

That's a link local address, you aren't going to be able to get rid of it.

11

I'm still too paranoid with ULAs. I'm laid back-back with link-locals, because I'm sure nothing anywhere outside reaches it.

You can't see the problem, because you can't see that the adress fe80::c6ad:34ff:fed5:3741 doesn't exist anymore. It's gone. It's history for the pihole. That's why I need it gone. But this device is hooked on it. I remove it, sooner or later it returns and removes the gateway I added. I find it aggravating; it disobeys me. It's like it shows the middle finger to me. Why would the routing system do this? Is it by design? Why make a routing table that gives me a nuisance? I delete it and add the correct address, but sooner or later or after reboot routing decides "No! Back to fe80::c6ad:34ff:fed5:3741" and overwrites my default route with this dead gateway. Like, why?

Are you sure this is an OS thing? Never confronted a machine doing this. Gotta be pihole which triggered it. No offense. Don't worry. I'm not besetting you.
I just find this thing especially frustrating. I got the solution for keeping the system, fixed the ipv4 gateway, fixed the ipv6 gateway, but the host just puts another hurdle on me and makes the ipv6 solution only temporarily.

12

Yeah, we don't do any kind of configuration beyond /etc/dhcpcd.conf.

13

What? Why? I can delete it. The host just for some reason puts it back and removes my changes.
Why does it not? That's unheard of. Why make a host give me a nuisance of a routing system? A router could break? Am I then doomed to have a dead link-local gateway? Why make the host disobey me to keep a gateway which could go away any day? Like really?

14

Yeah, really. Link-local address - Wikipedia

15

I know what a link-local is. But I don't see anywhere that hosts keep them persistent as gateways.
On my routers, I added and removed link-locals anytime. They keep my changes unlike this host which disobeys my changes on the routing table. What sort of design is this? Should I, like evertime, reinstall an os whenever I put the host somewhere else?
Well, I hope UK is on my long distance call plan. They're gonna hear from me.

I guess I have to pick up my hdmi, reach behind my pc for the keyboard plug and enable SSH, plug the keyboard back to the PC and install pihole. I better make an image with the sh file for pihole and store it. It wasn't long ago when I had to do that last time because of subnet moving.
I give this topic another day. Or rather 23 and a half for me. I'll make an image for the current just in case.

They can't just make a link-local gateway not removable...

18

You're mixing up Pi-hole and the the host system it is running on - they are separate entities.
As said before, your issue is not related to Pi-hole.

By design, IPv6 is leaning heavily towards auto-configuration. Just as your host system will construct a link-local address autonomously for itself, it will learn your gateway address automatically.

Instead of trying to manually override this by fiddling with routing tables, you should focus on determining where this information originates from (for IPv4 or IPv6, regardless). Your current approach seems a bit like putting buckets in front of the basin instead of turning off the tap.

If I understand you correctly, your Pi-hole's host system is learning an IPv6 address as gateway that you don't expect to be active (anymore).
Can you identify the device associated with that address? Are you positive it belongs to your old router?
Is that old router still seeing service in your network somewhere, e.g. as an access point?
What make and model is your old router?
What make and model is your new one?

19

I know that. I just referred the host as pihole. From now on, I rather refer it by its hostname Ryza instead of pihole.

From my digging on the web, I found out that RA means router advertizement. Which must mean that it gets it automatically. With the new image. It's still there.
So you are right. It is learning that link local from somewhere. I pinged it. It's active. And link-locals cannot reach outside of the router. Ryza is obtaining a gateway which I believed is dead. Now the reason why I belived that the gateway is dead is because the router's ifconfig Says something completely different from the gateway on Ryza's routing list. The other reason why I believed the gateway is dead is, when I deleted the default gateway and added the local-link adress from the router's ifconfig as default gateway, I got IPv6 internet access. After a while, Ryza deletes the default gateway I set and returns the gateway with that strange link-local address on the routing list and the IPv6 internet access ends.
That's why I believed that that gateway is dead.
And now for some reason, not even the link-local adress the router's ifconfig shows doesn't give me ipv6 internet access anymore, not even resolving IPv6 adresses (at least that was the case at around 2am).
As for the link-local adress from the router advertizement, I don't know where that is from. Ping reveals that it's active, but I have no clue where it belongs. As I said, the router's ifconfig doesn't show that link local address. Thus I cannot identify the device associated with the advertized link-local address. I have no idea how to track that thing and what I should do if I could. I show the result of ifconfig -a from the router. If I didn't, please remind me on that. Since, link-local adresses are not outside of the switches, it is in no way the old router. The old router is still in service as a switch as I turned DHCP off on it. I use it as a bridge, as I need another WAN port to have a gateway to a different subnet (So the DHCP servers don't collide). And also for VLAN which the one with the modem doesn't (so far). As I know Link-local, not any of that can be a reason.
The make of the old router is a Mikrotik RB760iGS. Has VLAN has, has ACL, but no modem.
The new router is a modified Fritzbox 7390. Has modem, now has ACL in form of iptables thanks to custom image, has many other things thanks to the custom image, has no VLAN (at least not configured).

root@fritz:/var/mod/root# ifconfig -a
adsl Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:2000 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:32
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)

cpmac0 Link encap:Ethernet HWaddr xxxxxxxxxxxxxxxxxxxx
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:177803 errors:0 dropped:0 overruns:0 frame:0
TX packets:301411 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:19210990 (18.3 MiB) TX bytes:374378466 (357.0 MiB)
Interrupt:14

dsl Link encap:Point-to-Point Protocol
inet addr:192.168.xx.1 P-t-P:192.168.xx.1 Mask:255.255.255.255
inet6 addr: xxxxxxxxxxxxxxxxxxxx/64 Scope:Global
inet6 addr: fe80::2665:11ff:fee8:a979/64 Scope:Link
UP POINTOPOINT RUNNING NOARP ALLMULTI MULTICAST MTU:1500 Metric:1
RX packets:17988 errors:0 dropped:0 overruns:0 frame:0
TX packets:18209 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:4270902 (4.0 MiB) TX bytes:1666061 (1.5 MiB)

eoam Link encap:Ethernet HWaddr xxxxxxxxxxxxxxxxxx
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)

eth0 Link encap:Ethernet HWaddr xxxxxxxxxxxxxxxxxxxxxxx
UP BROADCAST RUNNING ALLMULTI MULTICAST MTU:1500 Metric:1
RX packets:111264 errors:0 dropped:0 overruns:0 frame:0
TX packets:37709 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:128
RX bytes:9169003 (8.7 MiB) TX bytes:11039323 (10.5 MiB)

guest Link encap:Ethernet HWaddr 24:65:11:E8:A9:76
inet addr:192.168.179.1 Bcast:192.168.179.255 Mask:255.255.255.0
inet6 addr: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/64 Scope:Global
inet6 addr: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/64 Scope:Global
inet6 addr: fe80::2665:11ff:fee8:a976/64 Scope:Link
UP BROADCAST RUNNING ALLMULTI MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:151 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 B) TX bytes:31334 (30.5 KiB)

lan Link encap:Ethernet HWaddr xxxxxxxxxxxxxxxxxxxxxxxx
inet addr:192.168.xx.1 Bcast:192.168.xx.255 Mask:255.255.255.0
inet6 addr: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/64 Scope:Global
inet6 addr: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/64 Scope:Global
inet6 addr: fe80::2665:11ff:fee8:a976/64 Scope:Link
UP BROADCAST RUNNING ALLMULTI MULTICAST MTU:1500 Metric:1
RX packets:76461 errors:0 dropped:0 overruns:0 frame:0
TX packets:37722 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:7432997 (7.0 MiB) TX bytes:11040255 (10.5 MiB)

lan:0 Link encap:Ethernet HWaddr 24:65:11:E8:A9:76
inet addr:169.254.1.1 Bcast:169.254.255.255 Mask:255.255.0.0
UP BROADCAST RUNNING ALLMULTI MULTICAST MTU:1500 Metric:1

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:4721 errors:0 dropped:0 overruns:0 frame:0
TX packets:4721 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:829009 (809.5 KiB) TX bytes:829009 (809.5 KiB)

sit0 Link encap:IPv6-in-IPv4
NOARP MTU:1480 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)

vdsl Link encap:Ethernet HWaddr xxxxxxxxxxxxxxxxxxxxx
UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1
RX packets:34584 errors:0 dropped:0 overruns:0 frame:0
TX packets:1802328 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:5612995 (5.3 MiB) TX bytes:1206657216 (1.1 GiB)
Interrupt:36

wifi0 Link encap:UNSPEC HWaddr xxxxxxxxxxxxxxxxxxxxxxxx
BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:511
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
Interrupt:25 Memory:ba000000-ba010000

wifi1 Link encap:UNSPEC HWaddr xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:511
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
Interrupt:25 Memory:ba010000-ba020000

20

I strongly suspect that your old Microtik is sending out RAs along with your current one, as the link-local address you qoute as unexpected suggests a Microtik device.

Try to remove your old router from your network in order to confirm that suspicion.

If you decide to keep it, you may have to dig into its documentation. Depending on how you configure that old device, it may even be correct for it to advertise itself as gateway (i.e. if it's defining its own network segment).

As this is a networking issue and likely specific to both your network setup as well as your involved devices, you should consider to also consult additional sources for further and/or more knowledgable help.

EDIT: If you want to attract users from the Pi-hole community with similar experiences, you should probably include more relevant information in your topic's title, in order to better attract relevant attention. :wink:

22

As I know link-local-adresses, they are not reachable from outside the routers or switches. So it was out of the question for me that it's the old router. Turns out, it was the router. Aren't link-locals unreachable from outside? Strange still, I cannot see that address anywhere. Half of the host part of the adress matches. But that adress is nowhere on the adress list. So I don't even come to the option to disable advertizement. I even disabled the package IPv6 on that device and it still advertizes. I set the new router to higher priority and Ryza still biases to the old router. I'm going to look into it. Sorry to have bothered you with this. I may also read again what a link-local-adress is. I found it out of the question that a link-local reaches to another device.

I may do a reset on the old router.
If I find no fix on that, looks like I'm going to have to pull the cord to the old one to make updates on the pihole in the future.

Now that the problem revealed itself I'm gonna do so soon.
The thing is, I had couple of problems with IPv6 before on this device with the cause like this.
Like the problem of delayed IPv6 readibility and selective IPv6 adress resolution. Which I suspect was due to the Mikrotik router and hope to be gone with the Fritzbox. As I tested, the other subnet with its own internet connection did not have that problem. If that problem would stay I'll make a new thread on that.
So, as for this discussion, I wanted a fix first and see if that's the solution for getting IPv6 internet access. If I had gotten the host obedient to my routing change and still had no IPv6 connection, I would've asked to "I'm having no IPv6 connection from the bigger picture." Besides, I was so sure the route problem was the problem after all. I didn't mean to do an exploit or anything for attention.

Since this didn't bring a solution to me, I declare it unsolved, but case solved and closed. I may adapt the title within a couple of days. Or just delete it. I'll keep this discussion for a while. Maybe someone will come with a solution.

Anyway, since I know that this is no OS problem. I might make a post with instructions to precautions before moving. Because the host does obey with IPv4 routing changes. One may do so the changes afterwards if he has IPv6 on his LAN. You have a selection of IPs to choose from to reach the Pi.

Well, I apologize again for bothering you with this and thank you for your patience.

23

So.
Turns out, it was not the old router. It was the router behind it. I discovered that from disconnecting that router. Ryza's reboot gave me the right default gateway. When I reconnected it, I had taken a look at its adress list. An adress is a match. Strange though is that advertize has always been set to no with that adress. That part is a mystery to me. There was an adress active with DHCP server with the pool fd00::/64, but that didn't seem to play any role. I disabled that and the DHCP server carrying it.
Among other things I might've disabled, I disabled a rule in the neighbor discovery. I think that did the trick. The Pi is now getting the default route to the Fritzbox and keeps it. Case solved. Problem solved.