V6 on the TG589 v3
Quote from: MJN
Quote from: Bob I enabled the IPv6 PING responder in the router and assumed that would be sufficient?
That would only enable the ping responder service in the router, and perhaps accomodate it in the firewall, but it will only be valid for the router's address(es) and not those of any of the clients.
That's all I'm trying to achieve really just to compare latency to the router vs. IPv4.
Quote from: MJN
Quote I've changed the IP to the one my machine's using for lookups (presumably that's the address of the router?) and the TBB monitor's working now
Presumably that is the global IPv6 address of the router's LAN interface (ending fe97:fe70) and by lookups you mean DNS lookups?
Yep, that's the one.
Quote from: MJN Also, and this is going to trip many people for a long time to come, renewing IPv6 with ipconfig is actually done with: ipconfig /renew6
Sneaky eh?!
That's two things I've learnt in the space of a day!
Quote from: MJN
Quote Can't get to any of these sites (and probably loads of others). Tried multiple browsers and they just sit there trying to load:
http://www.thinkbroadband.com/
http://ipv6-test.com/
http://facebook.com/
http://www.moneysavingexpert.com/
http://www.ipv6forum.com/
https://adblockplus.org/
The IPv6 tests at testmyipv6.com still work but the page also still struggles to load in its entirety. This displays my temporary IPv6 address.
Hmm... how odd. I'll avoid temptation to brush the other sites off despite mine working for you as there clearly must be something going on! Just to check, do you get an IPv4 and IPv6 address respectively when visiting here and here? (The DNS for these URLs only have A and AAAA records respectively and so can be useful to check the operation of IPv4 even if it would ordinarily prefer to use IPv6 when both A and AAAA records exist).
Yep, IPv4 for the former and IPv6 for the latter.
Quote from: MJN
Quote IPv6 traceroutes to thinkboradband.com and facebook.com complete successfully
The plot thickens! Interesting, and perhaps telling, that you can traceroute to those two but not connect with the browser. Are you able to try another browser? It could well be that the current browser (what is it?) is remembering (caching?) oddities related to your 'old' setup and struggling to work even with the 'new'. If you were using a tunnel I'd probably be suspecting MTU issues as that can give similar symptoms however as you're native this shouldn't be an issue.
Firefox is my daily driver. Just completely cleared history/cache for Chrome and it's the same. Likewise with Opera which I rarely, if ever use. Add to this the fact that I see similar using myriad browsers on two Android devices (must admit I've not tried any of the iOS7 gadgets yet).
MTU doesn't look as if it should be causing any problems:
{Administrator}=>ip iflist
Interface Group MTU RX TX Admin O
per
1 loop. . . . . . . . . . . . . . local 4096 10 MB 6077 KB UP [
UP]
2 Internet. . . . . . . . . . . . wan 1492 141 MB 11 MB UP U
P
3 LocalNetwork. . . . . . . . . . lan 1500 15 MB 150 MB UP [
UP]
4 TV. . . . . . . . . . . . . . . wan 1500 3864 5296 UP U
P
Quote from: MJN
Quote After that I've a suspicion it's a Wireshark jobby?
Definitely.
I've captured the traffic of an attempt to browse to facebook.com that I'll happily PM across if you fancy your chances at interpreting it? I'm no expert with packet captures but I'm struggling to see anything obvious from the results. I've the raw and IPv6 filtered captures.
We have lift off! 
Your suggestion to bring Technicolor on board was a good one:
[quote author="Technicolor"]You are on VDSL so the main link out of your CPE is PPPoE not PPPoA and this means the MTU is 1492 not 1500.
So your PC will have a MTU of 1500, now on IPv4 packet fragmentation is a normal thing on IPv6 it is not allowed. So I guess your ICMP would be OK due to the small size but the sites are failing due to the packet size.
Try reducing the MTU on the PC interface to 1480 and see what happens!
So...
And like magic, all websites are now accessible! (see attached)
This obviously only fixes access from the desktop. Wondering if it's worth forcing the router LAN MTU to 1492 with:
Quote from: Bob MTU doesn't look as if it should be causing any problems: {Administrator}=>ip iflist
Interface Group MTU RX TX Admin O
per
1 loop. . . . . . . . . . . . . . local 4096 10 MB 6077 KB UP [
UP]
2 Internet. . . . . . . . . . . . wan 1492 141 MB 11 MB UP U
P
3 LocalNetwork. . . . . . . . . . lan 1500 15 MB 150 MB UP [
UP]
4 TV. . . . . . . . . . . . . . . wan 1500 3864 5296 UP U
P
Your suggestion to bring Technicolor on board was a good one:
[quote author="Technicolor"]You are on VDSL so the main link out of your CPE is PPPoE not PPPoA and this means the MTU is 1492 not 1500.
So your PC will have a MTU of 1500, now on IPv4 packet fragmentation is a normal thing on IPv6 it is not allowed. So I guess your ICMP would be OK due to the small size but the sites are failing due to the packet size.
Try reducing the MTU on the PC interface to 1480 and see what happens!
So...
C:\Windows\System32>netsh
netsh>interface
netsh interface>ipv6
netsh interface ipv6>show interfaces
Idx Met MTU State Name
--- ---------- ---------- ------------ ---------------------------
1 50 4294967295 connected Loopback Pseudo-Interface 1
10 20 1500 connected Local Area Connection
12 5 1400 disconnected Local Area Connection* 9
netsh interface ipv6>set subinterface "Local Area Connection" mtu=1480 store=persistent
Ok.
netsh interface ipv6>show interfaces
Idx Met MTU State Name
--- ---------- ---------- ------------ ---------------------------
1 50 4294967295 connected Loopback Pseudo-Interface 1
10 20 1480 connected Local Area Connection
12 5 1400 disconnected Local Area Connection* 9
And like magic, all websites are now accessible! (see attached)
This obviously only fixes access from the desktop. Wondering if it's worth forcing the router LAN MTU to 1492 with:
ip ifconfig intf=LocalNetwork mtu=1492
Ha ha excellent!
You're not going to believe this but I'll say it anyway - I checked out your packet captures and whilst DNS was working fine (over IPv6), along with the initial TCP handshakes with my server and even the HTTP GET request there was nothing more.... no subsequent data. This really does point towards an MTU issue (given that small packet exchanges were no issue) so was going to suggest that's where we went next! Oh well...
Incidentally, for info, in order to reduce loading on routers IPv6 doesn't allow routers to fragment packets any more. Instead, any fragmentation required has to be done by the end hosts. ICMPv6 and Path MTU discovery is meant to ensure that an appropriate MTU is used however that's the theory... In practice it is going to need manual assistance until things mature in that area - particularly in relation to what ICMPv6 traffic should and shouldn't be blocked (it'll need a more granular approach to the common block-everything stance with IPv4 ICMP!).
Yes - worth giving it a try. The router should then announce the MTU in the RA messages and clients will pick it up and set their interfaces accordingly. Given that ICMPv6 'packet too big' messages were, for some reason, not reaching your client it may actually be safer to set it to 1280 as that is the minimum MTU that every IPv6 link needs to support hence will (okay, 'should'!) guarantee you never have any issues. Perhaps just keep that one in your back pocket should you ever need it one day!
You're not going to believe this but I'll say it anyway - I checked out your packet captures and whilst DNS was working fine (over IPv6), along with the initial TCP handshakes with my server and even the HTTP GET request there was nothing more.... no subsequent data. This really does point towards an MTU issue (given that small packet exchanges were no issue) so was going to suggest that's where we went next! Oh well...
Incidentally, for info, in order to reduce loading on routers IPv6 doesn't allow routers to fragment packets any more. Instead, any fragmentation required has to be done by the end hosts. ICMPv6 and Path MTU discovery is meant to ensure that an appropriate MTU is used however that's the theory... In practice it is going to need manual assistance until things mature in that area - particularly in relation to what ICMPv6 traffic should and shouldn't be blocked (it'll need a more granular approach to the common block-everything stance with IPv4 ICMP!).
Quote This obviously only fixes access from the desktop. Wondering if it's worth forcing the router LAN MTU to 1492
Yes - worth giving it a try. The router should then announce the MTU in the RA messages and clients will pick it up and set their interfaces accordingly. Given that ICMPv6 'packet too big' messages were, for some reason, not reaching your client it may actually be safer to set it to 1280 as that is the minimum MTU that every IPv6 link needs to support hence will (okay, 'should'!) guarantee you never have any issues. Perhaps just keep that one in your back pocket should you ever need it one day!
And that's done the trick using:
Working from my smartphone anyway (Nexus 5), I'll shout up if I encounter problems with any of my other devices.
So let's take a look at those commands end-to-end:
Enable IPv6:
Enable DHCP:
Change MTU for IPv6 interfaces to avoid packet fragmentation over VDSL:
Optionally...
Enable ICMP6 response on the WAN interface:
Hopefully that'll help a few people out.
Thanks for all of your help MJN
=>:ip rt6advd ifdetach intf LocalNetwork
=>:ip rt6advd ifconfig intf LocalNetwork linkmtu 1492
=>:ip rt6advd ifattach intf LocalNetwork
Working from my smartphone anyway (Nexus 5), I'll shout up if I encounter problems with any of my other devices.
So let's take a look at those commands end-to-end:
Enable IPv6:
=>ppp ifdetach intf Internet
=>ppp ifconfig ipv6 enabled intf Internet
=>ppp ifattach intf Internet
Enable DHCP:
=>dhcp clientv6 ifconfig intf=Internet listenra=enabled stateless=disabled rapidcommit=disabled leasetime=7200 irt=86400 iana=1 iapd=1 duidtype=duid-llt leasehist=enabled)
=>dhcp clientv6 ifattach intf=Internet
Change MTU for IPv6 interfaces to avoid packet fragmentation over VDSL:
=>:ip rt6advd ifdetach intf LocalNetwork
=>:ip rt6advd ifconfig intf LocalNetwork linkmtu 1492
=>:ip rt6advd ifattach intf LocalNetwork
Optionally...
Enable ICMP6 response on the WAN interface:
=>service system ifadd name=PINGv6_RESP intf=Internet
Hopefully that'll help a few people out.
Thanks for all of your help MJN
Hmm, perhaps not out of the water just yet. My IPv4 download speeds seem to be about half what my IPv6 ones are:
