9 ms·

NAT Types

116 points by signa11 3y ago

zekica 3y ago
NAT "saved" the internet and broke much more: - we now have IP address markets - we now have STUN/TURN/ICE - we now have CGNAT None of that was needed, but why make a proper fix when you can instead do a series of band-aids?
- fenesiistvan 3y ago
  The fix is IPv6
  - signa11 3y ago
    that is just an urban-legend at this point in time.
    - throw0101a 3y ago
      45% of Google's traffic is IPv6: * https://www.google.com/intl/en/ipv6/statistics.html https://www.google.com/intl/en/ipv6/statistics.html It's the majority of traffic, 53%, in the US.
      - signa11 3y ago
        in was referring to op’s insinuation (i think) about ipv6 address space being large enough to not warrant usage of nat.
        lxgr 3y ago
        Are you disagreeing that it's large enough? The only instances of IPv6 NAT I've seen are situations like "I have only a single IPv6 address available but need to run a VM/a Wi-Fi hotspot/...", and arguably that's a completely different matter than "I have full control over my network, but I simply can't request the address space I need because there's none left". Practically, I've not encountered it myself. I was recently surprised to learn that even when tethering from my iPhone, client devices receive a public IPv6, so apparently mobile networks assign more than an /128 address to even single-line customers. On fixed-line IPv6, I've also never encountered any less than an /64 network.
        patrakov 3y ago
        /64 is not enough if you need to run two networks (e.g., a guest WiFi in addition to the main one). And yet, here in the Philippines, an IPv6 subnet larger than /64 is an enterprise-only feature that is denied to home users.
        megous 3y ago
        You can subnet /64. You'll just lose SLAAC. (+ some idiocy around some devices that refuse to implement both DHCPv6 and manual setting of IPv6 addresses)
        growse 3y ago
        This is a similar complaint to "I can't run a server from home because my ISP wont give me a static IP". Sure, it's a problem, but not one with the protocol.
        zekica 3y ago
        RIPE-738 (European RIR's address allocation and assignment policy) says that home users should get at least /56.
        jlokier 3y ago
        That's interesting. I've been tethering for years using Android phones, and using a 4G standalone router. I've never seen a client be allocated any IPv6 address in either case. I know the phone gets one for itself, but I don't think the router does. Looking at the phone's IP address status, it is given a non-public IPv4 by the mobile network (so CGNAT if it uses it), and what looks like a single IPv6 by the mobile network.
- theamk 3y ago
  I wish there were IP successor which would _only_ expand address space and not redo everything network-related. Increasing size of some structs and recompiling software is easy. Re-doing entire address allocation logic, address splitting, and network administration approach is much harder, as it affects millions of customized setups. Oh well, too late for this now. I guess this is the lesson for future network protocol designers: small, backwards-compatible changes will have much higher chances of working. And saying "you must drop old thing entirely and redo everything from scratch" means it'll take more than 30 years for your protocol to be deployed.
  - _a_a_a_ 3y ago
    When you've invented something better you can also invent a time machine, take a trip back half a century and cause everything to be done the right way from the very start.
  - growse 3y ago
    It's impossible to implement a backwards-compatible successor to IP without breaking the principle that every node can address other node. Old nodes will have no idea how to address "new" ones, and if you want actual communication to happen, then addressability needs to function in both directions. (You've also glossed over the fact that so much hardware assumed that an IP address was an int32. Swapping that out was always going to take a long time).
    - ok123456 3y ago
      If it was just a simple expansion you could have had a deadline for a switch over date. For example, on 1999-1-1 00:00:0.000Z stop using 32 bit address, and roll over to a 64 bit address. This is what happened when the internet switched from NCP to TCP. But, since it's not just a simple expansion of the address space and it fundamentally does things differently, this is impossible. And we've been stuck in limbo for about 28 years now.
      - growse 3y ago
        Things that break when you do "just a simple expansion" of the address length because they assume a 32 bit address: * ARP (goodbye all your switches) * DHCP (goodbye all your CPE routers) * DNS (A records don't work any more) * BGP (goodbye internet backbone routers) * ICMP (good luck without this) * etc. It is impossible to change the length of the address without fundamentally changing how the internet works.
- still_grokking 3y ago
  > None of that was needed, but why make a proper fix when you can instead do a series of band-aids? Exactly! There can't be anything beyond duct tape "engineering" in IT, because worse is "better"… You know? Doing things properly would cost money. Nobody is willing to pay. So nothing will ever change.
  - lxgr 3y ago
    > Doing things properly would cost money. Nobody is willing to pay. So nothing will ever change. That's not a fair characterization of the problem: Unless everybody switches at the same time (~impossible), IPv6 requires paying for both stacks until the migration is complete. That's simply not economical, and not everybody on the internet can afford to disregard economics that way. I'm also running IPv6 on all my hobbyist projects, but I really can't blame anyone that doesn't.
    - lloeki 3y ago
      It's a game theory problem: nobody wanted to foot the bill on their side, endlessly punting and waiting for others to foot it for them. End result is that now everyone foots a different, worse bill, yet will still have to foot the previous bill because the workarounds have their limits when the attrition game pans out.
    - marcosdumay 3y ago
      > IPv6 requires paying for both stacks until the migration is complete Yeah, the IP licensing costs are sure to bankrupt you. Only hobbyists have enough money to do it. Large corporations can not afford the money and labor.
      - lxgr 3y ago
        Hobbyists: "Wanna do IPv6? It's cool and we'll do our part for incentivizing people to also switch! It should only take a couple of Saturday afternoons." "Sure, sounds cool, let's do it!" Meanwhile, at any average corporation: "Ok, so implementing IPv6 will cost us x$ and n person months, got it. And the upside is that we'd get a badge on some IPv6 readiness site, yes? And what would be the consequence, for us, of not doing this? Interesting, absolutely nothing you say, at least until every single customer is at least on IPv6 dual stack, since we need to provide our existing IPv4 stack too? Cool, thank you for presenting, please don't come again!" About the only large commercial entities that see any benefits of rolling out IPv6 are eyeball-heavy ISPs (since selling native IPv6 + CG-NAT for IPv4 is a slightly less horrible proposition than selling CG-NAT alone), and much less importantly any entity so large that CG-NAT capacity (memory and assigned IP/port tuples) is an issue for them.
- throw0101a 3y ago
  > None of that was needed, but why make a proper fix when you can instead do a series of band-aids? It was needed temporarily until we got more address space. The original NAT RFC 1631 (later 3022) was released in 1994: The huge advantage of this approach is that it can be installed incrementally, without changes to either hosts or routers. (A few unusual applications may require changes). As such, this solution can be implemented and experimented with quickly. If nothing else, this solution can serve to provide temporarily relief while other, more complex and far-reaching solutions are worked out. * https://datatracker.ietf.org/doc/html/rfc1631 https://datatracker.ietf.org/doc/html/rfc1631 It served its purpose, and folks should be moving past it now.
- smashed 3y ago
  Yes, and the problem is that people and organizations have grown very accustomed and appreciate all these band aids. It's very flawed, but the flaws are very well understood and people actually seem to like operating all these workarounds. Not saying that's good, just what I'm seeing in the field.
  - kevincox 3y ago
    Who is appreciating these bandaids? Are you talking about the fact that NAT has a defacto inbound firewall? It would be pretty easy to implement that firewall without a NAT.
    - formerly_proven 3y ago
      There's two different ways of looking at the internet. The greybeards philosophy is how it initially was. There aren't multiple networks, there is supposed to be ONE network, THE internet with ONE global address space. The philosophy of those who grew up with NAT, who think that sounds insane. The internet is just the glue network between heaps and heaps of separate networks, each with their own, enclosed address space. Why would you want all networks to be one network, why should your printer have a globally-unique globally-routable address? The two different philosophies don't tend to get along.
      - kevincox 3y ago
        You can still have unique addresses and private networks. For things that shouldn't be globally routable give them a unique internal address. For things that should be give them a unique public address. It still makes things simpler to not have the NAT.
      - Dagger2 3y ago
        The whole point of using NAT is that you want to be part of the one network but can't get enough address space for your bit of it. If you didn't, you wouldn't even have routing to the Internet in the first place and therefore would have no need for NAT. It's perfectly fine to run a separate network. You can do that and still access Internet hosts easily by having one machine that's on both networks and running a proxy on it. But nobody wants to do that. Almost everybody actually wants to be able to route to the Internet and back, so they set a router up to join the networks, and then (on v4) they have to NAT because nobody will give them enough v4 space for their network. Unfortunately there's a severe lack of understanding of basic networking concepts and of what routing and NAT are doing, even in people who work in the field.
- bcook 3y ago
  I worry about the loss of the implicit firewall that NAT offers. Network security audits of dual-stack networks far too often show practically no open ports on IPv4, because of NAT, while IPv6 exposes everything. The security through obscurity of the practically unscannable IPv6 address space is not a firewall.
  - justsomehnguy 3y ago
    > I worry about the loss of the implicit firewall that NAT offers. ... NAT does not offer 'implicit firewall' It's just what Average Hacker somewhere on the net can't route easily into your local network. If this is no longer an Average Hacker or he is sitting on your wire then the only thing what your NAT 'offers' is your false sense of security. And by the way, nobody, noone forbade you from having explicit firewall rules denying anything from anywhere, not explicitly allowed. Just like it is done in a proper IPv4 configuration.
    - networkchad 3y ago
      [dead]
    - bcook 3y ago
      > And by the way, nobody, noone forbade you from having explicit firewall rules denying anything from anywhere, not explicitly allowed. Just like it is done in a proper IPv4 configuration. Sure, in a perfect world, migrating to IPv6 should be safe, but the default configuration on many ISP-supplied routers has no firewalling beyond what NAT offers.
      - Dagger2 3y ago
        Which is nothing. NAT offers zero firewalling. I won't say there aren't ISP routers without firewalling, but for the most part they're pretty decent at having it. It's just that the firewalling is a completely separate thing to NAT.
  - justsomehnguy 3y ago
    > but the default configuration on many ISP-supplied routers has no firewalling beyond what NAT offers Repeat after me: NAT does not provide firewalling in any way. What you think as 'firewalling' is just inability to route packets to your LAN[0] for someone further than your immediate gateway and this is true only until you have no active inbound NAT sessions. If for some reason there is a session what allows anyone to contact the machine on your LAN (ie Full Cone NAT) then... anyone can contact your machine behind the NAT. I'm not sure there any router or appliance what would do that automatically anymore (because by default outbound session would create a thing called Address and Port Restricted NAT in TFA) but it's quite easy to do this by misconfiguration or some automatic mechanism, like UPnP. If the problem is in the 'default configuration of many ISP-supplied routers' then you really should address that and not treat NAT as a firewall. And last, but not least: every modern OS comes with a built-in firewall. Even Windows' one is pretty decent to block anything not explicitly allowed. There is no network scanning in IPv6, it's pointless or requires to sit on the wire to listen for NDP - and at this point NAT wouldn't help, too. [0] or sometimes the packets are routed pretty fine in, it's just the absence of the state and/or proper rules what forbids the answer to be routed back. If you ever needed to troubleshoot an assymetric NAT you would know this. ADD: this should had been a reply for your further comment, of course, but I leave it here.
- deleted 3y ago
  [deleted]
richardwhiuk 3y ago
Essentially, most NATs are symmetric, with some port forwarding rules, which operate in Full Cone mode. More interesting questions are "what happens when there's multiple NAT IPs?" "how long do the symmetric rules stay around for?" "what keeps them around?"
- lxgr 3y ago
  At least most home routers (on connections that still get a public IPv4 address) are fortunately not symmetric, or STUN would not be working with them. (STUN only works if at least one endpoint is port-restricted or better, if I remember correctly; it might also have been both ends.) Many carrier-side NATs are indeed often symmetric, unfortunately.
syntaxfree 3y ago
Somehow I expected something something Peano something something
- Shazshe 3y ago
  [dead]
theamk 3y ago
It's kinda crazy how in CS, any random implementation-specific behavior is codified and relied upon. As in, the design goal of NAT - sharing small number of external IPs by larger number of machines -- is best realized with what STUN calls "symmetric NAT". I am pretty sure the only reason full cone/restricted NAT type exists is performance, routers trying to keep translation table smaller for memory or CPU reasons. And yet, based on router's internal implementation detail, there is now a protocol and an RFC and tools, detectors, software support, tutorials and so on.
- zer8k 3y ago
  This has less to do with CS and more to do with engineering constraints. Conflating the two is common but in this case it matters. Algorithms themselves are not system-specific. RFCs codify an idea and the people who write the code make the system specific modifications. In this case routers are bespoke enough still that standards are basically controlled by a few major players.
- pixl97 3y ago
  For the longest time home routers were coming with tiny amounts of memories. It was pretty easy to crash some of them by running P2P file sharing with connections to too many IPs
UnixSchizoid 3y ago
NAT, the bane of my sysadmin existence.
j1elo 3y ago
I wrote a similar article for the Knowledge Base of the Kurento project I'm maintaining: https://doc-kurento.readthedocs.io/en/latest/knowledge/nat.html https://doc-kurento.readthedocs.io/en/latest/knowledge/nat.h... Visualization is the more powerful tool to help readers conceptualize the text, but it's also difficult to get right. After some experimentation with diagramming tools, I ended up going for an ASCII-based view. It's important to not overlook the section "Types of NAT in the Real World", which is just a quote from the relevant part of Wikipedia, to essentially say that in practice none of these theoretical models are perfectly found in real-world equipment. Still a useful differentiation to learn, but one shouldn't expect network equipment to behave as one of the described categories 100% of the time.
- ejanus 3y ago
  Is it open source?
dfawcus 3y ago
In many ways, the NAT classification scheme generated from the BEHAVE wg is a lot better. Splitting it in to "mapping" and "filtering" characteristics, and then indicating if each is "endpoint independent" or "endpoint dependent", with the latter having "address dependent" or "address and port dependent". That then covers more than the simple, opaque, and inadequate terminology of "cones" used by the earlier RFCs. i.e. see https://www.rfc-editor.org/rfc/rfc4787 https://www.rfc-editor.org/rfc/rfc4787 See the following article, with the table "NAT Cone Types" for an easier to understand piece, and the sub-set of combinations which the cone terminology covers. https://tailscale.com/blog/how-nat-traversal-works/#naming-our-nats https://tailscale.com/blog/how-nat-traversal-works/#naming-o... As to "implicit firewall", as has been indicated, there isn't really such a thing, just the filtering behaviour. It is not uncommon for a CGNAT to have EIM and EIF, hence they're "full cone"; so that is what one will generally experience when tethering to a LTE/5G mobile network.
- OskarS 3y ago
  > As to "implicit firewall", as has been indicated, there isn't really such a thing, just the filtering behaviour. I mean, there clearly is a firewall. If you buy a printer today, you don't really have to worry very much about how safe its network features are or if the firmware is updated, because if you put it behind a NAT router, it's not reachable from the global internet. Which is clearly a kind of firewall. And, generally, a good thing: it would be TERRIBLE for security if every shoddy network enabled device that anyone's bought for the last 30 years were reachable from the public internet. In the utopian "every device has a unique IPv6 address!", that would be the case. It's true that an IPv6 gateway/router/whatever could have an explicit firewall that provides the same security, but the fact that this comes "by default" with a NAT router is honestly pretty nice for most users. And it's silly to deny it's an "implicit firewall", it clearly is. That's why I called the IPv6 version an "explicit firewall" two sentences ago.
  - dfawcus 3y ago
    The effect of EIM + EIF is that if a private port reaches out to somewhere on the Internet, then anywhere on the Internet can reach back to that port. So a port scan can find it. Off the shelf consumer NAT "routers" tend to have an "allow out by default" policy. Now given the garbage one tends to find in the software of lot of off the shelf devices, the only way to ensure they don't "reach out to the Internet" is with an explicit outbound firewall, which prevents them reaching out. A web browser these days opens so may connections, and is so vulnerable, that one should view those sitting behind a consumer NAT is not behind a firewall. FWIW - My day job includes implementing and maintaining (i.e. writing the software) for commercial NAT and firewall devices.

116 points by signa11 3y ago

NAT "saved" the internet and broke much more: - we now have IP address markets - we now have STUN/TURN/ICE - we now have CGNAT None of that was needed, but why make a proper fix when you can instead do a series of band-aids?

fenesiistvan 3y ago
The fix is IPv6
- signa11 3y ago
  that is just an urban-legend at this point in time.
  - throw0101a 3y ago
    45% of Google's traffic is IPv6: * https://www.google.com/intl/en/ipv6/statistics.html https://www.google.com/intl/en/ipv6/statistics.html It's the majority of traffic, 53%, in the US.
    - signa11 3y ago
      in was referring to op’s insinuation (i think) about ipv6 address space being large enough to not warrant usage of nat.
      - lxgr 3y ago
        Are you disagreeing that it's large enough? The only instances of IPv6 NAT I've seen are situations like "I have only a single IPv6 address available but need to run a VM/a Wi-Fi hotspot/...", and arguably that's a completely different matter than "I have full control over my network, but I simply can't request the address space I need because there's none left". Practically, I've not encountered it myself. I was recently surprised to learn that even when tethering from my iPhone, client devices receive a public IPv6, so apparently mobile networks assign more than an /128 address to even single-line customers. On fixed-line IPv6, I've also never encountered any less than an /64 network.
        patrakov 3y ago
        /64 is not enough if you need to run two networks (e.g., a guest WiFi in addition to the main one). And yet, here in the Philippines, an IPv6 subnet larger than /64 is an enterprise-only feature that is denied to home users.
        megous 3y ago
        You can subnet /64. You'll just lose SLAAC. (+ some idiocy around some devices that refuse to implement both DHCPv6 and manual setting of IPv6 addresses)
        growse 3y ago
        This is a similar complaint to "I can't run a server from home because my ISP wont give me a static IP". Sure, it's a problem, but not one with the protocol.
        zekica 3y ago
        RIPE-738 (European RIR's address allocation and assignment policy) says that home users should get at least /56.
        jlokier 3y ago
        That's interesting. I've been tethering for years using Android phones, and using a 4G standalone router. I've never seen a client be allocated any IPv6 address in either case. I know the phone gets one for itself, but I don't think the router does. Looking at the phone's IP address status, it is given a non-public IPv4 by the mobile network (so CGNAT if it uses it), and what looks like a single IPv6 by the mobile network.
theamk 3y ago
I wish there were IP successor which would _only_ expand address space and not redo everything network-related. Increasing size of some structs and recompiling software is easy. Re-doing entire address allocation logic, address splitting, and network administration approach is much harder, as it affects millions of customized setups. Oh well, too late for this now. I guess this is the lesson for future network protocol designers: small, backwards-compatible changes will have much higher chances of working. And saying "you must drop old thing entirely and redo everything from scratch" means it'll take more than 30 years for your protocol to be deployed.
- _a_a_a_ 3y ago
  When you've invented something better you can also invent a time machine, take a trip back half a century and cause everything to be done the right way from the very start.
- growse 3y ago
  It's impossible to implement a backwards-compatible successor to IP without breaking the principle that every node can address other node. Old nodes will have no idea how to address "new" ones, and if you want actual communication to happen, then addressability needs to function in both directions. (You've also glossed over the fact that so much hardware assumed that an IP address was an int32. Swapping that out was always going to take a long time).
  - ok123456 3y ago
    If it was just a simple expansion you could have had a deadline for a switch over date. For example, on 1999-1-1 00:00:0.000Z stop using 32 bit address, and roll over to a 64 bit address. This is what happened when the internet switched from NCP to TCP. But, since it's not just a simple expansion of the address space and it fundamentally does things differently, this is impossible. And we've been stuck in limbo for about 28 years now.
    - growse 3y ago
      Things that break when you do "just a simple expansion" of the address length because they assume a 32 bit address: * ARP (goodbye all your switches) * DHCP (goodbye all your CPE routers) * DNS (A records don't work any more) * BGP (goodbye internet backbone routers) * ICMP (good luck without this) * etc. It is impossible to change the length of the address without fundamentally changing how the internet works.
still_grokking 3y ago
> None of that was needed, but why make a proper fix when you can instead do a series of band-aids? Exactly! There can't be anything beyond duct tape "engineering" in IT, because worse is "better"… You know? Doing things properly would cost money. Nobody is willing to pay. So nothing will ever change.
- lxgr 3y ago
  > Doing things properly would cost money. Nobody is willing to pay. So nothing will ever change. That's not a fair characterization of the problem: Unless everybody switches at the same time (~impossible), IPv6 requires paying for both stacks until the migration is complete. That's simply not economical, and not everybody on the internet can afford to disregard economics that way. I'm also running IPv6 on all my hobbyist projects, but I really can't blame anyone that doesn't.
  - lloeki 3y ago
    It's a game theory problem: nobody wanted to foot the bill on their side, endlessly punting and waiting for others to foot it for them. End result is that now everyone foots a different, worse bill, yet will still have to foot the previous bill because the workarounds have their limits when the attrition game pans out.
  - marcosdumay 3y ago
    > IPv6 requires paying for both stacks until the migration is complete Yeah, the IP licensing costs are sure to bankrupt you. Only hobbyists have enough money to do it. Large corporations can not afford the money and labor.
    - lxgr 3y ago
      Hobbyists: "Wanna do IPv6? It's cool and we'll do our part for incentivizing people to also switch! It should only take a couple of Saturday afternoons." "Sure, sounds cool, let's do it!" Meanwhile, at any average corporation: "Ok, so implementing IPv6 will cost us x$ and n person months, got it. And the upside is that we'd get a badge on some IPv6 readiness site, yes? And what would be the consequence, for us, of not doing this? Interesting, absolutely nothing you say, at least until every single customer is at least on IPv6 dual stack, since we need to provide our existing IPv4 stack too? Cool, thank you for presenting, please don't come again!" About the only large commercial entities that see any benefits of rolling out IPv6 are eyeball-heavy ISPs (since selling native IPv6 + CG-NAT for IPv4 is a slightly less horrible proposition than selling CG-NAT alone), and much less importantly any entity so large that CG-NAT capacity (memory and assigned IP/port tuples) is an issue for them.
throw0101a 3y ago
> None of that was needed, but why make a proper fix when you can instead do a series of band-aids? It was needed temporarily until we got more address space. The original NAT RFC 1631 (later 3022) was released in 1994: The huge advantage of this approach is that it can be installed incrementally, without changes to either hosts or routers. (A few unusual applications may require changes). As such, this solution can be implemented and experimented with quickly. If nothing else, this solution can serve to provide temporarily relief while other, more complex and far-reaching solutions are worked out. * https://datatracker.ietf.org/doc/html/rfc1631 https://datatracker.ietf.org/doc/html/rfc1631 It served its purpose, and folks should be moving past it now.
smashed 3y ago
Yes, and the problem is that people and organizations have grown very accustomed and appreciate all these band aids. It's very flawed, but the flaws are very well understood and people actually seem to like operating all these workarounds. Not saying that's good, just what I'm seeing in the field.
- kevincox 3y ago
  Who is appreciating these bandaids? Are you talking about the fact that NAT has a defacto inbound firewall? It would be pretty easy to implement that firewall without a NAT.
  - formerly_proven 3y ago
    There's two different ways of looking at the internet. The greybeards philosophy is how it initially was. There aren't multiple networks, there is supposed to be ONE network, THE internet with ONE global address space. The philosophy of those who grew up with NAT, who think that sounds insane. The internet is just the glue network between heaps and heaps of separate networks, each with their own, enclosed address space. Why would you want all networks to be one network, why should your printer have a globally-unique globally-routable address? The two different philosophies don't tend to get along.
    - kevincox 3y ago
      You can still have unique addresses and private networks. For things that shouldn't be globally routable give them a unique internal address. For things that should be give them a unique public address. It still makes things simpler to not have the NAT.
    - Dagger2 3y ago
      The whole point of using NAT is that you want to be part of the one network but can't get enough address space for your bit of it. If you didn't, you wouldn't even have routing to the Internet in the first place and therefore would have no need for NAT. It's perfectly fine to run a separate network. You can do that and still access Internet hosts easily by having one machine that's on both networks and running a proxy on it. But nobody wants to do that. Almost everybody actually wants to be able to route to the Internet and back, so they set a router up to join the networks, and then (on v4) they have to NAT because nobody will give them enough v4 space for their network. Unfortunately there's a severe lack of understanding of basic networking concepts and of what routing and NAT are doing, even in people who work in the field.
bcook 3y ago
I worry about the loss of the implicit firewall that NAT offers. Network security audits of dual-stack networks far too often show practically no open ports on IPv4, because of NAT, while IPv6 exposes everything. The security through obscurity of the practically unscannable IPv6 address space is not a firewall.
- justsomehnguy 3y ago
  > I worry about the loss of the implicit firewall that NAT offers. ... NAT does not offer 'implicit firewall' It's just what Average Hacker somewhere on the net can't route easily into your local network. If this is no longer an Average Hacker or he is sitting on your wire then the only thing what your NAT 'offers' is your false sense of security. And by the way, nobody, noone forbade you from having explicit firewall rules denying anything from anywhere, not explicitly allowed. Just like it is done in a proper IPv4 configuration.
  - networkchad 3y ago
    [dead]
  - bcook 3y ago
    > And by the way, nobody, noone forbade you from having explicit firewall rules denying anything from anywhere, not explicitly allowed. Just like it is done in a proper IPv4 configuration. Sure, in a perfect world, migrating to IPv6 should be safe, but the default configuration on many ISP-supplied routers has no firewalling beyond what NAT offers.
    - Dagger2 3y ago
      Which is nothing. NAT offers zero firewalling. I won't say there aren't ISP routers without firewalling, but for the most part they're pretty decent at having it. It's just that the firewalling is a completely separate thing to NAT.
- justsomehnguy 3y ago
  > but the default configuration on many ISP-supplied routers has no firewalling beyond what NAT offers Repeat after me: NAT does not provide firewalling in any way. What you think as 'firewalling' is just inability to route packets to your LAN[0] for someone further than your immediate gateway and this is true only until you have no active inbound NAT sessions. If for some reason there is a session what allows anyone to contact the machine on your LAN (ie Full Cone NAT) then... anyone can contact your machine behind the NAT. I'm not sure there any router or appliance what would do that automatically anymore (because by default outbound session would create a thing called Address and Port Restricted NAT in TFA) but it's quite easy to do this by misconfiguration or some automatic mechanism, like UPnP. If the problem is in the 'default configuration of many ISP-supplied routers' then you really should address that and not treat NAT as a firewall. And last, but not least: every modern OS comes with a built-in firewall. Even Windows' one is pretty decent to block anything not explicitly allowed. There is no network scanning in IPv6, it's pointless or requires to sit on the wire to listen for NDP - and at this point NAT wouldn't help, too. [0] or sometimes the packets are routed pretty fine in, it's just the absence of the state and/or proper rules what forbids the answer to be routed back. If you ever needed to troubleshoot an assymetric NAT you would know this. ADD: this should had been a reply for your further comment, of course, but I leave it here.
deleted 3y ago
[deleted]

richardwhiuk 3y ago

Essentially, most NATs are symmetric, with some port forwarding rules, which operate in Full Cone mode. More interesting questions are "what happens when there's multiple NAT IPs?" "how long do the symmetric rules stay around for?" "what keeps them around?"

lxgr 3y ago
At least most home routers (on connections that still get a public IPv4 address) are fortunately not symmetric, or STUN would not be working with them. (STUN only works if at least one endpoint is port-restricted or better, if I remember correctly; it might also have been both ends.) Many carrier-side NATs are indeed often symmetric, unfortunately.

syntaxfree 3y ago

Somehow I expected something something Peano something something

Shazshe 3y ago
[dead]

theamk 3y ago

It's kinda crazy how in CS, any random implementation-specific behavior is codified and relied upon. As in, the design goal of NAT - sharing small number of external IPs by larger number of machines -- is best realized with what STUN calls "symmetric NAT". I am pretty sure the only reason full cone/restricted NAT type exists is performance, routers trying to keep translation table smaller for memory or CPU reasons. And yet, based on router's internal implementation detail, there is now a protocol and an RFC and tools, detectors, software support, tutorials and so on.

zer8k 3y ago
This has less to do with CS and more to do with engineering constraints. Conflating the two is common but in this case it matters. Algorithms themselves are not system-specific. RFCs codify an idea and the people who write the code make the system specific modifications. In this case routers are bespoke enough still that standards are basically controlled by a few major players.
pixl97 3y ago
For the longest time home routers were coming with tiny amounts of memories. It was pretty easy to crash some of them by running P2P file sharing with connections to too many IPs

UnixSchizoid 3y ago

NAT, the bane of my sysadmin existence.

j1elo 3y ago

I wrote a similar article for the Knowledge Base of the Kurento project I'm maintaining: https://doc-kurento.readthedocs.io/en/latest/knowledge/nat.html https://doc-kurento.readthedocs.io/en/latest/knowledge/nat.h... Visualization is the more powerful tool to help readers conceptualize the text, but it's also difficult to get right. After some experimentation with diagramming tools, I ended up going for an ASCII-based view. It's important to not overlook the section "Types of NAT in the Real World", which is just a quote from the relevant part of Wikipedia, to essentially say that in practice none of these theoretical models are perfectly found in real-world equipment. Still a useful differentiation to learn, but one shouldn't expect network equipment to behave as one of the described categories 100% of the time.

ejanus 3y ago
Is it open source?

dfawcus 3y ago

In many ways, the NAT classification scheme generated from the BEHAVE wg is a lot better. Splitting it in to "mapping" and "filtering" characteristics, and then indicating if each is "endpoint independent" or "endpoint dependent", with the latter having "address dependent" or "address and port dependent". That then covers more than the simple, opaque, and inadequate terminology of "cones" used by the earlier RFCs. i.e. see https://www.rfc-editor.org/rfc/rfc4787 https://www.rfc-editor.org/rfc/rfc4787 See the following article, with the table "NAT Cone Types" for an easier to understand piece, and the sub-set of combinations which the cone terminology covers. https://tailscale.com/blog/how-nat-traversal-works/#naming-our-nats https://tailscale.com/blog/how-nat-traversal-works/#naming-o... As to "implicit firewall", as has been indicated, there isn't really such a thing, just the filtering behaviour. It is not uncommon for a CGNAT to have EIM and EIF, hence they're "full cone"; so that is what one will generally experience when tethering to a LTE/5G mobile network.

OskarS 3y ago
> As to "implicit firewall", as has been indicated, there isn't really such a thing, just the filtering behaviour. I mean, there clearly is a firewall. If you buy a printer today, you don't really have to worry very much about how safe its network features are or if the firmware is updated, because if you put it behind a NAT router, it's not reachable from the global internet. Which is clearly a kind of firewall. And, generally, a good thing: it would be TERRIBLE for security if every shoddy network enabled device that anyone's bought for the last 30 years were reachable from the public internet. In the utopian "every device has a unique IPv6 address!", that would be the case. It's true that an IPv6 gateway/router/whatever could have an explicit firewall that provides the same security, but the fact that this comes "by default" with a NAT router is honestly pretty nice for most users. And it's silly to deny it's an "implicit firewall", it clearly is. That's why I called the IPv6 version an "explicit firewall" two sentences ago.
- dfawcus 3y ago
  The effect of EIM + EIF is that if a private port reaches out to somewhere on the Internet, then anywhere on the Internet can reach back to that port. So a port scan can find it. Off the shelf consumer NAT "routers" tend to have an "allow out by default" policy. Now given the garbage one tends to find in the software of lot of off the shelf devices, the only way to ensure they don't "reach out to the Internet" is with an explicit outbound firewall, which prevents them reaching out. A web browser these days opens so may connections, and is so vulnerable, that one should view those sitting behind a consumer NAT is not behind a firewall. FWIW - My day job includes implementing and maintaining (i.e. writing the software) for commercial NAT and firewall devices.