DHCPv6 stops halfway during communication with ISP

Installing and Using OpenWrt
1

I'm using a netgear WNDR3700v4 to try to connect to my ISP (hyperoptic, IPv6 instructions here). I'm running openwrt 19.07 with LuCI.

DHCPv6 is not working; we get a dhcp6 advertise back from the ISP but there is no dhcp6 request coming from the router afterwards. My config is nothing special, all default values, like this:

root:~# cat /etc/config/network 

[..]

config interface 'wan'
	option ifname 'eth0.2'
	option _orig_ifname 'eth0.2'
	option _orig_bridge 'false'
	option proto 'dhcp'

[..]

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

root:~# cat /etc/config/dhcp 

[..]

config dhcp 'wan'
	option interface 'wan'
	option ignore '1'

[..]

config dhcp
	option leasetime '12h'
	option limit '150'
	option interface 'lan1'
	option start '64'
	option ra 'server'
	option dhcpv6 'server'
	option ra_management '1'

[..]

Example of tcpdump ip6 -i eth0.2 after ifdown wan6; ifup wan6:

23:48:17.154708 IP6 fe80::<my router>.546 > ff02::1:2.547: dhcp6 solicit
23:48:17.165377 IP6 fe80::<ISP>.547 > fe80::<my router>.546: dhcp6 advertise
23:48:21.513540 IP6 fe80::<ISP> > fe80::<my router>: ICMP6, neighbor solicitation, who has fe80::<my router>, length 32
23:48:21.513748 IP6 fe80::<my router> > fe80::<ISP>: ICMP6, neighbor advertisement, tgt is fe80::<my router>, length 24
23:48:26.514467 IP6 fe80::<my router> > fe80::<ISP>: ICMP6, neighbor solicitation, who has fe80::<ISP>, length 32
23:48:26.526676 IP6 fe80::<ISP> > fe80::<my router>: ICMP6, neighbor advertisement, tgt is fe80::<ISP>, length 32
23:48:35.739646 IP6 fe80::<ISP> > ff02::1:XXX: ICMP6, neighbor solicitation, who has fe80::XXX, length 32
23:48:35.754198 IP6 fe80::<ISP> > ff02::1:YYY: ICMP6, neighbor solicitation, who has fe80::YYY, length 32
[etc; nothing more from my router]

Instead of trying random things, I wonder if anyone can help further debug this issue - I tried setting log level 7 but nothing further comes up in logread.

2

What does the status page says?

openwrt-status-prefix

3

@vuhuy there is no IPv6 upstream, it is stuck in "pending"

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

I'm thinking about a MTU problem. So I see you're using your own router and therefore connect via pppoe?

Edit: scrap that - i suppose you're connected through a modem seeing your WAN config. Anyway, I've seen negotiations fail before due to packet fragmentation.

5

@vuhuy I'm not sure if there is a modem - all I have is an ethernet port in my living room which I connect the router to. DHCPv6 is the way to go, according to my ISP's instructions, and at least I am getting dhcp6 solicit back from their side.

How would I experiment with the MTU?

6

Only a ethernet port? That's weird, do you share a connection with others? What's the IPv4 upstream gateway? What page do you get if you connect to that IPv4 upstream gateway address in your browser?

7

@vuhuy This ISP serves fibre to the whole apartment block, does that fit your definition of "share"? For IPv4 the ISP uses CGN (I believe) and the upstream gateway is a 100.64.* address. I can't connect to it, but I can ping it.

8

Okay that totally makes sense now. I was already guessing you're in some kind of apartment block. Normally ISPs don't supply ethernet connections out of the wall (at least not in my country). Yes, you're correct, 100.64.0.0/10 is usually the reserved address carrier grades NAT, your ISP is running DS-Lite (or another IPv6 transition technology).

Back on topic, if it was a MTU error, the answer lies probably in more detailed tcpdump logs. Try to add more verbosity (-vvv).

9

Thanks. I've had a chance to look at the dump more closely, and I don't think it's an MTU issue. In fact the ISP seems to be giving back the correct information and the UDP checksum is even fine. Do you see anything wrong with the below?

My openwrt-router, dhcp6 solicit 
21:15:24.647436 IP6 (flowlabel 0x29a7b, hlim 1, next-header UDP (17) payload length: 110)
  fe80::<my openwrt>.546 > ff02::1:2.547: [udp sum ok]
  dhcp6 solicit
    (xid=97b1ad
      (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 XXX)
      (reconfigure-accept)
      (Client-FQDN)
      (IA_NA IAID:1 T1:0 T2:0)
      (IA_PD IAID:1 T1:0 T2:0)
    )
