6 ms·

I noticed this article talks about IPv6 version NAT - NPT ``` Remember, this will blindly just swap prefixes in and out. Gone are the days of “only the traffi

I noticed this article talks about IPv6 version NAT - NPT ``` Remember, this will blindly just swap prefixes in and out. Gone are the days of “only the traffic I explicitly create a rule for can get in”. See, now, just adding that one step will, be default, expose your entire network! You now need firewall rules to block what you don’t want and add explicit allows, this time manually as an additional step. This is more of a “default pass” routing — unless I tell you not to, let it through. ``` This seems like a great security concern Would be good to know if this statement is accurate I might consider disabling IPv6 if this is true

redis_mlc 6y ago
If you're concerned about security, yeah I would disable IPv6. Until all firewall and router mfgs. re-QA every little feature added for IPv6, you don't really know what your equipment is doing.
- redis_mlc 6y ago
  Can somebody explain what the downvotes are for? Are you IPv6 fanbois? Have you audited all the firmware and software on your firewalls and routers?
  - alphager 6y ago
    Have you audited the IPv4-codepaths? Your comment contained no information above "I don't trust it".
    - redis_mlc 6y ago
      > Have you audited the IPv4-codepaths? Are you for real? There's been decades of production experience with IPv4 and does mostly what's expected. Of course IPv6 shouldn't be trusted. New software has bugs. That applies doubly for networking code. Get your fuzzers started ...
- josho 6y ago
  To provide a data point to your assertion my brand new tp-link wifi router has a setting for ipv6 firewall, but it does nothing. Yes all my home devices are exposed to the public internet. Yikes! The tech support team even confirmed that ipv6 firewall support is coming ‘soon’. Meanwhile my ASUS router’s ipv6 support is broken as well for dns configuration. So, yeh it is still early days for consumer ipv6 adoption.
  - redis_mlc 6y ago
    Thanks for the consumer datapoints. I don't expect much from consumer networking gear, good to see I won't be disappointed. I was actually referring to rack gear, but hey.
zaarn 6y ago
NPT does that if your default firewall rule is "allow all incoming". Atleast on my router, if I setup NPT it also automatically creates a firewall rule to drop all non-relevant traffic unless I allow it. I feel like I should point out that in IPv4 NAT you also still have a firewall to drop incoming traffic unrelated to anything.
wahern 6y ago
Not many firewalls support NPT. OpenBSD PF doesn't, where IPv6 NAT works much the same as IPv4 NAT. I wouldn't put much stock into that article. Many of their points are IPv6 pros (and the sections seem to make that clear), and many of the cons simply boil down to IPv6 being different, often necessarily so--for example, PTR records for a 128-bit address space were always going to be long even if the delegation prefix chunks were larger (e.g. 8 or 16 bits instead of 4). And I don't see how any of those problems constitute a nightmare. The only real pain point for IPv6 deployment IME is DHCP.[1] DHCPv6 was never even supposed to be a thing; the very fact that it exists shows that the alternatives can be replaced or supplemented. But either way this problem really comes down to tooling and operating system support. IPv6 deployment and the standards and software for deploying it will mature together, and complexity will ebb and flow as alternatives enter and leave the fray. It could never have been any other way. IPv4 was hardly without its hiccups. Heck, the switch to classless IPv4 addressing was somewhat bumpy and confusing even as late as the early 2000s simply because a lot of software, including standard tools like ifconfig(1), didn't make it ergonomic or even possible. Frankly the latent complexity is still annoying. I think it pays to remember that a lot of these articles are written by people with an eye toward job recruiting, interviewing, and generally grooming their credentials. The conclusions don't matter, they're just an excuse to exhibit familiarity with the technical details. They're a sales pitch for the author, and that essay is a particularly good one--the author demonstrates a comprehensive familiarity with the issues, notwithstanding their framing and conclusions. [1] The biggest pain point in earlier years was the need for BSD Sockets API support in application software. But it seems we're mostly over that hump, notwithstanding the regressions caused during the shift to cloud computing, where IPv6 support was and remains much more immature than in the wider ecosystem.
- whereistimbo 6y ago
  > DHCPv6 was never even supposed to be a thing; Why?
  - Arnt 6y ago
    There's a different protocol to do the same job. Or two if you want, RA and ND. Router advertisement, neighbour discovery. DHCPv6 does exist, but I don't really understand what it offers over RA+ND.
dxld 6y ago
I think this statement should be considered more as a criticism of pfSense and not of IPv6 in general. In fact there are a number of RFCs around how IPv6 firewalling should be implemented on _consumer_ routers but since pfSense seems to be mostly aimed at enterprise customers my guess is they don't necessarily follow all that. Specifically I'm referring to: - RFC4864 | Local Network Protection for IPv6, - RFC6092 | Recommended Simple Security Capabilities in Customer Premises Equipment (CPE) for Providing Residential IPv6 Internet Service and - RFC7084 | Basic Requirements for IPv6 Customer Edge Routers, which pulls in the other two by reference. In fact RFC4864 is specifically about this "Perceived Benefit of NAT" and how to preserve the security benefits in the v6 world. [RFC4864]: https://tools.ietf.org/html/rfc4864 https://tools.ietf.org/html/rfc4864 [RFC6092]: https://tools.ietf.org/html/rfc6092 https://tools.ietf.org/html/rfc6092 [RFC7084]: https://tools.ietf.org/html/rfc7084 https://tools.ietf.org/html/rfc7084 Just as an example, OpenWrt, a more consumer focused router distribution follows RFC7084 and provides the default deny behaviour on IPv6 ingress from WAN much like IPv4-NAT would do. Also note that IMO the author is simply conflating NAT as known in the IPv4 world with it's usual implementation of actual Address Translation plus Stateful firewalling. In fact prefix translation which he's going on about here isn't necessary at all to be exposed to this security problem. Just plugging a IPv6 (and DHCPv6-PD) capable router into a WAN would do if it weren't for the stateful firewall.
- magicalhippo 6y ago
  Thanks for the info. I've been running pfSense for years, but it's clear that it just is not made with residential IPv6 in mind. Been looking at the NanoPi R2S, think I'll try out OpenWrt on that as a replacement.
Olipro 6y ago
No, it's complete nonsense. NAT just happens to serve as a form of firewalling in IPv4 land because usually, the stuff behind your router has a private address. Proper firewalling is a matter of policies; it's completely orthogonal to whether your devices have a globally routable address or not.

redis_mlc 6y ago

If you're concerned about security, yeah I would disable IPv6. Until all firewall and router mfgs. re-QA every little feature added for IPv6, you don't really know what your equipment is doing.

redis_mlc 6y ago
Can somebody explain what the downvotes are for? Are you IPv6 fanbois? Have you audited all the firmware and software on your firewalls and routers?
- alphager 6y ago
  Have you audited the IPv4-codepaths? Your comment contained no information above "I don't trust it".
  - redis_mlc 6y ago
    > Have you audited the IPv4-codepaths? Are you for real? There's been decades of production experience with IPv4 and does mostly what's expected. Of course IPv6 shouldn't be trusted. New software has bugs. That applies doubly for networking code. Get your fuzzers started ...
josho 6y ago
To provide a data point to your assertion my brand new tp-link wifi router has a setting for ipv6 firewall, but it does nothing. Yes all my home devices are exposed to the public internet. Yikes! The tech support team even confirmed that ipv6 firewall support is coming ‘soon’. Meanwhile my ASUS router’s ipv6 support is broken as well for dns configuration. So, yeh it is still early days for consumer ipv6 adoption.
- redis_mlc 6y ago
  Thanks for the consumer datapoints. I don't expect much from consumer networking gear, good to see I won't be disappointed. I was actually referring to rack gear, but hey.

zaarn 6y ago

NPT does that if your default firewall rule is "allow all incoming". Atleast on my router, if I setup NPT it also automatically creates a firewall rule to drop all non-relevant traffic unless I allow it. I feel like I should point out that in IPv4 NAT you also still have a firewall to drop incoming traffic unrelated to anything.

wahern 6y ago

Not many firewalls support NPT. OpenBSD PF doesn't, where IPv6 NAT works much the same as IPv4 NAT. I wouldn't put much stock into that article. Many of their points are IPv6 pros (and the sections seem to make that clear), and many of the cons simply boil down to IPv6 being different, often necessarily so--for example, PTR records for a 128-bit address space were always going to be long even if the delegation prefix chunks were larger (e.g. 8 or 16 bits instead of 4). And I don't see how any of those problems constitute a nightmare. The only real pain point for IPv6 deployment IME is DHCP.[1] DHCPv6 was never even supposed to be a thing; the very fact that it exists shows that the alternatives can be replaced or supplemented. But either way this problem really comes down to tooling and operating system support. IPv6 deployment and the standards and software for deploying it will mature together, and complexity will ebb and flow as alternatives enter and leave the fray. It could never have been any other way. IPv4 was hardly without its hiccups. Heck, the switch to classless IPv4 addressing was somewhat bumpy and confusing even as late as the early 2000s simply because a lot of software, including standard tools like ifconfig(1), didn't make it ergonomic or even possible. Frankly the latent complexity is still annoying. I think it pays to remember that a lot of these articles are written by people with an eye toward job recruiting, interviewing, and generally grooming their credentials. The conclusions don't matter, they're just an excuse to exhibit familiarity with the technical details. They're a sales pitch for the author, and that essay is a particularly good one--the author demonstrates a comprehensive familiarity with the issues, notwithstanding their framing and conclusions. [1] The biggest pain point in earlier years was the need for BSD Sockets API support in application software. But it seems we're mostly over that hump, notwithstanding the regressions caused during the shift to cloud computing, where IPv6 support was and remains much more immature than in the wider ecosystem.

whereistimbo 6y ago
> DHCPv6 was never even supposed to be a thing; Why?
- Arnt 6y ago
  There's a different protocol to do the same job. Or two if you want, RA and ND. Router advertisement, neighbour discovery. DHCPv6 does exist, but I don't really understand what it offers over RA+ND.

dxld 6y ago

I think this statement should be considered more as a criticism of pfSense and not of IPv6 in general. In fact there are a number of RFCs around how IPv6 firewalling should be implemented on _consumer_ routers but since pfSense seems to be mostly aimed at enterprise customers my guess is they don't necessarily follow all that. Specifically I'm referring to: - RFC4864 | Local Network Protection for IPv6, - RFC6092 | Recommended Simple Security Capabilities in Customer Premises Equipment (CPE) for Providing Residential IPv6 Internet Service and - RFC7084 | Basic Requirements for IPv6 Customer Edge Routers, which pulls in the other two by reference. In fact RFC4864 is specifically about this "Perceived Benefit of NAT" and how to preserve the security benefits in the v6 world. [RFC4864]: https://tools.ietf.org/html/rfc4864 https://tools.ietf.org/html/rfc4864 [RFC6092]: https://tools.ietf.org/html/rfc6092 https://tools.ietf.org/html/rfc6092 [RFC7084]: https://tools.ietf.org/html/rfc7084 https://tools.ietf.org/html/rfc7084 Just as an example, OpenWrt, a more consumer focused router distribution follows RFC7084 and provides the default deny behaviour on IPv6 ingress from WAN much like IPv4-NAT would do. Also note that IMO the author is simply conflating NAT as known in the IPv4 world with it's usual implementation of actual Address Translation plus Stateful firewalling. In fact prefix translation which he's going on about here isn't necessary at all to be exposed to this security problem. Just plugging a IPv6 (and DHCPv6-PD) capable router into a WAN would do if it weren't for the stateful firewall.

magicalhippo 6y ago
Thanks for the info. I've been running pfSense for years, but it's clear that it just is not made with residential IPv6 in mind. Been looking at the NanoPi R2S, think I'll try out OpenWrt on that as a replacement.

Olipro 6y ago

No, it's complete nonsense. NAT just happens to serve as a form of firewalling in IPv4 land because usually, the stuff behind your router has a private address. Proper firewalling is a matter of policies; it's completely orthogonal to whether your devices have a globally routable address or not.