Dual stack (IPv6 and IPv4) configuration

DHCPv6, as you can see, is configured by default...

  • What kind of IPv6 service does your ISP provide?

Also verify that you have the following rules in firewall to allow the DHCPv6

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'
1 Like

Also make sure that you have enabled the default openwrt ipv6 icmp input rules.
Dhcpv6 doesn't give out a default gateway to the clients. Instead NDP is used for what.

I was experimenting with this yesterday (what a coincidence again...)
Because i wanted to completely get rid of icmp for ipv6.
The plan was to use a mtu of 1280 (should always be routeable and no icmp for pmtud is needed).
Then disable all icmpv6 allow rules.
But then odhcp6c failed because it was not able to send a router solicitation.(i have output set to deny and also use icmpv6 output rules)
So make sure NDP is allowed. (default config should cover this)
And for dhcpv6 itself
I only have this rule:

config rule
	option name 'WAN6-INPUT-Accept-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'

Which is also default and works fine.

//edit
Default icmpv6 rule:

# Allow essential incoming IPv6 ICMP traffic
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

Maybe you want to remove echo-request icmp type and adjust the limit a bit...
i use
option limit '1/sec'
option limit_burst '10'
for a small network.
Or even switch to the hashlimit module to have a per host limit rather then a global limit.

Both firewall entries are there ...

What kind of IPv6 service does your ISP provide?

no idea, it works with dd-wrt but I can't get it running under openwrt. Is there anything I could look/search for in the logs?

Interesting...I didn't know IPv6 worked "out-of-the-box" in DD-WRT without a config (their WIki describes using the command line).

Since you don't know about your IPv6 service (and it doesn't appear to be DHCPv6-based), that's difficult. Since you stated that it worked in DD-WRT, perhaps you can take a screenshot there.

ifstatus wan6

one thing that might be wrong is that the DHCP-PD might be tied to the DUID or MAC or whatever of the DD-WRT router and so when requesting a PD the OpenWrt router doesn't get a response. Calling the ISP and requesting to reset the ipv6 setttings could be in order.

1 Like

There is not much to configure in dd-wrt, you just enable IPv6, set it to "DHCPv6 with prefix delegation" add two IPv6 DNS servers et voila ...

@vgaetera

ifstatus wan6
{
	"up": false,
	"pending": true,
	"available": true,
	"autostart": true,
	"dynamic": false,
	"proto": "dhcpv6",
	"device": "eth0.2",
	"data": {
		
	}
}

@dlakelan
will try that, but I doubt they are willing to do, probably they will tell me to use the original box that was shipped when the contract started.

Is there anything else I could check out logwise?

I've never heard of that behavior. What would you do if that box was say burned out by a power surge? If it's pinned to a particular device, there will be a method to unpin it.

tcpdump -v -i eth0.2 udp port 546 &
killall -SIGUSR1 odhcp6c

I've heard if it...but if you're in the US (and also Germany I believe), they cannot require you to use a particular device.

Tell them to unpin it.

Also, the WAN doesn't get IPv6 Internet like a PC/laptop client - that sounds like what you're describing with DD-WRT. In that instance, the LAN shouldn't get IPv6. When I used DD-WRT, it wass not as simple as you describe. For the setup you need in OpenWrt, see:

Its true that they cannot require you to use a particular device, but they tell you that everything is working and don't give you any service unless you use their crappy provider box. Unfortunately that's the truth with my cable provider in Germany....

Regarding IPv6 and dd-wrt:
the infos on how to setup IPv6 is quite outdated, at least for my dd-wrt (kongmod) its now just as easy as I described before.
When checking on http://ipv6-test.com I get an IPv6 that is detected as being a native IPv6 coming from my cable service provider and not from a tunnel broker like HE.

1 Like

this is the output:

09:03:11.038942 IP6 (flowlabel 0x18388, hlim 1, next-header UDP (17) payload length: 112) fe80::4231:3cff:fed7:46c1.546 > ff02::1:2.547: [bad udp cksum 0xc2d1 -> 0xc5c4!] dhcp6 solicit (xid=be0f94 (elapsed-time 6551) (option-request SIP-servers-domain SIP-servers-address DNS-server DNS-search-list SNTP-servers NTP-server AFTR-Name opt_67 opt_82 opt_94 opt_95 opt_96 opt_82) (client-ID hwaddr type 1 40313cd746c1) (reconfigure-accept) (Client-FQDN) (IA_NA IAID:1 T1:0 T2:0) (IA_PD IAID:1 T1:0 T2:0))

means there is a IPv6 coming, but it is not accepted ?

Any ideas what else I could try?

I also found this bug:

I am quite new to openwrt but would really like to solve the problem / in case it is a bug help solving it.

seems to be a bug with current version as with an older version it works out of the box. Where should I report it?

@thorsten97: If the Xiaomi 3g also has an MT7621 chip (which IIRC it does), perhaps you can try the workaround in https://bugs.openwrt.org/index.php?do=details&task_id=1763 to disable the CONFIG_NET_MEDIATEK_OFFLOAD option.

thanks, will give it a try and report back!

works!! someone should include it in the official source or fix the bug!

That's great news!

Hm, I think I probably reported the bug in the wrong place... Anybody know how to get in contact with the right people?

1 Like

using this patch works for me. It was taken from the bug report page (https://bugs.openwrt.org/index.php?do=details&task_id=1763)

Hello guys, i have this issue but i'm a total noob and i can't find where i have to disable the "CONFIG_NET_MEDIATEK_OFFLOAD" line.
Someone can explain me?