IPv6 with IA_PD behind fritzbox with 6to4 does not work

Jonny007-MKD · December 6, 2023, 10:52pm

Hello,

Over years I was a Deutsche Telekom customer and had native IPv6. /60 prefixes were delegated to my OpenWRT router behind the fritzbox and everything was working fine. Except that it was VDSL.

Since today I am a Fiber customer of EWE. Unfortunately, they don't have native IPv6 (in 2023!). So I figured I could simply enable 6to4 in my fritzbox and delegate those prefixes to my OpenWRT router. Only it doesn't work I did not change anything about my OpenWRT config which worked since quite a while, I only plugged in another fritzbox at the WAN port which is delegating different IPv6 prefixes.

I updated from OpenWRT 22 to 23.05.2, but it still does not work.

Also, I added a -v in /lib/netifd/proto/dhcpv6.sh for odhcp6c, and found the output in logread. It looks like this:

Wed Dec  6 22:53:04 2023 daemon.notice netifd: Interface 'wan6' is setting up now
Wed Dec  6 22:53:05 2023 daemon.notice odhcp6c[9035]: (re)starting transaction on eth0
Wed Dec  6 22:53:05 2023 daemon.notice netifd: wan6 (9035): odhcp6c[9035]: (re)starting transaction on eth0
Wed Dec  6 22:53:05 2023 daemon.notice odhcp6c[9035]: Starting SOLICIT transaction (timeout 4294967295s, max rc 0)
Wed Dec  6 22:53:05 2023 daemon.notice netifd: wan6 (9035): odhcp6c[9035]: Starting SOLICIT transaction (timeout 4294967295s, max rc 0)
Wed Dec  6 22:53:05 2023 daemon.notice odhcp6c[9035]: Got a valid ADVERTISE after 3ms
Wed Dec  6 22:53:05 2023 daemon.info odhcp6c[9035]: IA_PD 0001 T1 1800 T2 2880
Wed Dec  6 22:53:05 2023 daemon.info odhcp6c[9035]: 2002:1234:ebe:f0::/60 preferred 3600 valid 7200
Wed Dec  6 22:53:05 2023 daemon.notice netifd: wan6 (9035): odhcp6c[9035]: Got a valid ADVERTISE after 3ms
Wed Dec  6 22:53:05 2023 daemon.notice netifd: wan6 (9035): odhcp6c[9035]: IA_PD 0001 T1 1800 T2 2880
Wed Dec  6 22:53:05 2023 daemon.notice netifd: wan6 (9035): odhcp6c[9035]: 2002:1234:ebe:f0::/60 preferred 3600 valid 7200

Wed Dec  6 22:53:06 2023 daemon.notice odhcp6c[9035]: Got a valid ADVERTISE after 1132ms
Wed Dec  6 22:53:06 2023 daemon.info odhcp6c[9035]: IA_PD 0001 T1 1800 T2 2880
Wed Dec  6 22:53:06 2023 daemon.info odhcp6c[9035]: 2002:1234:ebe:f0::/60 preferred 3600 valid 7200
Wed Dec  6 22:53:06 2023 daemon.notice netifd: wan6 (9035): odhcp6c[9035]: Got a valid ADVERTISE after 1132ms
Wed Dec  6 22:53:06 2023 daemon.notice netifd: wan6 (9035): odhcp6c[9035]: IA_PD 0001 T1 1800 T2 2880
Wed Dec  6 22:53:06 2023 daemon.notice netifd: wan6 (9035): odhcp6c[9035]: 2002:1234:ebe:f0::/60 preferred 3600 valid 7200

As you see, odhcp6c receives an ADVERTISE from the fritzbox having the wanted prefix (2002:1234:ebe:f0::/60), but it does not start the REQUEST transaction. Instead the SOLICIT is resent and answered with an ADVERTISE, which odhcp6c sorts into the same transaction ("after 1132 ms").

This is how it looks like with tcpdump:

tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
21:12:24.359027 IP6 (flowlabel 0x5e634, hlim 255, next-header ICMPv6 (58) payload length: 16) fe80::cccc:1111:eeee:cebb > ff02::2: [icmp6 sum ok] ICMP6, router solicitation, length 16
	  source link-address option (1), length 8 (1): xx:xx:xx:xx:ce:bb
	    0x0000:  c46e 1f54 cebb
21:12:24.363118 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 160) fe80::5555:3333:dddd::de8e > ff02::1: [icmp6 sum ok] ICMP6, router advertisement, length 160
	hop limit 255, Flags [other stateful], pref medium, router lifetime 1800s, reachable time 0ms, retrans timer 0ms
	  prefix info option (3), length 32 (4): 2002:1234:ebe::/64, Flags [onlink, auto], valid time 6750s, pref. time 3150s
	  prefix info option (3), length 32 (4): fd17::/64, Flags [onlink, auto], valid time 7200s, pref. time 3600s
	  rdnss option (25), length 24 (3):  lifetime 1200s, addr: fd17::5555:3333:dddd::de8e
	  mtu option (5), length 8 (1):  1472
	  route info option (24), length 8 (1):  ::/0, pref=medium, lifetime=1800s
	  route info option (24), length 16 (2):  2002:1234:ebe::/64, pref=medium, lifetime=1800s
	  route info option (24), length 16 (2):  fd17::/64, pref=medium, lifetime=1800s
	  source link-address option (1), length 8 (1): xx:xx:xx:xx:de:8e
21:12:24.558264 IP6 (flowlabel 0x095c6, hlim 1, next-header UDP (17) payload length: 142) fe80::cccc:1111:eeee:cebb.546 > ff02::1:2.547: [udp sum ok]
    dhcp6 solicit (xid=4b9a65 (elapsed-time 0) (option-request SIP-servers-domain SIP-servers-address DNS-server DNS-search-list SNTP-servers NTP-server AFTR-Name opt_67 opt_94 opt_95 opt_96 opt_82) (client-ID hwaddr type 1 1111eeeecebb) (reconfigure-accept) (Client-FQDN)
    (IA_NA IAID:1 T1:0 T2:0)
    (IA_PD IAID:1 T1:0 T2:0 (IA_PD-prefix ::/60 pltime:0 vltime:0)))
21:12:24.561057 IP6 (hlim 64, next-header UDP (17) payload length: 166) fe80::5555:3333:dddd::de8e.547 > fe80::cccc:1111:eeee:cebb.546: [udp sum ok]
    dhcp6 advertise (xid=4b9a65 (opt_82) (NTP-server subopt:1 fd17::5555:3333:dddd::de8e) (client-ID hwaddr type 1 1111eeeecebb) (server-ID hwaddr type 1 3333ddddde8e) (preference 0) (reconfigure-accept) (DNS-server fd17::5555:3333:dddd::de8e) (opt_86)
    (IA_PD IAID:1 T1:1800 T2:2880
        (IA_PD-prefix 2002:1234:ebe:f0::/60 pltime:3600 vltime:7200)
    ))

21:12:25.633094 IP6 (flowlabel 0x095c6, hlim 1, next-header UDP (17) payload length: 142) fe80::cccc:1111:eeee:cebb.546 > ff02::1:2.547: [udp sum ok]
    dhcp6 solicit (xid=4b9a65 (elapsed-time 107) (option-request SIP-servers-domain SIP-servers-address DNS-server DNS-search-list SNTP-servers NTP-server AFTR-Name opt_67 opt_94 opt_95 opt_96 opt_82) (client-ID hwaddr type 1 1111eeeecebb) (reconfigure-accept) (Client-FQDN)
    (IA_NA IAID:1 T1:0 T2:0)
    (IA_PD IAID:1 T1:0 T2:0 (IA_PD-prefix ::/60 pltime:0 vltime:0)))
