No you're right, the two other sites are unfortunatley using different Draytek routers. One is a 2760 and the other a 2925; both are on their latest respective firmwares. For me this does support WAN IPv6 PPP rather than DHCPv6.
However I have got a couple of packet captures for you (DHCPv6 and PPP) but I seem unable to get Wireshark to just capture IPv6 traffic (or filter out IPv4) so the DHCPv6 capture is close to 5mb in size. I've zipped them up but if you'd prefer direct links to the files let me know.
I did attempt to report this via the Indian Call Centre but after an hour of trying to explain whats happened, I resorted to a VPN Connection to work around this for everything except streaming media..
@jmarden What we're looking for is the DHCPv6 'solicit' and 'advertise' so you could simply enter "dhcpv6" in the filter bar at the top of the Wireshark window and see what you get. There may also be a 'request' and 'reply' depending upon whether the Draytek uses DHCPv6 'rapid commit' or not.
This DHCPv6 exchange is during link initialisation so you'll need to drop the link and re-establish it, or if there's an option on the Draytek to 'renew' the DHCPv6 request, then use that.
To simply see if there's any IPv6 in the 5MB capture then you can filter by putting "ipv6" into the filter bar towards the top of the window. This can be saved separately if you want by File -> Export Specified Packets, give the capture a file name and then select the "Selected Packets" radio button and click save.
@zzz. With your Netgear router are you able to perform similar steps as being done by @jmarden i.e., packet captures. If we can see the DHCPv6 exchange between your routers and the upstream delegating routers we may be able to figure out what's going on, or at least provide a moderator with sufficient information to allow him/her to escalate to the appropriate team in BT.
@jmarden. Thanks. I've been through the two captures from the link you sent over in the PM rather than the one from the link you posted here. For the two captures I looked at I see very different behaviours. Here's what I can see, filtering in Wireshark for "lcp or ipcp or ipv6cp or dhcpv6".
This is chronologically the first capture with timestamps up to 14:28:49.
- Frame 4112 and 4121 show a PPP termination request from the Draytek and acknowledgement from the upstream BRAS/MSE.
- From frame 4127 the Draytek is sending PPP Link Control packets to bring the PPPoE session back up. As expected the IPv4 side of things looks good and you get the IPv4 address and the DNS servers as expected in frame 4142.
- In frame 4135 we see the Draytek send a PPP IPv6 Control Protocol Configuration Request packet. We don't ever see an Acknowledgement which would seem to suggest that the BRAS/MSE you're connected to doesn't support IPv6.
What's also interesting from this capture is that in frame 4160 we see the Draytek send a DHCPv6 Release for prefix 2a00:b1aa:b1aa:f700/56 indicating it had previously been assigned this prefix from a delegating BT router.
Note that in frames 4610 and 4611 we see an IPv6 DHCPv6 Information Request and Reply, but this would seem to be between the Windows client you're running the Wireshark capture on and the Draytek router. I only mention it so it doesn't cause confusion if you look through the captures.
There's little else in here other than the Draytek periodically sending DHCPv6 Release and Solicits and getting no response to either.
File Capture 2860_IPv6_PPP.pcapng
This is chronologically the second with timestamps from 14:31:39, looks completely different to the first and is more like I'd expect.
- In frame 1333 and 1334 we see the the PPP IPv6 Control Protocol Configuration Request packets and the associated acknowledgements in frames 1335 and 1340.
- In frame 1369 we see the Draytek send a DHCPv6 Release for 2a00:b1aa:b1aa:f700::/56 and the reply from the BT delegating router in frame 1370.
- The Draytek sends the DHCPv6 solicit in frame 1406, gets an advertise with prefix 2a00:b1aa:b1aa:f900::/56 in frame 1407, with the final request and reply in frames 1551 and 1553.
If you've not rebooted the router or re-sync'd the line since this last capture I'd now expect (hope) the Draytek to be sending Router Advertisements (RA) on the LAN for 2a00:b1aa:b1aa:f901::/64 and the clients to assign themselves an address from this prefix.
If you run Wireshark on the Ethernet NIC of the Windows client and filter for "icmpv6.type==0x86" do you see the IPv6 RA?
I saw from your post on the Draytek forum that your clients have multiple IPv6 addresses from different prefix, some "Preferred" and some "Deprecated".
Ethernet adapter Ethernet 2: Connection-specific DNS Suffix . : blaa.local [snip] IPv6 Address. . . . . . . . . . . : 2a00:b1aa:b1aa:ec01::1(Preferred) Lease Obtained. . . . . . . . . . : 11 September 2017 12:39:57 Lease Expires . . . . . . . . . . : 18 October 2153 19:29:55 IPv6 Address. . . . . . . . . . . : 2a00:b1aa:b1aa:ec01:e138:90a5:3e6c:e4d5(Preferred) Temporary IPv6 Address. . . . . . : 2a00:b1aa:b1aa:e701:5c1a:576f:ebb3:824e(Deprecated) IPv6 Address. . . . . . . . . . . : 2a00:b1aa:b1aa:e701:e138:90a5:3e6c:e4d5(Deprecated) Temporary IPv6 Address. . . . . . : 2a00:b1aa:b1aa:ea01:5c1a:576f:ebb3:824e(Deprecated) IPv6 Address. . . . . . . . . . . : 2a00:b1aa:b1aa:ea01:e138:90a5:3e6c:e4d5(Deprecated) Temporary IPv6 Address. . . . . . : 2a00:b1aa:b1aa:ec01:5c1a:576f:ebb3:824e(Preferred) Link-local IPv6 Address . . . . . : fe80::e138:90a5:3e6c:e4d5%14(Preferred)
I've noticed with the Windows clients I have here is that they can continue to use a deprecated IPv6 address even though there's a preferred address on the same interface. If you see both preferred and deprecated addresses on the client try disabling and re-enabling IPv6 within the network control panel to clear out all the addresses and start afresh with just addresses from a single prefix.
I don't know how the PPP sessions are shared across available BRAS/MSE, but assuming there are different IPv4 address pools for different BRAS, it seems the two captures show connections to two different BRAS/MSE. In the first capture we see in frame 4141 an IPv4 address of 86.W.X.158, whilst in the second capture we see in frame 1366 an IPv4 address of 81.Y.Z.84. If the address pools are on different BRAS/MSE it may be that the first isn't enabled for IPv6, whilst the second one is.
Looking through the various packet captures and output from the routers of @jmarden and @zzz it would appear that not only are you both in the same area, but that you're both connecting to the same upstream delegating router.
Here's the default route seen in the routing table of @jmarden:
Destination Interface Flags Metric Next Hop ---------------------------------------------------------------------------------------------------- [snip] ::/0 WAN1 UGF 1024 FE80::EA4:2FF:FE3E:1
And here's the default route seen in the routing table of @zzz:
#ip -f inet6 route default from 2a00:b1aa:b1aa:a400::/56 via fe80::ea4:2ff:fe3e:1 dev pppoe-wan metric 512
Given that the link local address shown here is derived by using the prefix fe80:: and then appeding the modified EUI-64 address i.e., a modified MAC address, then this looks suspiciously like the same upstream router.
@JohnC2; @SeanD: Is there any chance someone could pick this up and try and get some escalation with the appropriate team? Seems at least two users in the same area, connected to what appears to be the same BT router are having the exact same problem. This is probably beyond first line helpdesk support.
Reading again the whole thread from the beginning, it seems that at least three users from Bracknell have reported issues with IPv6 - and all three usesrs are connecting to the same link local gateway fe80::ea4:2ff:fe3e:1 (@De_Carabas, @jmarden and I - @zzz).
This link local address is the only IPv6 address, external to my home network, that I'm able to ping and get back response:
# ping6 fe80::ea4:2ff:fe3e:1%pppoe-wan PING fe80::ea4:2ff:fe3e:1%pppoe-wan (fe80::ea4:2ff:fe3e:1%pppoe-wan): 56 data bytes 64 bytes from fe80::ea4:2ff:fe3e:1: seq=0 ttl=255 time=4.935 ms 64 bytes from fe80::ea4:2ff:fe3e:1: seq=1 ttl=255 time=5.122 ms 64 bytes from fe80::ea4:2ff:fe3e:1: seq=2 ttl=255 time=5.393 ms 64 bytes from fe80::ea4:2ff:fe3e:1: seq=3 ttl=255 time=4.905 ms 64 bytes from fe80::ea4:2ff:fe3e:1: seq=4 ttl=255 time=5.175 ms 64 bytes from fe80::ea4:2ff:fe3e:1: seq=5 ttl=255 time=4.913 ms 64 bytes from fe80::ea4:2ff:fe3e:1: seq=6 ttl=255 time=4.905 ms 64 bytes from fe80::ea4:2ff:fe3e:1: seq=7 ttl=255 time=5.365 ms 64 bytes from fe80::ea4:2ff:fe3e:1: seq=8 ttl=255 time=4.884 ms 64 bytes from fe80::ea4:2ff:fe3e:1: seq=9 ttl=255 time=4.908 ms ^C --- fe80::ea4:2ff:fe3e:1%pppoe-wan ping statistics --- 10 packets transmitted, 10 packets received, 0% packet loss round-trip min/avg/max = 4.884/5.050/5.393 ms
@smf22 kindly offered to perform a ping test to one of his IPv6 hosts (within BT's network, that is). This is the result (obfuscated) of the ping6 command that I issued twice:
# ping6 2a00:23c5:dead:beef:250:c0ff:ee90:6f19 PING 2a00:23c5:dead:beef:250:c0ff:ee90:6f19 (2a00:23c5:dead:beef:250:c0ff:ee90:6f19): 56 data bytes ^C --- 2a00:23c5:dead:beef:250:c0ff:ee90:6f19 ping statistics --- 12 packets transmitted, 0 packets received, 100% packet loss # ping6 2a00:23c5:dead:beef:250:c0ff:ee90:6f19 PING 2a00:23c5:dead:beef:250:c0ff:ee90:6f19 (2a00:23c5:dead:beef:250:c0ff:ee90:6f19): 56 data bytes ^C --- 2a00:23c5:dead:beef:250:c0ff:ee90:6f19 ping statistics --- 11 packets transmitted, 0 packets received, 100% packet loss
All packets got lost and the capture that @smf22 performed didn't contain any packets with source address of my end.
So I'm back to where I was at the beginning (4 months ago) - no working IPv6.