[Snap] IPv6 and Snap

Forums › 2degrees (including Slingshot, Orcon, Flip, Stuff Fibre, MyRepublic, 2talk and Vocus) › [Snap] IPv6 and Snap

kyhwana2

2553 posts

Uber Geek

#86416 6-Jul-2011 12:37

Anyone (I guess the Snap guys would know this. ;) know if Snap is looking at offering native IPv6 on their DSL plans any time soon?

I'm currently running a Cisco 877 on Xnet with their v6 trial. Looking at Snaps Naked DSL plan, it's $15 cheaper and includes 5GB of data.

1 | 2 | 3

2553 posts

Uber Geek

#491416 9-Jul-2011 14:16

Ah, this is the reply I got from SNAP support:

"Thanks for your query,

Unfortunatly, we are currently not trialing IPV6 as it doesn't work over ATM which the majority of Telecom's equipment uses. I also have no idea when Telecom will be updating to allow this, so no dates on when and if we will be trialing it in the future unfortunately. "

Uhm what. IPv6 is a few layers above ATM. You can do v6 over BUBA and EUBA (inside PPP) and most ISPs should be moving people to EUBA anyway. So it's unfair for SNAP to pass the buck to Telecom on this one.

I think they're just being lazy/not wanting to spend money or time (or trying to find an engineer who can do it) to upgrade their hardware/support/billing/etc. Seems like this is the case with most ISPs.

(For the record, XNet can do v6 over EUBA just fine.)

Backblaze

Backblaze Unlimited Backup. World’s easiest cloud backup. Get peace of mind knowing your files are backed up securely in the cloud (affiliate link).

Ragnor

8085 posts

Uber Geek

Trusted

#491436 9-Jul-2011 15:54

Blame Telecom is the go to standard response from every ISP when they haven't bothered to implement something new yet.

The real reason of course is an obvious business reason, lack of demand for it.

kyhwana2

2553 posts

Uber Geek

#491440 9-Jul-2011 16:03

Ragnor: Blame Telecom is the go to standard response from every ISP when they haven't bothered to implement something new yet.

The real reason of course is an obvious business reason, lack of demand for it.

Well, they'll be deploying CGNAT soon and then everyone on snap is screwed if they want a public IP (which they won't get, since they don't even have v6!)

jbergler

42 posts

Geek

ID Verified

#491614 10-Jul-2011 12:10

The issue is not directly with telecom's network being ATM based for a large chunk of legacy broadband connection - it lies more around the lack of support in 95% of the CPE's - specifically the ones which dont' support native ethernet over the DSL.

We are working on a V6 DSL offering and hopefully we should be able to begin trialling publicly within 6 - 8 weeks, but I don't expect the uptake to be significant because most users modems wont support it.

kyhwana2

2553 posts

Uber Geek

#491636 10-Jul-2011 13:14

jbergler: The issue is not directly with telecom's network being ATM based for a large chunk of legacy broadband connection - it lies more around the lack of support in 95% of the CPE's - specifically the ones which dont' support native ethernet over the DSL.

We are working on a V6 DSL offering and hopefully we should be able to begin trialling publicly within 6 - 8 weeks, but I don't expect the uptake to be significant because most users modems wont support it.

True, but ISPs are going to have to switch on IPv6 sooner or later, once CPE's start rolling out with support for it. You'd think they'd do this well _before_ they run out of V4, in order to get it tested before they completely run out.

kyhwana2

2553 posts

Uber Geek

#491637 10-Jul-2011 13:14

@jbergler: Also, are you from SNAP or some other ISP?

jbergler

42 posts

Geek

ID Verified

#491640 10-Jul-2011 13:18

kyhwana2: @jbergler: Also, are you from SNAP or some other ISP?

Snap. http://www.snap.net.nz/snap/ourteam

kyhwana2:

True, but ISPs are going to have to switch on IPv6 sooner or later, once CPE's start rolling out with support for it. You'd think they'd do this well _before_ they run out of V4, in order to get it tested before they completely run out.

True - but we've been running IPv6 Natively for over 2 years. A large portion of our ethernet customers have had the option for IPv6 for over a year.

kyhwana2

2553 posts

Uber Geek

#491642 10-Jul-2011 13:26

jbergler:

True - but we've been running IPv6 Natively for over 2 years. A large portion of our ethernet customers have had the option for IPv6 for over a year.

Nice. So you need to sort out billing/support then? (Like most ISPs)
I see you just got EUBA at your auckland handover point up and running?

Is there any timeline for trialling v6 on your DSL customers? Maybe SNAP staff at home? ;)

jbergler

42 posts

Geek

ID Verified

#491644 10-Jul-2011 13:43

kyhwana2:
Nice. So you need to sort out billing/support then? (Like most ISPs)
I see you just got EUBA at your auckland handover point up and running?

