IPv6

Forums › Spark New Zealand (including Skinny and BigPipe) › IPv6

paul151

313 posts

Ultimate Geek
+1 received by user: 45

Trusted

#171847 2-May-2015 23:27

Are there any further plans to launch a native IPv6 service for Spark customers - I understand Spark does not offer IPv6 at present - correct?

Does anyone know if the Alcatel gear installed in Dunedin for the Gigatown prize supports IPv6 over fibre?

Noodles

487 posts

Ultimate Geek
+1 received by user: 95

#1295971 3-May-2015 08:15

I don't know about Spark, but if you're looking for great ipv6 check out Snap.

chevrolux

4962 posts

Uber Geek
+1 received by user: 2638
Inactive user

#1296000 3-May-2015 09:22

UFB is sold to the RSP's as a layer 2 product so they can put whatever they want over it.
It would be up to spark to implement ipv6 if they chose to.

Personally I see zero benefit for residential customers so don't know why they would bother.

If you really want ipv6 why not just get tunnel from sixxs ?

SirHumphreyAppleby

2939 posts

Uber Geek
+1 received by user: 1860

#1296001 3-May-2015 09:37

chevrolux: If you really want ipv6 why not just get tunnel from sixxs ?

SixXS is a great service, but with higher speed UFB plans there is a noticeable performance penalty accessing IPv6 content. We also only have a single NZ-based PoP, and there is no guarantee that service will continue.

So no, I don't feel the solution is to just get a tunnel via SixXS. ISPs need to step up and get IPv6 implemented. It may have no appreciable benefit to the end user, but given many of the largest sites on the Internet are IPv6 enabled, it's not as if it is going to be sitting idle and unused as was almost the case five years ago.

BarTender

3629 posts

Uber Geek
+1 received by user: 2572

ID Verified

Trusted

Lifetime subscriber

#1296263 3-May-2015 20:28

SirHumphreyAppleby:
chevrolux: If you really want ipv6 why not just get tunnel from sixxs ?

SixXS is a great service, but with higher speed UFB plans there is a noticeable performance penalty accessing IPv6 content. We also only have a single NZ-based PoP, and there is no guarantee that service will continue.

So no, I don't feel the solution is to just get a tunnel via SixXS. ISPs need to step up and get IPv6 implemented. It may have no appreciable benefit to the end user, but given many of the largest sites on the Internet are IPv6 enabled, it's not as if it is going to be sitting idle and unused as was almost the case five years ago.

Find me the killer application that is V6 only. The main reason why ISPs are moving due to V4 exhaustion.

I doubt Spark will be moving soon to V6. I think they have plenty of spare address space and why spend time and money putting in something that spark doesn't need just yet and customers aren't demanding.

SirHumphreyAppleby

2939 posts

Uber Geek
+1 received by user: 1860

#1297639 4-May-2015 14:05

BarTender: Find me the killer application that is V6 only. The main reason why ISPs are moving due to V4 exhaustion.

I don't want to get too off topic, since this thread is essentially a request for information from Spark, but I will comment briefly on the above.

I have heard the "killer application" argument many times, and the simple fact is it is never going to happen. IPv6 doesn't offer any features which are going to make it essential to a killer application. The standard BSD socket libraries on which most systems are based make implementing IPv6 a trivial and familiar task. I personally have converted commercial software to use IPv6, and where modern socket code is already in use, adding IPv6 support requires as little as minor tweaks to (from memory) three function calls. Using a third party library would probably require changing a single line.

The above is of course not relevant to why ISPs don't provide IPv6, but emphasises my point that IPv6 isn't a killer anything. What it is, is a compatible, unobtrusive, and easily implemented protocol. The same is true at the network level, and unlike CG-NAT which is being deployed to address the issue of IPv4 address exhaustion (IPv6 is not, it does not address the issue), requires minimal effort to implement, and doesn't break anything [that matters]. Every network tech working for ISPs likely has already experienced IPv6 (not true for CG-NAT), and it's only the direction to deploy it which is lacking.

I am certain a proper analysis would show that the costs of deploying IPv6 are minimal, and I'm sure many techs are constantly raising the issue (as did I, and sales staff for the products with which I was involved), but I agree it's difficult to see benefits when there is nothing which requires it, and customers aren't (for the most part) asking for it - most don't even know it exists.

IPv6 exclusive content and applications aren't the real solution to the problem, but I predict the big push for IPv6 is going to come from a major provider such as Google, by putting definite date on phasing out IPv4 (or at the very least lowering rankings for non-compliant pages). That may sound absurd given there is no reason ever to phase it out, but without an organisation with sufficient clout forcing the issue, IPv6 just isn't going to happen.

