Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

NAT Is the Enemy of Low Power Devices

blog.golioth.io

Post reply on HN
Print view View original

141–150 of 180 posts

Re: NAT Is the Enemy of Low Power Devices

#141

Post by fc417fc802 »

Marsymars wrote: post #95
fc417fc802 wrote: post #60

Earlier quoted context omitted.

No, it doesn't. At least the last time I checked unless you go out of your way to implement a non-standard configuration IPv6 is a disaster for personal privacy for the typical multi-user household. Then again, the "typical" multi-user household is likely logged in to most things via SSO with Google or Facebook and probably has approximately zero fingerprinting mitigations in use so perhaps it isn't worth worrying ab…

Even disregarding fingerprinting, a single household doesn't have enough traffic from separate devices/users to the same servers to really matter from a privacy standpoint. If my PC uses the same IP as my partner's to talk to Google, it hardly matters for our privacy if they mix up the attribution of traffic between the two of us.

Speak for yourself. I also don't want it to be readily apparent how many different devices I have, or when I'm using which one, or how many people are in the household, or when who is home.

Granted any service that I consistently interact with is likely to be able to figure out at least some of that information if they put in some effort. But I don't want to be freely providing a complete picture for zero effort.

Creepy data aggregator stories pop up on the HN front page regularly so hopefully I don't need to explain why I feel this way.

Re: NAT Is the Enemy of Low Power Devices

#142

Post by smw »

Symbiote wrote: post #106
lupusreal wrote: post #96

Earlier quoted context omitted.

Yeah but the average person wouldn't know to set up a firewall (and can't count on their ISP to have their best interests at heart.) Therefore the general public benefits from the degree of protection that NAT provides.

Almost 50% of internet traffic is IPv6. Obviously, those average people have a suitable firewall provided by default on their routers.

I think the vast majority of that is from phones?

Re: NAT Is the Enemy of Low Power Devices

#143

Post by MerManMaid »

LegionMammal978 wrote: post #7
justahuman74 wrote: post #2

Interestingly, IPv6 is not listed as the solution

