cancel
Showing results for 
would you rather see results for 
Did you mean: 
Need help?

When will TalkTalk support IPv6

ANSWERED
Reply
stoatgobbler
Super Duper Contributor

 > I was actually told in an online chat that TalkTalk Business products supported IPv6 but I think the person was a bit confused by what IPv6 is.

 

I think so. I've been told the exact opposite by TT business recently.

 

It cost them the opportunity to bid on a seven-figure contract too.

 

 

"OK, now you need to reboot your computer. .... Um, sir, please stop kicking it."
www.deadtroll.com/index2.html?/video/helldeskcable.html~content
aoxm84
Problem Solver

For what it's worth, TalkTalk do own a large block of IPv6 addresses: 2001:7e0::/32 (that's a total of 79228162514264337593543950336 IP addresses).

 

Of course, what's of more interest is what TalkTalk are planning to do with them, and when.

stoatgobbler
Super Duper Contributor
That ipv6 /32 is so old it's registered to Opal Telecom - a little digging shows it was allocated on May 30th, 2002. They're not showing up in global BGP tables, so the apparent answer is "not much"
"OK, now you need to reboot your computer. .... Um, sir, please stop kicking it."
www.deadtroll.com/index2.html?/video/helldeskcable.html~content
aoxm84
Problem Solver

@stoatgobbler wrote:
That ipv6 /32 is so old it's registered to Opal Telecom - a little digging shows it was allocated on May 30th, 2002. They're not showing up in global BGP tables, so the apparent answer is "not much"

 

Where did you get the registration date and BGB table data from? Sounds interesting.

stoatgobbler
Super Duper Contributor