BarTender

3629 posts

Uber Geek
+1 received by user: 2572

ID Verified

Trusted

Lifetime subscriber

#1297869 4-May-2015 19:15

SirHumphreyAppleby: I am certain a proper analysis would show that the costs of deploying IPv6 are minimal, and I'm sure many techs are constantly raising the issue (as did I, and sales staff for the products with which I was involved), but I agree it's difficult to see benefits when there is nothing which requires it, and customers aren't (for the most part) asking for it - most don't even know it exists.

I strongly disagree with the statement that the costs are minimal... Lets just list a few things that would need to change with deployment at a telco grade v6 stack.

- Prefix delegation. Do you plan to deploy /64's, or something bigger such as /56's. Would they be static so if you moved across the country or would they be purely dynamic?
- Infrastructure upgrade. All the core switches, routers and firewalls need to support v6.
- Services upgrade. DNS Servers, Cache servers, CDNs (Google / Akamai) need upgrades.
- Router selection. Need to decide which router will be chosen, will scale and can be managed
- Continue with PPPoE or move to DHCPv6 and how the IP Addresses will be allocated via SLAAC or PD as different routers behave differently.

So the above doesn't sound trivial in my view and I am sure I have missed things for something you don't need right now and customers aren't demanding.

Would you put your money into more backhaul, BNGs or international capacity where the demands are. Or into V6?

SirHumphreyAppleby: IPv6 exclusive content and applications aren't the real solution to the problem, but I predict the big push for IPv6 is going to come from a major provider such as Google, by putting definite date on phasing out IPv4 (or at the very least lowering rankings for non-compliant pages). That may sound absurd given there is no reason ever to phase it out, but without an organisation with sufficient clout forcing the issue, IPv6 just isn't going to happen.

V4 isn't going to get phased out in the next 10 years and unless our population grows significantly all the T1 Telco's have plenty of addres space, especially when they are moving their mobile networks to CGNat.

If I were a betting man I would expect V6 deployments in mobile.

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.

SirHumphreyAppleby

2939 posts

Uber Geek
+1 received by user: 1860

#1298041 5-May-2015 08:08

BarTender: Lets just list a few things that would need to change with deployment at a telco grade v6 stack.

- Prefix delegation. Do you plan to deploy /64's, or something bigger such as /56's. Would they be static so if you moved across the country or would they be purely dynamic?
- Infrastructure upgrade. All the core switches, routers and firewalls need to support v6.
- Services upgrade. DNS Servers, Cache servers, CDNs (Google / Akamai) need upgrades.
- Router selection. Need to decide which router will be chosen, will scale and can be managed
- Continue with PPPoE or move to DHCPv6 and how the IP Addresses will be allocated via SLAAC or PD as different routers behave differently.

So the above doesn't sound trivial in my view and I am sure I have missed things for something you don't need right now and customers aren't demanding.

The above is a good list of things which need to be in place for IPv6 deployment, however the magnitude of change required, particularly in relation to infrastructure research and acquisition is greatly over-stated. Almost all infrastructure in a modern ISP environment already fully supports IPv6, and has for a number of years. Likewise, industry certifications for such systems have also added IPv6.

In a dual stack environment, the only services which needs any update at all are those relating to address allocation. Beyond that, everything else can be done as part of normal upgrades. Even DNS changes aren't strictly required as an IPv4-connected DNS server will resolve IPv6 addresses perfectly well, just as they do today. The two CDNs you mention are both already IPv6 enabled, so unless you're hosting content for them and bound by contractual obligations to provide them with IPv6 connectivity when available, they are entirely irrelevant.

Would you put your money into more backhaul, BNGs or international capacity where the demands are. Or into V6?

All of these represent significant ongoing costs to an ISP. Everything in the list of IPv6 requirements above represents a one-off cost, and requires little more than some time from a single competent individual to evaluate current systems, and decisions being made on some of the implementation details.

V4 isn't going to get phased out in the next 10 years and unless our population grows significantly all the T1 Telco's have plenty of addres space, especially when they are moving their mobile networks to CGNat.

If I were a betting man I would expect V6 deployments in mobile.

Nobody is asking or IPv4 to be phased out. Mobile or fixed isn't going to make any difference to the need to interconnect both networks. The same methods for interoperability (non-standard/deprecated) apply equally in both fixed and mobile networks, so the need for dual stack will remain, which means both CG-NAT or public IPs and IPv6 eventually.