Try adding: option ip6assign '64'
The WAN interface itself seems to lack IPv6. Not sure of this might help, I see this in notes when my ISP enabled IPv6.
(This was related to me asking about tcpdump output from WAN.)
That's not worked.
- I applied the command and rebooted.
- Restarted my PC's ethernet port to force it to update the DHCP.
- Rebooted again.
Windows hasn't cleared out the old IPs and is using ipv4.
All the dhcp address lease times are valid for at least 11 hours - although the dhcp entry is now using the current correct ipv6 address and is updating every 60 seconds.
1 Like
It is running as a DHCP client and is receiving data correctly.
Nope:
This is blank.
And your wan_ipv6 is not listed.
That's unfortunate, but you might want to test other time-related options:
https://openwrt.org/docs/techref/odhcpd?s=*time#dhcp_section
It should be ipv6-prefix for the upstream interface and ipv6-prefix-assignment for the downstream ones since the above output combines both.
On my device, I see an assignment for wan6 in both sections:
"ipv6-prefix": [
{
"address": "2xxx:xxxx:xxxx:xxxx::",
"mask": 56,
"preferred": 4803,
"valid": 4803,
"class": "wan6",
"assigned": {
"network2": {
"address": "2xxx:xxxx:xxxx:xxxx::",
"mask": 62
},
"xxxx_net": {
"address": "2xxx:xxxx:xxxx:xxxx::",
"mask": 64
},
"lan": {
"address": "2xxx:xxxx:xxxx:xxxx::",
"mask": 64
},
"wan6": {
"address": "2xxx:xxxx:xxxx:xxxx::",
"mask": 64
}
}
}
],
"ipv6-prefix-assignment": [
{
"address": "2xxx:xxxx:xxxx:xxxx::",
"mask": 64,
"preferred": 4803,
"valid": 4803,
"local-address": {
"address": "2xxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx",
"mask": 64
}
}
],
Also, I see from my ISP - the neighbor advertisements are from a SRC whose subnet contains the prefix.
It's also my understanding interfaces (i.e. on routers along the path) must also be assigned IPs.
1 Like
I have a similar output as the OP when run 2 OpenWrt VMs connected in cascade, and see an output like yours only after adding ip6assign to the wan6 interface.
1 Like
Well, I'm outta ideas. Your suggestions seem good.
1 Like
Just to clarify, do you happen to have ip6assign on the wan6 interface?
1 Like
Yep. This is mine:
config interface 'wan6'
option device 'wan'
option proto 'dhcpv6'
option reqaddress 'try'
option reqprefix 'auto'
option ip6assign '64'
list ip6class 'wan6'
option peerdns '0'
list dns 'xxxx:xxxx:xxxx::x'
I don't believe it was necessary for working - IPv6, I do recall it's needed for IPv6 traffic originating from the OpenWrt to have a SRC IP on the WAN interface instead of another.
1 Like
Perhaps this is specific to your ISP, but in my setup the downstream VM gets an IPv6 on the wan6 interface even without ip6assign.
3 Likes
Yeah, that's pretty much what I see when I cascade them.
Edge router config, where ISP is DHCPv6-only, so you'll see only the /128 for GUA and no ULA, plus the requested PD/56.
config interface 'wan6'
option device 'eth0'
option proto 'dhcpv6'
option reqaddress 'try'
option reqprefix '56'
config interface 'lan'
option device 'br-lan'
option proto 'static'
option netmask '255.255.255.0'
option ipaddr '10.1.1.1'
option ip6assign '56'
Subnet router config, where above upstream OpenWrt gives me two /128s (GUA, ULA), two /64s are SLAACed from the device's MAC and finally a PD/60 (as requested).
config interface 'wan6'
option device 'eth0'
option proto 'dhcpv6'
option reqaddress 'try'
option reqprefix '60'
config interface 'lan'
option device 'br-lan'
option proto 'static'
option ipaddr '10.1.3.1'
option netmask '255.255.255.0'
option ip6assign '60'
list ip6class 'wan6'
list ip6class 'local'
Edge router:
Subnet router:
1 Like
I tried this command, and now both dhcp timers are set to one minute, but the other timers remain unchanged.
uci set dhcp.lan.ra_useleasetime="1"
uci set dhcp.lan.preferred_lifetime="1m"
uci set dhcp.lan.leasetime="1m"
uci commit dhcp
/etc/init.d/odhcpd restart
Addr Type DAD State Valid Life Pref. Life Address
--------- ----------- ---------- ---------- ------------------------
Dhcp Preferred 42s 42s 2a02
Temporary Preferred 6d23h59m32s 23h54m31s 2a02:
Public Preferred 7d23h52m50s 6d23h52m50s 2a02:
Other Preferred infinite infinite fe80:
1 Like
You can also try this:
uci set dhcp.lan.leasetime="1m"
uci set dhcp.lan.ra_lifetime="30"
uci set dhcp.lan.ra_useleasetime="1"
uci commit dhcp
/etc/init.d/odhcpd restart
Unfortunately, it still isn't clearing out the old ipv6 addresses and I lose ipv6 connectivity after rebooting the router.
Addr Type DAD State Valid Life Pref. Life Address
--------- ----------- ---------- ---------- ------------------------
Temporary Preferred 6d23h57m42s 23h52m40s 2a02:x:b6ce:x
Public Preferred 7d23h40m 6d23h40m 2a02:x:b6ce:1:x
Dhcp Preferred 42s 42s 2a02:x:b6d0:1::150
Temporary Preferred 6d23h58m39s 23h53m38s 2a02:x:b6d0:1:x
Public Preferred 7d23h58m39s 6d23h58m39s 2a02:x:b6d0:1:x
Other Preferred infinite infinite fe80::x
1 Like
Undo the previous workarounds and test this one:
cat << "EOF" > /etc/odhcp6c.user.d/10-ip6prefix
DHCPC_EVENT="${2}"
NEWPREFIX=""
case ${DHCPC_EVENT} in
(bound|informed|updated|rebound|ra-updated) ;;
(*) exit 0 ;;
esac
for PREFIX in ${PREFIXES}
do if [ "${PREFIX%%,*}" != "${USERPREFIX}" ]
then NEWPREFIX="1"
fi
done
if [ -n "${NEWPREFIX}" ]
then
sleep 10
uci set network.${INTERFACE}.ip6prefix="${PREFIX%%,*}"
uci commit
/etc/init.d/network reload
fi
EOF
It stores the delegated prefix in UCI and deprecates it when a new one is available.
2 Likes
Please escape the variable names. 
EDIT: Today I learned something new about heredocs.
3 Likes
Yea, you get a /128 - that's absolutely fine.
I removed:
option ip6assign '64'
list ip6class 'wan6'
Then:
/etc/init.d/network restart
Protocol: DHCPv6 client
Uptime: 0h 1m 16s
MAC: xx:xx:xx:xx:xx:xx
RX: 184.81 GB (164786090 Pkts.)
TX: 24.35 GB (80703684 Pkts.)
IPv6-PD: xxxx:xxxx:xxxx:xxxx::/56
No "IPv6" address listed, just the PD.
Yea. must be.
2 Likes
You've clearly spent some time on this, so thanks.
What does this do and how would I implement it?
1 Like
I've emailed my ISP with some annotated screenshots of the issue.
It will be interesting to see if they respond or make any changes.
Hi,
I don't think My_ISP are following Best Practice for their implementation of ipv6.
When a router reconnects to your network after a reboot, you issue a fresh /48 block to the router.
This is a problem.
The router doesn't store the previous /48 in flash memory and the information is lost when the device reboots. This means the router has no knowledge of the previous /48 assignment.
The end result is a router that can't send out the required RA packets with a prefix valid lifetime of 0 to tell all devices that the old addresses are no longer valid.
Devices on the customer's network end up with old, inoperable, ipv6 addresses. The ipv6 connectivity fails and all devices are forced to fall back to ipv4. Which is a problem for My_ISP because you don't have enough ipv4 addresses available and are having to implement CGNAT as a workaround.
The only way to restore ipv6 connectivity is to disconnect the customer devices from the network and then reconnect them to force a new ipv6 assignment. This is clearly not a realistic or practical solution to the problem.
I think My_ISP need to update their dynamic ipv6 systems to only assign new /48 blocks upon expiry of the exiting dhcpv6 lease-time and not when devices reconnect to the network - i.e. ipv6 /48 assignment needs to be 'sticky', but not necessarily 'static'.
This would allow customers' routers to reconnect using their existing /48 network. The ipv6 addresses assigned to customer devices would remain valid and ipv6 connectivity would continue to work.
Once the lease expires, the dhcpv6 protocol will work its magic and the router will receive a new /48 block. The customer router will, in turn, issue the required RA packets with a prefix valid lifetime of 0 to inform all devices that the old addresses are no longer valid. All client devices will then receive new ipv6 addresses in the new /48 range, with the old /48 addresses automatically purged.
Thanks,
______________________________________________________________________________
This issue is covered in section 5.2 of 'Best Current Operational Practice for Operators: IPv6 prefix assignment for end-users - persistent vs non-persistent, and what size to choose'
https://www.ripe.net/publications/docs/ripe-690#5-2--why-non-persistent-assignments-are-considered-harmful
"5.2. Why non-persistent assignments are considered harmful
Taking a scenario where there is a connected CPE with a dynamically assigned prefix (e.g. 2001:db8:aaaa::/48). The CPE may sub-assign local loopback addresses out of the first /64 segment (2001:db8:aaaa:0::/64) and sub-assign 2001:db8:aaaa:1::/64 to the first LAN interface (and possibly 2001:db8:aaaa:2::/64 to the guest WiFi interface, and so on).
So, the hosts on the network autoconfigure IPv6 addresses out of 2001:db8:aaaa:1::/64 and/or 2001:db8:aaaa:2::/64 segments and start communicating with the rest of the Internet.
Now all of a sudden there is a power outage (which is very common in many regions/countries in the world, even “highly-developed” countries) or the CPE freezes and reboots and the connection has to be established again, but this time with a new IPv6 assigned prefix of 2001:db8:bbbb::/48. If the CPE knows that the delegated prefix has changed, it should send out RA packets with a prefix valid lifetime of 0 to tell all devices that the old addresses are no longer valid. However, the CPE rarely knows that before the reboot there was a different prefix on the network, and the packets to revoke the old IPv6 addresses do not get sent. In this case, multiple IPv6 addresses from completely different assigned prefixes end up on the same network interface, some of which will no longer work and may imply increase the number of claims to the call-centre.
Different OS vendors treat this scenario differently, but there often ends up being a wrong source IPv6 address for sending packets through the CPE out to the Internet. As the network operator's equipment deleted the previous delegated prefix route back to the CPE, any return packets never reach the originating device and IPv6 connectivity will be broken until the old IPv6 addresses time-out and are automatically removed from the interfaces. If another reconnection to the ISP is required in the interim, there will be a third set of IPv6 addresses from yet another assigned prefix, and this will cause even more confusion.
Some big content providers are measuring “IPv6 brokenness” in operator networks by matching the SYN, SYN ACK and ACK packets received/sent to/from a single source. If they see a SYN and send back SYN ACK, but never receive ACK in a timely manner, they slowly stop serving AAAA records for the AS number where they see this. So, if you decide to assign IPv6 non-persistent prefixes, don't be surprised if content providers start ignoring your IPv6 traffic quite quickly and force your customers back to IPv4. And these are usually destinations (big content providers) where you will be sending a significant amount of traffic."