[HN Gopher] Nat Types
___________________________________________________________________
Nat Types
Author : signa11
Score : 45 points
Date : 2023-07-24 12:08 UTC (10 hours ago)
(HTM) web link (www.roxlu.com)
(TXT) w3m dump (www.roxlu.com)
| UnixSchizoid wrote:
| NAT, the bane of my sysadmin existence.
| richardwhiuk wrote:
| 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 wrote:
| 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.
| zekica wrote:
| 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?
| smashed wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| fenesiistvan wrote:
| The fix is IPv6
| signa11 wrote:
| that is just an urban-legend at this point in time.
| throw0101a wrote:
| 45% of Google's traffic is IPv6:
|
| * https://www.google.com/intl/en/ipv6/statistics.html
|
| It's the majority of traffic, 53%, in the US.
| signa11 wrote:
| in was referring to op's insinuation (i think) about ipv6
| address space being large enough to not warrant usage of
| nat.
| lxgr wrote:
| 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 wrote:
| /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 wrote:
| 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 wrote:
| 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 wrote:
| RIPE-738 (European RIR's address allocation and
| assignment policy) says that home users should get at
| least /56.
| theamk wrote:
| 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.
| growse wrote:
| 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).
| _a_a_a_ wrote:
| 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.
| Dagger2 wrote:
| That's pretty much what v6 is. The other proposals were
| significantly different to v4, but v6 works almost exactly
| the same as v4 does.
|
| It's also backwards compatible with v4 in pretty much every
| way that you _can_ be backwards compatible with v4. It 's not
| v6's fault that v4 isn't forwards compatible with bigger
| address sizes.
|
| > Increasing size of some structs and recompiling software is
| easy
|
| This turns out to not be so easy. People are STILL writing
| new code with "struct sockaddr_in" allocations and
| "socket(AF_INET, ...)" and crap like that. That's the main
| thing blocking people from moving from dual stack to v6-only
| today.
| throw0101a wrote:
| > _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
|
| It served its purpose, and folks should be moving past it now.
| bcook wrote:
| 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 wrote:
| > 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 wrote:
| [dead]
| bcook wrote:
| > 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 wrote:
| 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.
| [deleted]
| still_grokking wrote:
| > 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 wrote:
| > 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.
| marcosdumay wrote:
| > 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 wrote:
| 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.
| lloeki wrote:
| 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.
| syntaxfree wrote:
| Somehow I expected something something Peano something something
| j1elo wrote:
| 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.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 wrote:
| Is it open source?
| theamk wrote:
| 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.
| pixl97 wrote:
| 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
| zer8k wrote:
| 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.
___________________________________________________________________
(page generated 2023-07-24 23:02 UTC)