News for hackers. Stuff that matters.
Re:Reasons for servers to support IPv6 by tyingq on Saturday January 29, 2022 @10:58AM (#30127301)
I'll admit to not understanding this position. Without NAT, you could do the same sort of firewalling, where the inbound allow list is driven dynamically. The only thing I can think of is that not using NAT exposes more detail about an internal network. Is that the reason you're hinting at, or is the reason something else?
Re:Reasons for servers to support IPv6 by justsomehnguy on Saturday January 29, 2022 @11:15AM (#30127473)
It's extremely funny how a network with NAT needs hole punching in the firewall and network without NAT sudenly doesn't have firewall at all. Like OK, in 1995 a router would have been a dedicated machine or appliance, but since 2005 anyone can buy a sub $30 device which routes, firewalls, provides a bunch a of (unnecessary) services... but suddenly incapable of firewalling if IPv6 is involved.
Re:Reasons for servers to support IPv6 by spookthesunset on Saturday January 29, 2022 @01:44PM (#30129092)
> but suddenly incapable of firewalling if IPv6 is involved.

It's been a few years but I've yet to see a consumer grade router that lets you mess with IPv6 firewall rules. I don't even know what these routers use for a default policy.

They all seem to have web ui's for IPv4 firewalls and port forwarding though...

Re:Reasons for servers to support IPv6 by vetinari on Saturday January 29, 2022 @03:39PM (#30130166)
Ever seen an average IPv6 firewall, even on $500 devices?

You can have dynamic prefix that can change with every moment on your wan interface, but then you have static IPv6 rules and you cannot specify something like use current prefix there.

So I understand if the first reaction is screw that.

Re:Reasons for servers to support IPv6 by 300bps on Saturday January 29, 2022 @11:10AM (#30127417)
Not OP but that’s how I think of it.

If my internal network is 10.0.0.0/8 and I have 100,000 hosts and a single IPV4 address that they all appear to be to the public Internet, I’ll sleep a lot better than if I had all 100,000 hosts with public routable IPV6 IP addresses attached to them.

Yes, you can depend on a firewall to protect you but at the very least it exposes information about your internal network and at worst opens you up to future firewall flaws.

I remember the days when people used to have every system have it’s own public IP address. People would scan for broadcast addresses of their networks and we got Smurf attacks as a result. Obviously those wouldn’t work with properly firewalled hosts but it still scares me.

Re:Reasons for servers to support IPv6 by fishtacos on Saturday January 29, 2022 @11:14AM (#30127460)
This is why we have firewalls. My pfSense router e.g. blocks external access by virtue of it being a firewall with sensible defaults.

All routers w/ firewalls will/should have them.

Re:Reasons for servers to support IPv6 by pm90 on Saturday January 29, 2022 @11:49AM (#30127825)
Firewalls are fine but having the ability to make machines unroutable is even more powerful, no?

While I get that firewalls are probably safe like 99.99% of the time… I’ve gotta say, I just don’t trust software to not have vulns of some sort that someone important already knows how to break. So eg for a corporate network I would be hesitant to do this, for my personal network not so much (unlikely that a 3 letter agency gives a shit about what I do).

Additionally. Firewall changes can sometimes fail for whatever reasons so you might have accidentally exposed a node publicly for some time.

Making those nodes not reachable from the internet seems prudent. It’s like your office building has a public address but your office assignments don’t need to be public.

Re:Reasons for servers to support IPv6 by justsomehnguy on Saturday January 29, 2022 @12:07PM (#30128003)
>Firewalls are fine but having the ability to make machines unroutable is even more powerful, no?

For the whole world there is absolutely no difference betwen routable address, non-routable address or even an absense of the machine... behind a firewall with drop all on a public interface.

Re:Reasons for servers to support IPv6 by 300bps on Saturday January 29, 2022 @01:12PM (#30128757)
Your statement doesn’t address the point you are responding to so it makes me think you completely missed the point you are replying to.

You are correct in theory. What you don’t seem to be taking into consideration are firewall vulnerabilities or other unknown things that could happen that make it different from a practical standpoint.

I started an ISP from the ground in 1996. I’ve seen a lot of weird stuff. You seem to just hand waive it away like firewalls are this perfect bastion of security.

Maybe you have more experience than I do?

Re:Reasons for servers to support IPv6 by blibble on Saturday January 29, 2022 @02:43PM (#30129681)
where do you think the NAT and associated connection tracking is occurring exactly?
Re:Reasons for servers to support IPv6 by mrkurt on Saturday January 29, 2022 @12:15PM (#30128092)
Anything smaller than a IPv6 /48 is effectively unroutable. Your ISP has to route smaller blocks, like /64s, privately (because only /48s hit public bgp). And then you have to route the /64 they assign you privately once again.
Re:Reasons for servers to support IPv6 by zekica on Saturday January 29, 2022 @12:02PM (#30127951)
No. There is no difference between the two from a security point.
Re:Reasons for servers to support IPv6 by floatboth on Saturday January 29, 2022 @01:42PM (#30129045)
Even firewalls are just a last resort defense IMO. The primary thing is not having any crap listening on ports in the first place.
Re:Reasons for servers to support IPv6 by mrkurt on Saturday January 29, 2022 @12:13PM (#30128067)
IPv4 with nat is effectively routing your 100,000 hosts through one of 4,294,967,296 possible IP prefixes (a /32).

IPv6 with a /64 routes one of 18,889,465,931,478,580,854,783 possible IP prefixes to your router. Everything that happens behind that is opaque. There are so many IPs in that prefix that people can't even guess which ones you're using. It's easier to guess internal IPv4 NAT addresses.

The internet can't see your IPs. "Publicly routable" doesn't mean much when you're talking about prefixes.

Re:Reasons for servers to support IPv6 by otabdeveloper4 on Saturday January 29, 2022 @01:25PM (#30128896)
Unless you're planning to assign random IPv6 addresses for each connecton then it's not at all the same thing.

And anyways, when you have a NAT you're probably routing traffic through a level 4 balancer or jumphost or using a VPN somewhere in your LAN.

Re:Reasons for servers to support IPv6 by mrkurt on Saturday January 29, 2022 @03:33PM (#30130105)
We assign IPv6 deterministically. Incrementing them is the most boring way to use IPv6 space.

You can also just start in the middle of a block and make a sequence of 10,000 IPs effectively unguessable.

I don't buy that keeping addresses private has much value, but IPv6 still isn't worse than NAT in that respect.

Re:Reasons for servers to support IPv6 by blibble on Saturday January 29, 2022 @01:43PM (#30129077)
> Unless you're planning to assign random IPv6 addresses for each connecton then it's not at all the same thing.

SLAAC

Re:Reasons for servers to support IPv6 by Dylan16807 on Saturday January 29, 2022 @03:05PM (#30129850)
SLAAC has an option to randomize, but it's a lot slower than per-connection.
Re:Reasons for servers to support IPv6 by doubleunplussed on Saturday January 29, 2022 @05:07PM (#30131045)
As soon as one of the computers in the subnet initiates traffic outside the network, its IP address becomes public knowledge though, right? Doesn't matter how large the space is, that information leaks, whereas with NAT it doesn't.
Re:Reasons for servers to support IPv6 by Plasmoid on Sunday January 30, 2022 @12:06AM (#30134221)
Modern OS change their outgoing IPv6 address fairly often. They could grab 10,000 from the pool and rotate between them every second.
Re:Reasons for servers to support IPv6 by doubleunplussed on Monday January 31, 2022 @08:34PM (#30157518)
IPv6 addresses can be ephemeral? What, DHCP is assigning a whole range to each client? Didn't know that.

Pretty weird. For internal stuff I would be using IP addresses to identify peers. Ephemeral IP addresses in logs aren't very useful.

Re:Reasons for servers to support IPv6 by Hnrobert42 on Saturday January 29, 2022 @11:39AM (#30127705)
Some of our service providers require us to provide the IP addresses of our services to them for them to safelist. It’s stupid, but it’s not something we can control.

Rather than constantly update them as our servers change, we route through a NAT. I wouldn’t know how to do it with IPv6. Maybe the service provider could safelist a subnet?

Re:Reasons for servers to support IPv6 by pm90 on Saturday January 29, 2022 @11:44AM (#30127774)
They probably wouldn’t support that. Most non software heavy companies outsource these sorts of projects and to make changes to their systems requires a bunch of upfront capital costs which can be expensive so they will push back against changes unless you are big enough to force them to or you convince them of the merits of such changes.
Re:Reasons for servers to support IPv6 by antxxxx on Saturday January 29, 2022 @01:01PM (#30128636)
Depending on the type of connection it's fairy easy to set up squid as a proxy for outbound connections so everything appears to come from the squid box which can have a static address and can be added to an allow list
Re:Reasons for servers to support IPv6 by miyuru on Saturday January 29, 2022 @02:03PM (#30129310)
>Maybe the service provider could safelist a subnet?

Yes, thats what prefixes are for. Although its unpractical in IPv4 world, in IPv6 it is the way to whitelist a range of ips.

Re:Reasons for servers to support IPv6 by otabdeveloper4 on Saturday January 29, 2022 @01:22PM (#30128860)
Yes, of course.

Exposing your LAN confguration for the world to see is insanity, it's like hiding your private SSH keys in a password-protected Excel file.

And yes, you need both NAT and firewall. They're complimentary technologies and do not replace each other.