4 ms·

Exactly! IPv4 management is hideous compared to IPv6 once you grok it. The sooner you upgrade to it, the sooner you can deprecate horrid mitigations like NAT.

LegionMammal978 2y ago
Out of curiosity, what parts of NAT management tend to be so horrible in practice?
- kstrauser 2y ago
  The fact that it exists. I was a network engineer before NAT became a common thing and remember how it use to be when nodes on the network were legitimately peers. NAT is a bletcherous band-aid for the fact there are more people than 32 bit numbers. Now we're seeing true abominations like CGNAT. That stuff needs to be lost to the realm of scary legends told late at night.
  - LegionMammal978 2y ago
    I was asking about practical issues, not just complaints of subjective ugliness. While I'll grant that CGNAT can be pretty bad (though not entirely indefensible for mobile networks), I don't think we can ever return to "every node being a peer" in any case, not when any typical network will have a firewall that denies incoming connections.
    - nobody9999 2y ago
      >I don't think we can ever return to "every node being a peer" in any case, not when any typical network will have a firewall that denies incoming connections. Forgive me if I'm missing something here, but how is that any different WRT IPv4 vs. IPv6? In both cases, except for those services one wishes to expose to the Internet (assuming one has a use-case for that), all incoming connections should be blocked, IPv4 or IPv6. Or are you arguing that NAT masquerade confers some sort of security benefit on one's network that precludes the necessity of blocking incoming connections? I'd argue that NAT (N:1 or 1:1) doesn't provide any security benefit. Nor does IPv4+NAT reduce the complexity of firewall rules as compared with IPv6. In fact, I'd posit that NAT makes things more complicated and not less. That said, you can use NAT/NPT[0] with IPv6 (along with ULA/SLAAC) if you really want. As such, I'd say that IPv6 provides the best and worst of IPv4, plus additional benefits. IF we ever get completely off IPv4, that will be a good day. [0] https://en.wikipedia.org/wiki/Network_address_translation#NAT_in_IPv6 https://en.wikipedia.org/wiki/Network_address_translation#NA...
      - LegionMammal978 2y ago
        I don't think I'm disagreeing with you regarding firewalls: what I was trying to say is that "every node being a peer" isn't a good argument against NAT, since these days it holds neither in IPv4 nor in IPv6, now that everything has a firewall in front of it. > In fact, I'd posit that NAT makes things more complicated and not less. Sure, it clearly adds some iota of additional work, but I've never seen it as being the worst thing in the world. I'm young enough to have never witnessed the legendary paradise of globally-reachable static IPs for everything, so it seems more like "just the way things are". And yet there is widespread hatred against the existence of NAT, and I can't tell if it's primarily ideological, or if NAT is causing real practical difficulties for many setups. (Though at least the issues with CGNAT are easy to see. And also with broken NAT implementations.) Meanwhile, one might argue that things like SLAAC in IPv6 can similarly add conceptual difficulties compared to IPv4. E.g., "How do I identify some particular device in my network, if its link-local IP is changing on a regular basis?" (To which the answer is something DNS-like, I guess?) So switching a network's internal operations from NATted IPv4 to NATless IPv6, with all of its different mechanisms, would seem like more of a tradeoff than an unequivocal win.
        throw0101a 2y ago
        > I don't think I'm disagreeing with you regarding firewalls: what I was trying to say is that "every node being a peer" isn't a good argument against NAT, since these days it holds neither in IPv4 nor in IPv6, now that everything has a firewall in front of it. In residential environments you can do whole bunch with UPNP/PCP, but with IPv4 you have the added complexity of STUN, TURN, and ICE: * https://community.cisco.com/t5/collaboration-knowledge-base/demystifying-nat-traversal-with-stun-turn-and-ice/ta-p/4766853 https://community.cisco.com/t5/collaboration-knowledge-base/... * https://medium.com/@ecosmobtechnologies/webrtc-best-practices-understanding-stun-turn-and-ice-servers-4836109904ec https://medium.com/@ecosmobtechnologies/webrtc-best-practice... With IPv6 you simply punch a whole and and the two clients simply talking to each other with their GUAs. (In more tightly controlled environments (e.g., work), firewall policies and hole punching are dictated by IT.) > Meanwhile, one might argue that things like SLAAC in IPv6 can similarly add conceptual difficulties compared to IPv4. E.g., "How do I identify some particular device in my network, if its link-local IP is changing on a regular basis?" If a device gets its address via DHCP(v4), how do you identify it? SLAAC is for dynamic environments, but if you want static services, configure IPv6 statically. At least with IPv6 you don't need DHCP infrastructure (and complexities like IP helpers configured on routers) to get going.
    - MerManMaid 2y ago
      IPv4 as well as IPv6 was designed with endpoint to endpoint communication in mind so when NAT was conceived (originally intended to be a stop-gap while we moved to IPv6) we also had to re-write many other protocols and create many new ones since NAT broke IPv4's design principle (each IP needs to be unique) This has lead to many context specific problems as many of the re-written protocols don't work as well not to mention the added complexities of protocols designed specifically with NAT in mind. As another network engineer I can attest to the problems this has caused. Pretty much everything from overlay VPN networks, VoIP solutions, security and ACLS, and just our day to day maintenance tasks are complicated by NAT. It has gotten so out of hand that many of us have dedicated NAT routers just handling NAT translation. It's so weird to me that so many people in our industry spout scalability but then laugh off IPv6... How the heck do you guys plan to communicate to the ever increasing amount of smart devices? IPv4 literally ran out a space years ago...
  - mort96 2y ago
    I mean adding IPv6 support doesn't make nodes "legitimate peers". NAT still exists in a v4+v6 world; there will always be a distinction between "nodes with a public v4 address" and "nodes without a public v4 address".
