IPv6 default route disappears

entrader

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.

Derelict

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

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.
Route expired?

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! :)

Derelict

Yeah. Cox (American ISP) here also sends RAs with an 1800-second lifetime.

They send an RA every 3 to 5 seconds.

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! :)

Derelict

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.

Derelict

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

@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.

entrader

@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.

Derelict

I'll bet it is.

entrader

The ISP now sends RAs periodically, so this part is solved.

Derelict

Does the route now stay? You actually got someone there to fix it?

entrader

@derelict 2xYes!

JeGr

Almost unbelievable: an ISP that actually fixes its stuff? That indeed is noteworthy!

entrader

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!

Derelict

I bookmarked this thread. Especially in light of the other "German ISPs are immovable objects" threads around here. Vote with your deutchemarks, people.

JeGr

@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.