News for hackers. Stuff that matters.
Re:IAB Statement on IPv6 by ncw33 on Tuesday November 08, 2016 @08:38AM (#12900081)
Not much! Just a few bytes for each packet. Running a NAT service requires a big table of all the active connections, ie. it's stateful - IPv6 with no NAT needs no per-connection state in the router so that's a big space-saving.
Re:IAB Statement on IPv6 by proactivesvcs on Tuesday November 08, 2016 @09:18AM (#12900362)
As I understand it, there have been a few nation-scale Internet outages that have been a result of IPv4 address tables reaching their resource ceiling (not relating to NAT) - another example of how IPv4 is no longer fit for purpose regarding hardware resources.
Re:IAB Statement on IPv6 by mprovost on Tuesday November 08, 2016 @01:44PM (#12902816)
Those were caused because Cisco by default (optimistically) partitioned a big chunk of the routing table memory for v6 routes. The fix was to reduce the memory usage for v6 and give that memory back for v4 routes. So really it was allocating so much space for v6 before there was any need that caused those outages.
Re:IAB Statement on IPv6 by tptacek on Tuesday November 08, 2016 @12:55PM (#12902397)
If 32 bit address tables are reaching capacity, increasing the size of the address space is unlikely to resolve the problem.
Re:IAB Statement on IPv6 by mikecb on Tuesday November 08, 2016 @01:47PM (#12902844)
Doesn't ipv6 include efficiencies for this, like hierarchical prefixes?
Re:IAB Statement on IPv6 by tptacek on Tuesday November 08, 2016 @01:56PM (#12902911)
In practical reality, doesn't that just mitigate the strain caused by an explosion in the size of the address tables?
Re:IAB Statement on IPv6 by toast0 on Tuesday November 08, 2016 @09:51PM (#12905758)
A sometimes large but solvable part of the problem in ipv4 routing table sizes is numerically adjacent routes that could be aggregated into fewer announcements but aren't; ipv6 doesn't help with that. Another part of the problem is that many networks have lots of allocations that aren't adjacent, so they can't aggregate them; ipv6 should help with that as there's room for big allocations.
Re:IAB Statement on IPv6 by mikecb on Tuesday November 08, 2016 @02:28PM (#12903200)
I guess it depends on how big the efficiency gain is, but afaik it's pretty big.
Re:IAB Statement on IPv6 by _red on Tuesday November 08, 2016 @09:08AM (#12900296)
So you don't want stateful inspection on your private LAN router? Its ok for every hacker to portscan the 100's of IoT devices in your house? You're a very trusting fellow.
Re:IAB Statement on IPv6 by lmm on Tuesday November 08, 2016 @10:43AM (#12901098)
How many IoT devices need to allow incoming connections at all? And how many connections do they need to make?

IoT devices, if I had any use for them, would go on my private LAN. My private-public router can do complex stateful tracking, because it only has to handle a few connections at a time. Meanwhile my grown-up internet devices go on the public side and get actual internet access, meaning that e.g. two people inside my house can play an online game with a person outside my house, and aren't slowed down by a complex connection-tracking router. Also means my guests don't get access to my IoT devices.

Re:IAB Statement on IPv6 by buzer on Tuesday November 08, 2016 @11:10AM (#12901357)
> How many IoT devices need to allow incoming connections at all? And how many connections do they need to make?

If they need outgoing connections, they likely also need incoming when we are speaking about stateless filtering. Without incoming connections only UDP would be allowed and it would be usually impossible to determine if the packet should be send again (it would only be possible if there was out of band method to detect it).

Ok, I will admit that it's possible to check the TCP headers and just drop incoming SYN packets without ACK, but then you need to start trusting that the IoT device can handle invalid TCP packets.

Re:IAB Statement on IPv6 by lmm on Tuesday November 08, 2016 @11:16AM (#12901423)
> Ok, I will admit that it's possible to check the TCP headers and just drop incoming SYN packets without ACK, but then you need to start trusting that the IoT device can handle invalid TCP packets.

I have more faith in that than I have faith in a router that does complex state-tracking logic to not contain RCE vulnerabilities itself.

Re:IAB Statement on IPv6 by woah on Tuesday November 08, 2016 @10:03AM (#12900742)
Are you recommending NAT as some sort security-by-accident measure?