I don't think the issue is being caused by the ISP (beyond their use of dynamic ipv6 addresses). It is OpenWrt's failure to detect the assignment of a new /48 block when the router boots. If the assignment of a new block happens when the router already has a /48 block assigned, then it correctly detects the change and updates the hosts on the network.
This is part of the runtime configuration which cannot survive reboot.
It must be re-sent by the server side on the client request.
3 Likes
Could a cron job read the current ipv6 address and compare it to one stored in flash? If they don't match, it could
- Force an update to be sent to clients.
- Overwrite the ipv6 address stored in flash.
- Start the checking process again.
Unless the router was rebooting continuously, there would be minimal file write operations, so I don't think it would be a danger to the integrity of the flash card.
What about a 'hack' to resolve the issue?
Could something like this be added to the local startup?
(eth1 down && sleep $((10)) && eth1 up) &
The idea being that:
- WAN interface starts at boot.
- WAN interface obtains an ipv6 address from the ISP.
- Router restarts the WAN interface.
- ISP issues a new /48 block.
- Router correctly identifies the change and sends an update to all network clients.
What do you think?
- I was actually expecting to see the tcpdump of RA's from WAN - apologies if I missed them
- (makes me think) Have you altered your WAN firewall in any manner (e.g. removing the rule allowing ICMPv6-Router Advertisement)?
I noticed some old threads where you show configs, and I didn't notice it.
I also don't recall this answer. Can you post your:
cat /etc/config/firewall
Better create an odhcp6c script as linked above.
Runtime configuration is not stored on flash, but it should be possible with some scripting.
What makes steps 1 and 3 different?
When the router first boots, it doesn't know what the previous /48 network was, so it doesn't know that it needs to force an update for all network devices. If the WAN interface is restarted shortly after boot, then it will (hopefully) get another /48 block assigned and the router will be able to compare that new block with the one assigned at boot. It will then detect the change and force an update for the clients.
root@rp4-openwrt:~# cat /etc/config/firewall
config defaults
option input 'ACCEPT'
option output 'ACCEPT'
option forward 'REJECT'
option synflood_protect '1'
config zone 'lan'
option name 'lan'
option input 'ACCEPT'
option output 'ACCEPT'
option forward 'ACCEPT'
list network 'lan'
list network 'vpn'
config zone 'wan'
option name 'wan'
option output 'ACCEPT'
option masq '1'
option mtu_fix '1'
option input 'DROP'
option forward 'DROP'
list network 'wan_ipv4'
list network 'wan_ipv6'
config forwarding
option src 'lan'
option dest 'wan'
config rule
option name 'Allow-DHCP-Renew'
option src 'wan'
option proto 'udp'
option dest_port '68'
option target 'ACCEPT'
option family 'ipv4'
config rule
option name 'Allow-Ping'
option src 'wan'
option proto 'icmp'
option icmp_type 'echo-request'
option family 'ipv4'
option target 'ACCEPT'
config rule
option name 'Allow-IGMP'
option src 'wan'
option proto 'igmp'
option family 'ipv4'
option target 'ACCEPT'
config rule
option name 'Allow-DHCPv6'
option src 'wan'
option proto 'udp'
option src_ip 'fc00::/6'
option dest_ip 'fc00::/6'
option dest_port '546'
option family 'ipv6'
option target 'ACCEPT'
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'
1 Like
But that won’t make the router advertise 0 preferred lifetime for the prefix from BEFORE the reboot.
Perhaps you don't even need to remember the old prefix?
Just run something like this at startup:
IFACE="wan_ipv6"
for IFUPD in ifdown ifup
do sleep 20; ${IFUPD} ${IFACE}
done
IFACE="wan6" would that be the name I've assigned to the interface - e.g. IFACE="wan_ipv6"?
Is this correct?
2 Likes
Yes, then reboot and monitor the changes to adjust the delay:
ifstatus wan_ipv6; ifstatus lan
Was that a command to run via SSH? I don't think I was quick enough logging into the router when it booted up.
In terms of the reboot, it has settled on b6c1
Some addresses are deprecated, but not others.
ipv6 is failing on my Windows PC.
Restarting the PC's interface clears out the old addresses and restores ipv6.
So, that hasn't resolved the problem.
In any case, check the output of the above diagnostic commands.
root@rp4-openwrt:~# ifstatus wan_ipv6; ifstatus lan
{
"up": true,
"pending": false,
"available": true,
"autostart": true,
"dynamic": false,
"uptime": 1003,
"l3_device": "eth1",
"proto": "dhcpv6",
"device": "eth1",
"metric": 0,
"dns_metric": 0,
"delegation": true,
"ipv4-address": [
],
"ipv6-address": [
{
"address": "2a02:x:x:x::6bd",
"mask": 128,
"preferred": 603797,
"valid": 690197
},
{
"address": "2a02:x:x:x:62a4:x:x:cc60",
"mask": 64,
"preferred": 604694,
"valid": 2591894
}
],
"ipv6-prefix": [
{
"address": "2a02:x:b6c1::",
"mask": 48,
"preferred": 603797,
"valid": 690197,
"class": "wan_ipv6",
"assigned": {
"lan": {
"address": "2a02:x:b6c1:1::",
"mask": 64
},
"vlan20": {
"address": "2a02:x:b6c1:20::",
"mask": 64
},
"vlan30": {
"address": "2a02:x:b6c1:30::",
"mask": 64
},
"vlan40": {
"address": "2a02:x:b6c1:40::",
"mask": 64
},
"vlan50": {
"address": "2a02:x:b6c1:50::",
"mask": 64
}
}
}
],
"ipv6-prefix-assignment": [
],
"route": [
{
"target": "2a02:x:x:x::",
"mask": 64,
"nexthop": "::",
"metric": 256,
"valid": 2591894,
"source": "::/0"
},
{
"target": "::",
"mask": 0,
"nexthop": "fe80::x:x:x:f0e1",
"metric": 512,
"valid": 1694,
"source": "2a02:x:b6c1::/48"
},
{
"target": "::",
"mask": 0,
"nexthop": "fe80::x:x:x:f0e1",
"metric": 512,
"valid": 1694,
"source": "2a02:x:x:x:62a4:x:x:cc60/64"
},
{
"target": "::",
"mask": 0,
"nexthop": "fe80::x:x:x:f0e1",
"metric": 512,
"valid": 1694,
"source": "2a02:x:x:x::6bd/128"
}
],
"dns-server": [
],
"dns-search": [
],
"neighbors": [
],
"inactive": {
"ipv4-address": [
],
"ipv6-address": [
],
"route": [
],
"dns-server": [
"2a02:x::53:1"
],
"dns-search": [
"isp.co.uk"
],
"neighbors": [
]
},
"data": {
"passthru": "001700102a02x000000000000000000530001001800160e636f6d6d756e697479666962726502636f02756b00"
}
}
{
"up": true,
"pending": false,
"available": true,
"autostart": true,
"dynamic": false,
"uptime": 1046,
"l3_device": "br-lan",
"proto": "static",
"device": "br-lan",
"updated": [
"addresses"
],
"metric": 0,
"dns_metric": 0,
"delegation": false,
"ipv4-address": [
{
"address": "192.168.0.1",
"mask": 24
}
],
"ipv6-address": [
],
"ipv6-prefix": [
],
"ipv6-prefix-assignment": [
{
"address": "2a02:x:b6c1:1::",
"mask": 64,
"preferred": 603797,
"valid": 690197,
"local-address": {
"address": "2a02:x:b6c1:1::1",
"mask": 64
}
}
],
"route": [
],
"dns-server": [
],
"dns-search": [
],
"neighbors": [
],
"inactive": {
"ipv4-address": [
],
"ipv6-address": [
],
"route": [
],
"dns-server": [
],
"dns-search": [
],
"neighbors": [
]
},
"data": {
}
}
Ideally an ISP would reserve a static /48 for each customer, rather than pulling the rug out from under them periodically.
This is exactly what is happening-- the clients need to receive an RA containing the old prefix with a lifetime of zero-- only then will they remove it from their interface and seek a new IP.
A possible workaround may be to configure odhcpd to advertise only a short lifetime on the LAN prefixes, then the clients will sooner expire the obsolete IP and seek a new one. In a small network the overhead of frequent renewals is negligible. This is also recommended if you are changing your network and/or rebooting the router frequently.
Rebooting a router tends to be very disruptive to the network, especially with OpenWrt where the paradigm is to store most operating state in RAM. Avoid rebooting your router.
2 Likes
It looks like there is no trace of the old prefix left on OpenWrt, so try this way:
uci set dhcp.lan.preferred_lifetime="1m"
uci commit dhcp
/etc/init.d/odhcpd restart
It seems the protocol was designed with static IPs in mind because there is no need to worry about running out of addresses.
ISPs have business models that push dynamic IPs. My ISP only offers static IPs to business customers and charges 10x the price for 1Gbps fibre. If they offered a static IP on their residential broadband, I expect they'd potentially lose a lot of business from people that would use a residential package for business purposes, such as hosting.
It seems that my ISP is operating in direct contravention of 'Best Practice' and is potentially risking being blacklisted by the major players.
I think this is something that probably needs to be fixed by hardware manufacturers and software projects, such as OpenWrt, because telcos aren't going to break their business models unless they're forced to by the regulator - and that's not about to happen.
Will that config be 'sticky' after I reboot? Or is it a test command to apply after I reboot?
Committed UCI settings become persistent.
Be sure to reconnect the clients to apply the changes since it doesn't affect the prefix that is already deprecated, and may not affect the current one, but should affect the new ones.