Anyone been able to use odhcpd relay for ipv6?

Software SW help
1

I’ve been trying to get this to work per the OpenWRT doc at https://wiki.openwrt.org/doc/uci/network6 section “Router Advertisement & DHCPv6” but have had no success. I set up the relaying configuration and can ping ipv6 sites from the router, but not from LAN clients. The LAN clients are getting valid ipv6 addresses though. I need to do relaying as my ISP doesn’t support prefix delegation.

I see this person tried to get it to work out of the box: https://forum.test.turris.cz/t/please-update-odhcpd-to-latest-version/1323 but said that the supplied odhcpd is buggy. is there an updated version I can try anywhere?

2

I can just confirm that this feature has been broken for quite a long time in OpenWRT upstream and works highly unreliably, if at all.

3

Hmm, that limits the options seriously to get ipv6 working for situations where you don’t get prefix delegation. The other option I know of would be to use ebtables/brouter functions. (bridge the ipv6 and continue to route ipv4). the team recently fixed ebtables on the test branch (it was core dumping continuously before): https://gitlab.labs.nic.cz/turris/openwrt/commit/13a856bf83cdafb35a9d50a687e7b368b0c0b06f Is there anything else you know of that would block that way (for example, does the kernel have broute support?). if the broute way doesn’t work, there’s no way to get ipv6 readily I believe for this case.

4

What kind of ISP doesn’t do the prefix delegation? Prehaps they should fix their network. PD is the most common way of deploying IPv6.
Couldn’t you then just use bridge without any routing at all?

5

Unfortunately, yes there are ISPs that don’t do PD, including one of the largest ones in the United States (AT&T). AT&T is basically a giant bureaucracy so getting them to fix their network is beyond me. Basically what I did is bridge the ipv6 traffic as you suggested: https://wiki.openwrt.org/ipv6_brouter I had to pick up ebtables_2.0.10-4-4 for the Omnia from a recent nightly (older ebtables for the Omnia core dump on startup). I worked with the author of the Brouter script to fix a number of issues with it and it works well for this situation on the Omnia.

6

Isn’t IPv6 at AT&T actually deployed using 6rd? I just googled something that suggests it:

In that case, you can switch you modem/whatever to bridge mode and create your own 6rd tunnel directly in Omnia: https://wiki.openwrt.org/doc/uci/network6#rd_tunnel_isp-provided_ipv6_transition

7

Yes, AT&T does use 6rd upstream of their modems. However, they don’t give out the NVG589 modem described in that article anymore. Their current modem is the Pace 5268AC, which doesn’t pass protocol 41 traffic…there are lots of articles describing similar experiences to mine:

https://www.dslreports.com/forum/r31029624-AT-T-Gigapower-1000-with-Pace-5268ac-and-IPv6-6rd-problems

the modem they supply eats the protocol 41 traffic so you can’t do any kind of tunnel yourself. Further, they only allow 802.1x authenticated devices to connect directly to their network, and the certificates to do so are embedded in the device firmware. So you can’t buy your own device and connect it either. Yeah, it’s a piece of work, locked down so hard that you can’t do anything with it. That left me with either trying to get odhcpd relay, or bridging/broute to work. Luckily broute did work, otherwise wouldn’t have gotten ipv6 at all.

8

—>I can just confirm that this feature has been broken for quite a long time in OpenWRT

That’s not true. odhcpd works fine in newer openwrt builds. What odhcp version are you running? And what exactly is broken? Maybe, if turris didn’t use a version of odhcpd that’s damn near 2 years old, we wouldn’t be having this problem. If you read the post:

you’ll see I’ve posted the logs files that show ICMP6 neighbor solicitation is clearly working with a newer version of odhcpd --whereas it doesn’t work with the outdated odhcp-2015 Turris OS version. Let me know if you need help reading those logs. When you see this
fe80::da58:d7ff:fe00:472b > 2a02:8070:4b8:200:4fe:68ba:abdd:a029
it means it was able to discover the global address (2a02:8070…) from my clients linked-local address (fe80…)

9

agreed, please, please try to update odhcpd. The old versions are a big blocker to making ipv6 work in many situations with the Turris Omnia. @leif.liddy has built newer versions as you can see in the other thread, so it is doable.

10

Hello,

what I could do to set up my WAN6? Ive got IPv6 prefix from ISP, but I am not so sure, where to write it… WAN6 automatically doesnt get IP assigned (as my provider told me, that should be that way - just plug the router in). I have only this in my network config

config globals 'globals'
        option ula_prefix 'fdfe:4a76:4994::/48'

config interface 'wan6'
        option ifname '@wan'
        option proto 'dhcpv6'

I didnt setup fdfe:4a76:4994::/48 and its not the prefix, assigned from ISP

11

Great. I noticed this is broken in Barrier Breaker and I actually haven’t check since final release of Chaos Calmer, which goes back to 2015. On the other hand, there is no newer stable release of OpenWRT.

Have you made the odhcpd update request into pull request or at least issue? It can be easily missed if you just write it here in the forum.

12

@Ondrej_Caletka yes I had emailed Turris tech support with this issue and had been given RT ticket number 790217 for it. Is there any better way to request it? If so let me know.

13

I think support request is good enough. You can also try to file an issue to either Gitlab or GitHub, where you can also submit pull requests.

14

I can confirm issues with NDProxy on OpenWRT (Chaos Calmer 15.05.1). The problem is not in getting address, it is actually worse. It will provide you with the address but it would write your address pointing on WAN interface rather then LAN (in routing table). There is a workaround, by running routing daemon, it is possible to force static routes on br-lan interface. However the NDProxy is broken in OpenWRT and doesn’t run out of box.