mort96 2y ago
You're missing the point, I believe intentionally. You can't get away from IPv4 as long as you have users who can't access IPv6-only servers. All your users and potential users can access IPv4-only servers.
- simoncion 2y ago
  I think you're misunderstood what you quoted: > It's a terrible it to start a new project in 2024 without IPv6 support though. That does not preclude ALSO supporting IPv4. Remember that for many technical folks out there, the default is "Only do IPv4 support" which is (IMO) just batshit stupid. (Do also note that the sentence immediately prior to the one you quoted is "I didn't recommend dropping IPv4.".)
  - mort96 2y ago
    As you know, we have two options: 1. Support IPv4 and IPv6. 2. Support only IPv4. #2 has essentially no downsides and is radically simpler. That's my point. It's not terrible to start a new project without IPv6 support, because adding IPv6 support adds a ton of complexity for almost no benefit. I never claimed or insinuated that you recommend dropping IPv4. If I thought your recommendation was to drop v4, my argument about the complexity of dual-stack would've made no sense.
    - simoncion 2y ago
      > I never claimed or insinuated that you recommend... Check my handle. I'm not who you seem to think I am. > ...adding IPv6 support adds a ton of complexity for almost no benefit. That doesn't at all match my experience with IPv6 support in greenfield projects for the past decade+. You actually have to do extra work to make them IPv4-only. Remember that the statement you initially responded to said "It's a terrible it to start a new project in 2024..."
      - mort96 2y ago
        > > I never claimed or insinuated that you recommend... > Check my handle. I'm not who you seem to think I am. Sorry, I didn't notice. Pretend I said "they" rather than "you". > > ...adding IPv6 support adds a ton of complexity for almost no benefit. > That doesn't at all match my experience with IPv6 support in greenfield projects for the past decade+. You actually have to do extra work to make them IPv4-only. Remember that the statement you initially responded to said "It's a terrible it to start a new project in 2024..." Huh, I never found it difficult to ... not add an AAAA DNS record to point to a server. It surprises me that you find that to be extra work.

LegionMammal978 2y ago

Out of curiosity, what parts of NAT management tend to be so horrible in practice?

