Yealink Forums

Full Version: T48G IPv6 SLAAC regression with V80
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Hi,

we're currently testing T48G phones for a company wide replacement of our legacy Snom hardphones. We're pretty happy, but have hit an annoying regression regarding IPv6 in recent firmware versions.

I'll reply to this post with more dumps, but the short story looks like this.

Our test network is dualstacked with IPv4 DHCP and IPv6 SLAAC+stateless DHCPv6 (that means the address is assigned by SLAAC (via router advertisement), and the client/phone can request additional information using stateless DHCPv6 information request as described in RFC 3736 if necessary. This is signaled in the router advertisement using the O (Other Configuration) Flag.

We haven't tested DHCPv6 in this mix so far, but up to the latest 35.73.* versions this worked quite well. The phone got an IPv4 address from DHCP, an IPv6 address from SLAAC and was contacting dualstacked SIP servers via IPv6.

With all 35.80.* versions the phone does assign an IPv6 address from SLAAC (it is pingable and the Web GUI is reachable on that address), but the SIP part does not seem to accept it. The phone is only doing A DNS queries for the SIP servers (not AAAA), is connecting to dualstack SIP servers using IPv4 and cannot connect to IPv6 only servers at all. Additionally it is regularly sending out stateful DHCPv6 solicitations despite stateful DHCPv6 not being enabled in this network.

Can anyone from Yealink shed some light on this. SLAAC with stateless DHCPv6 would be our preferred operating mode.

Note that I am not sure whether 35.73.* did everything correctly here, as we didn't test IPv6-only operation with stateless DHCPv6 so far. But dualstacked with SLAAC did work.

Thanks,
Bernhard
Shortened tcpdumps, can send full dumps by PM if necessary

35.73.0.50:

Code:
# IPv6 router solicitation
10:55:52.673427 IP6 fe80::215:65ff:fe6e:b26c > ff02::2: ICMP6, router solicitation, length 16
10:55:54.765707 IP6 fe80::a0ca:39ff:fe00:6 > ff02::1: ICMP6, router advertisement, length 64

# Also sending stateful DHCPv6 request and not getting an address back
10:56:19.480564 IP6 fe80::215:65ff:fe6e:b26c.546 > ff02::1:2.547: dhcp6 solicit

# AAAA DNS queries over IPv4 transport (DNS servers assigned by DHCPv4) for both identities
10:56:51.332658 IP 192.0.2.205.56151 > 10.156.33.53.53: 10118+ AAAA? voip-fs.domain. (41)
10:56:51.333535 IP 10.156.33.53.53 > 192.0.2.205.56151: 10118* 1/4/7 AAAA 2001:db8:0:101::81bb:a21 (311)
10:56:51.511671 IP 192.0.2.205.55334 > 10.156.33.53.53: 42611+ AAAA? secureV6.dus.net. (34)
10:56:51.512742 IP 10.156.33.53.53 > 192.0.2.205.55334: 42611 1/4/6 AAAA 2a04:2100:0:100::73 (273)

# SIP/TLS Connection established over IPv6 to both identities
10:56:51.542807 IP6 2001:db8:0:ff00:215:65ff:fe6e:b26c.54067 > 2001:db8:0:101::81bb:a21.5061: Flags [S], seq 3913542321, win 5760, options [mss 1440,sackOK,TS val 4294944410 ecr 0,nop,wscale 2], length 0
10:56:51.725958 IP6 2001:db8:0:ff00:215:65ff:fe6e:b26c.54063 > 2a04:2100:0:100::73.5061: Flags [S], seq 4088716600, win 5760, options [mss 1440,sackOK,TS val 4294944429 ecr 0,nop,wscale 2], length 0

Compare this to 35.80.0.125:

Code:
# Router solicitation
10:42:49.141320 IP6 fe80::215:65ff:fe6e:b26c > ff02::2: ICMP6, router solicitation, length 16
10:42:49.255058 IP6 fe80::a0ca:39ff:fe00:6 > ff02::1: ICMP6, router advertisement, length 64

# Stateful DHCPv6
10:42:52.060120 IP6 fe80::215:65ff:fe6e:b26c.546 > ff02::1:2.547: dhcp6 solicit

# A DNS query for first identity, connect via IPv4
10:43:19.746376 IP 192.0.2.205.49881 > 10.156.33.53.53: 38900+ A? voip-fs.domain. (41)
10:43:19.747409 IP 10.156.33.53.53 > 192.0.2.205.49881: 38900* 1/4/7 A 192.0.10.33 (299)
10:43:19.752635 IP 192.0.2.205.11880 > 192.0.10.33.5061: Flags [S], seq 3550190186, win 5840, options [mss 1460,sackOK,TS val 4294944634 ecr 0,nop,wscale 2], length 0

# A DNS query for second identity (IPv6-only), getting NODATA, not connecting at all
10:43:19.940542 IP 192.0.2.205.37345 > 10.156.33.53.53: 12679+ A? secureV6.dus.net. (34)
10:43:19.941247 IP 10.156.33.53.53 > 192.0.2.205.37345: 12679 0/1/0 (94)

So basically
  • both versions are (wrongly) attempting stateful DHCPv6 when stateless DHCPv6/SLAAC are advertised
  • SLAAC should be a third option for network.ipv6_internet_port.type =
  • or better: SLAAC/stateless DHCPv6 vs. stateful DHCPv6 should be autodetected from router advertisement
  • 35.73.* uses IPv6 from SLAAC even if no DHCPv6 lease is received
  • 35.80.* does not use IPv6

It might possibly use IPv6 if a stateful address is assigned, I'll test that later.[/code]
So I've enabled stateful DHCPv6 on this network, the phone is getting an address but still not connecting over IPv6. It is not a corner case, but just plain broken.

Please fix this.
(06-21-2016 07:36 PM)bschmidt Wrote: [ -> ]So I've enabled stateful DHCPv6 on this network, the phone is getting an address but still not connecting over IPv6. It is not a corner case, but just plain broken.

Please fix this.

We are testing the T48G IPV6 with SLAAC only, it gets an address fine but will not connect to the sip server using the servers IPV6 address. I did not try the older version, also on the firmware 35.80.0.125.
Just an update in case it's useful to someone: The T48Gs are now working fine with IPV6. They get their addresses via SLAAC which was working fine. My problem seemed to be that the IPV6 address I put into the server field had an incorrect format at the end. Once I testing pinging the server from a computer and put that exact string into the phone server field it worked fine. So far T48G IPV6 looks very good.
Reference URL's