Loosing IPv6 upstream after 30 minutes

I am running the latest 18.06 checkout on R7800 (mostly hnymans build) and got IPv6 up and running in a quite good understandable way.
After checking the setup and the stability it became obvious that IPv6 upstream gets lost exactly after 30 minutes.
My Provider is KabelBW, now Unitymedia and the setup is:
ISP - Unitymedia Connect Box - R7800 OpenWrt

I am wondering why it is exactly 30 minutes until I loose the IPv6 address and the overview screen shows:
OpenWrtUpstream

When I restart the interface wan6 in GUI or terminal ifdown wan6 && ifup wan6 everything is back up and IPv6 looks healthy for another exactly 30 Minutes.

Is there any special setting / refresh I am missing or might this be related to something on this stupid Unitymedia connect box? I found the RA lifetime is fitting to 30 minutes (180 secs).

The box DHCPv6 config looks as follows:
UnityMediaConnectBox

Yes, the Router Advertisement Lifetime value is set to exactly 30 minutes.

1800s = 30m

Thank you for your response. This what the screenshot shows, you spotted it correctly!
You also repeated correctly what the TO mentioned in the first post, and added the missing "0" as this is visible in the screenshot.
Is there anything further that might help, in the context above?
There is also a Router advertisement interval
This is 180 seconds = 3 minutes

What are you seeking further help with?

If you mean regarding loss of IPv6 connectivity, just try lowering the Router Advertisement Lifetime.

I think the lifetime says how long the advertised prefix should be considered valid. The interval shows how often the router advertisements should be sent out. The fact that the ipv6 prefix is timing out suggests that the RA packets are not flowing to where they need to be. Lowering the lifetime should simply make the loss of connection happen faster

What's needed is to figure out why the packets sent every 3 minutes are not refreshing the lifetime.

EDIT: also since you've selected "stateless" the DHCPv6 features may not be in use at all. It's possible to do both DHCPv6 and stateless, but that's not what the GUI suggests is going on.

1 Like

Frequent RAs are a crucial part of a smoothly operating IPv6 network. It's a little different with IPv6 where RAs are used to indicate routers and the routes they can handle, in contrast to IPv4 where DHCP typically provides a default route for its clients.

RAs are small packets, and sending them frequently makes sure that

  • Your hosts on your network can auto-configure quickly
  • Your "upstream" routers know that your router is able to route traffic to your hosts

Lifetime is how long you're willing to "guarantee" that your router is able to handle the route advertised. Interval is how often you tell your link-local nodes about it.

From https://tools.ietf.org/html/rfc4861

      MaxRtrAdvInterval
                     The maximum time allowed between sending
                     unsolicited multicast Router Advertisements from
                     the interface, in seconds.  MUST be no less than 4
                     seconds and no greater than 1800 seconds.

                     Default: 600 seconds

      MinRtrAdvInterval
                     The minimum time allowed between sending
                     unsolicited multicast Router Advertisements from
                     the interface, in seconds.  MUST be no less than 3
                     seconds and no greater than .75 *
                     MaxRtrAdvInterval.

                     Default: 0.33 * MaxRtrAdvInterval If
                     MaxRtrAdvInterval >= 9 seconds; otherwise, the
                     Default is MaxRtrAdvInterval.

On my router, 3-second intervals can be seen in use (this is the ISP-facing interface):

$ sudo tcpdump -i enp1s0 ip6
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on enp1s0, link-type EN10MB (Ethernet), capture size 262144 bytes
11:04:51.928942 IP6 fe80::aaaa.bbbb.cccc.dddd > ip6-allnodes: ICMP6, router advertisement, length 144
11:04:54.938955 IP6 fe80::aaaa.bbbb.cccc.dddd > ip6-allnodes: ICMP6, router advertisement, length 144
11:04:58.419127 IP6 fe80::aaaa.bbbb.cccc.dddd > ip6-allnodes: ICMP6, router advertisement, length 144
11:05:01.998855 IP6 fe80::aaaa.bbbb.cccc.dddd > ip6-allnodes: ICMP6, router advertisement, length 144

Even at this "fastest permissible limit" it is a whopping 384 bps of traffic...

With the apple pie getting too watery.

then I loose IPv6 upstream even faster.
That result is: negative / worse than before. My router is supposed to keep a connection up and running.

Your clients should also re-request it faster.

With stateless, I have two IPv6 addresses on WAN6

