Hacker News new | past | comments | ask | show | jobs | submit login

> because maintaining state for GCNAT tables is far more complex then just forwarding packets.

But it’s a solved problem with mature solutions, decades old. Is it really financially expensive?




compared to rolling out IPv6? definitely, especially on the longer term.

For instance, most Core/Edge routers (my experience is mainly with juniper MX series, but i assume the model is roughly the same for other vendors), you need specific licenses or interface card's to do stateful services like NAT.

Compared to doing IPv6, which is "just forwarding packets" and doesn't require the hardware to track state in nearly the same manner.

Most serious core/edge hardware vendors also do not put IPv6 behind licenses compared to CGNAT and other NAT-like features, because packet based forwarding is the most basic functionality a router should provide.

Routers which are able to do less state, also are frequently far less expensive.


You’re presenting a false dichotomy. The choice for an ISP today is not “v4 or v6”, it’s either “v4 or v4+v6”. A v6 only connection in the US is unusable.


The v4 fallback can operate on slower equipment if needed. The majority of bandwidth-heavy services support IPv6 (and the slowness will encourage outliers to migrate).


The more traffic you can get onto ipv6 the less stress is on the v4 infrastructure. Each v6 connection is one your CGNAT doesn't have to provide an ipv4 port for.


So what? That’s still just a scaling factor at that point and still requires you to have v4 cgnat infrastructure + ipv6.


You don't have to beef up your v4 infra as much though. Think 4 powerful v4 routers instead of 5 or something. If the traffic to the big streaming providers doesn't have to run through these routers, you can save a lot. Same goes for the ipv4 address space you have to rent/buy. The more connections are on ipv6, the less public ipv4 addresses you need to have.

So ipv6 support might be saving you costs already in a dual stack setting.


Take a step back to the wider context of a brand new ISP though. If you’re rushing to market like Starlink appears to be, you either implement just v4 and scale later or implement both v4/v6 up front.

Until there is a bunch of exclusive v6 stuff customers will be up in arms over missing, the answer of which thing to prioritize is obvious.


Yeah I guess it's the same as with the inter satellite communication which is promised for later, but not implemented yet so that they get at least some product out to customers. I don't think dual stack is that hard to do for entirely new networks though.

Also, one of the reasons to do satellite internet is lower latency which is a bit hurt by CGNAT infrastructure.

Last, generally brand new ISPs are in the situation that they have a hard time of getting ipv4 address space. The incumbents, especially the older ones, were around when ipv4 addesses were still plenty so they usually have way less problems with ipv4 address space. Starlink only has 166k ipv4 addresses according to https://ipinfo.io/AS14593 . Compare this to AT&T which has over a hundred million for their AS 7018 https://ipinfo.io/AS7018 alone, and there are other AS numbers they have like AS20057 with 7 million ipv4s. This roughly matches the number of AT&T customers while Starlink has more than double the number of subscribers than its number of public IPs, with growth ahead.


Having your core as v6 only lets you push NAT to limited places (one of the many options for 4x6x4 NAT, including stateless options if you're willing to cut certain corners off v4).

And v6 connections help drop the pressure on NAT resources - and sites that are optimizing for mobile connections are already going to be on IPv6 where possible (due to mobile networks prioritizing v6 traffic for various reasons, including licensing - and NAT resource costs)


CGNAT is just a slightly more fiddly version of DS-Lite (and frankly at this stage your internal network is either v6 or an ad-hoc informally-specified bug-ridden implementation of half of it). You're always going to have to do messy connection tracking stuff with connections going to v4-only sites, the only question is whether you want to do it for connections to v6-enabled sites as well or not.


All apps on iOS support DNS64 on ipv6 only network.


That doesn’t help for servers that are only reachable via ipv4 (see GitHub).


NAT64+DNS64 is specifically for IPv6-only clients to access IPv4-only servers.


A problem being solved doesn't mean the current solution is inexpensive or optimal.


The same could be said about IPv6. I think the point is that IPv6 scales better with traffic increases, to the point where switching from CGNAT to IPv6 becomes financially attractive.


What do you mean, solved problem?




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: