[Solved] DHCPv6 issue, no Prefix Delegation

[trendy]

Hello all, I recently managed to get IPv6 from my ISP, so I could drop HE tunnel.
The setup should be quite simple. PPPOE for the IPv4 wan, SLAAC on IPv6 wan, and DHCPv6 for prefix delegation.

SLAAC works fine, wan6 or wan_6 interface (option ipv6 in pppoe-wan 1 or auto, tried them both) has a correct IPv6 and can see it works with pings etc.

The problem seems to be with DHCPv6. With tcpdump I can see solicit from OpenWrt and advertise from server. However OpenWrt should reply with a request, instead it sends again solicit, server sends advertise and this continues indefinitely.

Temporarily, i.e for about a minute, I can see in ifstatus that wan6 has the PD, but valid timer is less than a minute and soon is vanished.

My normal router is RSPro on 18.06.4, but since I tried too many variations I thought I test on a Carambola2 also 18.06.4 with clean install.

My ISP basically told me the same. His testing router (tp-link, not OpenWrt) successfully concluded the DHCPv6 sequence, while mine is stuck in the first 2 steps.
Any idea how to troubleshoot further?

ifstatus wan_6

root@koutsomoura:~# ifstatus wan_6
{
        "up": true,
        "pending": false,
        "available": true,
        "autostart": true,
        "dynamic": true,
        "uptime": 34923,
        "l3_device": "pppoe-wan",
        "proto": "dhcpv6",
        "device": "pppoe-wan",
        "metric": 0,
        "dns_metric": 0,
        "delegation": true,
        "ipv4-address": [

        ],
        "ipv6-address": [
                {
                        "address": "REDACTED:227:75d3:7d7e:7b15:4a9d:3d90",
                        "mask": 64,
                        "preferred": 604734,
                        "valid": 2591934
                }
        ],
        "ipv6-prefix": [

        ],
        "ipv6-prefix-assignment": [

        ],
        "route": [
                {
                        "target": "REDACTED:227:75d3::",
                        "mask": 64,
                        "nexthop": "::",
                        "metric": 256,
                        "valid": 2591934,
                        "source": "::\/0"
                },
                {
                        "target": "::",
                        "mask": 0,
                        "nexthop": "fe80::10c",
                        "metric": 512,
                        "valid": 1734,
                        "source": "REDACTED:227:75d3:7d7e:7b15:4a9d:3d90\/64"
                }
        ],
        "dns-server": [

        ],
        "dns-search": [

        ],
        "inactive": {
                "ipv4-address": [

                ],
                "ipv6-address": [

                ],
                "route": [

                ],
                "dns-server": [
                        "2001:4860:4860::8888",
                        "2001:4860:4860::8844"
                ],
                "dns-search": [

                ]
        },
        "data": {
                "passthru": "001700202001486048600000000000000000888830014840486000000000000000008448",
                "zone": "wan"
        }
}

network

root@koutsomoura:~# uci show network.wan
network.wan=interface
network.wan.proto='pppoe'
network.wan.username='user'
network.wan.password='pass'
network.wan.mtu='1492'
network.wan.peerdns='0'
network.wan.ifname='eth0'
network.wan.metric='10'
network.wan.macaddr='00:15:6D:C3:30:B6'
network.wan.ipv6='auto'
network.wan.keepalive='6 5'

tcpdump

root@koutsomoura:~# tcpdump -i pppoe-wan -vvn ip6
tcpdump: listening on pppoe-wan, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
11:23:39.651810 IP6 (flowlabel 0xde80e, hlim 1, next-header UDP (17) payload length: 118) fe80::7d7e:7b15:4a9d:3d90.546 > ff02::1:2.547: [udp sum ok] dhcp6 solicit (xid=bcd27b (elapsed-time 65535) (option-request SIP-servers-domain SIP-servers-address DNS-server DNS-search-list SNTP-servers NTP-server AFTR-Name opt_67 opt_82 opt_83 opt_94 opt_95 opt_96 server-unicast) (client-ID hwaddr type 1 02156dc330b8) (reconfigure-accept) (Client-FQDN) (IA_NA IAID:1 T1:0 T2:0) (IA_PD IAID:1 T1:0 T2:0))
11:23:39.667443 IP6 (hlim 64, next-header UDP (17) payload length: 126) fe80::10c.547 > fe80::7d7e:7b15:4a9d:3d90.546: [udp sum ok] dhcp6 advertise (xid=bcd27b (client-ID hwaddr type 1 02156dc330b8) (server-ID hwaddr type 1 6c3b6bee0d46) (preference 255) (DNS-server 2001:4860:4860::8888 2001:4860:4860::8844) (IA_PD IAID:1 T1:30 T2:48 (IA_PD-prefix REDACTED:225:7500::/56 pltime:54 vltime:60)))

[trendy]

I have made it work, with a few workarounds. Namely:

1. "option ipv6 1" under wan, so to configure wan6 manually.
2. added ip6prefix manually
3. added a route6 for ::/0

But still if someone has any idea, I am all ears.

[shm0]

Hi!
I have the same issue.
Sometimes delegation doesn't work, then it starts working again.
Did you disable/modify the default dhcpv6 firewall rule?
Even though the tcpdump log shows the dhcpv6 response from the server,
maybe the response got dropped somewhere...
I think tcpdump 'sees' traffic before iptables, at least for inbound traffic.

In my case, adding:

	option reqaddress 'force'
	option reqprefix '59' (yes, my isp only gives me a 59 prefix)
	option forceprefix '1' (Not sure if this option is depreacted)
	option noserverunicast '1'

seems to make delegation more reliable.

Do you have any other (alias) interfaces configured for eth0?

Did you change:

config defaults
.....
	option input		ACCEPT
	option output		ACCEPT
......

in /etc/config/firewall ?

Offtopic question....
By default, all INPUT traffic is allowed (for every zone and can individually be overwritten per zone)
WAN zone has default INPUT policy of DROP.
So this is why input rules for the wan zones are needed. (for example, dhcpv4/6)
But those rules are applied only when the wan/wan6 interface is up.
Now, what happens when someone changes the default input policy to drop/reject?

• Router boots up
• Firewall gets started (default policy set to DROP, network is not up/configured yet)
• Network gets started
• wan/wan6 sends dhcp request but can't receive the response because the wan/wan6 zone input allow rules are not yet applied. Is this correct?

[trendy]

@shm0

Did you enable/modify the default dhcpv6 firewall rule?
Even though the tcpdump log shows the dhcpv6 response from the server, I think tcpdump 'sees' traffic before iptables, at least for inbound traffic.

Yes it is enabled and I have tried to loosen it up without any result.
I am under the same impression, that tcpdump will capture traffic on the wire.

@shm0

Do you have any other (alias) interfaces configured on eth0?

No, wan and wan6.

@shm0

Did you change:

config defaults
.....
	option input		ACCEPT
	option output		ACCEPT
......

They are ACCEPT/REJECT, but should not matter, as interfaces are assigned in wan zone.

@shm0

Is this correct?

Default rules apply to interfaces that are not assigned to any zone.
In wan zone input is dropped/rejected, so you do need specific allow rules for the DHCPv4/v6, ICMPv6 and other flows. That applies to ingress traffic. When you send any egress traffic, the firewall is tracking the connection and allows the reply in.

[shm0]

@trendy

Default rules apply to interfaces that are not assigned to any zone.
In wan zone input is dropped/rejected, so you do need specific allow rules for the DHCPv4/v6, ICMPv6, and other flows. That applies to ingress traffic.

What I was trying to say was when are the (wan) zone rules are applied?
I guess, when the firewall is started, otherwise, it would make no sense.

@trendy

When you send any egress traffic, the firewall is tracking the connection and allows the reply in.

Does this also apply to dhcpv6 traffic? Because it is sent via multicast?

[trendy]

@shm0

What I was trying to say was when are the (wan) zone rules are applied?
I guess, when the firewall is started, otherwise, it would make no sense.

I agree, but where is this going?

@shm0

Does this also apply to dhcpv6 traffic? Because it is sent via multicast?

For v4 as well, the reply is not coming from the same address it was sent to. At least this is how I interpret it.

[trendy]

@shm0

In my case, adding:

	option reqaddress 'force'
	option reqprefix '59' (yes, my isp only gives me a 59 prefix)
	option forceprefix '1' (Not sure if this option is depreacted)
	option noserverunicast '1'

By the way, I tried that adjusted to my case, but no joy. I'd say it was even worse, as I noticed that with 'reqaddress force' I don't even get an address on the wan

[shm0]

@trendy

I agree, but where is this going?

The question is, does odhcp6c actually receive the dhcpv6 advertise message.
If not, what is blocking it?
When the zone rules are only get applied when an interface in that zone comes up then odhcp6c can never receive the advertise message. (if the default input policy is set to drop/reject)
But I think this is not the case, the rules are applied before the network is started.
Does delegation work when you restart the wan6 interface?
If yes, maybe there is a problem with the firewall and the firewall rules are not correctly applied at boot.
If no, maybe something else is hindering odhcp6c from receiving the advertise message or
odhcp6c receives the advertise message but there is a problem with the packet format or something.

odhcp6c has a -v parameter to increase verbosity but I have no clue how to enable it via uci.
Maybe you have to edit a script to enable it. (/lib/netifd/dhcpv6.script)

[trendy]

I just configured the wan and default input to ACCEPT. Behavior remains the same, Solicit and Advertise only.
I believe this can rule out the firewall from the list. I was anyway using the defaults for the firewall, so if it didn't work for me it wouldn't work for anyone else.

And now the plot thickens...
The engineer from my ISP asked me how's the troubleshooting going and he showed me his test raspberry running OpenWrt and connecting properly with almost defaults.

config interface 'wan6'
    option proto 'dhcpv6'
    option reqaddress 'try'
    option reqprefix 'auto'
    option ifname '@wan'

[shm0]

Is there no config interface wan6 section in your network config? (by default there should be one)
Does it work now?

//edit
Maybe the auto spawned wan_6 interface doesn't enable delegation by default.
I'm also not sure how to configure the auto spawned wan_6 interface.

Do the settings from wan6 also apply to wan_6?
Or do you have to set option ipv6 '1' instead of 'auto' in the interface wan section?
And then configure all the settings in the interface wan6 section.

Or create a new interface wan_6 section and use the same options/settings as wan6 does?

Did you set option ip6assign on your lan interface?

When you search for odhcp6c in the luci process overview (or 'ps | grep odhcp6c' in terminal), what parameters/flags are applied to it? (-Ntry ?)

Did the engineer mention which version of openwrt he was using?
If yes, do you use the same version?
Maybe there is a problem with netifd/ubus (or something else) where the reporting/handling of prefix delegation is bugged.

[trendy]

@shm0

Is there no config interface wan6 section in your network config? (by default there should be one)
Does it work now?

I had tried them both options, with auto (wan_6) and manual (wan6).
My config since the second post is this one:

config interface 'wan6'
        option proto 'dhcpv6'
        option ifname '@wan'
        option reqaddress 'try'
        option peerdns '0'
        option reqprefix 'auto'
        option ip6prefix 'REDACTED:225:7500::/56'
config route6
        option interface 'wan6'
        option target '::/0'
        option gateway 'fe80::10c'

@shm0

Maybe the auto spawned wan_6 interface doesn't enable delegation by default.
I'm also not sure how to configure the auto spawned wan_6 interface.

You cannot configure the auto spawned wan_6 indeed. That is what my ISP told me as well, they had trouble with autoconfiguration too.

@shm0

Do the settings from wan6 also apply to wan_6?
Or do you have to set option ipv6 '1' instead of 'auto' in the interface wan section?
And then configure all the settings in the interface wan6 section.

If you use the auto in ipv6 option in wan interface, then wan_6 is created automatically and you cannot configure it. It will try to acquire ipv6 for itself and a prefix for the lan.
If you use 1 then you manually need to create wan6 interface and add all these options there.

@shm0

Did you set option ip6assign on your lan interface?

Yes, /60

@shm0

When you search for odhcp6c in the luci process overview (or 'ps | grep odhcp6c' in terminal), what parameters/flags are applied to it? (-Ntry ?)

14941 root 1028 S odhcp6c -s /lib/netifd/dhcpv6.script -Ntry -P0 -t120 pppoe-wan

@shm0

Did the engineer mention which version of openwrt he was using?
If yes, do you use the same version?
Maybe there is a problem with netifd/ubus (or something else) where the reporting/handling of prefix delegation is bugged.

No, he didn't mention the version, however I guess that he used the latest.
But I suppose that if something that important was buggy, it would affect others too.

[shm0]

@trendy

You cannot configure the auto spawned wan_6 indeed. That is what my ISP told me as well, they had trouble with autoconfiguration too.

I'm not sure.
Here are some configuration examples for some ISPs.

ISP Configurations

They use ipv6 'auto' and then do the configuration on the wan6 interface.
What prefix length does your isp provide?
Are sure 60 will work?
Maybe OpenWRT will fallback to a different prefix length but I'm also not sure about this one.

So you already tried the following config and it didn't work?

config interface 'wan'
...........
	option ipv6 '1'
...........

config interface 'wan6'
.........
    option ifname '@wan'
    option proto 'dhcpv6'
    option reqaddress 'try'
    option reqprefix 'auto'
..........

config interface 'lan'
.......
	option ip6assign '64'
..........

And remove the route6 config section.
Then reboot the device.

The odhcp6c command line looks fine to me.

@trendy

No, he didn't mention the version, however I guess that he used the latest.
But I suppose that if something that important was buggy, it would affect others too.

Latest trunk or latest stable version?

Do you have banip, bcp38 or similar packages installed?

[trendy]

@shm0

They use ipv6 'auto' and then do the configuration on the wan6 interface.

Then they will end up with wan6 and wan_6, which I don't think is a good idea.

@shm0

What prefix length does your isp provide?
Are sure 60 will work?
Maybe OpenWRT will fallback to a different prefix length but I'm also not sure about this one.

They offer /56 which is visible in the packet capture, but it doesn't even install that one under ifstatus wan6, let alone adding it under lan interface.

@shm0

So you already tried the following config and it didn't work?

And remove the route6 config section.
Then reboot the device.

Yes still nothing.

Current summary

network.wan=interface
network.wan.proto='pppoe'
network.wan.username='blahblah'
network.wan.password='blahblah'
network.wan.mtu='1492'
network.wan.peerdns='0'
network.wan.ifname='eth0'
network.wan.metric='10'
network.wan.macaddr='blahblah'
network.wan.ipv6='1'
network.wan.keepalive='6 5'

network.wan6=interface
network.wan6.proto='dhcpv6'
network.wan6.ifname='@wan'
network.wan6.reqaddress='try'
network.wan6.reqprefix='auto'

network.lan=interface
network.lan.proto='static'
network.lan.netmask='255.255.255.0'
network.lan.ipaddr='10.0.2.1'
network.lan.dns='10.0.2.3 10.0.2.2'
network.lan.ip6assign='64'
network.lan.force_link='0'
network.lan.ip6ifaceid='::1'
network.lan.ifname='eth1.4'

@shm0

Latest trunk or latest stable version?

I can ask him next time we talk, it got already midnight here

@shm0

Do you have banip, bcp38 or similar packages installed?

I have banip, but it is auto-adding the link local IP of my ISP in the white list.
Moreover the only hit is from bogon_6 which doesn't contain the prefix of my provider or any link local addresses.

[shm0]

@trendy

Then they will end up with wan6 and wan_6, which I don't think is a good idea.

I wonder why the wiki page recommends this setup?

@trendy

They offer /56 which is visible in the packet capture, but it doesn't even install that one under ifstatus wan6, let alone adding it under lan interface.

Sorry that I overlooked this. So 60 should work fine.

@trendy

I have banip, but it is auto-adding the link local IP of my ISP in the white list.
Moreover the only hit is from bogon_6 which doesn't contain the prefix of my provider or any link local addresses.

Strange, banip doesn't whitelist any upstream ipv6 addresses.
I have configured wan and wan6 as interfaces in banip.
Maybe it is a problem with the latest version.
But when there are no hits for your isp prefixes or link locals, banip can also be ruled out.

[trendy]

@shm0

I wonder why the wiki page recommends this setup?

No clue.

I just tried with a recently flashed Carambola2 on 18.06.5 that I keep spare.
I only configured the pppoe on wan and wan6 was almost ready from factory config.
This time I could see solicit, advertise, request and reply. However there was no prefix available from what I could see in the packet capture. Not sure if this was some defense measure from the ISP. I'll need to discuss it with them tomorrow as well.

Good night for now

[shm0]

@trendy

Not sure if this was some defense measure from the ISP

Maybe because of different mac address.

//edit

OpenWrt 19.07.0 first release candidate

Hi, The OpenWrt community is proud to announce the first release candidate of the upcoming OpenWrt 19.07 stable version series. It incorporates over 3700 commits since branching the previous OpenWrt 18.06 release and has been under development for about one a half years. With this release the OpenWrt project brings all supported targets back to a single common kernel version and further refines and broadens existing device support. It also provides initial support for the new ath79 target, the…

.....
Bugfixes in DHCPv6 client and server
.....

[trendy]

Famous network engineer words:

It's the MTU or the DNS, always.

I noticed that in the config snipet that my ISP sent me there was no mtu=1492 in the wan interface. I tried to remove it too and it worked!
Regardless of that the pppoe interface still has the mtu set.

pppoe-wan Link encap:Point-to-Point Protocol  
[...]
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1492  Metric:1

Weird, cause the IPv4 worked for years with this setting, and it is something I automatically configure in pppoe interfaces. Maybe I missed some update.

@shm0 thank you for the help and suggestions!

[shm0]

I'm glad your got it working.

But how can an MTU issue break delegation and not everything else also?

I think the option mtu statement sets the MTU for physical interface
and launches the ppp daemon with the mtu specified.
So if you set 1492 as MTU, eth0 MTU will be 1492 and
the ppp daemon gets launched with mtu 1492,
but because of the 8byte overhead of pppoe the actual mtu will be 1484.
MTU = 1500 is the proper value here if you want a 'pppoe mtu of 1492'
But I'm not sure about this

[trendy]

You are absolutely right, that is what was happening. The eth0 MTU was 1492 and pppoe-wan 1484.
I deleted the option and now everything is correct, eth0 1500 and pppoe-wan 1492.
Regarding why it broke delegation and not something else, I have no idea. Maybe it broke something that went unnoticed. And it was my wrong to use it without checking first documentation or the "ip link". Too much confidence I guess and I got carried away from other operating systems.