IPv6: 2a02:bbbb:cccc:dddd:8e3b:adff:feba:225f/64
IPv6: 2a02:bbbb:cccc:dddd::a6/128
IPv6-PD: 2a02:bbbb:cccc:eeee::/60

with stateful,
it is only

IPv6: 2a02:bbbb:cccc:dddd::a6/128
IPv6-PD: 2a02:bbbb:cccc:eeee::/60
for a first check, net clients ipv6 looks fine

I'd suggest:

  • reducing MinRtrAdvInterval to 3 seconds
  • reducing MaxRtrAdvInterval to 600 seconds, as per RFC 4861, and since it seems that 1800 seconds causes connectivity loss
  • reducing AdvDefaultLifetime to somewhere between 600 seconds and 1800 seconds, as per RFC 4861

This way your upstream routers should "always" know that your router is able to route the packets, as well as having a reasonable lifetime for a home situation where your router may go down periodically, or you want to configure it differently or perhaps switch it out for something else.

3 Likes

This is getting interesting!
With stateful config type on the cable modem, I see this on the router (besides of lots of other "stuff"):

tcpdump -i eth0.2 ip6
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0.2, link-type EN10MB (Ethernet), capture size 262144 bytes
21:32:55.952825 IP6 fe80::aaaa:bbbb:cccc:dddd > ip6-allnodes: ICMP6, router advertisement, length 88
21:33:01.148661 IP6 fe80::aaaa:bbbb:cccc:dddd > ip6-allnodes: ICMP6, router advertisement, length 88
21:33:05.668606 IP6 fe80::aaaa:bbbb:cccc:dddd > ip6-allnodes: ICMP6, router advertisement, length 88
21:33:15.038293 IP6 fe80::aaaa:bbbb:cccc:dddd > ip6-allnodes: ICMP6, router advertisement, length 88

Setting is:
dhcpv6stateful

BUT: It is still getting lost - after 10 minutes.

Whereas fe80::aaaa:bbbb:cccc:dddd is the IP of the OpenWrt router, NOT the cable modem.
Isn't it that also the cable modem is supposed to send these RAs?

I understood that both, cable modem and router is the role of a router and the OpenWrt router is the router for the network hosts and the host for the cable modem.

So stateless is doing both SLAAC and DHCPv6

OpenWRT sends RA packets to your LAN which seems to be eth0.2 on your machine.

What is going on on the WAN (is that eth0.1 ?)

When you say that you lose connectivity is it that the OpenWRT router loses the ipv6 address that it has on the WAN?

Yes, the ISP equipment should be advertising ipv6 routes. Perhaps OpenWRT is ignoring those advertisements ?

Here's my recommendation, set the advertisement lifetime to 600 seconds, and the DHCPv6 valid lifetime to 300 seconds. You'll be constantly renewing your DHCPv6 address, but at least you'll be doing it much more often than the valid lifetime of the router advertisements. Perhaps this will keep things from getting confused?

1 Like

This is confusing. I was dumping on WAN interface but got the LAN packets.
WAN and WAN6 is eth0.2

interfaces

there is a minimum required:
Selection_013

As of now, I am "ifup wan6" with cron every 30 minutes (with RA lifetime set to 1800) which is fixing it.

Interface WAN6 IPv6 addresses are disappearing nicely on the screen and in terminal, and the upstream IPv6 box in the router overview is getting clear and clean.
overview

Well, I guess openwrt might be advertising itself as the router for your delegated prefix on all interfaces. That's ok, the question is how does the ISP equipment handle that. I guess it should be fine. If you look at that dump though, do you also see RA packets from the ISP equipment?

It seems odd to me that they make you have an 83 hour minimum lifetime for DHCPv6 leases on a link where the prefix is only guaranteed for a few tens of minutes.

This doesn't surprise me, since you're looking on your OpenWrt box telling "any node that I'm directly connected to" that:

  • I'm a router
  • This networks has its addresses managed by [ you /or/ managed on the network (such as by DHCPv6) ]
  • (Optionally) I can route packets for..."

(see RFC 4861, Section 4.2).

It is not unusual for node-to-node IPv6 routing to be done entirely with link-local (fe80::) addresses, except for the end points. Since routing is generally a link-local next-hop kind of thing, a link-local address is sufficient for both ends to know the Layer 2 (typically Ethernet) address associated with the next-hop interface.