An IPv6 router with a stateful firewall blocking incoming connections could have just the same issues with timeouts, I'd imagine. Switching to IPv6 doesn't just mean that anyone can make a P2P connection to anyone else (even STUN needs a third-party server to coordinate the two peers). (D)TLS session resumption (I'm not sure if their "Connection IDs" are that or something similar) seems like the most foolproof soluti…

>An IPv6 router with a stateful firewall blocking incoming connections could have just the same issues with timeouts, I'd imagine.

You'd be surprised... PCP (Port Control Protocol) implemented by large vendors such as Cisco and Apple are able to punch through a firewall for up to 24 hours in a single session.

https://github.com/Self-Hosting-Group/wiki/wiki/Port-Mapping...

Re: NAT Is the Enemy of Low Power Devices

#144

Post by positr0n »

api wrote: post #5
userbinator wrote: post #4

Earlier quoted context omitted.

IPv6 is its own complexity.

Why?

Great question that I don't think the other commentors really answered. Sadly I don't really know "why" either. Second system effect?

Instead of making IPv6 just "IPv4 with 128bit instead of 32bit address space" the designers changed a bunch of things. NDP is new and different than ARP. ICMPv6 is extended and different. MLD instead of IGMP for multicast group membership. DHCP is extended and has a bunch of other alternatives, like SLAAC. IPsec is mandatory now.

All the new IPv6 protocols seem more secure, more powerful, and more efficient. So I guess that is "why". But I bet in an alternative history where backwards compatibility and the upgrade process were prioritized IPv6 would be a lot more widespread.

Re: NAT Is the Enemy of Low Power Devices

#145

Post by lxgr »

nolist_policy wrote: post #127
lxgr wrote: post #120

Earlier quoted context omitted.

Why would it not? There's even a third MAC address field in the 802.11 headers for just that scenario, as far as I remember (i.e. to distinguish between "802.11 source/destination" and "Ethernet-level actual source/destination").

You actually need to use special 4addr/WDS frames with 4 addresses[1]. However no one accepts these by default so it's unusable for a Laptop that you want to connect to random wlan networks. [1] https://lore.kernel.org/netdev/1258465585.3682.7.camel@johan...

Hm, maybe I'm mixing up something here, but all I can say is that it works like this on my machine: I have a VM running in bridged mode, I'm connected to my home router using Wi-Fi, and I can see the virtual MAC address of the VM on the router management interface.

Possibly this is just at the DHCP level, though, and what the router sees just comes from my host MAC address? A quick packet trace suggests that.

Re: NAT Is the Enemy of Low Power Devices

#146

Post by lxgr »

Spivak wrote: post #136
lxgr wrote: post #100

Earlier quoted context omitted.

Sounds like you like the idea of a stateful firewall, and good news: There are stateful firewalls for IPv6! They have all the upsides of NATs (i.e. an option to block inbound connections by default), with none of the downsides (they preserve port numbers, can be implemented statelessly, they greatly simplify cooperative firewall traversal, you can allow inbound connections for some hosts).

I found it weird that IPv6 folks are so against NAT as a cultural thing when it works perfectly well on IPv6. They're not fundamentally opposed. I could have all of my servers in public subnets and give them all public IP addresses, but I still prefer to put everything I can in private. Not only does the firewall not allow traffic in, but you can't even route to them. It now becomes really hard to accidentally grant…

I'm not opposed to anyone voluntarily using a NAT at all. I just hate it when somebody makes that decision for me, and that unfortunately still happens all the time.

If it's a well-reasoned decision, sure, but I do suspect that more often than not it's a lack of knowledge about alternatives that makes people still opt for NATs, and that just makes me sad on top of being annoyed with the inconvenience of having to tunnel when a direct connection seems so close at hand.

> I would hazard that most devices on there internet are in the boat of want to talk to the internet but not be reachable on it.

I highly doubt that. One big example is VoIP: Incredibly common these days, yet so much of it is going through centralized relays, and often for absolutely no technical reason.

Re: NAT Is the Enemy of Low Power Devices

#147

Post by thowawatp302 »

Dylan16807 wrote: post #93
LegionMammal978 wrote: post #79

Earlier quoted context omitted.

> Based on your description, you're using NAT as a means to bypass network restrictions. The threat model on this big enterprise WAN isn't "an authorized user creates a VM on an existing machine", but rather "some rando plugs something in with an Ethernet cable and goes to town on the intranet services". It has a whole web portal where you can log in and register your devices. So it's not like anything's really being…

> The threat model on this big enterprise WAN isn't "an authorized user creates a VM on an existing machine", but rather "some rando plugs something in with an Ethernet cable and goes to town on the intranet services". It has a whole web portal where you can log in and register your devices. So it's not like anything's really being bypassed here. Isn't that what the MAC filtering is for? I don't see the point of stop…

If IT doesn’t want random things plugging into the network? That’s what 802.1x is for

Re: NAT Is the Enemy of Low Power Devices

#148

Post by Dylan16807 »

LegionMammal978 wrote: post #117
Dylan16807 wrote: post #93

Earlier quoted context omitted.

> The threat model on this big enterprise WAN isn't "an authorized user creates a VM on an existing machine", but rather "some rando plugs something in with an Ethernet cable and goes to town on the intranet services". It has a whole web portal where you can log in and register your devices. So it's not like anything's really being bypassed here. Isn't that what the MAC filtering is for? I don't see the point of stop…

I might be misremembering some of the details (in fact, given that the web portal works, I think it might allow new devices to have local IPs, but bounce all outbound packets until they're registered), but however it works exactly, it does not like passthrough networking on VMs in practice. (If I had to guess, just letting any machine have a million new IPs for the firewall to track has its own issues, so you'd end u…

The firewall shouldn't have to track IPs, just the connections it would be tracking no matter what.

And sure a million IPs could cause problems, but that's not a good reason to set the limit to 1.

> I'm skeptical of the typical IPv6 position of "a flat /64 network (or something emulating one) is all you'll ever need".

That's not the position. You can have as many networks as you want. Connect them with routers like you would on IPv4.

Re: NAT Is the Enemy of Low Power Devices

#149

Post by raggi »

freedomben wrote: post #130
raggi wrote: post #112

What I want from platforms, and I fought for at one time in Google with no success: a platform API that provides applications a way to schedule packets when the radio turns on. The mobile platforms in particular continue to assume that you can live with their high level HTTP stuff, and it's just not good enough. The non-mobile platforms largely don't even approach the problem at all.

Indeed, that sounds like an obvious feature. Hard to believe it hasn't been implemented! I'd love to have that feature on Linux desktop/laptops. I think you could make lots of applications behave a whole lot better.

the arguments from folks on the "architecture review boards" was that multiple connections are always bad and that developers can't be trusted. i'm willing to accept that they did get beat up quite a bit over power at various points when at times applications were a big part of the problem. That said this is also a gross misunderstanding of the problem and overall solution space, as well as very much gatekeeping.
Post reply on HN