Hacker Newsnew | past | comments | ask | show | jobs | submit | orangeboats's commentslogin

>Support for IPv6 is notoriously bad in residential modems.

No? Over here at (South) East Asia we have been deploying IPv6 for nearly a decade now. The users are getting their IPv6 connectivity. Before someone jumps out and shouts SeCuRiTy: the firewall is enabled by default.

I am not saying the support is perfect. I know some people moan about lackluster IPv6 configuration in many routers. But for 90% of residential internet users (who care about pretty much nothing but the ability to watch YouTube and browsing social media), it damn sure is.


I am tired of people claiming that you can make a "new Internet protocol that is compatible with IPv4".

No, backwards compatibility is not the problem here: IPv6-only hosts can easily connect to IPv4 hosts. Just append "64:ff9b::" to an existing IPv4 address, like so: 64:ff9b::8.8.8.8. Even prior to NAT64, we have plenty of schemes like 6to4 to bridge IPv4 and IPv6.

But no IPv4 hosts can ever connect to IPv6 hosts, or IPv7, or IPvInfinite for that matter. I will refer to my previous comment on why that is: https://news.ycombinator.com/item?id=46469336


I think the people complaining about compatibility are more talking about the concepts in IPv4 and IPv6. IPv6 could have been "everything is the same except the IP address is 16 bytes instead of 4". Instead there are new ways to do everything.

Addressing works differently (no broadcast, multicast everywhere, link-local is mandatory). Configuration works differently (SLAAC, RA, DHCPv6 is not a drop-in replacement for regular DHCP). Neighbor discovery replaces ARP and depends on ICMPv6 working. Fragmentation behavior changed. NAT is “not a thing” by design, which breaks a bunch of assumptions people built entire networks around.


Reading comprehension! The GP was clearly referring to the current AI boom, which is the root cause of DRAM price surging.


Very apt username for the occasion.


When something happens over IPv4 people treat it like "the Internet has malicious actors, water is wet", but when it happens over IPv6 it must be IPv6's fault.

Sigh...


Most network vulnerabilities apply equally to both, but of the ones that don’t, most are IPv6 only. This bothers me. I don’t like adding unnecessary attack surface to my infrastructure.


Compared to 0% like others?

50% is a very substantial retention rate.


Would hand been 100% if his site supported ipv4 natively instead of relying on CloudFlare to do the translation.

The story here is not “ipv6 made my site resilient to CloudFlare outage”. It’s “50% of my customers can’t reach my site even when I turn off CloudFlare”.


>if his site supported ipv4 natively

And it's becoming difficult for people to do so precisely because of IPv4 addresses running out...


Another day, another Godwin's law of networking.

>It was doomed the moment you had to maintain two separate stacks

Pray, tell me, how are we supposed to extend IPv4 with another {insert a number here} bits without creating a new protocol (that neccessitates running two stacks)?

Suppose that you have an old computer that understands only 32 bit addresses -- good ol' IPv4. Let's name it 192.168.10.10.

It then receives a packet from another computer with hypothetical "IPv4+" support, 172.12.10.98.12.4.24.31... ...Wait a minute, it can't, because your old computer understands only 32 bit addresses!

What if we really forced it to receive the packet anyway? It will see that the packet is from 172.12.10.98, because once again, it understands 32 bit addresses only.

It then sends back the reply to... you guessed it, 172.12.10.98. Not 172.12.10.98.12.4.24.31.

Yeah,172.12.10.98.12.4.24.31 will never get its reply back.

Do you see why any "IPv4 with extra octets" proposal are doomed to begin with now?


It wouldn't be able to receive it. That simple. Which is not a problem, any server would still have an old ipv4 address (172.12.10.98 from your example), like they currently do and probably will for decades.


Devil's advocate. There could be a extension for ipv4 stacks. Ipv4 stacks would need to be modified to include the extension in any reply to a packet received with one. It would also be a dns modification to append the extension if is in the record. Ipv6 stacks would either internally reconstruct the packet as if it were ipv6.


It would be easy to make such an extension, but you're going to hit the same problem v6 did: no v4 stacks use your extension.

How will you fix that? By gradually reinventing v6, one constraint at a time. You're trying to extend v4, so you can't avoid hitting all of the same limits v6 did when it tried to do the same thing. In the end you'll produce something that's exactly as hard to deploy as 6to4 is, but v6 already did 6to4 so you achieved nothing.


Having just optional field in the ipv4 header with extra address bits would leave all the stack source code with just some 100 lines of extra code. Would mean, you can have one stack that handles just both. Make special addresses where the additional bits are all 0, which means the field is not there at all. These addresses could reach ipv4 only addresses and could be reached from them. When you really want to make sure these devices aren't parsing ipv4+ packets, change the checksum-code for all packages that contain the optional field. That would mean all ipv4 only devices would ignore ipv4+ packages. Instead you could change the version to 5 for all with optional address bits.

This is stuff that could be implemented in any ipv4 stack in some days of work.

IPv6 is overengineered, thats the reason why it's not adopted after 30 years.


You clearly do not understand networking. Or else you won't make such a statement:

>This is stuff that could be implemented in any ipv4 stack in some days of work.

The sysadmins across the world, who had to deal with decades-old, never-updated devices facepalmed in unison.

At least the other comment agreed that "IPv4+" hosts will never be able to talk to IPv4 hosts.

>IPv6 is overengineered, thats the reason why it's not adopted after 30 years.

It is already adopted in many countries. Don't blame the protocol for your countrymen's incompetence.


By being IPv6-only they are effectively making their users to preferentially connect over native IPv6 though.

Personal anecdote, but once you have IPv6 setup properly (meaning your devices prefer IPv6 over IPv4) 70-80% of your internet traffic will be IPv6.

The NAT64 is really just there for the holdouts.


I run dual stack at home with dns64/nat64. I average 50/50 traffic v4/v6. Web browsing gets skewed v6 but large file transfers and some streaming pushed it back to 50/50 overall. My family would revolt if I went v6 only so I'm not sure I'd say its just there for holdouts. Major annoyances include any old device and my hue bridge.


>CGNAT is nowhere near the common case yet. And frankly, I’m horrified that anyone’s describing it as a good thing.

For some reason, "CGNAT == privacy" is a very common sentiment on Hacker News. Yeah, Hacker News. It's bewildering, and after my last comment [0] talking about it, I have kinda already given up trying to convince people that CGNAT is devilish and not at all a privacy protector.

[0]: https://news.ycombinator.com/item?id=40180058


It’s right up there with “NAT == security”, which is also disappointing for here. It’s not so much the sentiment, as how confidently it’s asserted.


Without NAT my computer isn't on the internet, because my ISP only affords me one IP which my router uses. If it's not on the internet, and adversary can't send my computer any packets.

With NAT, an adversary can't send my computer any packets either unless I explicitly set up port mappings.

So, if you can't send my computer any packets, how is it not providing security?

Of course, it doesn't provide full security like a firewall can do, since there's ways to punch holes in the NAT from the inside. But it seems just as incorrect to fully dismiss "NAT == security".

NAT provides some functional security. It is not a replacement for a proper firewall.


My question with all of the lovely IoT devices that rely on that same mechanism is. Why would you even care about connection from outside? Shouldn't you also be secure against inside? Trusting on NAT alone is idiotic and foolish. If you want to protect a port do it properly in the first place. No excuses.


> Why would you even care about connection from outside?

Because if those nice IoT devices were reachable from the internet they could be compromised easily due to their likely shitty firmware with backdoors and hardcoded passwords.

> Trusting on NAT alone is idiotic and foolish.

Sure, but that's a far cry from saying NAT provides no security.


>IPv6 ... still hasn't taken over the world [after thirty years of deployment]." is a very different statement than "IPv6 has failed.".

It's incredibly likely that the GP was referring to comments in this thread, which were indeed claiming that IPv6 has failed, despite the fact that its deployment has been steadily climbing up worldwide.

By the way...

>In the future, SOHO/home LANs can run servers on IPv6

The future is now. My web server is IPv6 only precisely due to the same reason you mentioned: my ISP has put me under a CGNAT. People can still connect to my website through the Cloudflare reverse proxy though (which I have only enabled for IPv4, IPv6 users get to enjoy direct connection).


> The future is now.

One part of it is for some-to-many folks, yes, and the third is here for a distressingly large number of people (without the solid support of the second part). Do note that the future I outlined has three parts. ;)


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

Search: