Sky rolling out Broadband - made for Entertainment

Forums › New Zealand Broadband › Sky rolling out Broadband - made for Entertainment

1 | 2 | 3 | 4

1456 posts

Uber Geek

ID Verified

Lifetime subscriber

#2679993 24-Mar-2021 20:15

Silly question perhaps but are there any plans to offer just Broadband (as that could put SKY in the running for broadband for our new build later this year) or is the intention to only provide service to those who also subscribe to other SKY services?

Is dual-stack IPv6+4 provided over PPPoE? Asking as I know Vocus does not usually offer IPv6-over-PPPoE via their own brands (at least for Slingshot which is IPv4 PPPoE or dual-stack IPv4+6 DHCP) so curious to see if you're using the same config as Vocus or something different.

frudrew

143 posts

Master Geek

#2680016 24-Mar-2021 21:08

Have been a long suffering sky customer for years (I know... but I pay for my folks)
Hopefully we'll get the offer soon!

fe31nz

1232 posts

Uber Geek

#2680113 25-Mar-2021 01:09

Sky's pricing is very attractive, but I do have a few questions:

1) How are you handling the IPv6 problems with PPPoE? The IPv6 RFCs require that over long dropped packets result in an ICMPv6 "packet too long" packet is sent back to the source telling what happened. This is mandatory. But all the PPPoE software I have ever met fails to do this and silently drops over long IPv6 packets. This breaks the IPv6 path MTU discovery mechanism and stops IPv6 connections from working as soon as a single full size packet gets sent. The usual result of connecting IPv6 over a PPPoE connection with an MTU of less than 1500 is that you get screams from the teenagers that Facebook has stopped working, because Facebook is fully IPv6 capable and its front page sends full length IPv6 packets when you log in. It is possible to get your router to advertise (in its IPv6 router advertisement packets) that it uses an IPv6 MTU that is smaller so that over long packets do not happen. But doing that also results in the smaller MTU also being used for all your home network's internal IPv6 traffic, which is inefficient and less than ideal.

To help with problems like this, Chorus provides overprovisioning on all fibre connections so that the Ethernet and VLAN 10 connections can be set to MTU 1508 and hence the PPPoE connection can run at the full default MTU of 1500. If you use that setup, full length IPv6 packets are not over long and pass over the PPPoE interface without problems. But the Sky website is saying "MTU 1492" which implies that Sky is not making use of this overprovisioning. Even for IPv4, an MTU of 1492 is not ideal as all long IPv4 packets (1493-1500 bytes) will need to be fragmented to pass over the PPPoE connection. Fragmentation of packets typically is not able to be done by the router's hardware offloading, so it gets done on the CPU. So for a full speed connection using full length IPv4 packets, it is likely that the CPU will wind up handling all the packets with no hardware offloading being done, and that is likely to be more than the CPU can actually do and the connection speed will be reduced, as well as the starting of new connections being slowed down by all the CPU activity.

So if I were to use my Edgerouter 4 instead of the Sky router, and I tried to use the overprovisioning and set the PPPoE MTU to 1500, would that work? Or does the Vocus network not support that?

2) I run my own home servers, including public (non-recursive) DNS, web, FTP and email. At a minimum, that requires static IP addresses for both IPv4 and IPv6 - it does not work if your master DNS server changes IP address, ever! So is Sky intending to make IPv6 allocations static? If so, when? And why on earth are Sky's IPv6 addresses dynamic? The RFCs defining IPv6 make it very clear that it is intended that all IPv6 allocations be static. There are enough IPv6 addresses that there is never a need to do dynamic allocation of them.

3) What size IPv6 address allocations are Sky providing? /48 (the RFC recommended size)? /56? Something in between? Will that change when/if you start doing static IPv6 addresses?

4) For a home email server to work these days, it needs to be sending emails via a recognised email server. If I send email directly from my own IP address rather than relaying via my ISP's email servers, the address gets checked by lots of receiving email servers and they see that it is not a recognised valid email server address and reject the email. So does Sky (or Vocus for Sky) provide an email server for relaying customer emails?

kelots

48 posts

Geek

Trusted

Sky Broadband

#2680146 25-Mar-2021 08:43

kelots, would you be willing to promise that no existing customers will be booted onto a CG-NAT IP in the future, at least by providing free public IPs to those who request?

We'll likely do something along these lines, but until we put the plan together on how we'll make this change in future I can't guarantee it 100% incase there are any unavoidable constraints or if it occurs when I'm not working here for some reason!

I will say that this certainly is the intent, as I don't think it would be fair to effectively lift the price by $10 for anyone who requires a public IP mid contract.

Silly question perhaps but are there any plans to offer just Broadband?

Absolutely! While the focus initially is on providing high quality internet to our existing customers, we're here to establish ourselves as a broadband provider.

Is dual-stack IPv6+4 provided over PPPoE? Asking as I know Vocus does not usually offer IPv6-over-PPPoE via their own brands

Yep

fe31nz

Most of this is a bit out of my depth so have reached out to the network team, but sharing a few comments

#1 1492 MTU issues on v6

I've not observed these types of performance issues in the time I've been on the trial and I've not seen it in the feedback from our customers/staff either. Most trialists are using our routers and the customers using 3rd party devices havn't reported issues like this.

I'll look into this a bit further however and keep a close eye out for issues of this type thanks.

#2 static v6

I get what you mean, I'll look into this and get back to you when we firm up our plans here

#3 What size v6 allocations

/56

#4 Email server

We are not currently offering an email server and don't have plans too sorry!

I'll get back to you in general later today!

Evan

Product Owner | Sky Broadband

vexxxboy

4244 posts

Uber Geek

#2680168 25-Mar-2021 09:32

nztim:

kelots:

Voice runs off the ONT

This is very attractive

not when they will charge 17 cents a minute for all domestic calls not in your area

Common sense is not as common as you think.

nztim

3819 posts

Uber Geek

ID Verified

Trusted

TEAMnetwork

Subscriber

#2680238 25-Mar-2021 11:12

vexxxboy:

not when they will charge 17 cents a minute for all domestic calls not in your area

I am referring to the technology used to deliver voice services - Voice over the RGW means you cant poke/prod/change your router without interfering with Voice

Voice over the ONT is clean and simple and means it is not dependent on any other equipment in your location

Any views expressed on these forums are my own and don't necessarily reflect those of my employer.

frudrew

143 posts

Master Geek

#2680376 25-Mar-2021 13:45

Lol, I was looking forward to it.

Judging by some of the comments I might skip :)

Quic Broadband

Move to New Zealand's best fibre broadband service (affiliate link). Free setup code: R587125ERQ6VE. Note that to use Quic Broadband you must be comfortable with configuring your own router.

dolsen

1476 posts

Uber Geek

Trusted

Lifetime subscriber

#2684749 31-Mar-2021 13:30

Well I, for one, am looking forward to My Republic no longer being able to have all over their advertising that they are New Zealand's fastest ISP...

HellraiserNZ

110 posts

Master Geek

ID Verified

#2704239 10-May-2021 08:06

Well its been over a month and no response from @kelots to any of the follow ups he promised... hopefully there's a better presence on GZ from some sky broadband representative.

kelots

48 posts

Geek

Trusted

Sky Broadband

#2705300 10-May-2021 11:13

Thanks for the reminder, i had raised the question about MTU on IPV6 internally and had some internal discussion, but didn't have an answer substantial enough to warrant a post here. I have chased up and will respond once i have my head around it.

Can update ipv6 static IP's is on the roadmap, but not part of our launch products

I think that was the 2 outstanding actions, let me know if i missed one!

Evan

Product Owner | Sky Broadband

HellraiserNZ

110 posts

Master Geek

ID Verified

#2705827 11-May-2021 08:23

kelots:

Thanks for the reminder, i had raised the question about MTU on IPV6 internally and had some internal discussion, but didn't have an answer substantial enough to warrant a post here. I have chased up and will respond once i have my head around it.

Can update ipv6 static IP's is on the roadmap, but not part of our launch products

I think that was the 2 outstanding actions, let me know if i missed one!

Thanks @kelots. I see its live now for people to subscribe to!

kelots

48 posts

Geek

Trusted

Sky Broadband

#2705887 11-May-2021 10:30

So after a chase up, below i'll quickly paraphrasing what my team here have said:

IPv6 has a feature that can discover real MTU the server used. Smaller MTU in router only means extra packets for some requests, it shouldn't break communications. Testing on mtu1280.test-ipv6.com confirmed IPv6 MTU discovery works as expected. (Getting 'Packet too big' before fragmenting). There are no broken comms with bigger/smaller server MTU configuration and overall our current configuration doesn't impact the end users experience - this lines up with feedback from our trialists.

For your Edgerouter 4, Jumbo MTU can be enabled only if all the devices in a network support it, we did a quick test with 1508 MTU and it broke communications - but we're investigating internally on why this is.

I'm definitely concerned about the scenarios you outlined (especially facebook issues) and would like to investigate further before we get more customers on (which is beginning now as Hellraizer noted). Any advice on how to replicate/test this that i could share with my team?

Evan

Product Owner | Sky Broadband

fe31nz

1232 posts

Uber Geek

#2706332 12-May-2021 03:09

kelots:

So after a chase up, below i'll quickly paraphrasing what my team here have said:

IPv6 has a feature that can discover real MTU the server used. Smaller MTU in router only means extra packets for some requests, it shouldn't break communications. Testing on mtu1280.test-ipv6.com confirmed IPv6 MTU discovery works as expected. (Getting 'Packet too big' before fragmenting). There are no broken comms with bigger/smaller server MTU configuration and overall our current configuration doesn't impact the end users experience - this lines up with feedback from our trialists.

For your Edgerouter 4, Jumbo MTU can be enabled only if all the devices in a network support it, we did a quick test with 1508 MTU and it broke communications - but we're investigating internally on why this is.

I'm definitely concerned about the scenarios you outlined (especially facebook issues) and would like to investigate further before we get more customers on (which is beginning now as Hellraizer noted). Any advice on how to replicate/test this that i could share with my team?

Evan

The MTU problems with IPv6 only happen with PPPoE - all the PPP software I have met is broken for IPv6, as it fails to obey the basic rule for IPv6 which requires that it sends an ICMPv6 packet whenever a packet that is too big is dropped. IPv4 does not have this requirement as it just fragments oversize packets automatically and sends on two smaller packets. But doing that causes overheads in the router as fragmentation is not done in the fast routing hardware, so the big packets all have to be sent to the router's CPU for fragmentation to be done. And router CPUs generally can not handle doing fragmentation at full line speed, so an IPv4 connection that is sending full size packets all the time will normally cause a significantly slower connection speed due to CPU being flat out and unable to handle the packets fast enough. That then also affects the first packet of all new connections as the first packet always needs the CPU to set up the fast routing hardware to handle the new packet stream. Your team's comment about MTU path discovery is correct, but the MTU discovery mechanism relies on getting ICMPv6 "Packet too big" responses for over large packets. Since that does not happen from the PPP software, IPv6 MTU path discovery is broken by that and the sending end will keep on sending over large packets that will all get dropped at the PPP interface. IPv4 optionally also can do MTU path discovery, and good TCP/IP stacks do that. But if it fails because of the broken PPP implementation, IPv4 will just fall back to fragmenting the packets and keep on going, with a slightly slower connection speed.

Since you have said that you are using PPPoE/VLAN 10 just like my 2Degrees connection, then you will be affected by this IPv6 PPP bug, unless the routers you are providing have had a fix in their PPP code (and I do not know of any router that has such a fix). Even then, you will be affected in the case of anyone using their own routers. However, the common workaround for this problem does work, so I expect that is what your routers are doing. I am sure your IPv6 users would have noticed by now and told you if Facebook was not working! The workaround sets the MTU for IPv6 8 bytes lower (to 1492) in order to allow for the extra 8 bytes of the PPP headers that get added over the PPPoE connection and removed on the other side. This same MTU fix really ought to be used for IPv4 also to prevent the slowdown of streams of full size packets. The problem with setting the MTU to 1492 is that it causes all IPv6 packets on the LAN side of the router to also be restricted to using MTU 1492 as that is the MTU advertised by the router, so you are slowing down the IPv6 traffic between devices on the LAN side by a measurable amount. IPv4 does not suffer from that problem as it does not use a global MTU setting controlled by the router - each IPv4 connection uses local MTU settings in the devices connecting to each other.

To see if your router is advertising a smaller IPv6 MTU, run Wireshark on something connected to the LAN side of the router and capture the IPv6 Router Advertisement (RA) packets. These are sent out regularly, but the repeat time varies between routers. It may take a few minutes to capture one, unless some device sends a Router Solicitation (RS) packet, so if you want to get an RA immediately, just connect an IPv6 capable device to that subnet and the new device will send an RS and get an RA response. The RA packet specifies the IPv6 MTU in one of its optional fields. See here for the RA packet definition:

https://datatracker.ietf.org/doc/html/rfc4861#section-4.2

http://www.tcpipguide.com/free/t_ICMPv6RouterAdvertisementandRouterSolicitationMess-2.htm

In Wireshark, use a capture filter of "icmp6" and a display filter of "icmpv6.type==134" to see just the RA packets.

But the proper fix is to set the MTU of both the WAN Ethernet connection and WAN VLAN 10 connection to 1508. That allows the PPPoE MTU to be set to the standard Ethernet setting of 1500. Since Chorus are well aware of this problem, they have overprovisioned all their fibre connections so that an MTU of 1508 is available on the ONT Ethernet ports. So you should be using that - anything else is a compromise that reduces the maximum speed of connections using large packets. It does depend on your router's PPP code being the later version that supports larger MTUs, but most routers now have that version of PPP as it has been around a long time now.

The FritzBox routers supplied by 2Degrees are automatically configured to use MTU 1508, but I am not sure it that is the native defaults of the FritzBoxes or whether it comes as part of the default 2Degrees configuration that they load into them. Most routers default to MTU 1500, and only some support MTUs up to 1508, even if they have the later PPP code, as their GUI or settings management does not permit > 1500 to be set. Such routers can only use the workaround to make IPv6 work correctly. Should your routers be of this type, please ask their manufacturer to fix them to support MTUs up to 1508.

The other end of the PPP connection where the client PPP connections are terminated in your ISP routers also needs to support the MTU 1508 option, but as far as I know the routers used for this purpose (eg Cisco, Juniper, ...) all support this. It does need to be enabled in their settings though, or in the Radius database if you are using that.