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:
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).
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
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.
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.
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):
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.
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.
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?
This is confusing. I was dumping on WAN interface but got the LAN packets.
WAN and WAN6 is eth0.2
there is a minimum required:
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.
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.
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
Periodic RAs to everyone "on the link", that's the one every 180 seconds you see to ip6-allnodes
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?
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
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'
