Is the IPv6 address I get static?

[Anonymous]

Looking at the configuration dump of a fresh router that has never before been connected, I see a global IPv6 /56 routed prefix hard coded into it. Does this mean that my IPv6 assignment is static? I doubt it because while waiting for a replacement router I used an OpenWrt device to get by and it would get a different v6 IP via DHCPv6 every time it rebooted. If the IP is indeed static to that particular router, is there a way to change that behaviour to dynamic DHCP6 assignment of the routed prefix? If not then it's fine.

[jamesn123]

@Anonymous 

As far as I know its dynamic, Sky dont offer static IPs and dont issue them by default 

[Anonymous]

So, I have the latest greatest Wifi setup, the speeds I get over my WLAN/LAN through Wifi are better than direct Gigabit ethernet. The weak link in that chain is the Sky Hub, it's only ac 80MHz bandwidth and far inferior to the rest of the WLAN. Right now I have all its Wifi turned off and my super-duper wifi router plugged into it in access point mode and all is good. The issue I'm having is that the hub's Wifi decides to turn itself back on after a reboot. With the two devices so close to each other this is impacting the MIGHTY router's performance and the two seem to keep getting into a "channel battle" causing my mega router to drop down in bandwidth. How do I get the Sky hub's Wifi to stay turned off?

[Anonymous]

Thanks for replying. I was pretty sure it was going to be dynamic, but with IPv6 you never know. Their rules for static IPs on v4 may not apply to v6 as there's so much address space available they could have statically hard coded every router for the sake of convenience. If it's dynamic then there's no issue, that's what I wanted.

[jamesn123]

@Anonymous 

The WiFi should stay switched off after a reboot if thats how you have set it. If it isnt that suggests you have a faulty router or dodgy firmware as its not saving your settings in persistent storage. Either way I'd seek a replacement from Sky. 

[Mr+Slant]

The "hardcoded" IPv6 address on the router you see is labelled "ULA" yes?

Its a "unique local address", not a global address.

Have a search around but the tl;dr is that it helps keep your IPv6 clients communicating on the LAN when your WAN (internet service) is down. Various client implementations (Android/Apple/whatever) have historically had issues when the WAN goes down then comes back up with a different IPv6 PD. ULA can help to ameliorate these issues. Or complicate them - depends on how broken the client implementation was in the first place (some IoT devices have hideously broken IPv6 stacks). Edit - I rather suspect Sky uses the ULA to maintain firewall rules in IPv6 somewhat gracefully between WAN down/up events but there's no visibility of that on their routers.

On Sky the IPv6 PD is what I'd call "sticky". You're unlikely to get assigned a new PD lease unless you connect/disconnect a lot of times over 24 hours. IPv4 is a lot less "sticky".

[Anonymous]

No it's the global prefix, starts with 2a02: and ends with ::/56

The line in the config file

<X_BROADCOM_COM_IPv6SitePrefix>2a02:[redacted]00::/56</X_BROADCOM_COM_IPv6SitePrefix>

[Anonymous]

A /56 prefix gives you 256 subnets to use. When I plug a 3rd party router into the ONT I am able to use and route those subnets with no problem. However the Sky hub won't route anything but the 00 subnet. This is annoying because I have use cases for them. It seems a waste to give consumers 72 bits of address space but only allow them to use 64.

[Mr+Slant]

That's never going to happen due to the support issues it'd cause.

[Anonymous]

I am seeing many reports from Sky users reporting slow fibre speeds. This includes me, the maximum speeds I was getting on downloads was 4MB/s. At first I just put this down to the speed of the server I was downloading from and every speed test I ran gave me a high speed, 130-150 Mb/s (I'm on a 150Mb/s line). Now something about those speed tests was fishy, this has been reported in other threads too, it starts by shooting up to around 30-40 Mb/s stays there for a while and then ramps up to a higher speed. This is NOT how a speed test should run and it made me VERY suspicious. My initial hypothesis was that Sky is limiting to slow speed and only ramping it up when it detects it needs to do so. If this is the case it is a clear violation of contract. So I decided to run my own test. I started to download a large file; a linux ISO, about a 5GB file. Sure enough it was coming down at 4MB/s. Then I opened a new tab and started to run a speed test. Again the test started low and then began to start ramping up. At this point I closed the speed test and checked the download speed of the big file I was downloading. It started to shoot up, it got to 9MB/s before it started falling back down to 4. I tried this a few times, a couple of times the download speed didn't shoot up but all other times it did.

I won't say this is proof, but it's stong evidence in favour of deceptive behaviour from Sky here. I'd like some clarification from them about exactly what it is they're doing that is causing this, maybe it's perfectly innocent, I don't know. But from the tests I have done it's not looking good. I know that's not going to happen here as everyone is a consumer, but I will be contacting them about this tomorrow.

I've only just signed up for a new contract so I am within my cool-off period, so for me it is easy to switch. For anyone else mid-contract it'll be more tricky. If however Sky are doing what I suspect they're doing, it's basically misrepresentation and will render a contract void.

[Anonymous]

Further testing reveals this is likely only an issue on IPv4. I saw another post claiming their speed went up after connecting to a VPN. Well I have my own personal VPN so decided to try this. Everything was still the same, download speeds at 4MB/s, speed test behaviour the same. This leads me to believe there is no "speed-test" detection as VPN traffic is encrypted and they wouldn't be able to infer anything from it other than a bunch of UDP packets to and from a single IP.  So my suspicion in that area is somewhat lessened. However, I can connect to my VPN via IPv4 or IPv6, I have it setup for both, so I connected using IPv6. Hey presto, speed tests behave like they're supposed to, high speeds and downloading is at 10+MB/s.

So whatever it is they're doing only seems to affect the IPv4 side of things. To me now, it's looking less nefarious and more a question of incompetence to be brutally frank.

[Anonymous]

Okay, been messing with this in all sorts of ways and I'd like to forward a hypothesis.

Normal internet usage is not going to push a high-speed connection. For just standard browsing, YouTube etc.. the difference between a 30Mb/s connection and 500Mb/s would probably not be noticable. It's latency that makes the difference there, not so much speed. So what I think is going on is this. Sky are limiting the speed of connections to a lower level , 30-40Mb/s it seems. Then if the connection tops out and stays topped out for a set period,  they lift the limit and allow full speed. This would explain the "lag" when performing a speed-test. It would also explain why it only seems to be happening on IPv4 as the protocols and supporting software for doing this sort of thing are very different. for both protocols and they've probably only got it setup for IPv4 currently. I suspect that it's some kind of "trial" and it simply isn't working properly, which is causing a lot of folk to be experiencing the slow speed all the time. 

Like I say this is only a hypothesis based on the testing and evidence I've gathered in this short period.

[Anonymous]

Not really, normal users would never even know about it or attempt it, it wouldn't generate a single support request from any of them. Only advanced users who know what they're doing would set it up and they're unlikely to need any support and those that do would be very few. So that reasoning is IMO faulty.

[Mr+Slant]

You don't know Sky matey, its never ever going to happen.

[Anonymous]

Well hate to contradict you but it is happening. I figured out how to do it earlier. It's the Sky Hub that prevents it, but it's not by design by the look of it. It's just a consequence of how the Hub is configured. A few teaks to the dumped config and voila.