Hacker News new | ask | show | jobs
by Fabricio20 49 days ago
Personal experience that I see noone talk about with IPv6 is how much more expensive hardware that handles it correctly is for datacenters. On IPv4 your usual unit of allocation is a /32 for customers - that means a simple hashmap `1.1.1.1=destination mac` works wonderfully and is cheap (single memory lookup), but for ipv6 your usual unit is a /64 so its longest prefix match instead, which requires parsing the address to group it back into the /64 and alot of switches and routers that are already expensive still have very low limits on LPM memory banks.

Expensive switch at work we have can only do 3000 route entries for example on ipv6. If we did /128s it's basically infinite though, because it goes from a LPM to exact match, which has much much more memory available.

Doesn't help as well that for example, to be able to do SLAAC or even DHCPv6 (which barely works reliably in my experience) you need to do a /64 at minimum, those mechanisms dont even work otherwise, so for ISPs who can easily have more than 3000 downstream customers doing routed ipv6 is such an increase in hardware cost vs just doing NAT which they were already doing anyway.

3 comments

Never mind the actual performance issues that I keep seeing in production deployments.

We have large networks that are essentially rolling on autopilot totally unmanaged, like Lumen'e recently sold Quantum Fiber asset that is now owned by AT&T holding company Forged Fiber 37 LLC

No native IPv6 still on this forgotten about network, 6RD keeps having weird routability issues, but if you just disable IPv6 everything works fine.

NAT requires remembering every connection pair (IPv4:port for both internal and external sides of the NAT)

You don’t need more than the /64 to know where to send traffic, all of the bits required are still just in the prefix. One route per customer… the edge deals with addressing issues.

Why on earth would you ever want to route something smaller than a /64? At the ISP level, you'd only be concerned about your customers' /48 or maybe /56 networks.
OP seems to want to route /64 or larger to each customer, but can only have 3000 total entries larger than /128 in the expensive routers his firm owns.

Essentially the hardware doesn't support scaling a /64 or /56 to each customer, leaving OP in a terrible position when it comes to proper IPv6 deployment.

When you look at Ziply Fiber, they seem to be ripping out these types of Enterprise grade routers left and right in favor of a simple Linux box doing routing. I think a large portion of why they're doing this is due to limitations like what OP is experiencing

Both of which are LPM and cause the issue I just mentioned! It's not about "routing lower than a /64" its about LPM vs Exact Match memory bank usage (and for some reason, how much more expensive good hardware that handles LPM is).