IPv6 default route disappears
-
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. -
@derelict said in IPv6 default route disappears:
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.
-
@derelict said in IPv6 default route disappears:
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?
-
@derelict 2xYes!
-
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.
-
@derelict said in IPv6 default route disappears:
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.
