> ok, but why?
So we can get rid of STUN/ICE/etc and make peer-to-peer easier. All you're left with is hole punching through your SPI firewall (no worse than today).
> Are you _really_ just going to allow random traffic into your network?
I don't know why this misconception is so wide spread: globally addressable ≠ globally reachable.
Firewalls still exist with IPv6.
Before I recently changed ISPs, I was with one which gave out IPv6, and so all devices had an address (including things like my printer). But I couldn't initiate connections from the outside in—only replies to internally-initiated messages were let in by my Asus.
Even if things were wide open—which they were not—good luck scanning a /64.
Do you really think Roomba is going to let you run your Robot Vacuum without contacting, er permission, from their data center in Virginia?
So this is completely unrelated. IP addressing schemes will not change the business methods of large consumer device companies.
That's exactly the point; they market it as if it would make a plethora of new and innovative things happen but in reality they will allow none of it.
So, it's pointless to rush adoption.
How much innovation and applications have been stymied by artificial network-layer barriers:
> First is actually a more subtle issue... the Skype peer-to-peer network architecture elected certain nodes to be "supernodes", to help maintain the index of peers as well as handle parts of the NAT/firewall traversal for other peers.
* https://ip.topicbox.com/groups/ip/T9f6a724f4bcd6616-M0e99aba...
* https://arstechnica.com/information-technology/2012/05/skype...
CPE gear has gotten better hole punching over time (PCP, UPnP), but one still has to futz around with STUN/ICE/TURN.
We've invented entirely new protocols (QUIC) because of middleware boxes blocking things (SCTP, DCCP) and generally getting in the way.
What I meant in the grandparent comment is that if a company makes it their business strategy to have all devices call home, they will do that regardless if they use ipv4 or ipv6. But if ipv6 is widely implemented and there is no cost to ip addresses, it is entirely possible that another company can create an ap that allows you to directly communicate to your devices without using a central server.
Ideally yes, but IRL they are related concepts. Things will get misconfigured, often by default.
> So we can get rid of STUN/ICE/etc and make peer-to-peer easier. All you're left with is hole punching through your SPI firewall (no worse than today).
There’s (IMO) a much better reason: so your endpoints can have globally unique addresses. If I have a service in Google Cloud and a service in AWS and an on-prem service and a customer service and ten different upstream services from ten different hosted providers, I want these services to have different addresses, TYVM. And I want to configure my networking to them without needing to worry about whether all parties actually agree on the addressing scheme.
This is far more important than actually making anything globally routable. If my AWS thingy is 192.168.3.7, I don’t need whatever random third party service I’m using to be able to route to 192.168.3.7 (and I’d probably prefer that it not be able to route there). But I don’t want to worry about the service provider using 192.168.3.7 for another purpose.
I’d also like traceroute to work without having a bunch of intermediate hops where the addresses simply cannot be mapped to their owners without extra side knowledge of the network topology.
Complications with address space collisions (esp. M&A) was one of the reasons give in this Wells Fargo presentation from 2014:
Because NAT breaks a lot of services.
> Is that going to change with ipv6?
Yes. You no longer need NAT, so port negotiation is much easier (even when inbound is blocked)
> Are you _really_ just going to allow random traffic into your network?
Common misconception! Even without NAT, the router can have port/traffic policies. There's just no address translation happening.
There's a lot of good stuff about IPv6, and I would encourage more people to learn about it and try it out.
- ULAs can act like static internal LAN addresses
- A "strong" NAT is easier to avoid and no longer breaks connections to things that are sensitive like gaming consoles
- Randomized, temporary IPv6 public addresses are a nice feature, and mostly turned on by default
- The biggest one is people seem to equate NAT = router/firewall. This is absolutely not the case, and they are distinctly different. You can absolutely have a router/firewall without NAT!
- CG-NAT is becoming more popular due to the lack of IPv4 addresses, and I hate everything about that.
- You can even run a NAT64 to provide IPv4 access to your IPv6-only devices
Which ones? I'm here and everything works right now. Literally everything works just fine. Please name exactly one service I have right now that is broken because of NAT.
https://serverfault.com/questions/208522/what-is-strict-mode...
This can particularly play havoc with sensitive protocols like STUN. I believe many game consoles make use of this when in multiplayer matches. I have personally run into this using OpenBSD's pf, but I'm fortunate enough to have access and the known-how to fix it for my consoles.
It's one of those things that's fine until you run into "edge cases," and unfortunately NAT configurations can introduce a lot of undefined behavior from the user perspective.
Two peers, each behind a CG-NAT (or other symmetric NAT), depend on somebody running a relay in order to be able to communicate.
This makes it very expensive (and sometimes risky, since unrestricted relays can be used for all kinds of nefarious things too) to deploy any new VoIP service.
I'd call that "broken by NAT".
> everything works right now.
Yes, everything that works right now works right now, but that's a tautology, not proof of anything. The things that don't exist because they wouldn't work in a predominately NATted world don't work, because we live in a predominately NATted world.
IPv6 (or more generally, the absence of NAPT) just changes the switch label from "try [not] to use direct connections, unless NAT gets in the way" to "[always|never] use direct connections".
In other words, it cleanly separates the two distinct concerns of privacy and connection topology. I think that's a good thing.
Furthermore, in populous countries like India, ISPs enforce extremely aggressive timeouts on IPv4 connections in order to keep the 5-tuples on the egress side of things manageable. Trying to make a request that takes 10 seconds to process (like a user requesting a report consisting of multiple SQL queries)? You get a connection reset.
I must also must point out the HN guidelines because you bring a combative tone to this entire conversation which is not helping it.
> Be kind. Don't be snarky. Converse curiously; don't cross-examine.
But isn't all that still necessary as long as the typical user isn't going to be opening their firewall on those ports to arbitrary incoming connections? That's the whole point here.
And STUN scales almost infinitely better than TURN.
I dont think anyone equate that, but IPv6 proponents refuse to recognize that decades and decades, especially in home users, and SMB space, NAT was a layer of the security model, often times one of the biggest
Right or wrong is irrelevant, that is/was the reality
Just tossing IPv6 as a replacement for ipv4 with out factoring that in while simply screaming into the void "NAT IS NOT A FIREWALL" will be of little comfort to the elderly retiree that has their home computer ransomwared, or the small business that is put under due to a cyber attack because the ipv6 address was strait on the public internet
If an IPv6 home router closes all ports by default, then the same level of security is achieved.
> Randomized, temporary IPv6 public addresses are a nice feature, and mostly turned on by default
I really do not want this.
Then disable it. IPv6 SLAAC privacy extensions are device-controlled, meaning neither your ISP nor your router can force you to use/not use them (unless they're so incompetent that they do things like hand out /128s).
The rare times I want something publicly accessible, I use DMZ or port forwarding.
If you take away the mapping the tracking doesn't go away. Inbound traffic still needs to match to to a session created by outbound traffic.
https://datatracker.ietf.org/doc/html/rfc2993#page-22
https://threatpost.com/remote-attackers-internal-network-dev... https://www.anvilsecure.com/blog/dhcp-games-with-smart-route...
Not really. Many home routers used to assign all ports to the first device to connect to the router, and you'd need to setup NAT just for your second computer. Eventually the default settings wised up.
It is much more probable that security defaults will be much tighter today than they were when ADSL initially took off.
This is definitely what I'm seeing. IPv4 is really engrained in us - I actually had a really hard time conceptualizing how things worked until I forced myself to learn by deploying dual-stack and ipv6-only networks.
The major downside I see right now is that "addresses are harder to memorize," but there are solutions to that as well.
Definitely. That DNS thing sounds promising!
When IPv6 was created they had the opportunity to just make it an expansion of the IPv4 space they chose not to do that and instead they added in a bunch of wish list items that were not needed to accomplish the goal that they were seeking to do which was prevent the exhaustion of IPv4 addresses
Absent address space exhaustion I massively prefer working with IPv4 than I do IPv6
In practice someone can still configure NAT on IPv6 same as on IPv4 at least on Linux and some vendors, even if IETF resists standardizing it.
https://blogs.infoblox.com/ipv6-coe/you-thought-there-was-no...
So you might still see CGNAT if someone is determined to configure it.
As for public reachability, most OSes have a firewall of sorts (nftables, pf etc.) and can be configured to block traffic by default; on consumer OSes they already do so. There's also the local unicast range fc00::/7, which seems conveniently forgotten about in these kinds of comments.
CGNAT on IPv4 is not gonna save you from the Big Brother. IPv6 has many issues, but it is disingenuous to say the least that "it's a distraction from the big problems." The big problems you're talking about are completely unrelated to your IP packet version, and are not to be fought easily on this battlefield.
Anti-ipv6 is like the NIMBYism of IP address space, why can't we just "build" more to inflate the supply and crater the prices of existing ones?
> Do you really think IoT device makers are going to allow your smartphone to connect directly to your device
This happened because of IPv4 NAT.
You might not be facing issues in your country but here in India millions are behind NAT and it degrades QoS
> Is that going to change with ipv6?
Yes, because stateful firewalls are much easier to consistently traverse than NAPTs. This alone is a huge advantage for P2P applications.
Behind a (usually symmetric) CG-NAT, I have no way to directly connect to anybody else behind one without a relaying server (which are expensive and add needless latency).
> Are you _really_ just going to allow random traffic into your network?
No, but nobody is suggesting that.
> ipv6 is a distraction from the really problem of control and privacy
IPv6 is also doing nothing to combat pollution by microplastics and overfishing.
We disagree but I actually laughed at that.
Having globally unique addresses removes the need of (stateful) mapping tables, which in turn make it easier to intentionally allow traffic in.
In other words, it's quite hard to even name the traffic you want to let in if names are globally overloaded.
> ok, but why?
Because it makes things easier.
> Is that going to change with ipv6?
It already has.
> Are you _really_ just going to allow random traffic into your network?
Doesn't mater if I _am_ or not. I want the option. (And before you say port forwarding: try forwarding ports when its your ISP doing the NAT)
Why not?
The predecessor of my ISP introduced full IPv6 support for all customers 15 years ago. The only argument against at this point is inertia.
Instead, ipv6 created a separate world, with extra goals like making every device addressable (aka removing NAT), using randomized addresses, and resetting all ownership of existing blocks. "We're out of addresses" is not a good excuse for all that.
That's not possible. IPv4 addresses are 32-bit numbers. Once you change that, you're no longer "preserving existing addresses".
> once enough routers are updated to support them.
That's actually "once all routers and end devices are updated to support them". As the classic spamsolutions.txt says, "requires immediate total cooperation from everybody at once".
> This could've even used the exact ipv6 packet structure, making it quite similar to v6 under the hood but more like v4 from the user's perspective.
Changing the packet structure means changing all hardware and software (yes, software too, the API for IPv4 uses 32 bits for the addresses). The changes visible to the user are the easy part.
> Instead, ipv6 created a separate world, with extra goals like making every device addressable (aka removing NAT),
It's more like "not needing NAT" than removing it; port mapping NAT is not a part of IPv4 (it's a hack on top of it), and it can be done identically in IPv6, but few do it on IPv6 since it's not necessary.
> using randomized addresses,
This is an optional thing which was added later; nothing in IPv6 requires randomized addresses, but IPv6 makes them possible by virtue of having enough free bits in the address. Were randomized addresses possible with IPv4, we'd see them happening.
> and resetting all ownership of existing blocks.
IPv6 has done no such thing; the existing IPv4 blocks are still there.
This point cannot be emphasized enough. To quote Hyrum's Law [0]:
> With a sufficient number of users of an API, it does not matter what you promise in the contract: all observable behaviors of your system will be depended on by somebody.
And for networking this means that, even if the NRO decreed that all reserved/testing IPv4 blocks [1] would be publicly routable and turned over to the RIRs for allocation, those blocks would be effectively unusable. It doesn't matter how many RFCs you produce saying "you must assume these addresses will be someday used", networking hardware and software has ossified around specific expectations pertaining to what addresses are valid and invalid, what protocols are acceptable, etc.
A great example of this is TLS 1.3: due to protocol ossification, the spec had to be rewritten to be more similar to TLS 1.2 because network middleboxes kept assuming it was a threat and blocking the connections [2]. This is also the reason SCTP has yet to gain widespread adoption, and why any new layer 4 protocol is likely doomed to fail: networking hardware hates anything that deviates from the acceptable traffic patterns which have been hard-coded in, RFCs be damned.
Imagine if previously unused IPv4 blocks started getting allocated. You'd be cut off from most of the internet, and most of the internet would be cut off from you. It wouldn't be enough, of course - even if all 2^32 addresses were publicly routable, that's still not even enough for 1 IP per person, you'd still have to rely on NAT, and all the problems it causes. (This is also why I think suggestions like "organizations like Apple who have a /8 but barely use it should just give up those extra IPv4s" are misguided and really understate of the scale of the problem - it's just putting a band-aid on an open fracture that cut your femoral artery.)
[0]: https://www.hyrumslaw.com/
[1]: https://en.wikipedia.org/wiki/Reserved_IP_addresses#IPv4
[2]: https://blog.cloudflare.com/why-tls-1-3-isnt-in-browsers-yet...
I am uniquely employee number 6100. That field is 32 bits in HR's database. If they make it 64-bit, I'm still 6100.
> That's actually "once all routers and end devices are updated to support them". As the classic spamsolutions.txt says, "requires immediate total cooperation from everybody at once".
No it doesn't, it requires gradual cooperation, as the 4.1-compatible hosts will still speak v4 as needed. Same as how v6 stack support was added even to hosts not using it.
> It's more like "not needing NAT" than removing it; port mapping NAT is not a part of IPv4 (it's a hack on top of it), and it can be done identically in IPv6, but few do it on IPv6 since it's not necessary.
Yeah but the goal is to remove it. The feature set of v6, including random addressing, is intended to support p2p applications. The authors of ipv6 did not envision NAT being enable by default. Defaults and intent matter more than technical details here.
> IPv6 has done no such thing; the existing IPv4 blocks are still there.
They aren't there on practically any ipv6 network, despite an optional ipv6 extension for v4-mapped addresses. That's the critical difference vs what I've described.
* "OMG Every device needs a publicly addressable IP!!!"
ok, but why?
* "It's so hard to initiate a connection to something behind a ipv4 NAT firewall!! "
Is that going to change with ipv6?
Are you _really_ just going to allow random traffic into your network?
Do you really think IoT device makers are going to allow your smartphone to connect directly to your devices at home without going through their private AWS servers?
ROFL, lol, no, they're not going to give you direct control of the devices you own.
ipv6 is a distraction from the really problem of control and privacy, and given who is pushing for it the hardest: Facebook, Google, Amazon, and the like, it's no wonder. I usually think HN'ers see the big picture but it blows my mind how little people are reading between the lines.