Hacker News Reader

Comment by ahbs66 | Hacker News Reader

I don't find it surprising that they can't find a correlation between GDP/growing user base/IPv4 stress and IPv6 deployment.

IPv6 deployment is a matter of politics. It depends on the opinions of the network personnel, on the hardware they have in their core network, on the hardware their customers have (CPEs), on the support contracts they have, etc. That's what decides whether they put a CGNAT in place, whether they buy more IPv4 addresses, or whether they deploy IPv6.

View on HN

>" It depends on the opinions of the network personnel, on the hardware they have in their core network, on the hardware their customers have (CPEs), on the support contracts they have, etc."

Are you saying there are network engineers/management at ISPs who don't believe IPv6 is an imperative? As someone who in a former life worked inside large ISPs on the networking side I can tell you that that view would be quite rare. What would be the politics exactly?

Most ISPs run Juniper and Cisco gear in their core, both of these have have been capable of routing v6 for well over a decade now. Additionally if you are running older gear you would have hit the 512K route TCAM limit years ago.[1]

None of this would have anything to do with existing support contracts either. You would be pretty hard-pressed to find a rev of JunOS or IOS/NXOS that didn't support v6.

It's actually much more efficient to route v6 than v4. The global IPv4 table 719K prefixes now while IPv6 has 52K See:

http://www.cidr-report.org/as2.0/

and

http://www.cidr-report.org/v6/as2.0/

Lastly the fee schedule for IPv6 allocations from RIRs are not cost prohibitive for an ISP. Using ARIN as an example here:

https://www.arin.net/fees/fee_schedule.html

[1] https://blogs.cisco.com/sp/global-internet-routing-table-rea...

>Are you saying there are network engineers/management at ISPs who don't believe IPv6 is an imperative?

Unfortunately, this is true for at least one major ISP in the USA. IPv6 support is seen as a low priority internally, as they work to merely keep their devices online.

One huge secret about Juniper devices is that the hardware is remarkably unreliable. At one company, a partial Juniper SSG failure prevented a failover to good hardware. At another, we so many Juniper SRX RMAs that we had a full time network engineer handling the RMA paperwork. (Admittedly, they said we were their biggest client, and had a bigger implementation than Juniper's own network lab.) They have a bad habit of failing on reboot - one was operating fine, we reboot it and it reports errors. This happened repeatedly in several data centers - at one point we had 1/6 of our data centers non-redundant while we waited for RMA shipping.

>"One huge secret about Juniper devices is that the hardware is remarkably unreliable."

This is patently untrue. The MTTF is the same as Cisco gear. The only reason this would be a "huge secret" is because it is not widely held opinion.

There are bad revision of chipsets on certain boards from time to time yes. And if you place a large order you will likely feel that pain if you're shipped boards with those revs. I know this first hand and with SRXs. Firewalls are but one segment of their product line and the one that was never their core strength(in fact this was the Netscreen acquisition.)

The T4000 and MX 960s are both "big iron" and in both the core and edge of Tier 1 ISPs. The reputation of these are exceptional and for good reason. Their EX/QFX ToR switches also have a well-deserved reputation.

To use your anecdotal experience with on particular segment of their product line and make a sweeping generalization of the quality of their entire offering is absurd.

I say this as someone who doesn't have a horse in the race and has very little love for network hardware vendors in general.

MX series routers do seem more reliable than their SRX counterparts. It's just frustrating to go into a major incident retrospective and hear that - yet again - we're not redundant in a data center because we rebooted a Juniper device and now it needs an RMA.

Juniper even instructed us to reboot the passive node before any failover, just to catch these issues.

I've heard that a lot of ISPs in Australia are stuck on IPv4 as their whole billing systems (written in early 2000s) use IPv4 addresses for everything. Including techniques like mapping an array of size 2^32 (entirely possible with virtual addresses) to keep counters for each user. It would be a complete rewrite of their billing systems to work with IPv6, and they no longer have many/any programmers on staff.

There's no particular reason to use the entire IP as the lookup key though; all customers will be numbered out of the ISP's single allocation and you don't need to keep track of the traffic of each individual host, just the overall traffic of each customer.

You'd end up needing a much smaller array for v6 -- small enough that you could fit it into the presumably-unused parts of those 2^32 arrays that correspond to the v4 class E space.

Most residential customers don't have static IP addresses -- how does that work when a customer's IPv4 address changes?

I believe they take a snapshot (which can be as simple as fork(), hooray for COW memory) of the array every minute to see how much you've downloaded. The same IPv4 address isn't reused by another customer until a day has passed.

>Most residential customers don't have static IP addresses

Where is this? What do you have to back up this claim?

>how does that work when a customer's IPv4 address changes?

As far as I can tell, it wouldn't. But I don't see what your point is.

I'm not in Australia, but I've had the same IP for decades, even having gone through multiple routers, so it's probably tied to the DSLAM port I'm connected to, which makes sense for such a billing scheme. Also might be why I don't have IPv6 yet either.

>Are you saying there are network engineers/management at ISPs who don't believe IPv6 is an imperative?

If the rest of your message is true, why are the ipv6 numbers so low, if it's not because of politics?

IPv6 growth has been an almost flat curve for many years. Now suddenly it's not.

I personally expected IPv6 growth to slow down gradually. I find it very odd that the growth hit a wall like that. Oversimplifying somewhat: The number of new v6-capable users increased every month, then boom, zero.

I also find it odd that politics would have no effect at 13% or 14% deployment and then block growth entirely at 15%.

Then please explain exactly what these "politics" are then rather just throwing around the word around in the abstract. I find it odd that people say "oh its politics" without explaining what or how IPv6 is being "politicized."

People appear to use the word "politics" to mean any motivation that's very weakly connected to the matter at hand, but rather instead to another relationship between the parties. Ill will from a previous confrontation, for example. Or a general desire to prevent department x from meeting more of the Quarterly Corporate Targets than department y does.

In this context it has to mean something that didn't impede IPv6 growth at all for a while, then suddenly blocked IPv6 growth completely. Can't imagine what it would be.

(Sorry, didn't notice the comment until much too long had passed. I realise noone's going to read this. Oh well.)

The numbers are not so low, they've simply plateaued recently.

Also, IPv4 exhaustion doesn’t affect Africa yet, only the American, Asian and European RIR.

Reply on news.ycombinator.com