In the new standard every publicly routable packet will include a cryptographically signed passport number of the responsible person.
Then the government could, for example, limit criminals' access to the internet by mandating that their packets be dropped on most major ISPs, or at least deprioritised.
Funny enough I actually looked at a scheme for corporate networks where your personal corporate ID is encoded as part of the host bits of the IPv6 packet and policy could be applied based on who you are instead of what machine it is (or both). It was kind of neat but the complexity was too high for it to gain traction, and also it turns out that most corporate networks are allergic to IPv6 and government networks doubly so.
Hostnames are either in a static hosts file, which you need to distribute to your machines somehow (probably using older names or raw addresses, which you do not know, because need the names in the first place), or a DNS, and for most people the DNS is under ISP's control.
Even if you have your own DNS server out there somewhere, you still need to allow a bit of DNS hijacking from your ISP in order to receive that verification SMS and enter the code into the ISP's log-in page.
DNS is a great thing, but just too much of a pain to configure.
It doesn't really matter. Any communications provider must keep call records for the FSB, so routing them through central servers and recording there is the only option anyway.
Of course it matters. STUN isn't theoretical, it's in actual, practical use across a great many things. There's plenty of things that aren't "calls" in a telecommunications sense. Discord, Telegram, Zoom, Slack, Jitsi, and far more. And there are plenty of other things entirely that use the same tactics to get direct peer-to-peer connections.
That is a quite extreme outlier, then. Hardly relevant to the global IPv6 and peer-to-peer conversation we're having here, and your objection still only applies to one narrow use of the technology under discussion.
>That is a quite extreme outlier, then. Hardly relevant to the global IPv6 and peer-to-peer conversation we're having here
It's China with it's 1bn of internet users and 2bn+ devices .
If you're happy to exclude half of the internet from your "global peer-to-peer conversation", then you don't need ipv6 either, just use the Chinese IPs for your own purposes, there are plenty of them.
Actually this is the attitude I am seeing from the ipv6 zealots all the time: blatant disregard of reality. Nobody wielding and non-negligible amount of power wants peer-to-peer communication. Companies don't want it, governments don't want it, large masses of people who want a person with a vested interest to be responsible for the link quality don't want it.
What ipv6 zealots don't realize is that ipv6 will not bring them their coveted p2p, because, guess what, incoming connections are to peasant computers are blocked by ISPs by default.
As I said, p2p benefits even you right now, today, on IPv4, despite your unwillingness to acknowledge it. I've never even owned an IPv6 address in my life, so this mental image you've painted of myself and of our interaction is quite inaccurate.
You've taken this conversation quite far off its rails. This started due to your objection about phone calls not benefiting from P2P connections, which as I said are one narrow use of the overall technology. P2P connections are still useful. Nobody's blocking China. China connects peers, too.
I'd also like you to clarify something for me, earlier you mentioned P2P doesn't work, specifically for calls, specifically for your country, because all calls need to be transported through the FSB. This isn't any sort of accusation, I fully believe you are in China, but I'm curious what the FSB has to do with you in that case?
You don’t need to allow peer-to-peer connections with IPv6. They’re easier to allow and book keep - but also easier to block. The workarounds for peer-to-peer with IPv4 NAT are extremely difficult to detect and stop (STUN, various proxying setups, etc.). A lot of software does it though, for performance reasons. CGNAT is quite expensive and error prone, and causes a lot of support calls too.
Every ISP router I’ve gotten (US, India, Brazil, Germany) in the last few years had IPv6 AND default block for inbound connections in the stateful firewall. Which is fast, cheap, and easy. And most of my traffic (~90%) ended up being over IPv6 by default in a dual stack environment, with certainly no apparent latency penalty. In most situations, a latency decrease near as I can tell, as I didn’t need to route through someone else’s random servers at first to initiate connections for certain kinds of traffic. And no, I wasn’t torrenting.
The hilarious thing here is what is even the fight about?
There are too many humans on this planet for even one IPv4 address per, and too much traffic/connections to sanely coalesce every thing under CGNAT - and why go through all the trouble, when IPv6 is simpler and faster at an infrastructure level anyway than multiple layers of CGNAT and dealing with all the crazy BS that comes up when you have that much address translation and packet rewriting going on.
Which, notably, is more expensive than the more straightforward stateful firewall stuff anyway.
No one is intentionally going to IPv4 unless they have no choice due to backwards compatibility, and that is an increasingly shrinking pie. In another 5-10 years as the old consumer gear finally EOLs, it’s probably going to only be used for niche backwards compatibility (like RJ11 and the old school telephone system), and corporate use where their EOL timelines look more like 50 years. But pipe over tunnels over IPv6.
Which works great BTW - 90% of my active IPv4 usage is for internal servers using Tailscale, which is all actually transported over IPv6. And it does that because while it can use CGNAT punching tricks with TUN/S, etc. it’s faster to just connect directly (through the firewall rule I explicitly created to allow this).
And that is just because the Tailscale software prefers to display/default copy-paste it’s internal IPv4 addresses over internal IPv6 addresses for some reason, which I’m sure will change at some point.
It doesn't really matter where I live. In any case, "worksforme" ia not a solution.
We are discussing a supposedly global standard, which should work and be better for everyone, including Russia, China, Iran, everyone.
You know, Western politicians usually have exactly the same desires as their authoritarian Eastern counterparts, they are just unable to express them publicly. But hey, ipv6 is a niche problem discussed only by geeks, they don't actually have to say anything publicly about it, they can just silently sabotage its implementation.
China obviously has a state security service, but it doesn't really matter, I used FSB as a generic term for a law enforcement agency which tells ISPs what to do.
What do you mean by popular? I hosted a site on a home machine in the early teens. If you don't know how to do that with NAT, you should not have a web server under your control exposed to the internet.
The early teens didn’t have huge proliferation of ISPs using CGNATs.
These days ISP can’t get hold of new IPv4 blocks, and increasingly don’t provide public IP addresses to residential routers, not without having to pay extra for that lowly single IPv4 address.
Hosting a website behind a NAT isn’t as trivial as it used to be, and for many it’s now impossible without IPv6.
> Hosting a website behind a NAT isn’t as trivial as it used to be, and for many it’s now impossible without IPv6.
The example I keep coming back to is multiplayer games like Mario Kart, where Nintendo tell you to put the Switch in the DMZ or forward a huge range of ports (1024-65535!) to it [1].
If you’ve got more than one Switch in the household, though, then I guess it sucks to be you.
To require that, the person would have needed to disable upnp on their router. I’ve played tons of multiplayer games on the switch and upnp handled it seamlessly on the 7 or 8 home networks I connected it to over its life. Never once even had to think about it.
So yes, if you disable the requisite, standard, built-in feature on your router, you may need a pretty annoying workaround. Weird!
What percentage of users do you imagine disable upnp? Let’s be real. This is a problem that your average user will never, ever experience a problem with.
No they wouldn't. UPnP is not requisite, certainly not standard, or necessarily built-in. For example, the router I've got doesn't implement UPnP.
It's not unusual for it to be disabled, because it's a security issue that something with no authentication can punch enduring holes out through NAT.
It's also irrelevant in a scenario where the ISP's using CGNAT.
I'm sure the Switch deals with conflict resolution with multiple consoles on the same network too but shrug it's another example of how NAT is a pain and also contradicts your assertion that incoming connections would be a breach of ISP ToS [1].
Edit: A quick Google suggests the Switch originally didn't support UPnP, and the Switch 2 now supports IPv6.
Ok, so it didn’t even need upnp then. Are you talking about using their LAN head-to-head feature across the internet? Or perhaps all the times I used my switch on various networks to play head-to-head games it was… my imagination? Sure. If people had to consistently forward every port on their home router to play Fortnite, smash, etc. with a portable console you’d never hear the end of it. This is literally the first time I encountered someone saying this was a problem. Regardless, most people don’t buy routers— they use the ones their ISPs gave them, and I haven’t seen one of those come without upnp in at least a decade. You’re seeking out reasons to dislike NAT.
Would you be interested in a small commercial application of your node?
I need a few messages transmitted to as many peers as possible once in a while.
Nothing illegal, just a small contribution to the economy.
We're selling pure herbal organic medicine which helps males perform better, and our product announcement will fit perfectly in you 200 characters limit.
reply