IPv6 default route disappears
First of all: great project, thanks! :)
TL;DR: My IPv6 default route disappears
Hardware: PcEngines APU2 + SSD
ISP: Fiber via media converter to RJ45
When connecting to my ISP, the connection setup is successfully.
I'm getting my IPv4 + IPv6 addresses, an IPv6 prefix and everything works fine.
I can ping remote hosts and have a IPv6 default route.
But after some time, my IPv6 default route is gone and I'm no longer able to connect to remote hosts via IPv6.
The IPv6 default gateway is still listed and pingable via IPv6.
If I open the IPv6 gateway settings and save them without changing any values, the IPv6 default route re-appears and IPv6 works (again).
System > Routing > Gateways > Edit
Connection is up:
No default route:
Default gateway still listed:
After opening the default gateway settings and saving them, without modifying anything, the default route reappears.
Any clue? :)
If the default route vanishes, it is probably due to defective Router Advertisements from upstream.
In IPv6, the default gateway is not obtained via DHCP. It is obtained based on RAs from the routers.
You can packet capture on WAN for this:
Address family: IPv6 Only
Host Address: ff02::1
Start that and let that roll through getting a working interface then losing the default gateway. Stop it and see what's there. You probably want to download the capture so you can upload it if necessary.
Wireshark will also decode a lot of it for you if you open the capture there.
What does your ISP have to say about this fail?
I'll capture traffic and look for defective RAs.
But why does the default route instantly (!) reappear when I open and save the default gateway settings without any modification?
My first guess was that the router has sent a Router Solicitation after I've saved the settings but I haven't seen any.
My first guess was that the router has sent a Router Solicitation
That is a safe assumption.
If you catch the RAs from the upstream router it will tell us a lot like the lifetime, etc.
It might be a good idea to just capture all ICMPv6 and not limit it to ff02::1. You might want to set a capture size of 1000000 frames or something. You want it to run until you get what you need but protect yourself from filling the disk.
entrader last edited by entrader
I've captured on the underlaying NIC which runs the WAN PPPoE connection.
The pcap file is attached, I'm aware of the information exposed.
Packet #59 carries a router advertisement with a lifetime of 1800s.
It's the only RA I've seen.
This seems to be related to my problem:
Pinging a remote host via IPv6 fails after 30 minutes and the default route is gone.
And now the most confusing part:
When opening the gateway settings and saving them, the default route for IPv6 is back.
But the router hasn't sent any IPv6 packets.
Help needed! :)
Yeah. Cox (American ISP) here also sends RAs with an 1800-second lifetime.
They send an RA every 3 to 5 seconds.
entrader last edited by entrader
Okay, my ISP seems to send RAs only in response to RSs...
I've created a cron job as a workaround: "rtsol -DF pppoe" every minute.
I'll check if this helps.
Your two cents?
Still two remaining questions:
- Is there a way to trigger/cron RSs via GUI?
- Why does the route reappear even it's expired?
BTW: Thanks a lot for your support! :)
Your ISP is broken. They should fix their IPv6 deployment. Expecting a workaround for every way an ISP chooses break IPv6 is unreasonable.
6.3.7. Sending Router Solicitations When an interface becomes enabled, a host may be unwilling to wait for the next unsolicited Router Advertisement to locate default routers or learn prefixes. To obtain Router Advertisements quickly, a host SHOULD transmit up to MAX_RTR_SOLICITATIONS Router Solicitation messages, each separated by at least RTR_SOLICITATION_INTERVAL seconds. Router Solicitations may be sent after any of the following events: - The interface is initialized at system startup time. - The interface is reinitialized after a temporary interface failure or after being temporarily disabled by system management. - The system changes from being a router to being a host, by having its IP forwarding capability turned off by system management. - The host attaches to a link for the first time. - The host re-attaches to a link after being detached for some time. ***(are any of these conditions present based on the fact that the upstream simply stops sending Router Advertisements? No.)*** A host sends Router Solicitations to the all-routers multicast address. The IP source address is set to either one of the interface's unicast addresses or the unspecified address. The Source Link-Layer Address option SHOULD be set to the host's link-layer address, if the IP source address is not the unspecified address. Before a host sends an initial solicitation, it SHOULD delay the transmission for a random amount of time between 0 and MAX_RTR_SOLICITATION_DELAY. This serves to alleviate congestion when many hosts start up on a link at the same time, such as might happen after recovery from a power failure. If a host has already performed a random delay since the interface became (re)enabled (e.g., as part of Duplicate Address Detection [ADDRCONF]), there is no need to delay again before sending the first Router Solicitation message. In some cases, the random delay MAY be omitted if necessary. For instance, a mobile node, using [MIPv6], moving to a new link would need to discover such movement as soon as possible to minimize the amount of packet losses resulting from the change in its topological movement. Router Solicitations provide a useful tool for movement detection in Mobile IPv6 as they allow mobile nodes to determine movement to new links. Hence, if a mobile node received link-layer information indicating that movement might have taken place, it MAY send a Router Solicitation immediately, without random delays. The strength of such indications should be assessed by the mobile node's implementation depending on the level of certainty of the link-layer hints, and it is outside the scope of this specification. Note that using this mechanism inappropriately (e.g., based on weak or transient indications) may result in Router Solicitation storms. Furthermore, simultaneous mobility of a large number of mobile nodes that use this mechanism can result in a large number of solicitations sent simultaneously. Once the host sends a Router Solicitation, and receives a valid Router Advertisement with a non-zero Router Lifetime, the host MUST desist from sending additional solicitations on that interface, until the next time one of the above events occurs. Moreover, a host SHOULD send at least one solicitation in the case where an advertisement is received prior to having sent a solicitation. Responses to solicited advertisements may contain more information than unsolicited advertisements. If a host sends MAX_RTR_SOLICITATIONS solicitations, and receives no Router Advertisements after having waited MAX_RTR_SOLICITATION_DELAY seconds after sending the last solicitation, the host concludes that there are no routers on the link for the purpose of [ADDRCONF]. However, the host continues to receive and process Router Advertisements messages in the event that routers appear on the link.
I say again:
Once the host sends a Router Solicitation, and receives a valid
Router Advertisement with a non-zero Router Lifetime, the host MUST
desist from sending additional solicitations on that interface, until
the next time one of the above events occurs.
JKnott last edited by
It might be a good idea to just capture all ICMPv6 and not limit it to ff02::1.
I use the link local address for the WAN interface and ICMP6. That works well and catches both multicast and unicast packets.
Your ISP is broken.
Yep, I've read the RFC and I think you're right.
I've opened a ticket and I hope they will fix it.
But my question remains: Why is the route reappearing after saving the settings page? :)
The router is not receiving a RA.
I'll bet it is.
The ISP now sends RAs periodically, so this part is solved.
Does the route now stay? You actually got someone there to fix it?
Almost unbelievable: an ISP that actually fixes its stuff? That indeed is noteworthy!
It's a small local (germany) ISP, offering FTTB for a reasonable price.
And you're right: You can talk directly with the technical staff, that's awesome! They're doing a great job!
I bookmarked this thread. Especially in light of the other "German ISPs are immovable objects" threads around here. Vote with your deutchemarks, people.
Vote with your deutchemarks, people.
They are called Euros for years, ya' know?
Problem is, that those small little pearls are mostly local ISPs in specific regions or cities. Even if I'd wanted to go all out and "shut up and take my money", it won't get me far. In most non-crowded places you're happy if you can get DSL with PPPoE or Cable from the same few companies. There are only some like e.g. DG / Deutsche Glasfaser / "german fiber" that will get you FTTH or FTTB.
So more often then not, voting with ones wallet isn't possible as no other/better service is available.