5 ms·
Maybe. In the alternate reality, we probably would have the same threats on the internet as we do today, and the same boneheaded software that misconfigures thi
by ninkendo 2y ago
Maybe. In the alternate reality, we probably would have the same threats on the internet as we do today, and the same boneheaded software that misconfigures things, so my guess is that we’d still have consumer firewalls at the gateway that just default-deny everything. Maybe there would be better standards about auto-configuring these firewalls though. (Or maybe the standards we already have would have just been better supported?)
But for certain, today if we had IPv6 everywhere, it still wouldn’t let you design something like a VoIP phone (or a pure peer-to-peer version of FaceTime) that just listened for connections and let other people “call” you by connecting to your device. That software would only be usable by people who know how to configure their router, and that doesn’t make for very good market penetration. You still need something like UPnP, so you’re basically right back to where we are today. At least the connection tracking would be stateless, I guess?
- vel0city 2y ago> You still need something like UPnP I have two SIP phones both wanting to register port 5061 to forward to their address. How does this work with IPv4/UPnP?
- ninkendo 2y agoI’m not talking about SIP, I’m talking about a hypothetical piece of software that an IPv6 proponent may typically claim that is made possible by unique GUA’s for each device. My point is that the GUA alone isn’t enough to make this work, you still need: - UPnP or something like it - A place to register your address, since they change all the time even in IPv6 And if you need these two things anyway, you can do this with IPv4, with the added change that you also include the port when registering your address, which makes the “multiple phones in a network” thing work.
- vel0city 2y ago> I’m talking about a hypothetical piece of software that an IPv6 proponent may typically claim that is made possible by unique GUA’s for each device. Like, say, a SIP client? Wanting to listen on the standard SIP port? Or say two web servers that both want to listen on :443 and you don't want to have to reverse proxy them from another box. > UPnP or something like it > https://datatracker.ietf.org/doc/html/rfc6887 https://datatracker.ietf.org/doc/html/rfc6887 Port Control Protocol seems to be pretty well supported on most of the devices I own even in IPv6. And in the end I'm pretty boned if I'm on CGNAT usually. I can pretty much never get my Switch to do matchmaking with peers on IPv4 when I'm on a CGNAT network. If we were all on IPv6, it wouldn't be a problem.
- ninkendo 2y ago> Like, say, a SIP client? No, not like, say, a SIP client. You seem pretty intent on not reading my whole comments or something. Mind responding to what I’m saying and not just making up your own arguments? I’m saying “ipv6 alone won’t solve X”, and you’re saying “but what about Y?”
- vel0city 2y agoI'm saying "but what about Y" and you're acting like Y is never a valid issue that anyone ever seems to have. So once again, how do two devices both share port 5061 on a UPnP NAT with a single public IP address? Or even worse, if they're CGNAT'd? It's a simple answer with IPv6...
- ninkendo 2y agoAgain with the not reading. Let me try to sum up my position so we can end this whole “nuh uh!” nonsense. IPv6 was designed in a world where we thought we’d have a truly peer-to-peer internet where anyone could just talk to someone else’s device. This obviously isn’t what happened. An ipv6 proponent may say “this is because NAT breaks the necessary assumptions”, but that’s extremely oversimplified and wrong. The reason that, when I use my iPhone to FaceTime my mom’s iPhone, it doesn’t just use SIP to contact her phone, isn’t because IPv4 and NAT. It’s because the very idea of that is nearly impossible to implement at scale even if everyone had a unique address. I’m aware you can’t have multiple devices behind a NAT address listen on the same port. Thank you for pointing that out, you’re very smart. But it really doesn’t address my point at all, does it? My point being that the reason we don’t use SIP and related technologies for billions of end user devices today, isn’t because of NAT. It’s because the myriad of other problems that would need to be solved for it to work reliably, and because of NAT. Eliminating NAT wouldn’t really meaningfully change the landscape of how software works. FaceTime calls would still go through Apple servers. People would still use centralized services run in real data centers, etc.
- vel0city 2y ago
- Hikikomori 2y agoWhy would they need the same port?
- vel0city 2y agoBecause they don't want to have to rely on an external service to find the right port. Just like how your browser doesn't need to be told to connect to :443 for HTTPS. If you're connecting encrypted SIP, the port is assumed to be 5061. Just like HTTP is assumed to be 80, SSH is 22, etc.
- Hikikomori 2y agoBut the external service needs to know your ip, so why not port as well?
- vel0city 2y agoDid you have to look up something to know this site is hosted on :443 or did you just make an assumption? Some kind of standardized port you connected on? Wouldn't it be nice if every device could just assume the standardized ports were available for them if they wanted them?
- Hikikomori 2y agoVOIP systems don't really work like random webservers though.
- vel0city 2y agoThere's little reason why they couldn't though. Why shouldn't I just call Apple by doing sip://support.apple.com ? Why can't people just call me at sip://desk-phone.vel0city.whatever (they actually can, if they know the right name) or sip://cell.hikikomori.apple.net ? Instead, we're locked into proprietary platforms or relying on old phone systems.
- saurik 2y agoThe two devices shouldn't both need to be on the one port 5061: we have numerous solutions to that problem at this point, from specifying the port as part of the connection to auto-detecting it using SRV in DNS. Yes: making some small changes to existing software to not assume hardcoded ports is required in this future... but there is no way that those changes would have been (or frankly even still are) harder than the insane solution of reimplementing and redesigning the entire world--requiring its own changes to every protocol (including SIP) and breaking a strict and extremely large superset of the same references that merely needed a port number--to support IPv6.