My ISP has recently started supporting IPv6. They offer a /64 address via DHCPv6 and a statically allocated /56 address. There are unresolved routing problems with some of the DHCPv6 /64 addresses, but addresses from the static /56 space work well.
I have configured the router to use static-pd with the /56 address and assign one /64 to each of the lan and wan interfaces. Configuration files below. This works (with a work around).
The odhcp6c daemon it is running on the wan interface and grabbing a /64 address, which isn't routed properly. This address has priority and all outbound IPv6 traffic goes a couple of hops then gets lost.
I can see with ifstatus wan6 that the wan6 interface has two IPv6 addresses <ipv6_good> and <ipv6_bad>. traceroute -6 -s <ipv6_good> ipv6.google.com works but traceroute -6 -s <ipv6_bad> ipv6.google.com fails at the ISP boundary.
My current work around is to add the config route6 block to /etc/config/network. This insures the good IPv6 address is used outbound.
I have been poking around at this for a few months, but have exhausted my meagre knowledge of openwrt and IPv6.
ifstatus wan6 shows that the wan6 interface is getting ipv6 addresses both statically and via DHCPv6
traceroute shows my ISP has routing error. This has been confirmed by another customer.
ps shows the process odhcp6c -s /lib/netifd/dhcpv6.script -P0 -t120 pppoe-wan is running
I found that odhcp6c is run from /lib/netifd/proto/dhcpv6.sh and edited this file to add the -v flag for verbose output to the system log file
I added some logger commands to the script to see the options passed in
I tried killing odhcp6c from the command line but it returns from the dead
I hard coded the command line to odhcp6c -s /lib/netifd/dhcpv6.script -v -Nnone pppoe-wan which stops DHCPv6 from requesting an address
When I look at what is happening when /lib/netifd/proto/dhcpv6.sh is called I see
This gives the odhcp6c command line above.
I'd like to know
Should odhcp6c be running when option proto 'static' is specified?
Can I stop odhcp6c from running?
Where is it called from?
If I can't stop it, can I pass the option -Nnone to it to make it mostly harmless?
That command "ip addrlabel" can be used to affect how the linux kernel chooses IPv6 source addresses. When selecting a source address the kernel will choose an address with the same label as the destination address. If you want the kernel to avoid addresses from a certain IPv6 prefix then you can configure that prefix with its own label. Which means those addresses will only be used when communicating with another address within the same prefix.
You probably need ip-full for the addrlabel command, and /etc/rc.local is a suitable location to add the call.
The wan interface wan uses the pppoe protocol. The DHCPv6 client is launched by the autoipv6 feature of the pppoe proto. To inhibit this automatic IPv6 handling, set option ipv6 0 on the wan PPPoE interface.
... but after a reboot other "bad things" happened with IPv6. I have reverted to my previous working configuration and – at least for now – will just work around my ISPs brokenness. It is working so I really should just leave it alone.
Thanks for the useful information. I had fun digging around in openwrt internals and learned a little more about IPv6.
NOW I think I understand. The results below surprised me – probably because I didn't understand the documentation. These results apply to a pppoe protocol wan interface.
The value of network.wan.ipv6 can be auto (default), 0 or 1:
0: IPv6 is not available on wan interface
1: IPv6 requested on wan interface and a Link Local address is allocated – presumably if available. odhcp6c not started automatically
auto (default): IPv6 requested on wan interface and Link Local address is requested. pseudo-interface wan_6 is created and odhcp6c started automatically
For me network.wan.ipv6 = 0 or 1 works best. I can use the network.wan6 section to configure IPv6 as static, dhcpv6 or whatever. When odhcp6c isn't doing things behind my back the network behaviour is much more predictable.
I think my previous confusion was due to:
assuming that the default value for ipv6 was either '0' or '1'.