ISP's router, dhcp6 advertise 
21:15:24.658497 IP6 (flowlabel 0x00201, hlim 255, next-header UDP (17) payload length: 157)
  fe80::<ISP>.547 > fe80::<my openwrt>.546: [udp sum ok]
  dhcp6 advertise
    (xid=97b1ad
      (IA_NA IAID:1 T1:43200 T2:64800 (IA_ADDR <some public IPv6 address> pltime:72000 vltime:86400))
      (IA_PD IAID:1 T1:43200 T2:64800 (IA_PD-prefix <some public IPv6 prefix>::/56 pltime:72000 vltime:86400))
      (client-ID hwaddr type 1 XXX)
      (server-ID hwaddr/time type 1 time 588232101 YYY)
      (reconfigure-accept)
      (DNS-search-list hyperoptic.com.)
    )

For comparison, my ISP-router (the one I am supposed to connect to my ISP with) outputs the following solicit, when I connect its WAN port to my openwrt router LAN port as a test:

My ISP-router, dhcp6 solicit 
21:11:56.185363 IP6 (hlim 1, next-header UDP (17) payload length: 71)
  fe80::<my isp-router>.546 > ff02::1:2.547: [udp sum ok]
  dhcp6 solicit
    (xid=69f7e1
      (client-ID hwaddr/time type 1 time 360292831 XXX)
      (IA_PD IAID:1000 T1:0 T2:0)
      (elapsed-time 0)
      (vendor-class)
      (option-request DNS-server)
    )

After receiving a dhcp6 advertise from my router (i.e. what must be an invalid one) it nevertheless sends:

My ISP-router, dhcp6 request 
21:11:57.226048 IP6 (hlim 1, next-header UDP (17) payload length: 114)
  fe80::<my isp-router>.546 > ff02::1:2.547: [udp sum ok]
  dhcp6 request
    (xid=983f76
      (client-ID hwaddr/time type 1 time 360292831 XXX)
      (IA_PD IAID:1000 T1:86400 T2:138240 (IA_PD-prefix <the fake IA_PD-prefix from my openwrt>::/62 pltime:4294967295 vltime:4294967295))
      (server-ID hwaddr type 1 YYY)
      (elapsed-time 0)
      (vendor-class)
      (option-request DNS-server)
    )

The differences between the solicits seem minor, what do you think? (Sadly I don't have the equipment to generate a full dump of my ISP-router communicating with the ISP through the whole DHCP flow.)

10

Well, now I am very confused. I connected my openwrt router (WAN) to my ISP-router (LAN) (whilst it is connected to my ISP) and dumped the DHCPv6 messages - it seems my openwrt router is happy to configure its IPv6 network using only the dhcp6 advertise messages received from my ISP-router. I thought the client is suppose to send a follow-up dhcp6 request, but I don't see any in my dumps, yet the interface is configured (albeit without a IA_PD, a separate issue). Am I misunderstanding how DHCPv6 is supposed to work?

Specifically, what happens is that my openwrt router sends dhcp6 solicit, then my ISP-router replies with dhcp6 advertise, this happens 4 times, then the "IPv6 upstream" gets configured successfully with the IP_NA from the advertise message.

My ISP-router, dhcp6 advertise 
23:09:12.766838 IP6 (hlim 64, next-header UDP (17) payload length: 109)
  fe80::1.57357 > fe80::<my openwrt>.546: [udp sum ok]
  dhcp6 advertise
    (xid=548c84
      (client-ID hwaddr type 1 XXX)
      (server-ID hwaddr type 6 YYY)
      (IA_NA IAID:1 T1:35042 T2:56068 (IA_ADDR <some public IPv6 address> pltime:70085 vltime:84485))
      (preference 7)
      (DNS-server fe80::1)
    )

By contrast, when I remove the ISP-router, and connect my openwrt router directly to my ISP, the same sequence of 4 x (dhcp6 solicit, dhcp6 advertise) happens, but my openwrt router's wan6 remains stuck on "pending". (Note: this is the situation I described in the first part of the previous post, compare with "ISP's router, dhcp6 advertise" above.)

11

Issue filed to odhcpd as https://github.com/openwrt/odhcpd/issues/159, let's see what they say.