1 Like

Correction:
I monitored longer and more precise - sorry for the wrong info above. I reset of Cable modem (after Router did not get any global IPv6 anymore (happens if WAN6 is getting deactivated for a longer time) - I figured the reset of Cable Modem as the only option to get it back)
This leads to
tcpdump -i eth0.2 ip6 | grep "router advertisement"
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0.2, link-type EN10MB (Ethernet), capture size 262144 bytes
lots of

22:42:26.742030 IP6 fe80::aaaa:bbbb:cccc:dddd > ip6-allnodes: ICMP6, router advertisement, length 88

and ONE

23:22:59.687968 IP6 fe80::aaaa:bbbb:cccc:dddd > fe80::eeee:ffff:gggg:hhhh ICMP6, router advertisement, length 128

fe80::aaaa:bbbb:cccc:dddd is cable modem (gateway of the router) and fe80::eeee:ffff:gggg:hhhh is router

That makes sense, the cable modem sends it ever 3,5 minutes, which is more that 180 secs that are set for the RA interval.

The point is:
There are lots of RA from Cable modem -> ip6-allnodes
But there is only one specific for Cable modem --> Router with fe80 router IPv6

@jeff had also just ip6-allnodes

Now it is getting more interesting
The single 1:1 RA can be reproduced: Press restart button of WAN6 interface

I don't know

  • if the 1:1 is the regular "update" RA
  • who requires the 1:1 and cannot work properly with the 1:all RA
  • if the 1:1 RA is fixing the problem or the down+up of the WAN6 interface

There are two mechanisms:

  1. Periodic RAs to everyone "on the link", that's the one every 180 seconds you see to ip6-allnodes
  2. Responses to neighbor discovery request for routers. That's the 1:1, most likely your OpenWRT requested neighbor discovery: "all routers, please send me your router advertisement... " and the ISP equipment responded.

Both of these are valid things to have going on. The question is, given that these are happening, why does your OpenWRT lose its WAN6 IP address?

1 Like

Should I file a bug for that?
I mean, there is nothing to analyze or capture at the time when the connection gets lost, since there is nothing going on on the wire or in the system logs.

The same issue occurs with a built of 18.06.1 on the Archer C7.

There was another issue that was encountered "sometimes", but this seems to be not related

Do you have the relevant firewall rules for inbound DHCPv6 enabled on your OpenWrt router?

This is what is there for IPv6

config rule
	option target 'ACCEPT'
	option src 'wan'
	option proto 'udp'
	option dest_port '547'
	option name 'Allow DHCPv6 (546-to-547)'
	option family 'ipv6'
	option src_port '546'

config rule
	option target 'ACCEPT'
	option src 'wan'
	option proto 'udp'
	option dest_port '546'
	option name 'Allow DHCPv6 (547-to-546)'
	option family 'ipv6'
	option src_port '547'

config rule
	option name 'Allow-MLD'
	option src 'wan'
	option proto 'icmp'
	option src_ip 'fe80::/10'
	list icmp_type '130/0'
	list icmp_type '131/0'
	list icmp_type '132/0'
	list icmp_type '143/0'
	option family 'ipv6'
	option target 'ACCEPT'

config rule
	option name 'Allow-ICMPv6-Input'
	option src 'wan'
	option proto 'icmp'
	list icmp_type 'echo-request'
	list icmp_type 'echo-reply'
	list icmp_type 'destination-unreachable'
	list icmp_type 'packet-too-big'
	list icmp_type 'time-exceeded'
	list icmp_type 'bad-header'
	list icmp_type 'unknown-header-type'
	list icmp_type 'router-solicitation'
	list icmp_type 'neighbour-solicitation'
	list icmp_type 'router-advertisement'
	list icmp_type 'neighbour-advertisement'
	option limit '1000/sec'
	option family 'ipv6'
	option target 'ACCEPT'

config rule
	option name 'Allow-ICMPv6-Forward'
	option src 'wan'
	option dest '*'
	option proto 'icmp'
	list icmp_type 'echo-request'
	list icmp_type 'echo-reply'
	list icmp_type 'destination-unreachable'
	list icmp_type 'packet-too-big'
	list icmp_type 'time-exceeded'
	list icmp_type 'bad-header'
	list icmp_type 'unknown-header-type'
	option limit '1000/sec'
	option family 'ipv6'
	option target 'ACCEPT'