Is there any timeline for trialling v6 on your DSL customers? Maybe SNAP staff at home? ;)

jbergler:

We are working on a V6 DSL offering and hopefully we should be able to begin trialling publicly within 6 - 8 weeks, but I don't expect the uptake to be significant because most users modems wont support it.

Short answer - sooner rather than later.

gregb

49 posts

Geek

#491754 10-Jul-2011 20:30

I've been asking Snap regularly for IPv6 over residential DSL. I tend to ring them every month or two and ask similar questions. I don't always get the same answer but I sometimes get new information (some of it being true). One thing that has come up is the lack of a IPv6 address/prefix management database.

In lieu of native IPv6 I have setup a 6in4 tunnel to Sixxs which is provided by ACSdata in Wellington. This provides reasonably latency (way way better than a HE tunnel to the US). It is unfortunate that Snap peer with ACSData at APE even though the tunnel traffic goes to Wellington (WIX). The MTU on this is way less than 1500.

If you want to just setup a simple 6to4 tunnel, then there is a 6to4 anycast server close to Snap (which appears to be run by FX Networks).

My usual set of questions for Snap include, can I please have:

native IPv6

QOS over EUBA

VoIP

What size prefix are Snap looking to give out to customers? What MTU are Snap looking to offer for native IPv6? How are Snap looking to encapsulate IPv6? (PPPoA, PPPoE, IPoE or something else?)

In preparation for native IPv6 (and QoS) I moved to a EUBA configuration. Snap were helpful in getting me moved to a EUBA service. I was disappointed that IPv4 over PPPoE MTU went down below 1500 (Snap said they wanted 8 bytes for QinQ).

The other thing I have noticed is that the Cisco 877 is hitting a CPU limitation of around 11Mbps for IPv4 and I think it is worse for IPv6 (IOS 15.1, ZBFW, PPPoE, NAT). What happens for people that want full ADSL2+ speeds? What Cisco router will handle VDSL2 speeds without breaking the bank?

--

68.16.69.111.static.snap.net.nz (111.69.16.68) 11.656 ms 12.785 ms 13.373 ms
168.19.69.111.static.snap.net.nz (111.69.19.168) 15.312 ms 16.496 ms 17.683 ms
fx.chix.nzix.net (218.100.24.18) 26.018 ms 27.248 ms 28.486 ms
GigabitEthernet0-0-918.wnmur-rt1.fx.net.nz (202.53.187.69) 53.457 ms 259.887 ms 260.388 ms
192.88.99.1 (192.88.99.1) 20.603 ms 20.869 ms 23.281 ms

kyhwana2

2553 posts

Uber Geek

#491758 10-Jul-2011 20:40

gregb:
The other thing I have noticed is that the Cisco 877 is hitting a CPU limitation of around 11Mbps for IPv4 and I think it is worse for IPv6 (IOS 15.1, ZBFW, PPPoE, NAT). What happens for people that want full ADSL2+ speeds? What Cisco router will handle VDSL2 speeds without breaking the bank?

Really? I can pull 14-15Mbit/s off my Cisco 877, i've got the RAM upgrade in it. ALthough i'm not using the IPSec/QOS stuff in it atm. Just NAT/firewall stuff. (Along with native v6 from xnet)

jbergler

42 posts

Geek

ID Verified

#491786 10-Jul-2011 22:15

I can't really comment about the voice side of things - its not something i'm involved in. V6 on DSL should be coming as per my earlier post. On the other points I'll respond without my Snap hat on and take a general approach.

In lieu of native IPv6 I have setup a 6in4 tunnel to Sixxs which is provided by ACSdata in Wellington. This provides reasonably latency (way way better than a HE tunnel to the US). It is unfortunate that Snap peer with ACSData at APE even though the tunnel traffic goes to Wellington (WIX). The MTU on this is way less than 1500.

The address for the ACS Sixxs tunnel box is advertised equally to APE, WIX & CHIX. A service provider has no way to tell what is better and from experience APE is the best choice out of the peering points. If ACS was to advertise the route at better at WIX than elsewhere this should solve your problem.

MTU will never be better because the tunnel has to traverse across a 1500 byte network.

If you want to just setup a simple 6to4 tunnel, then there is a 6to4 anycast server close to Snap (which appears to be run by FX Networks).

This could be one of Nathan Wards teredo boxes which alot of service providers are hosting. I believe he may have one in Snap's network but I think he manages these. Regardless teredo isn't a nice solution and probably shouldn't be relied upon.

QOS over EUBA

This point actually makes me curious. What are you expecting from this? Would you pay extra for it?

QOS doesn't work across the internet. It works in the confines of a tightly managed and controlled network - which is internet is not. The very best you could expect is for us to obey your markings to our upstreams at which point they would be lost. Traffic coming back would not be marked. This is just on of the reasons why applications which require QOS are not designed to be run across the internet.

If a service provider was to provide QOS on a DSL internet the only service which could realistically be supported would be a service hosted on the service providers network - ie their own voice service or similar - which for me doesn't fall under the internet umbrella - it's a value add service not part of the internet - it just happens to be delivered using the same piece of string.

What size prefix are Snap looking to give out to customers? What MTU are Snap looking to offer for native IPv6? How are Snap looking to encapsulate IPv6? (PPPoA, PPPoE, IPoE or something else?)

PPPoA vs PPPoE has minimal differences - mostly CPE's that don't have support for Ethernet over EUBA wont support v6 anyway. Initially, I'd IP6oPPP will be the most likely as it simply involves sending a few additional attributes with the login - everything else keeps working (cough billing cough)

IPoE is the way forward and then it will be DHCP6.

In preparation for native IPv6 (and QoS) I moved to a EUBA configuration. Snap were helpful in getting me moved to a EUBA service. I was disappointed that IPv4 over PPPoE MTU went down below 1500 (Snap said they wanted 8 bytes for QinQ).

MTU could be a CPE issue - I'm running 1500 bytes on my EUBA tail - but I'm using a modem in bridge mode and a mikrotik behind it. The modem is a linksys AM300 which doesn't care about bridging more than 1500 (i think it will pass around 1518 - 1524 form memory and i think euba's max is 1528ish)

You'll have to be using ethernet mode though - PPPoA to PPPoE translation likes to mess things up a bit from experience.

The other thing I have noticed is that the Cisco 877 is hitting a CPU limitation of around 11Mbps for IPv4 and I think it is worse for IPv6 (IOS 15.1, ZBFW, PPPoE, NAT). What happens for people that want full ADSL2+ speeds? What Cisco router will handle VDSL2 speeds without breaking the bank?

Theres an 877 software bug (fixed by 12.24 i think) which limits dsl to about 16meg on PPPoA.
I've seen pretty poor performance on the 877's running PPPoE using the 0/110 pvc but its a new feature so I imagine this might get better with newer code / hardware.

As with other cisco kit the more features you enable the slower it will perform.

We've played with the 887VA's a bit and they seem to fly.

gregb

49 posts

Geek

#491787 10-Jul-2011 22:18

What is the CPU load at 14-15Mbps? I'm doing an single ipv4 rsync at around 6Mbps and it is using around 50% CPU. Looking at the stats it's mostly interrupt time. Not sure of the RAM (236544K/25600K bytes of memory).

--
#show proc cpu his

Marathon   10:10:48 PM Sunday Jul 10 2011 NZST

      555555555566666555555555544444555555555544444555554444455555
      333335555511111222223333388888666663333399999000008888811111
100
   90
   80
   70
   60      **********               *****
   50 ************************************************************
   40 ************************************************************
   30 ************************************************************
   20 ************************************************************
   10 ************************************************************
     0....5....1....1....2....2....3....3....4....4....5....5....6
               0    5    0    5    0    5    0    5    0    5    0
               CPU% per second (last 60 seconds)

#show proc cpu sorted
CPU utilization for five seconds: 46%/43%; one minute: 50%; five minutes: 52%
PID Runtime(ms)     Invoked      uSecs   5Sec   1Min   5Min TTY Process
66    48032966    11777279       4078 1.99% 1.99% 1.97%   0 COLLECT STAT COU
106     5168713     2922253       1768 0.55% 0.28% 0.34%   0 IP Input
279       66653    73521918          0 0.07% 0.02% 0.01%   0 PPP Events
269       13265     9418468          1 0.07% 0.00% 0.00%   0 MLD
76       76318      236596        322 0.07% 0.00% 0.00%   0 ATM OAM Input
273       10638     4595290          2 0.07% 0.01% 0.00%   0 IP NAT Ager
   7           0           1          0 0.00% 0.00% 0.00%   0 DiscardQ Backgro

Cisco 877-M (MPC8272) processor (revision 4.0) with 236544K/25600K bytes of memory.

gregb

49 posts

Geek

#491810 10-Jul-2011 23:15

jbergler: V6 on DSL should be coming as per my earlier post.

I'd be keen get a native prefix when you're ready please.

jbergler: The address for the ACS Sixxs tunnel box is advertised equally to APE, WIX & CHIX. A service provider has no way to tell what is better and from experience APE is the best choice out of the peering points. If ACS was to advertise the route at better at WIX than elsewhere this should solve your problem.

MTU will never be better because the tunnel has to traverse across a 1500 byte network.

From a technical POV I understand that (but don't claim to be a BGP and/or peering expert). From an IPv6 user running a tunnel POV it would seem better if the traffic could go a more direct path.

jbergler: This could be one of Nathan Wards teredo boxes which alot of service providers are hosting. I believe he may have one in Snap's network but I think he manages these. Regardless teredo isn't a nice solution and probably shouldn't be relied upon.

I would concur. However when I have asked for IPv6 from Snap this has been presented as an option.

jbergler:
This point actually makes me curious. What are you expecting from this? Would you pay extra for it?

An interesting question. I don't know how much more I would paid for some prioritised traffic. I can see that I would buy a VoIP offering from Snap over another provider if it came with some form of QoS (even if it was a few dollars more). I guess the counter question is do you think it would be a service that Snap could offer that would be a competitive advantage? Would selling it as a value add for VoIP not be an advantage? Can it be sold to gamers?

I'm mainly looking at it for VoIP (and specifically SIP). I can see how it would be straightforward to understand the QOS/COS in a service provider/custom scenario (I'm not sure what Xnet are doing but they seem to be leading this game). In my case I can see it working the same where my prioritised traffic is prioritised only up to the ISP's border (a trust boundary where the ISP's trusts the markings). Return traffic would need to use a scheme (say DSCP) to decide whether it's prioritised traffic. Given the tiny bandwidth available on the EUBA offerings the policing/dropping of all over allocation traffic means it won't tend to be abused for 'faster torrents'.

jbergler: I've seen pretty poor performance on the 877's running PPPoE using the 0/110 pvc but its a new feature so I imagine this might get better with newer code / hardware.

Although the EUBA offering is new-ish, PPPoE should be really well understood. Worldwide I would have thought that it was more widely used that PPPoA (e.g. BUBA & EUBA in compatibility mode).

jbergler

42 posts

Geek

ID Verified

#491818 10-Jul-2011 23:32

jbergler: The address for the ACS Sixxs tunnel box is advertised equally to APE, WIX & CHIX. A service provider has no way to tell what is better and from experience APE is the best choice out of the peering points. If ACS was to advertise the route at better at WIX than elsewhere this should solve your problem.

gregb: From a technical POV I understand that (but don't claim to be a BGP and/or peering expert). From an IPv6 user running a tunnel POV it would seem better if the traffic could go a more direct path.

My point here is that although a service provider could make this better for the user they shouldn't (and if they did it would probably break things long term). It's up to the content provider to make the decision on where their traffic comes from, not vice versa.

jbergler: This point actually makes me curious. What are you expecting from this? Would you pay extra for it?

gregb: An interesting question. I don't know how much more I would paid for some prioritised traffic. I can see that I would buy a VoIP offering from Snap over another provider if it came with some form of QoS (even if it was a few dollars more). I guess the counter question is do you think it would be a service that Snap could offer that would be a competitive advantage? Would selling it as a value add for VoIP not be an advantage? Can it be sold to gamers?

Sure it could - but it would cost a significant chunk of money. If an ISP is selling QOS they need to ensure it end to end which in this case would mean peering with the game servers you want an enhanced service to. It very quickly stops being an internet service and heads towards an transport service which costs lots of $.

I don't think QOS will ever be something you can buy on your internet connection - at least I hope not. This becomes a net neutrality argument very quickly. Why is X on the internet more important than Y etc.
The difference between QOS for voice from your isp is that its not an internet service.

gregb: I'm mainly looking at it for VoIP (and specifically SIP). I can see how it would be straightforward to understand the QOS/COS in a service provider/custom scenario (I'm not sure what Xnet are doing but they seem to be leading this game). In my case I can see it working the same where my prioritised traffic is prioritised only up to the ISP's border (a trust boundary where the ISP's trusts the markings). Return traffic would need to use a scheme (say DSCP) to decide whether it's prioritised traffic. Given the tiny bandwidth available on the EUBA offerings the policing/dropping of all over allocation traffic means it won't tend to be abused for 'faster torrents'.

I'm not concerned with a user abusing the service - the potential for that is minimized because any traffic in excess of the traffic class's bandwidth is discarded, there is no borrowing or lending, its simply policed.
Which means if I want to be malicious I will send you 48kbps of cos marked UDP traffic and your phone will stop working. It's not actually the case because as you say qos only works to trust boundries - which means everything from the 'internet' is rewritten to best efforts and suddenly using QOS for games or voice outside your ISP's network isn't going to work.

jbergler: I've seen pretty poor performance on the 877's running PPPoE using the 0/110 pvc but its a new feature so I imagine this might get better with newer code / hardware.

gregb: Although the EUBA offering is new-ish, PPPoE should be really well understood. Worldwide I would have thought that it was more widely used that PPPoA (e.g. BUBA & EUBA in compatibility mode).

It's not the PPPoE support i'm worried about - it's the half complete implementation of the ethernet over dsl encapsulation in the 800 series. Which incidentally to my knowledge doesn't even support qos marking - last i looked you had to go back to PPPoA and the legacy PVC doesn't support QOS as its not ethernet the whole way.

1 | 2 | 3