Sorry in advanced about quoting but I couldn't get single sentences to only quote.

 

> Hi, may I know your internet service provider?

 

leaptel.com.au

 

> Deco IPV6 configuration page is a simplified version to adapt to the phone UI.

 

Ummm, there is virtually no WebUI on the Deco BE65 Pro, although I haven't tried accessing it from my phone to check, what I can see on my laptop only mentions the IPv6 IP on the LAN interface, virtually everything is done through the app, and the app doesn't seem to have all the options you screen shotted.

 

> So it doesn't matter whether Deco could get an IPV6 address or not. As long as it passes the PD from the ISP to the connected clients to format their own IPV6 unicast addresses, the clients are able to use IPV6 service.

 

When I used DCHPv6 on the WAN, routing was happening, and the WAN IP was listed in the app as "::" and didn't show the DNS servers at all.

However when I switched to SLAAC it showed the IPv6 address it got from the ISP, as well as the DNS server addresses.

 

>  it is very likely that the ISP already provides a complete IPV6 address format and a Prefix Delegation, instead of two Prefix Delegations under DHCPV6(one for Deco and one for the connected clients behind Deco).

 

As I understand it, the ISP has set things up so when they get a DHCPv6 request they return a  /64 for the WAN and a /48 for the LAN via PD. Same thing happens for SLAAC requests. There are problems if a router does both however, not sure what the Deco does if it's set to auto, which is why I initially set the router to do DHCPv6, but was getting 20-50% packet loss for whatever reason, so I changed to SLAAC and got the connection reset at the ISP end and that stopped the packet loss.

 

At least one user of the same ISP with TP-Link devices also said they had packet loss using DHCPv6, that went away when they switched to SLAAC.

 

https://forums.whirlpool.net.au/thread/374pr2mk?p=62

 

> Many web servers support both IPV4 and IPV6. If the IPV6 DNS resolution failed, the IPV4 DNS server could resolve the current IPV4 address. In this way, the clients can still access this web server even though there is no IPV6 DNS server.

 

I never tested if IPv6 DNS lookups were working, other than noting it's absence in the app, and due to a number of reasons, like my IPv6 firewall settings getting wiped and the packet loss, so I don't wish to switch back to DHCPv6 just to check.

 

> Currently, the firewall rules of Deco are based on the IPV6 address. I think if the following two red sections didn't change, the firewall profile shouldn't be removed.

 

All you have to do is change the DNS setting from manual to auto, or vice versa, and the firewall rules go away, in fact I think any change to IPv6 internet settings has the same outcome, but I don't want to fiddle cause it's a pain to set it all up again. I want to add a lot more allow rules for my servers on the LAN but not if I'm going to lose them all each time a change is made.

 

My previous ASUS router only supported DHCPv6, no SLAAC on the WAN, and it was working fine when I replaced it with a pair of Decos.

 

Regards,

Duane

Just logged into the ISP portal and it lists both the /64 and /48 that was requested and replied to for each connection session.

 

2400:a844:x:x::/64    2400:a844:x::/48

 

It only shows the last 10 successful connections but they all list the same details.

David-TP wrote

I'll report the firewall setting issue to the engineers to see if they can reproduce this issue on their end.

 

 "Get IPV6 Address" is set to "Auto" by default. It is compatible with both DHCPv6 and SLAAC. In rare cases, "None Address" was used for some ISPs. The last 64 bits of an IPV6 address(128 bits) are known as the interface identifier, which is derived from the device's MAC address. Usually, if the ISP assigns a /56 prefix or less for the WAN, it is more likely to be DHCPv6 as the ISP needs to maintain the relationship between each user and the prefix they use. 

 

Thanks for the follow-up, it's annoying and tedious to re-enter firewall allows, maybe instead of removing them just change the first 64bits when needed. Also the router seems to block ICMP packets that IPv6 needs to function properly.

 

As for auto I thought that may be the case, but our ISP has pubically stated getting both DHCPv6 and SLAAC requests causes confusion in their routers and they prefer people to use DHCPv6 where possible, and they only have a SLAAC option because current consumer CPEs often default to it, as do PCs/Laptops.

 

Our ISP only does /64 + /48 allocations, and now they are "statically" assigned via PD for free, initially for whatever reason when I joined it was 1 dollar/mon extra, unless you paid more for a statically assigned IPv4.

 

PS your forum thought the dollar symbol + 1 = sensitive information.

 

PPS While trying to diagnose why I was getting weird IPv6 information from our ISP, I disabled and re-enabled IPv6 in their portal and this changed the /48 I was allocated and looking in the firewall/allow list in the Deco app wasn't wiped, but it still lists the old subnet, again updating the first 64bits would be the sane thing to do.

I've now fully tested our ISP connection, bypassing our TP-Link Deco BE65 Pro v1.0 running 1.2.0 firmware, and plugging my laptop directly into the Network Termination Device (NTD) and doing both SLAAC and DHCPv6 connection requests and I'm not seeing any IPv6 packet loss at all.

 

However when the Deco is setup as the primary router connected to the NTD, running mtr -6 ns2 [dot] leaptel [dot] network we get anywhere from 20-50% packet loss on all hops via IPv6, when there is virtually no (0.1-0.2%) packet loss from the router itself, and there is a similarly a small amount (0.1-0.3%) of packet loss doing mtr -4 ns2 [dot] leaptel [dot] network

 

Another weird thing is when using mtr or ping to test to the router's LAN IPv6 IP, it replies with an IP assigned to a Linux server on the LAN, mtr shows all 30 hops replying with the same server IP. With a twist, traceroute to the router IP returns the expected result. I've never seen this happen before. Ping, mtr and traceroute to the the IPv4 LAN address is all correct.

 

Also the TP-Link app has the option to allow ICMP replies to the WAN IPv4 IP, but no such option to allow the same for IPv6 WAN or LAN IPs, and per my previous reply the firewall in the router seems to block all ICMPv6 packets, even the ones needed for IPv6 to function correctly.

 

PS the forum software has problems with writing the correct hostname I obfuscated above to get my reply to post

I'm not sure what's different or has changed but now the IPv6 WAN IP and DNS servers are showing in the app when the router is set to request DHCPv6 via the WAN, and now mtr is reporting just as much packet loss via IPv6 for the router as all the other hops, is it rate limiting or something?

 

Haven't set QoS or anything else as far as I know that would effect things like that.

 

Update: Since re-instating the Deco as the router connected to the NTD and switching from SLAAC to DHCPv6 on the WAN there no longer is any packet loss for IPv6 traffic.

 

I'm at a loss as to what has changed, it's not router firmware cause I disabled auto update but there isn't a newer version anyway, but the IPs now show so something somewhere has changed.

The only other issue I have is the IPv6 firewall allow section only accepting numerical input for port numbers, not ranges like in the IPv4 section.

 

Since whatever changed changed, the router now responds to ping/mtr with it's own IP, not the Linux server.

 

Also there is still a small amount of packet loss, 0.4% after 12,000 packets to each hop to the same hostname, but there was none when my laptop was connected directly to the NTD, so there is something going on with the router still, although probably not enough to impact any real world applications including ssh at this point.