21:12:25.635605 IP6 (hlim 64, next-header UDP (17) payload length: 166) fe80::5555:3333:dddd::de8e.547 > fe80::cccc:1111:eeee:cebb.546: [udp sum ok]
    dhcp6 advertise (xid=4b9a65 (opt_82) (NTP-server subopt:1 fd17::5555:3333:dddd::de8e) (client-ID hwaddr type 1 1111eeeecebb) (server-ID hwaddr type 1 3333ddddde8e) (preference 0) (reconfigure-accept) (DNS-server fd17::5555:3333:dddd::de8e) (opt_86)
    (IA_PD IAID:1 T1:1800 T2:2880 (
        IA_PD-prefix 2002:1234:ebe:f0::/60 pltime:3600 vltime:7200)
    ))

21:12:27.713063 IP6 (flowlabel 0x095c6, hlim 1, next-header UDP (17) payload length: 142) fe80::cccc:1111:eeee:cebb.546 > ff02::1:2.547: [udp sum ok]
    dhcp6 solicit (xid=4b9a65 (elapsed-time 315) (option-request SIP-servers-domain SIP-servers-address DNS-server DNS-search-list SNTP-servers NTP-server AFTR-Name opt_67 opt_94 opt_95 opt_96 opt_82) (client-ID hwaddr type 1 1111eeeecebb) (reconfigure-accept) (Client-FQDN)
    (IA_NA IAID:1 T1:0 T2:0)
    (IA_PD IAID:1 T1:0 T2:0 (IA_PD-prefix ::/60 pltime:0 vltime:0)))
21:12:27.715655 IP6 (hlim 64, next-header UDP (17) payload length: 166) fe80::5555:3333:dddd::de8e.547 > fe80::cccc:1111:eeee:cebb.546: [udp sum ok]
    dhcp6 advertise (xid=4b9a65 (opt_82) (NTP-server subopt:1 fd17::5555:3333:dddd::de8e) (client-ID hwaddr type 1 1111eeeecebb) (server-ID hwaddr type 1 3333ddddde8e) (preference 0) (reconfigure-accept) (DNS-server fd17::5555:3333:dddd::de8e) (opt_86)
    (IA_PD IAID:1 T1:1800 T2:2880 (
        IA_PD-prefix 2002:1234:ebe:f0::/60 pltime:3600 vltime:7200)
    ))

To me it looks like odhcp6c is receiving the ADVERTISE and decodes it correctly, but then does not continue to accept it by sending a REQUEST. Can anybody tell me, why?

This is my interface config:

config interface 'wan6'
	option device 'eth0'
	option proto 'dhcpv6'
	option reqaddress 'force'
	option reqprefix '60'
	option peerdns '0'

Jonny007-MKD · December 6, 2023, 11:13pm

I scrolled through the source code of odhcp6c looking for the strings which are being logged and then went looking for where REQUESTS are being sent. I found this line which only does something if the mode is "try":

github.com

openwrt/odhcp6c/blob/bcd283632ac13391aac3ebdd074d1fd832d76fa3/src/dhcpv6.c#L1667


      
          	int ret = DHCPV6_STATELESS;
          
          	// Clear lingering candidate state info
          	odhcp6c_clear_state(STATE_SERVER_ID);
          	odhcp6c_clear_state(STATE_IA_NA);
          	odhcp6c_clear_state(STATE_IA_PD);
          
          	if (!cand_len)
          		return -1;
          
          	if (cand->has_noaddravail && na_mode == IA_MODE_TRY) {
          		na_mode = IA_MODE_NONE;
          
          		dhcpv6_retx[DHCPV6_MSG_SOLICIT].max_timeo = cand->sol_max_rt;
          		dhcpv6_retx[DHCPV6_MSG_INFO_REQ].max_timeo = cand->inf_max_rt;
          
          		return dhcpv6_request(DHCPV6_MSG_SOLICIT);
          	}
          
          	hdr[0] = htons(DHCPV6_OPT_SERVERID);
          	hdr[1] = htons(cand->duid_len);

I have set it to "force". I didn`t change it, but now it is working.

Unfortunately the documentation for reqaddress is quite minimalistic:

Behaviour for requesting addresses

From the name and values I would have guessed that "force" is stronger than "try" and should succeed in more cases. Now I don't know whether that is expected behavior or a bug in odhcp6c.