It’s better than no P2P but IPv6 solves exhaustion and NAT without the performance hit or protocol limitations and with no extra third party intermediary in the way.
BTW this maintains data privacy but you can still tell a whole whole lot from metadata.
On the flip side it would prevent the kind of “griefing” with DDOS that happens every once in a while with self hosted and P2P things. It’s not that common unless you are engaging with certain communities but it is an inherent Internet architectural flaw that this kind of works around (at a cost).
> It’s better than no P2P but IPv6 solves exhaustion and NAT without the performance hit or protocol limitations and with no extra third party intermediary in the way.
I just don't see ISPs ever implementing IPv6 without governments forcing them to. It enables p2p which increases upload bandwidth requirements and cuts into their bottom line. And even if we get IPv6 you still need the ability to open firewall ports in a way the average user can understand. Not hard technically but that's another standard that everyone is going to have to agree on and implement.
[0]: Which I know you can appreciate. "Decentralize until it hurts; centralize until it works" is still one of my mottoes.
PS - typing the IPv6 address was super annoying and error prone compared to IPv4.
Depends on the carrier network though. I am on Spectrum (Verizon network) in Ohio and get V6 with CGN for V4. My wired ISP provides dual stack.
You still usually need hole punching with IPv6 if there's any kind of firewall in the way, but unlike IPv4 with NAT it's virtually 100% successful. Even if IPv6 NAT is deployed there's usually a 1:1 internal/external IP mapping making hole punching 100% successful.
It works better outbound than the old model though. I use iSH to get a Linux shell and with a mini Bluetooth keyboard I work on some hobby projects on the train from my iPhone.
The hard truth is that implementing IPv6 costs money and customers are not willing to pay for it.
Once you wire fiber upstream bandwidth doesn't matter that much. ISPs are directly peered into the core of the Internet and pay bulk peering bandwidth pricing not cloud bandwidth pricing. Cloud bandwidth pricing is completely insane, like 10000% markup or more in many cases, and the fact that they charge more for outbound is just a strategy to make data flow into their cloud but not out. Bandwidth is actually dirt cheap or companies like Cloudflare could never exist.
The main reason they drag their feet on IPv6 is that there's no strong forcing function and dual stack adds complexity. When they're on a deadline to ship they punt on it. They are starting to get complaints from gamers though. Gamers tend to be the top home users that drive early adoption of all kinds of things.
Edit: another funny thing is that most ISP/telecom stuff these days is IPv6 at the core. If they're not doing it at the edge for new stuff it means they've just got it off and are running IPv4 over IPv6 within their network most of the time. This is even more true for mobile networks, some of which are IPv6 only and the phone does 4to6.
The rollout is still happening... slloooooooowly... The Internet is huge and it takes forever to do a major upgrade like this. I wish they'd have just made IP 48 or 64 bit with an easier upgrade path, but that's water under the bridge now.
Overlay networks are probably the future. IPv6 lets them be fully P2P and more decentralized.
Edit: one more piece of detail about upstream bandwidth at home. 30-40mbps/sec up is a DOCSIS cable system limit. That's the only reason for that really. Cable was never designed to be bidirectional and the stuff they do with modulation to get shared upstream is heroic. It's also related to why cablemodems tend to use a lot of power. They have to blast spread spectrum pretty loud to get it to the CO. Fiber will save energy.
That is awfully expensive for something ipv6 already solves minus the privacy part. I don't see how it can be considered "huge". A slight convenience maybe?
Also, routing everything through a 3rd party is a massive downside.
Here’s the attack:
- You want to get to A
- And you’re on a device B that has access to hole-punch-as-a-service but no direct access to A. Good network administrator / sysadmin!
- Attack NDP (ie ARP spoofing but IPv6 flavored) to trick the firewall just for a moment that you’re A [1] and request the port be opened to your evil server C on the public internet.
- Oops.
EDIT: I agree we definitely need something like UPnP, or maybe even UPnP itself, but it's another adoption problem currently.
AFAIK it doesn't use third party servers and it seems to get through any router just fine...
This can have quite an effect on sync speed. I set it up for my dad and initially his PC and laptop were syncing incredibly slowly. It turned out they both thought his home network was a public one, so everything was going out to a relay server and back.
This explains so much of what I’ve seen added to their codebase recently
Would love to give this a try, though from the post it's not clear if we could use our own custom domains instead of the provided ts.net ones? This is a necessity for my use case where I need to be able to handle wildcard subdomains.
> Our connector, cloudflared, was designed to be lightweight and flexible enough to be effectively deployed on Raspberry Pi, your laptop or a server running your data center. Tunnel does not programmatically enforce any throughput limitations.
> If you are hosting a Tunnel in GCP, AWS, or Azure you can view our deployment guides which are more prescriptive in assigning minimum system requirements.
https://developers.cloudflare.com/cloudflare-one/connections...
The big question is going to be pricing. The current top player in this space is Cloudflare Tunnel, which is a loss-leader product that technically forbids selfhosting anything other than HTML sites.
Selfhosting media can use tons of bandwidth. Any service that doesn't charge per GB is incentivized to limit your speeds.
[0]: https://github.com/anderspitman/awesome-tunneling