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'
OMG @lbdroid you saved my life. I have the same problem as the original poster, and whenever I've used tcpdump on the OpenWRT box to check if the upstream router (Unitymedia Connectbox) was sending RA's I got replies and IPV6 was working for hours on end. Then, after I shut down tcpdump, I would lose connectivity after 30 minutes.
I thought that it must be the promiscuous mode tcpdump activates on the interface, but I had ruled it out since I couldn't imagine it really being something stupid as this.
I fiddled with the VLAN, Firewall and everything else that could potentially swallow the RA's, to no avail. I had also already checked that the upstream router sends the RA's to the IPV6 multicast MAC 33:....
@lbdroid Can you explain why the interface does not activate allmulti by itself, or who deactivates it if it should be on? Or is the upstream router actually sending the multicast message to the wrong MAC address(es)? Sorry if these questions seem stupid, I'm not really familiar with IPV6.
Also I would obviously like a different solution than setting a mode on the interface that's not really required, especially promiscuous, for fear of creating security vulnerabilities.
Sorry for digging up an ancient topic. Actual problem though.
Apparently OpenWRT's IPv6 client odhcp6c expects regular RA sollicitations from upstream router. Without RA messages the default route times out after a certain time (probably 30min). After that OpenWRT apparently deletes the default route and connection is lost.
Two workarounds exist:
a) get your ISP sending RA's. See Dutch fix (in Dutch)
b) apply Steffen_Weinreich's workaround and copy odhcp6c.user in /etc/ in your router. See Steffen_Weinreich's fix
After a long conversation with my ISP this behavior seems specific to IPv6 and specific to OpenWRT. I would like to let the communtity decide whether this is a bug or not. And hey, this might be a good contribution for the IPv6 configuration page.
Credits go to the original posters
# /etc/odhcp6c.user
# https://forum.turris.cz/t/solved-loosing-ipv6-default-route-after-30-minutes/3883
# by Steffen_Weinreich
logger -t odhcp6c.user INterface $1 State $2
# log env
env | logger -t odhcp6c.user
routing () {
if [ "$2" = "bound" ] ; then
for entry in $RA_ROUTES; do
local duplicate=0
local addr="${entry%%/*}"
entry="${entry#*/}"
local mask="${entry%%,*}"
entry="${entry#*,}"
local gw="${entry%%,*}"
entry="${entry#*,}"
local valid="${entry%%,*}"
entry="${entry#*,}"
local metric="${entry%%,*}"
for xentry in $RA_ROUTES; do
local xprefix="${xentry%%,*}"
xentry="${xentry#*,}"
local xgw="${xentry%%,*}"
[ -n "$gw" -a -z "$xgw" -a "$addr/$mask" = "$xprefix" ] && duplicate=1
done
if [ -z "$gw" -o "$duplicate" = 1 ]; then
# proto_add_ipv6_route "$addr" "$mask" "$gw" "$metric" "$valid" "$paddr"
logger -t odhcp6c.user setting route 1: ip route add "$addr"/"$mask" via "$gw" dev $1 metric "1$metric"
ip route add "$addr"/"$mask" via "$gw" dev $1 metric "1$metric"
else
for prefix in $PREFIXES $ADDRESSES; do
local paddr="${prefix%%,*}"
logger -t odhcp6c.user setting route 2: ip route add "$addr"/"$mask" via "$gw" dev $1 metric "2$metric" from "$paddr"
ip route add "$addr"/"$mask" via "$gw" dev $1 metric "2$metric" from "$paddr"
done
fi
done
fi
}
routing $1 $2
(Older versions of) OpenWrt is the basis for many commercial router SDKs, all OEM firmwares for QCA and Mediatek chipsets are using it for their devices, so blaming 'just' OpenWrt isn't quite an option for an ISP.
@slh thanks for the clarification. To be clear I love OpenWrt and am using this excellent piece of software for many years already and in multiple CPE's. Per the RFC my ISP offers a kind of broken native IPv6 service, let's tell them that, "you are the only customer with such a router" hehe ;). For fixing this inconvenience Steven Barth's workaround consists of the 'fakeroutes' default option, which unfortunately did not work for me.
Some ISP seem to only do stateful DHCPv6 and not sending RAs.
This is technically broken because plain DHCPv6 doesn't carry routes.
We work around here by faking a default route to the DHCPv6 server
if we do not receive a useful RA from the ISP.
This workaround can be turned off with: option fakeroutes 0
Signed-off-by: default avatarSteven Barth <steven@midlink.org>
git-svn-id: svn://svn.openwrt.org/openwrt/branches/barrier_breaker@42842 3c298f89-4303-0410-b956-a3cf2f4a3e73