alt Hacker NewsAs someone with a background in electronics who doesn't manage any internet-connected equipment but has multiple embedded devices connected to a WAN, I'm glad that IPv4 still seems to have a bit of life left in it.
When IPv6 was developed, over 30 years ago, connecting everything to the internet seemed like a great idea. I know that IPv6 can be made secure, but I don't have the background or research time to learn how to do so, and the NAT-by-default of IPv4 effectively means that I get the benefit of a default-deny security strategy that makes it impossible to accidentally directly connect anything to the internet.
I'm hoping I can keep using IPv4 until IPv8 or IPv4.5 or whatever comes next is developed with the modern proliferation of cheap insecure IoT in mind.
For some background on why IoT products are so insecure:
Hardware manufacturers don't really comprehend the idea of updates, let alone timely of security patches. Hardware has to work on the day of release, so everything is documented and tested to verify it will work. I have hardware with a TCP/IP stack that was released 20 years, (https://docs.wiznet.io/Product/Chip/Ethernet/W5500) and doesn't have a single errata published, despite widespread use. This is expected for every single component, for even the smallest 1-cent transistor, which has dozens of guaranteed performance characteristics laid out over several pages of documentation (https://en.mot-mos.com/vancheerfile/files/pdf/MOT2302B2.pdf).
When manufacturers venture into a product that runs software, they don't realize that for a given complexity, working through undocumented or, worse yet, incorrectly documented APIs takes more time than the equivalent hardware development and documentation. I've worked on multiple projects where software bugs were fixed with hardware workarounds, because it's faster, cheaper, and easier to develop, test, document, retool, and add a few cents of bill-of-materials cost per product, than to get reliable output from the already-written library that's supposed to provide the functionality.
The hardware TCP/IP stack that I linked to was developed at a time when it was the cheapest way to connect a low-power embedded system to a network. Modern low-power embedded systems have multiple cores running at hundreds to thousands of MIPS making the resources to run a softtware TCP/IP stack trivial, but the product still sells well, because when security is an absolute must, the hardware development and maintenance cost for the functionality is still cheaper than through software, even when there's no marginal cost to run the software.
Replies
IPv6 is just as secure as IPv4. NAT usually combines address translation with a stateful firewall. I remember when they were separate things. IPv6 has the stateful firewall, all the same security but without the mess of address translation.
Also, if you have devices connected to WAN, then they are insecure because they are not NATed.
NAT is not a security measure at all. It just obscures what's behind a firewall, but that is leaky and not reliable from a security perspective. It might make you feel better, but that is not security.
> I know that IPv6 can be made secure, but I don't have the background or research time to learn how to do so, and the NAT-by-default of IPv4 effectively means that I get the benefit of a default-deny security strategy that makes it impossible to accidentally directly connect anything to the internet.
To get the "unsolicted traffic is rejected or dropped" behavior of the typical IPv4 NAT, forward inbound traffic that's related to an established connection and drop or reject the rest.
You can also use the exact same NAT techniques you use for IPv4 addresses with IPv6 addresses. The only differences are that instead of you using RFC 1918 Private Internets addresses (10./8 and friends) you use RFC 4193 ULA addresses (fd00::/8), and you need the usual NAT rules on your edge router, except for IPv6, rather than IPv4. Remember that IPv6 is still IP, just with larger addresses.
It's recommended that you generate your ULA subnet rather than selecting one by hand, but absolutely nothing stops you from choosing fd::/64. If you're statically assigning addresses to your LAN hosts, then your router could be -say- fd::1 and you count up from there. Also note that DHCP exists for IPv6 [0] and is used by every non-toy OS out there except for Android.
> I'm hoping I can keep using IPv4 until IPv8 or IPv4.5 or whatever comes next...
IPvnext is not happening in either of our lifetimes. You're either going to have to buy edge gear that's set up with a "reject or drop unsolicited inbound forwarding traffic" firewall, or learn how to set it up yourself. Either path is not hard. Well, I guess there's secret option #3: "Die without doing either.". That's also not hard.
[0] It has been around for nearly twenty-three years.
For some background why IoT products will stop being insecure: if you sell one in the EU, you're liable for all the damage your botnet causes.
Luckily, common EU home routers have firewalls, even for IPv6. And it's so much easier to punch holes on purpose! Instead of messing with port forwarding and internal and external IP addresses, you can just say "this device is a server, please allow traffic on port 80 and 443, thank you"
> the NAT-by-default of IPv4
IPv4 is not NAT-by-default. The reality of the world we live in today is that most home networks have a NAT, because you need multiple devices behind a single IP.
That said, I agree: it's quite unknowable how many services I've turned on on local machines with the expectation that a router firewall sat between me and potential clients.
But that doesn't go away with IPv6 - the NAT does, the router doesn't, and the firewall shouldn't either. For example, the default UniFi firewall rules for IPv6 are: 1. Allow Established/Related Traffic (outbound return traffic), 2. Block Invalid Traffic, 3. Block All Other Traffic
You must explicitly open a firewall rule for inbound IPv6 traffic. NAT is not the firewall.