IPv6pipe:

 

You might like to update your GZ handle name and avatar picture for the foreseeable future :)

insane:

IPv6pipe:

You might like to update your GZ handle name and avatar picture for the foreseeable future :)

So there was a bunch of routers on the UniFi controller I run with IPv6 from BigPipe running and about 3 with IPoE configured. I've reconfigured them all and removed IPv6 (so it doesn't fill up the logs more than anything). Honestly, I could just imagine waking up one morning to a mass of emails from people without internet service. One of the joys of running such a controller :)

So thanks @skewt for the heads up ahead of time. Honestly, without reading it here I would have never known.

watsonash:

insane:

 

IPv6pipe:

 

 

 

 

 

 

You might like to update your GZ handle name and avatar picture for the foreseeable future :)

 

Haha. How about bigpipeipv1_partylikeits1977 with an avatar of a telephone with a bell on the top!

I wouldn't be opposed to being renamed IPv4Pipe if deemed necessary. :)

he.net does free tunnels to sydney for ipv6 (https://tunnelbroker.net/).  you'd need to get a static IP and I'm not sure what routers are like for tunneling from them.

IPv6pipe:

 

I wouldn't be opposed to being renamed IPv4Pipe if deemed necessary. :)

 

How about IPv6RIPipe

Passive-agressive stuff like in the screenshot (after being told they have no update just hours before) won't win you any favors, neither will all the secrecy about your "roadmaps", just so you know. I got a better deal on Voyager, who have IPV6 working, and will be keeping it. Things like this, and your lack of customer service (outlined in other threads I've posted) have caused me to move from you after being your customer for years. There have been quite a few others on Twitter moving as well. You may want to let your bosses know how stupid of a decision this entire thing was, as well as train your employees in how not to be passive-agressive jerks, even when a customer is leaving. Especially when that customer has tried to sort out a connection for over a month, and gotten the run around.

deadlyllama:

 

I assume moving to Spark's network means Will Never Ever Engage In Settlement-Free Peering... sigh.

 

Show me the compelling business case to peer with the local IXs. As there are real world non-trivial costs associated with doing it. Such as:

- Implementing BGP filters to only permit importing certain prefixes, plus having that list being maintained by someone. Since if you don't do that someone on the IX could export 8.8.8.8 at a low MED and all of a sudden a bucketload of traffic goes somewhere new and you break the internet for a whole lot of your customers.

- Implementing multiple 10GB interconnect links to the IXs and also capacity managing them to make sure that they are large enough

- Implementing and maintaining core interconnect filters to make sure that smaller ISPs don't use the Spark 100GB+ backbone for domestic transit for free. Or if there was peering would the peering only apply to Auckland Spark customers on the Auckland IX. Or would you (naturally) assume that with Spark peering on the Auckland and Wellington IX then *any* Spark customer anywhere in the country would have interconnect to them.

- And I am sure other reasons for it too.

I can only agree with @talkiet and @cbrpilot that the number of IPv6 customers would be a far smaller subset of the people who notice a non-trivial improvement in their download speed and overall browsing experience especially with international sites. The further south you go the more you would notice the improvement on Bigpipe vs Spark. And the people who wouldn't care about their browsing experience would be even less likely to care about IPv6.

 

Show me the compelling business case to peer with the local IXs. As there are real world non-trivial costs associated with doing it. Such as:

 

- Implementing BGP filters to only permit importing certain prefixes, plus having that list being maintained by someone. Since if you don't do that someone on the IX could export 8.8.8.8 at a low MED and all of a sudden a bucketload of traffic goes somewhere new and you break the internet for a whole lot of your customers.

 

- Implementing multiple 10GB interconnect links to the IXs and also capacity managing them to make sure that they are large enough

 

- Implementing and maintaining core interconnect filters to make sure that smaller ISPs don't use the Spark 100GB+ backbone for domestic transit for free. Or if there was peering would the peering only apply to Auckland Spark customers on the Auckland IX. Or would you (naturally) assume that with Spark peering on the Auckland and Wellington IX then *any* Spark customer anywhere in the country would have interconnect to them.

 

- And I am sure other reasons for it too.

 

I can only agree with @talkiet and @cbrpilot that the number of IPv6 customers would be a far smaller subset of the people who notice a non-trivial improvement in their download speed and overall browsing experience especially with international sites. The further south you go the more you would notice the improvement on Bigpipe vs Spark. And the people who wouldn't care about their browsing experience would be even less likely to care about IPv6.

 

Which would be fine EXCEPT that the Spark network is attached and peering a very limited subset of routes for NFL, so most of the the above is moot, its just pure anti-competitive behavior.

BarTender:

 

 

 

Show me the compelling business case to peer with the local IXs. As there are real world non-trivial costs associated with doing it. Such as:

 

- Implementing BGP filters to only permit importing certain prefixes, plus having that list being maintained by someone. Since if you don't do that someone on the IX could export 8.8.8.8 at a low MED and all of a sudden a bucketload of traffic goes somewhere new and you break the internet for a whole lot of your customers.

 

- Implementing multiple 10GB interconnect links to the IXs and also capacity managing them to make sure that they are large enough

 

- Implementing and maintaining core interconnect filters to make sure that smaller ISPs don't use the Spark 100GB+ backbone for domestic transit for free. Or if there was peering would the peering only apply to Auckland Spark customers on the Auckland IX. Or would you (naturally) assume that with Spark peering on the Auckland and Wellington IX then *any* Spark customer anywhere in the country would have interconnect to them.

 

- And I am sure other reasons for it too.

 

I can only agree with @talkiet and @cbrpilot that the number of IPv6 customers would be a far smaller subset of the people who notice a non-trivial improvement in their download speed and overall browsing experience especially with international sites. The further south you go the more you would notice the improvement on Bigpipe vs Spark. And the people who wouldn't care about their browsing experience would be even less likely to care about IPv6.

 

Yet every other ISP in NZ does it and does a good job at it.

(And infact you guys do it too, just not in NZ....)

The "we don't want small ISP's using us as domestic transit" story is also pretty weak, as your customer, who is requesting the traffic has already paid for it. you just want to be paid twice.

Sounddude:

BarTender:

 

 

 

Show me the compelling business case to peer with the local IXs. As there are real world non-trivial costs associated with doing it. Such as:

 

- Implementing BGP filters to only permit importing certain prefixes, plus having that list being maintained by someone. Since if you don't do that someone on the IX could export 8.8.8.8 at a low MED and all of a sudden a bucketload of traffic goes somewhere new and you break the internet for a whole lot of your customers.

 

- Implementing multiple 10GB interconnect links to the IXs and also capacity managing them to make sure that they are large enough

 

- Implementing and maintaining core interconnect filters to make sure that smaller ISPs don't use the Spark 100GB+ backbone for domestic transit for free. Or if there was peering would the peering only apply to Auckland Spark customers on the Auckland IX. Or would you (naturally) assume that with Spark peering on the Auckland and Wellington IX then *any* Spark customer anywhere in the country would have interconnect to them.

 

- And I am sure other reasons for it too.

 

I can only agree with @talkiet and @cbrpilot that the number of IPv6 customers would be a far smaller subset of the people who notice a non-trivial improvement in their download speed and overall browsing experience especially with international sites. The further south you go the more you would notice the improvement on Bigpipe vs Spark. And the people who wouldn't care about their browsing experience would be even less likely to care about IPv6.

 

 

Yet every other ISP in NZ does it and does a good job at it.

 

(And infact you guys do it too, just not in NZ....)

 

The "we don't want small ISP's using us as domestic transit" story is also pretty weak, as your customer, who is requesting the traffic has already paid for it. you just want to be paid twice.

 

 

 

 

madduck: I'm also keen to find out in what the alternatives are. I'd want an ISP who understands networking, including the IPv4 protocol that's >25 years old, and offers static IPs. Booooh Bigpipe.

I’ve been with 2degrees, previously Snap, for some years and been very satisfied with them.

Add to this discounts for being 2degrees mobile customers and Super Gold Card holders.  

It’s disappointing that so many NZ ISP’s are dragging the chain on IPv6. We participated in the Worldxchange IPv6 trial which started over 10 years ago and was then closed to new applicants. Top level exhaustion of IPv4 addresses happened over seven years ago and IPv6 technology has been fully operational in pretty much every piece of modern CPE equipment for years.  

For me IPv6 is a must have and in my view any serious participant in the industry should be well advanced with deployment by  now. Removing support for IPv6 is tragic and reprehensible.

kiwibob1:

 

[snip] Removing support for IPv6 is tragic and reprehensible.

 

And this is _literally_ the worst exaggeration ever in the history of the universe, by anyone, evah :-)

I kind of feel that a very small number of users are losing sight of the _fact_ that the performance of their connections is going to improve after this migration.

Moving to the Spark network and maintaining IPv6 at the same time is not possible. The performance and coverage benefits for customers, and the efficiency benefits for us wildly exceed the downsides of TEMPORARILY losing IPv6.

For the avoidance of doubt, Spark is currently working on IPv6 for BB subscribers and we have it working in the lab. We're not ready to trial on the production network yet.

Cheers - N

Talkiet:

 

kiwibob1:

 

[snip] Removing support for IPv6 is tragic and reprehensible.

 

 

And this is _literally_ the worst exaggeration ever in the history of the universe, by anyone, evah :-)

 

OK I noted the smiley face :)

At this point IPv6 should not be a lab project, it's a deployment project which should have clear action items and timetables.

We are _literally_ years into the exhaustion of IPv4 addresses and IPv6 should be as much a part of a large ISP's offering as IPv4 imho.

"Watch this space" may have been adequate at one time but, accepting that it was a beta trial, there should at least be an announced implementation date even if it's the xth quarter 2018.

On the plus side Bigpipe should be congratulated for dumping CGNAT