IPv6 default route disappears



  • First of all: great project, thanks! :)

    TL;DR: My IPv6 default route disappears

    Setup:
    Hardware: PcEngines APU2 + SSD
    Software: 2.4.4-p2
    ISP: Fiber via media converter to RJ45

    WAN: PPPoe
    WAN6: DHCPv6

    Problem
    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
    

    DHCPv6:
    0_1552046190284_1.png

    Connection is up:
    1_1552046190284_2.png

    No default route:
    2_1552046190284_3.png

    Default gateway still listed:
    3_1552046190285_4.png

    After opening the default gateway settings and saving them, without modifying anything, the default route reappears.
    4_1552046190285_5.png

    Any clue? :)


  • LAYER 8 Netgate

    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:

    Interface: WAN
    Address family: IPv6 Only
    Protocol: ICMPv6
    Host Address: ff02::1
    Count: 100000

    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.


  • LAYER 8 Netgate

    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.



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


  • LAYER 8 Netgate

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

    They send an RA every 3 to 5 seconds.



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


  • LAYER 8 Netgate

    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.

  • LAYER 8 Netgate

    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.


  • LAYER 8 Netgate

    I'll bet it is.



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


  • LAYER 8 Netgate

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



  • @derelict 2xYes!


  • LAYER 8 Moderator

    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!


  • LAYER 8 Netgate

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


  • LAYER 8 Moderator

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


Log in to reply