kstrauser 2y ago
The fact that it exists. I was a network engineer before NAT became a common thing and remember how it use to be when nodes on the network were legitimately peers. NAT is a bletcherous band-aid for the fact there are more people than 32 bit numbers. Now we're seeing true abominations like CGNAT. That stuff needs to be lost to the realm of scary legends told late at night.
- LegionMammal978 2y ago
  I was asking about practical issues, not just complaints of subjective ugliness. While I'll grant that CGNAT can be pretty bad (though not entirely indefensible for mobile networks), I don't think we can ever return to "every node being a peer" in any case, not when any typical network will have a firewall that denies incoming connections.
  - nobody9999 2y ago
    >I don't think we can ever return to "every node being a peer" in any case, not when any typical network will have a firewall that denies incoming connections. Forgive me if I'm missing something here, but how is that any different WRT IPv4 vs. IPv6? In both cases, except for those services one wishes to expose to the Internet (assuming one has a use-case for that), all incoming connections should be blocked, IPv4 or IPv6. Or are you arguing that NAT masquerade confers some sort of security benefit on one's network that precludes the necessity of blocking incoming connections? I'd argue that NAT (N:1 or 1:1) doesn't provide any security benefit. Nor does IPv4+NAT reduce the complexity of firewall rules as compared with IPv6. In fact, I'd posit that NAT makes things more complicated and not less. That said, you can use NAT/NPT[0] with IPv6 (along with ULA/SLAAC) if you really want. As such, I'd say that IPv6 provides the best and worst of IPv4, plus additional benefits. IF we ever get completely off IPv4, that will be a good day. [0] https://en.wikipedia.org/wiki/Network_address_translation#NAT_in_IPv6 https://en.wikipedia.org/wiki/Network_address_translation#NA...
    - LegionMammal978 2y ago
      I don't think I'm disagreeing with you regarding firewalls: what I was trying to say is that "every node being a peer" isn't a good argument against NAT, since these days it holds neither in IPv4 nor in IPv6, now that everything has a firewall in front of it. > In fact, I'd posit that NAT makes things more complicated and not less. Sure, it clearly adds some iota of additional work, but I've never seen it as being the worst thing in the world. I'm young enough to have never witnessed the legendary paradise of globally-reachable static IPs for everything, so it seems more like "just the way things are". And yet there is widespread hatred against the existence of NAT, and I can't tell if it's primarily ideological, or if NAT is causing real practical difficulties for many setups. (Though at least the issues with CGNAT are easy to see. And also with broken NAT implementations.) Meanwhile, one might argue that things like SLAAC in IPv6 can similarly add conceptual difficulties compared to IPv4. E.g., "How do I identify some particular device in my network, if its link-local IP is changing on a regular basis?" (To which the answer is something DNS-like, I guess?) So switching a network's internal operations from NATted IPv4 to NATless IPv6, with all of its different mechanisms, would seem like more of a tradeoff than an unequivocal win.
      - throw0101a 2y ago
        > I don't think I'm disagreeing with you regarding firewalls: what I was trying to say is that "every node being a peer" isn't a good argument against NAT, since these days it holds neither in IPv4 nor in IPv6, now that everything has a firewall in front of it. In residential environments you can do whole bunch with UPNP/PCP, but with IPv4 you have the added complexity of STUN, TURN, and ICE: * https://community.cisco.com/t5/collaboration-knowledge-base/demystifying-nat-traversal-with-stun-turn-and-ice/ta-p/4766853 https://community.cisco.com/t5/collaboration-knowledge-base/... * https://medium.com/@ecosmobtechnologies/webrtc-best-practices-understanding-stun-turn-and-ice-servers-4836109904ec https://medium.com/@ecosmobtechnologies/webrtc-best-practice... With IPv6 you simply punch a whole and and the two clients simply talking to each other with their GUAs. (In more tightly controlled environments (e.g., work), firewall policies and hole punching are dictated by IT.) > Meanwhile, one might argue that things like SLAAC in IPv6 can similarly add conceptual difficulties compared to IPv4. E.g., "How do I identify some particular device in my network, if its link-local IP is changing on a regular basis?" If a device gets its address via DHCP(v4), how do you identify it? SLAAC is for dynamic environments, but if you want static services, configure IPv6 statically. At least with IPv6 you don't need DHCP infrastructure (and complexities like IP helpers configured on routers) to get going.
  - MerManMaid 2y ago
    IPv4 as well as IPv6 was designed with endpoint to endpoint communication in mind so when NAT was conceived (originally intended to be a stop-gap while we moved to IPv6) we also had to re-write many other protocols and create many new ones since NAT broke IPv4's design principle (each IP needs to be unique) This has lead to many context specific problems as many of the re-written protocols don't work as well not to mention the added complexities of protocols designed specifically with NAT in mind. As another network engineer I can attest to the problems this has caused. Pretty much everything from overlay VPN networks, VoIP solutions, security and ACLS, and just our day to day maintenance tasks are complicated by NAT. It has gotten so out of hand that many of us have dedicated NAT routers just handling NAT translation. It's so weird to me that so many people in our industry spout scalability but then laugh off IPv6... How the heck do you guys plan to communicate to the ever increasing amount of smart devices? IPv4 literally ran out a space years ago...
- mort96 2y ago
  I mean adding IPv6 support doesn't make nodes "legitimate peers". NAT still exists in a v4+v6 world; there will always be a distinction between "nodes with a public v4 address" and "nodes without a public v4 address".

mort96 2y ago

You're missing the point, I believe intentionally. You can't get away from IPv4 as long as you have users who can't access IPv6-only servers. All your users and potential users can access IPv4-only servers.

simoncion 2y ago
I think you're misunderstood what you quoted: > It's a terrible it to start a new project in 2024 without IPv6 support though. That does not preclude ALSO supporting IPv4. Remember that for many technical folks out there, the default is "Only do IPv4 support" which is (IMO) just batshit stupid. (Do also note that the sentence immediately prior to the one you quoted is "I didn't recommend dropping IPv4.".)
- mort96 2y ago
  As you know, we have two options: 1. Support IPv4 and IPv6. 2. Support only IPv4. #2 has essentially no downsides and is radically simpler. That's my point. It's not terrible to start a new project without IPv6 support, because adding IPv6 support adds a ton of complexity for almost no benefit. I never claimed or insinuated that you recommend dropping IPv4. If I thought your recommendation was to drop v4, my argument about the complexity of dual-stack would've made no sense.
  - simoncion 2y ago
    > I never claimed or insinuated that you recommend... Check my handle. I'm not who you seem to think I am. > ...adding IPv6 support adds a ton of complexity for almost no benefit. That doesn't at all match my experience with IPv6 support in greenfield projects for the past decade+. You actually have to do extra work to make them IPv4-only. Remember that the statement you initially responded to said "It's a terrible it to start a new project in 2024..."
    - mort96 2y ago
      > > I never claimed or insinuated that you recommend... > Check my handle. I'm not who you seem to think I am. Sorry, I didn't notice. Pretend I said "they" rather than "you". > > ...adding IPv6 support adds a ton of complexity for almost no benefit. > That doesn't at all match my experience with IPv6 support in greenfield projects for the past decade+. You actually have to do extra work to make them IPv4-only. Remember that the statement you initially responded to said "It's a terrible it to start a new project in 2024..." Huh, I never found it difficult to ... not add an AAAA DNS record to point to a server. It surprises me that you find that to be extra work.