The allocation date is on the RIPE allocation summary page (It's in yyyymmdd format in the notes)

 

I was wrong about bgp adverts - it is being advertised but the major transit points don't list it because it generates no traffic.

 

 

"OK, now you need to reboot your computer. .... Um, sir, please stop kicking it."
www.deadtroll.com/index2.html?/video/helldeskcable.html~content
aoxm84
Problem Solver

Ok, thanks.

aoxm84
Problem Solver
stoatgobbler
Super Duper Contributor

Sky is not TT (they resell BT, which has rolled out IPv6) and no sign of it anywhere inside TT's network (yet)

 

I think there may be some milage in complaining to Ofcom that widespread IPv6 deployment across europe and increasingly so in UK ISPs means that anyone not offering it is not offering "Internet access"

 

I've raised this in the past and they agreed that at some point using the term would require IPv6

 

 

"OK, now you need to reboot your computer. .... Um, sir, please stop kicking it."
www.deadtroll.com/index2.html?/video/helldeskcable.html~content
aoxm84
Problem Solver

@stoatgobbler wrote:

Sky is not TT (they resell BT, which has rolled out IPv6) and no sign of it anywhere inside TT's network (yet)


 

 

Yes I know. The point I'm making is that a major UK ISP is making a move towards IPv6, and so should TalkTalk.

 

Also, Sky to not resell BT in most cases, they use LLU.

stoatgobbler
Super Duper Contributor

"The point I'm making is that a major UK ISP is making a move towards IPv6 and so should TalkTalk."

 

No argument from this camp.

 

Ofcom are as useless as always, but Trading Standards might get into the loop if enough people complain that Internet includes IPv6 and therefore ISPs are engaging in misleading sales.

 

 

"OK, now you need to reboot your computer. .... Um, sir, please stop kicking it."
www.deadtroll.com/index2.html?/video/helldeskcable.html~content
aoxm84
Problem Solver

One method AAISP proposed is that customers should complain to their ISPs that they are not providing access to http://www.loopsofzen.co.uk/ (an IPv6 only website) and therefore are not providing full access to the internet.

 

I never went down that road myself, but I like the idea.

zefal
Popular Poster

Any update on this? I assume TalkTalk are not handing out Ipv6 to routers still?

 

I ask because I'm a network engineer and a user had problems with VPN and it looks like it was due to TalkTalk router giving out incorrect IPv6 settings. The superhub was giving out IPv6 LAN addresses but no actually having WAN IPv6 address (what is the point in this?)

 

Real issue though was he was getting IP address but weird fe80::1%12 DNS server which broke our split-tunnel and split-DNS VPN. Turning off IPv6 on the super router which didn't actually stop it from providing rogue IPv6 address to LAN client... but it did stop handing out fe80::1%12 Ipv6 DNS server... and all was working again.

 

I have talktalk at home as well but I have my own router... it doesn't give out IPv6 addresses LAN side unless it gets on on WAN side...which makes sense. What are these superhub things doing???

aoxm84
Problem Solver

@zefal wrote:

Any update on this? I assume TalkTalk are not handing out Ipv6 to routers still?

 

I ask because I'm a network engineer and a user had problems with VPN and it looks like it was due to TalkTalk router giving out incorrect IPv6 settings. The superhub was giving out IPv6 LAN addresses but no actually having WAN IPv6 address (what is the point in this?)

 


 

 

It's quite normal, they are IPv6 link-local addresses. Lots of devices have them now, and if you run ipconfig on Windows you'll see the PC has one too (unless you altered the default IPv6 network settings on Windows).

 

See: http://en.wikipedia.org/wiki/Link-local_address#IPv6

zefal
Popular Poster

Oh sorry I should have clarified, I know what Link local addresses are and they are enabled on most devices... my issue is the super hub is giving out real IPv6 addresses on the LAN even though the WAN interface has none assigned.

 

i.e.

 

Wireless LAN adapter Wireless Network Connection:

 

   Connection-specific DNS Suffix  . : lan

   Description . . . . . . . . . . . : Intel(R) Dual Band Wireless-AC 7260

   Physical Address. . . . . . . . . : FC-F8-AE-76-EB-F2

   DHCP Enabled. . . . . . . . . . . : Yes

   Autoconfiguration Enabled . . . . : Yes

   IPv6 Address. . . . . . . . . . . : fd58:1f28:42db:c000:3087:d7f4:b0ef:5c05(Preferred)

   Temporary IPv6 Address. . . . . . : fd58:1f28:42db:c000:34e8:5e57:7c28:eb2c(Preferred)

   Link-local IPv6 Address . . . . . : fe80::3087:d7f4:b0ef:5c05%12(Preferred)

   IPv4 Address. . . . . . . . . . . : 192.168.1.71(Preferred)

   Subnet Mask . . . . . . . . . . . : 255.255.255.0

   Lease Obtained. . . . . . . . . . : 10 June 2015 09:01:52

   Lease Expires . . . . . . . . . . : 11 June 2015 09:01:52

   Default Gateway . . . . . . . . . : 192.168.1.1

   DHCP Server . . . . . . . . . . . : 192.168.1.1

   DHCPv6 IAID . . . . . . . . . . . : 318568622

   DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-1A-96-27-D0-EC-F4-BB-02-74-71

   DNS Servers . . . . . . . . . . . : fe80::1%12

                                       192.168.1.1

                                       192.168.1.1

   NetBIOS over Tcpip. . . . . . . . : Enabled

 

I said strange fe80::1 because I don't know what the %12 is about but it looks like it is windows appending that?

 

Turning off IPv6 on the superhub stopped it giving out this fe80::1 address for DNS server and my issues went away... however even with IPv6 "turned off" the laptop was still getting the fd58 address.

 

I'm trying to work out what these super routers are doing!

aoxm84
Problem Solver

Oh right. The fd58 IPv6 is a Unique Local Addresses as opposed to a Link-Local Address. They are somewhat equivalent to the usual 192.168.1.0/24 addresses used in IPv4 NAT.

 

The issue is probably that some software attempts to route globally using the Unique Local Address, but it should not attempt to do that.

zefal
Popular Poster

Ah perfect thank you - completely forgot about ULA. Now to work out why the super router is handing those out...

aoxm84
Problem Solver

Possibly the router hands out ULAs when an IPv6 WAN IP is not available, in an attempt to support IPv6-only clients (a very rare scenario, but you never know). That said, the IPv6 clients still could not route globally, so I agree the decision to use ULAs is somewhat questionable, and it would probably be better for the router just to hand out IPv4 addresses to clients until a WAN IPv6 address was assigned to the router.

zefal
Popular Poster

You are probably right, I can confirm that the client was not able to router IPv6 globally with that ULA address assigned. It was able to resolve IPv6 addresses though...just unable to router there as expected. Thanks for taking time to discuss this with me.

 

My issue is that with this non-routable ULA configuration it kills internet for split-tunnel and split-dns VPN config (Cisco AnyConnect SSLVPN).

 

So to confirm, TalkTalk still definitely don't hand out IPv6 addresses and the superrouters are handing out ULA addresses when they don't get IPv6 addresses on WAN side...

LumKitty
Conversation Starter

The % is the zone index, which is basically the interface name. On windows it corresponds to the interface number, on linux it would be e.g. %eth0. It's because all link local addresses are in the fe80:: range and so the OS needs a bit of help knowing which interface to use.

 

Also if your VPN setup is failing because a user's LAN has IPv6 enabled then I would suggest the issue is with your VPN software, not with TalkTalk's router. Sure getting local DNS over IPv6 when there is no actual connection is a bit weird but it's a perfectly valid setup.

 

IPv6 on local LANs is going to become increasingly common over the next few years and users with actual working IPv6 setups are going to be unhappy about disabling it on their network just to connect to a VPN.

aoxm84
Problem Solver

Yes, it is worth raising this with Cisco since if ULAs are breaking their VPN software they need to fix it.