162

For years the press has been writing about the problem that there are now very few IPv4 addresses available. But on the other hand, I'm using a server hosting company which gladly gives out public IPv4 addresses for a small amount of money. And my private internet connection comes with a public IPv4 address.

How is that possible? Is the problem as bad as the press wants us to believe?

  • 23
    Some companies still have lots of IPv4 addresses on hand. Others have very little. I have to think very carefully about using up an IPv4 address; as a result I have quite a few IPv6-only machines. – Michael Hampton Jan 28 '18 at 14:25
  • 21
    It also gives you some perspective to the amount of pain ISPs are willing to cause other people just to avoid having to deploy IPv6. – immibis Jan 28 '18 at 22:34
  • 22
    I wouldn't call it evil, but it certainly is a pain. That said, most consumers probably wouldn't care they're behind a nat, assuming facebook and whatsapp work ._. – Journeyman Geek Jan 29 '18 at 2:57
  • 8
    @JourneymanGeek Well, average consumers don't really care about anything they don't understand. There are ideas for distributed social media, for example (because that makes it very difficult to censor), but nobody cares about such things until after they've taken off the ground, which they can't because of NAT. I daresay NAT is one of the reasons we've ended up with a centralized Web, because it's basically impossible to host your own website without paying someone. – immibis Jan 29 '18 at 23:19
  • 15
    As @Azendale pointed out, game server hosting is a big one. Why can't I just run minecraft_server.exe and give my friends my address? Because of NAT. "Consumers" most certainly do want to run game servers sometimes. – immibis Jan 29 '18 at 23:25

10 Answers 10

177

It's very bad. Here is a list of examples of what I have first hand experience with consumer ISPs doing to fight the shortage of IPv4 addresses:

  • Repeatedly shuffling around IPv4 blocks between cities causing brief outages and connection resets for customers.
  • Shortening DHCP lease times from days to minutes.
  • Allow users to choose if they want network address translation (NAT) on the Customer Premise Equipment (CPE) or not, then retroactively turn it on for everybody anyway.
  • Enabling NAT on CPE for customers who already used the opportunity to opt out of NAT.
  • Reducing the cap on number of concurrently active media access control (MAC) addresses enforced by CPE.
  • Deploying carrier-grade NAT (CGN) for customers who had a real IP address when they signed up for the service.

All of these are reducing the quality of the product the ISP is selling to their customers. The only sensible explanation for why they would be doing this to their customers is shortage of IPv4 addresses.

The shortage of IPv4 addresses has lead to fragmentation of the address space which has multiple shortcomings:

Without NAT there is no way we could get by today with the 3700 million routable IPv4 addresses. But NAT is a brittle solution which gives you a less reliable connectivity and problems that are difficult to debug. The more layers of NAT the worse it will be. Two decades of hard work has made a single layer of NAT mostly work, but we have already crossed the point where a single layer of NAT was sufficient to work around the shortage of IPv4 addresses.

  • 57
    One thing to add is that NAT also leads to malicious users impacting normal users and generally makes IP unreliable as a user-differentiation mechanism. For example, Wikipedia blocking almost every Qatari user due to one or a few users' vandalism. – IllusiveBrian Jan 28 '18 at 17:55
  • 9
    @IllusiveBrian makes a valid point. I inherited ad-targeting software that used IP addresses as a primary identifier. This is nowhere near sufficient nowadays and has had to be extensively modified to keep it reliable. India and Greece seem to be two of the worst affected countries. I can see an ad being hit 100+ times per day from the same IPv4, but each hit can be a different user, determined by other tracking methods – Darren H Jan 28 '18 at 19:46
  • 15
    @DmitriySintsov no more than a simple stateful firewall would. If an edge device can do NAT, it can do stateful firewalling. – mfinni Jan 29 '18 at 14:05
  • 15
    @DarrenH "ad-targeting software that used IP addresses as a primary identifier... and has had to be extensively modified to keep it reliable. " Well that reason alone is enough to keep NAT. – Andy Jan 30 '18 at 23:35
  • 6
    @DarrenH Its just a comment about not liking ad software, whatever tone you're feeling is in your own head. – Andy Jan 30 '18 at 23:55
131

Before we started to run out of IPv4 addresses, we didn't (widely) use NAT. Every internet connected computer would have its own globally unique address. When NAT was first introduced, it was to move from giving ISP's customers 1 real address per device the customer used/owned to giving 1 customer 1 real address. That fixed the problem for a while (years) while we were supposed to be switching to IPv6. Instead of switching to IPv6, (mostly) everybody waited for everybody else to switch and so (mostly) nobody rolled out IPv6. Now we are hitting the same problem again, but this time, a second layer of NAT is being deployed (CGN) so that ISPs can share 1 real address between multiple customers.

IP address exhaustion is not a big deal if NAT is not terrible, including in the case where the end user has no control over it (Carrier Grade NAT or CGN).

But I would argue that NAT is terrible, especially in the case where the end user does not have control over it. And (as a person whose job is network engineering/administration but has a software engineering degree) I would argue that by deploying NAT instead of IPv6, network administrators have shifted the weight of solving the address exhaustion out of their field and on to end users and application developers.

So (in my opinion), why is NAT a terrible, evil thing that should be avoided?

Lets see if I can do it justice in explaining what it breaks (and what issues it causes that we've become so accustomed to that we don't even realize it could be better):

  • Network layer independence
  • Peer to peer connections
  • Consistent naming and location of resources
  • Optimal routing of traffic, hosts knowing their real address
  • Tracking the source of malicious traffic
  • Network protocols that separate data and control into separate connections

Let's see if I can explain each of those items.

Network layer independence

ISPs are supposed to just pass around layer 3 packets and not care what is in the layers above that. Whether you are passing around TCP, UDP, or something better/more exotic (SCTP maybe? or even some other protocol that is better than TCP/UDP, but is obscure because of a lack of NAT support), your ISP is not supposed to care; it's all supposed to just look like data to them.

But it doesn't -- not when they are implementing the "second wave" of NAT, "Carrier Grade" NAT. Then they necessarily have to look at, and support, the layer 4 protocols you want to use. Right now, that practically means you can only use TCP and UDP. Other protocols would either just be blocked/dropped (vast majority of the cases in my experience) or just forwarded to the last host "inside" the NAT that used that protocol (I've seen 1 implementation that does this). Even forwarding to the last host that used that protocol isn't a real fix -- as soon as two hosts use it, it breaks.

I imagine there are some replacement protocols for TCP & UDP out there that are currently untested and unused just because of this issue. Don't get me wrong, TCP & UDP were impressively well designed and it is amazing how both of them have been able to scale up to the way we use the internet today. But who knows what we've missed out on? I've read about SCTP and it sounds good, but never used it because it was impractical because of NAT.

Peer to Peer connections

This is a big one. Actually, the biggest in my opinion. If you have two end users, both behind their own NAT, no matter which one tries to connect first, the other user's NAT will drop their packet and the connection will not succeed.

This affects games, voice/video chat (like Skype), hosting your own servers, etc.

There are workarounds. The problem is that those workarounds cost either developer time, end user time & inconvenience, or service infrastructure costs. And they aren't foolproof and sometimes break. (See other users comments about the outage suffered by Skype.)

One workaround is port forwarding, where you program the NAT device to forward a specific incoming port to a specific computer behind the NAT device. There are entire websites devoted to how to do this for all the different NAT devices there are out there. See https://portforward.com/. This typically costs end user time and frustration.

Another workaround is to add support for things like hole punching to applications, and maintain server infrastructure that is not behind a NAT to introduce two NATed clients. This usually costs development time, and puts developers in a position of potentially maintaining server infrastructure where it would have not be previously required.

(Remember what I said about deploying NAT instead of IPv6 shifting the weight of the issue from network administrators to end users and application developers?)

Consistent naming/location of network resources

Because a different address space is used on the inside of a NAT then on the outside, any service offered by a device inside a NAT has multiple addresses to reach it by, and the correct one to use depends on where the client is accessing it from. (This is still a problem even after you get port forwarding working.)

If you have a web server inside a NAT, say on port 192.168.0.23 port 80, and your NAT device (router/gateway) has a external address of 35.72.216.228, and you set up port forwarding for TCP port 80, now your webserver can be accessed by using either 192.168.0.23 port 80 OR 35.72.216.228 port 80. The one you should use depends on whether you are inside or outside of the NAT. If you are outside of the NAT, and use the 192.168.0.23 address, you will not get to where you are expecting. If you are inside the NAT, and you use the external address 35.72.216.228, you might get where you want to, if your NAT implementation is an advanced one that supports hairpin, but then the the web server serving your request will see the request as coming from your NAT device. This means that all traffic must go through the NAT device, even if there is a shorter path in the network behind the NAT, and it means that logs on the web server become much less useful because they all list the NAT device as the source of the connection. If your NAT implementation doesn't support hairpin, then you will not get where you were expecting to go.

And this problem gets worse as soon as you use DNS. Suddenly, if you want everything to work properly for something hosted behind NAT, you will want to give different answers on the address of the service hosted inside a NAT, based on who is asking (AKA split horizon DNS, IIRC). Yuck.

And that is all assuming you have someone knowledgeable about port forwarding and hairpin NAT and split horizon DNS. What about end users? What are their chances of getting this all set up right when they buy a consumer router and some IP security camera and want it to "just work"?

And that leads me to:

Optimal routing of traffic, hosts knowing their real address

As we have seen, even with advanced hairpin NAT traffic doesn't always flow though the optimal path. That is even in the case where a knowledgeable administrator sets up a server and has hairpin NAT. (Granted, split horizon DNS can lead to optimal routing of internal traffic in the hands of a network administrator.)

What happens when an application developer creates a program like Dropbox, and distribute it to end users that don't specialize in configuring network equipment? Specifically, what happens when I put a 4GB file in my share file, and then try to access in on the next computer over? Does it directly transfer between the machines, or do I have to wait for it to upload to a cloud server through a slow WAN connection, and then wait a second time for it to download through the same slow WAN connection?

For a naive implementation, it would be uploaded and then downloaded, using Dropbox's server infrastructure that is not behind a NAT as a mediator. But if the two machines could only realize that they are on the same network, then they could just directly transfer the file much faster. So for our first less-naive implementation try, we might ask the OS what IP(v4) addresses the machine has, and then check that against other machines registered on the same Dropbox account. If it's in the same range as us, just directly transfer the file. That might work in a lot of cases. But even then there is a problem: NAT only works because we can re-use addresses. So what if the 192.168.0.23 address and the 192.168.0.42 address registered on the same Dropbox account are actually on different networks (like your home network and your work network)? Now you have to fail back to using the Dropbox server infrastructure to mediate. (In the end, Dropbox tried to solve the problem by having each Dropbox client broadcast on the local network in hopes of finding other clients. But those broadcasts do not cross any routers you might have behind the NAT, meaning it is not a full solution, especially in the case of CGN.)

Static IPs

Additionally, since the first shortage (and wave of NAT) happened when many consumer connections were not always on connections (like dialup), ISPs could make better use of their addresses by only allocating public/external IP addresses when you were actually connected. That meant that when you connected, you got whatever address was available, instead of always getting the same one. That makes running your own server that much harder, and it makes developing peer to peer applications harder because they need to deal with peers moving around instead of being at fixed addresses.

Obfuscation of the source of malicious traffic

Because NAT re-writes outgoing connections to be as if they are coming from the NAT device itself, all of the behavior, good or bad, is rolled into one external IP address. I have not seen any NAT device that logs each outgoing connections by default. This means that by default, the source of past malicious traffic can only be traced to the NAT device it went through. While the more enterprise or carrier class equipment can be configured to log each outgoing connection, I have not seen any consumer routers that do it. I certainly think it will be interesting to see if (and for how long) ISPs will keep a log of all TCP and UDP connections made through CGNs as they roll them out. Such records would be needed to deal with abuse complaints and DMCA complaints.

Some people think that NAT increases security. If it does, it does so through obscurity. The default drop of incoming traffic that NAT makes mandatory is the same as having a stateful firewall. It is my understanding that any hardware capable of doing the connection tracking needed for NAT should be able to run a stateful firewall, so NAT doesn't really deserve any points there.

Protocols that use a second connection

Protocols like FTP and SIP (VoIP) tend to use separate connections for control and actual data content. Each protocol that does this must have helper software called an ALG (application layer gateway) on each NAT device it passes through, or work around the issue with some kind of mediator or hole punching. In my experience, ALGs are rarely if ever updated and have been the cause of at least a couple of issues I have dealt with involving SIP. Any time I hear someone report that VoIP didn't work for them because audio only worked one way, I instantly suspect that somewhere, there is a NAT gateway dropping UDP packets it can't figure out what to do with.

In summary, NAT tends to break:

  • alternative protocols to TCP or UDP
  • peer-to-peer systems
  • accessing something hosted behind the NAT
  • things like SIP and FTP. ALGs to work around this still cause random and weird problems today, especially with SIP.

At the core, the layered approach that the network stack takes is relatively simple and elegant. Try to explain it to someone new to networking, and they inevitably assume their home network is probably a good, simple network to try to understand. I've seen this lead in a couple of cases to some pretty interesting (excessively complicated) ideas about how routing works because of confusion between external and internal addresses.

I suspect that without NAT, VoIP would be ubiquitous and integrated with the PSTN, and that making calls from a cell phone or computer would be free (except for the internet you already paid for). After all, why would I pay for phone when you and I can just open a 64K VoIP stream and it works just as well as the PSTN? It seems like today, the number 1 issue with deploying VoIP is going through NAT devices.

I suspect we don't usually realize how much simpler many things could be if we had the end to end connectivity that NAT broke. People still email (or Dropbox) themselves files because if the core problem of needing a mediator for when two clients are behind NAT.

  • 3
    @supercat IPv6 addresses are globally unique, but not flat (to support routing, which needs to be hierarchical). Seems to me that if we want any two Internet-connected hosts to theoretically be able to communicate, globally unique addresses in some form are necessary. – Jakob Jan 29 '18 at 20:43
  • 9
    @supercat It's unfortunately a persistent myth that IPv6 still doesn't have enough space for everyone. You could give a /48 to everyone on earth and still have vast amounts of space left over. To exhaust the currently allocated 2000::/3 you would have to repeat that exercise over 4,000 times! or give everyone a /34. But a /48 is good enough for virtually everyone, and those who need more can easily get it. Even if that weren't enough, there's still 4000::/3, 6000::/3, etc., available. We have a LOT of room; it's time to use it. See also RFC 6177. – Michael Hampton Jan 29 '18 at 23:15
  • 7
    @immibis You seem to have missed something. Organizations are not limited to getting either a /48 or a /32. They can get virtually any size block. It could be a /44 or a /40 or /39 or /47 or whatever. You also should read RFC 6177. – Michael Hampton Jan 29 '18 at 23:52
  • 4
    Unfortunately many people have started to use NAT as a crappy form of security and many devices like chromecasts and IoT devices assume any device that is able to connect to it is a trusted device so every consumer router I have seen will drop incoming connections to ipv6 devices as well and some I have seen have no way to disable this, only the regular port forwarding. – Qwertie Jan 30 '18 at 2:17
  • 14
    ... Ok I hate NAT now; how do I switch to IPv6? – Adam Barnes Jan 30 '18 at 17:57
20

One big symptom of IPv4 exhaustion I didn't see mentioned in other answers is that some mobile service providers started going IPv6-only several years ago. There's a chance you've been using IPv6 for years and didn't even know it. Mobile providers are newer to the Internet game, and don't necessarily have huge pre-existing IPv4 allocations to draw from. They also require more addresses than cable/DSL/fiber, because your phone can't share a public IP address with other members of your household.

My guess is IaaS and PaaS providers will be next, due to their growth that isn't tied to customers' physical addresses. I wouldn't be surprised to see IaaS providers offering IPv6-only at a discount soon.

  • 10
    I've already seen a few small providers offering IPv6-only VMs and charging a premium for IPv4. – Michael Hampton Jan 29 '18 at 19:20
14

The major RIRs ran out of space for normal allocations a while ago. For most providers therefore the only sources of IPv4 addresses are their own stockpiles and the markets.

There are scenarios in which it is preferable to have a dedicated public IPv4 IP but it's not absolutely essential. There are also a bunch of public IPv4 addresses that are allocated but not currently in use on the public internet (they may be in use on private networks or they may not be in use at all). Finally there are older networks with addresses allocated far more loosely than they need to be.

The three largest RIRs now allow addresses to be sold both between their members and to each others members. So we have a market between organizations who either have addresses they are not using or who have addresses that could be freed up for a cost on one side and organizations who really need more IP addresses on the other.

What is difficult to predict is how much supply and demand there will be at each price-point and therefore what the market price will do in future. So-far the price per IP seems to have remained surprisingly low.

  • AfriNIC has less than a /8 worth of addresses still available, and I've seen lots of examples of orgs outside Africa grabbing these up. – Michael Hampton Jan 28 '18 at 20:05
7

Ideally, every host on the internet should be able to obtain a global scope IP address, however IPv4 address exhaustion is real, infact ARIN has already ran out of address in their free pool.

The reason why everyone can still access internet services just fine, is thanks to Network Address Translation (NAT) techniques which allow multiple hosts to share public IP addresses. However, this doesn't come without problems.

  • 18
    I don't want to know how many man-hours, resources, and millions have been wasted between Napster, Gnutella, Gossip, Kazaa, BitTorrent, Kademlia, FastTrack, eDonkey, Freenet, Grokster, Skype, Threema, Spotify, and so on, developing NAT-piercing techniques. – Jörg W Mittag Jan 28 '18 at 17:16
  • @JörgWMittag Not to mention how spectacular it failed for Skype in December 2010. – kasperd Jan 28 '18 at 21:40
  • 4
    And the fact that you have to use NAT-piercing techniques in the first place. If machine X and machine Y are both on ordinary connections they can't talk to each other without a mediator. Annoying for things like file synchronization tasks. – Loren Pechtel Jan 29 '18 at 2:36
  • @kasperd Could you elaborate on this "failed for Skype in December 2010"? I could find that a large number of supernodes failed at once, for some unspecified reason. And fail to see how that is relevant to IPv4 address exhaustion. – ivan_pozdeev Feb 2 '18 at 7:04
  • 4
    @ivan_pozdeev Supernodes is a workaround for problems caused by NAT. NAT itself is a workaround for the shortage of IPv4 addresses. Thus the need for Skype to use supernodes in the first place was entirely driven by shortage of IPv4 addresses. Had the internet been upgraded to IPv6 at a more reasonable pace Skype would not have needed supernodes, and that particular outage would not have happened. – kasperd Feb 2 '18 at 23:44
5

ISP's used to give out blocks of 256 IP addresses to companies. Now, ISP's are stingy and give you (a company) like 5. Back in the day (2003), every PC and connected device in your home had its own internet IP address. Now, the cable/DSN/Fios router has one IP address and gives out 10.0.0.x ip addresses to all the PCs in your home. Summary: ISP's used to waste IP addresses and now they're not wasting them any more.

  • 5
    "Back in the day (2003), every PC and connected device in your home had its own internet IP address." Only if you paid for the 2nd, 3rd, 4th, etc. – RonJohn Jan 30 '18 at 0:30
  • 2
    RonJohn is correct. I was one of the early adopters of broadband when cable internet came to my area in 1997. I paid $50 (US) per month for it, and I distinctly remember that they offered a second IP address for an additional $20 per month. Even though I wanted one, I wasn't willing to pay for it. The following year, my problem was solved when I discovered NAT devices. They didn't have many features (such as port-forwarding for incoming connections) but the one I got solved my immediate need. – Charles Burge Jan 31 '18 at 1:15
  • @CharlesBurge I also remember that. And we are seeing some providers try to do the same thing with IPv6 now, too. – Kevin Keane Feb 1 '18 at 1:10
  • @CharlesBurge: This depended on your ISP. I had a friend on cable in Phoenix, AZ around the same time, and he got a fully routed subnet, a /29 block, with 8 addresses, 5 usable. We ran a Linux server on it with gated (by accident on our part), and the cable network actually shared full BGP routing information with it. That and people putting their Windows PCs and printers with fully open shares on the network made life interesting. – Zan Lynx Feb 1 '18 at 18:19
  • Oh yeah I do remember the network visibility. Everyone else on my loop was visible in "Network Neighborhood", and I could browse any shares that they had. – Charles Burge Feb 1 '18 at 19:32
5

You already got many excellent answers, but I would like to add something that hasn't been mentioned yet.

Yes, IPv4 address exhaustion is bad, depending on how you measure it. Some companies still have a huge supply of IPv4 addresses, but we are starting to see workarounds like carrier-grade NAT.

But many of the answers are wrong when they veer off into IPv6.

Here is a list of technologies that can help deal with the IPv4 address shortage. Each has its own advantages and drawbacks.

  • IPv6

    • Advantage: standardized and available in most operating systems.
    • Drawback: despite frequent statements to the contrary, serious security problems. As far back as 2005, US CERT warned of security issues caused by IPv6's global addressing. IPv6 can be secured properly, but given the state of consumer routers, it may not happen.
    • Drawback: migrating takes time, money and expertise.
    • Drawback: many consumer-grade devices are seriously flawed. For instance, a number of D-Link routers support IPv6 by simply forwarding all traffic without offering any firewalling.

Another consideration: even if IPv6 caught on completely today, it would still take another 20 years or so to phase out IPv4, due to legacy equipment that people will be using for a very long time (I still see Windows 2003 servers and Windows XP workstations occasionally! Not to mention all the printers and cameras and IoT gadgets that don't support IPv6).

  • CGNat:
    • Advantage: works without changes on customer premises.
    • Drawback: only supports outbound connections.
    • Drawback: may not support a few protocols.

Eventually, CGNat won't be enough. Maybe IPv6 will catch on, but it's also quite possible that we'll end up seeing country-grade NAT, or something along those lines.

Currently, as a consultant, I often have to point out to my customers that they are exposed on IPv6 (often thanks to Teredo). The next question will invariably be: "how much does it cost to fix that?" and then "How much does it cost to block it? What do we lose if we turn it off?" Guess what the decision will be every time.

Bottom line: to answer your question, yes, IPv4 exhaustion is real. And we will see quite a few mechanisms for coping with it. IPv6 may or may not end up being the equation.

To be clear: I'm not saying that I like this situation. I would like for IPv6 to succeed (and I would like to see a number of improvements to IPv6). I'm just looking at the situation as it is on the ground right now.

  • 2
    CGN, like any NAT, only works with TCP, UDP, and ICMP, and not other transport protocols. It also breaks many application-layer protocols. NAT is an ugly solution to try to extend IPv4, and it has really outlived its usefulness. – Ron Maupin Feb 1 '18 at 2:40
  • 3
    @supercat, IP packets do not have DNS names. That would be a different protocol. Only TCP, UDP, and ICMP transport protocols work with NAPT, others do not. Many applications and application-layer protocols do not work with NAPT, and they require ugly hacks on top of the ugly NAPT hack. The premise of IP is that every end-device has a unique address, and many protocols were designed around that. IPv6 solves that problem, as well as some IPv4 shortcomings. – Ron Maupin Feb 1 '18 at 21:32
  • 3
    @supercat, if it is really that simple, there would have been no reason for the huge installed base of IPX networks to convert to IPv4. You could do the same type of thing between IPX and IPv4, and it was done for a while, but it is just a kludge. – Ron Maupin Feb 1 '18 at 22:07
  • 1
    @supercat - so in order to support such a network, we need to abandon existing standards, and rewrite all existing applications that connect directly to addresses? That doesn't sound like a good approach to me. – Jules Feb 1 '18 at 22:58
  • 2
    @KevinKeane I'm not terribly surprised that an ancient consumer router from 2010 has IPv6 problems. A 30 second browse of Google search results indicates they solved that problem years ago. – Michael Hampton Feb 2 '18 at 19:05
-1

NAT is what happened when IPv6 was an idea, before it was reality, and IP address allocation was becoming a real issue (anyone remember when they were handing out Class C's basically for the asking?) and the real world needed a solution in the meantime.

NAT is not sufficient for IoT. If IoT is going to happen, it's going to happen with IPv6. The nature of IoT is more closely aligned with how the dialup world worked, except that there will be several orders of magnitude more devices connected at the same time.

  • 2
    From a quick search, NAT appears to have been originally defined by RFC 1631 in May 1994. IPv6 is defined in RFC 1883, published December 1995 as a proposed standard (which is pretty far along the standards track). I don't know where you draw the line between "an idea" and "reality", but mostly working IPv6 code almost certainly existed in testbeds well before RFC 1883 was published. Compare this to the often-referenced RFC 1918, which was published in February 1996, a few months after the initial IPv6 RFC. – a CVn Jan 30 '18 at 21:38
  • 2
    Standards are useless without implementation, and an implementation that consumers or businesses are willing to pay for, at that. Testbeds and proofs of concept don't count in the market. My point about NAT is that working implementations reached market (and therefore gained traction) because the existing hardware (and there was a of of it by that time) all spoke IPv4. So it was more a matter of "problem solved, lets work on more pressing issues now". – Xavier Jan 31 '18 at 2:43
  • 2
    @Xavier: 64K is an upper limit a NAT device can't even reach. For one, all the low ports under 1024 are restricted. And most NAT limits itself to a high port range of about 20K ports. And of course there's the memory issue: even today we have routers falling over and resetting because somebody tried to open 10,000 TCP connections at the same time. Looking at you, Google Home. – Zan Lynx Feb 1 '18 at 18:24
  • 1
    @KevinKeane - because part of the draw to IOT is being able to connect in to your devices from externally. At the moment, because configuring NAT is a pain that device manufacturers don't want to inflict on consumers, we're often doing this via external "hookup" services provided by device manufacturers but this isn't sustainable long term. All it needs is for a high profile manufacturer to go out of business and suddenly everyone will be wary of relying on their devices continuing to work. The only way this is going to carry on working in the long term is if most people have IPv6. – Jules Feb 1 '18 at 22:35
  • 1
    @supercat - perhaps, but so far that seems to be even less likely to happen than universal IPv6 availability... – Jules Feb 1 '18 at 22:56
-4

The whole IPv4 address issue is rather convoluted. You may find certain article reporting it is exhausted, yet another talking about large number of surplus (never used) addresses being sold from one party to another. The question would be why are these not available to those (emerging regions and rural areas of developed countries) short of them?

Below is the result of a study that we accidentally ventured into. It utilizes nothing more than the original IPv4 protocol RFC791 and the long-reserved yet hardly-utilized 240/4 address block to expand the IPv4 pool by 256M fold. We have submitted a draft proposal called EzIP (phonetic for Easy IPv4) to IETF:

https://tools.ietf.org/html/draft-chen-ati-adaptive-ipv4-address-space-03

Basically, the EzIP approach will not only resolve IPv4 address shortage issues, but also largely mitigate the root cause to cyber security vulnerabilities, plus open up new possibilities for the Internet, all within the confines of the IPv4 domain. In fact, this scheme may be deployed "stealthily" for isolated regions where needed. These should relieve the urgency to deploy the IPv6 for an appreciable length of time, and invalidate the market of trading the IPv4 addresses.

Any thought or comment will be much appreciated.

Abe(2018-07-15 17:29)

  • 3
    ServerFault is not an IETF WG. – womble Jul 16 '18 at 0:35
-6

Honestly, I think it is not as bad as people think. Yeah, maybe in some places, but not so much because there's not enough addresses. It's because they are all owned. Maybe it's my location or something, but I've done IT work for a bunch of small to medium-sized businesses in the last seven years or so, and all the things you are all talking about are usually just standard setup. Pretty easy unless you have a crappy device, or there's a shitty setup with the network in the first place that needs to be sorted out.

Personally, I'm fine with NAT. It's an added layer of protection, generally speaking. At least they either have to get through an extra device, or find a way to indirectly hijack my connection. As far as running servers, that's generally outside of and/or considered a breach of contract with your ISP unless your paying for it. Sure you can do it, and they probably won't bug you about it, but they could.

Port-forwarding and all that is not exactly complicated. Now, maybe some devices are not easy to configure, but that's not because of IPv4. It still offers the most compatibility simply because it is ubiquitous.

Nobody actually needs to email themselves, and sending something to Drop-box or Google Drive, or a million other similar services isn't exactly rocket science, nor slow, these days. I mean everything syncs. You drop it in a folder. Unless you're nerdy like me, and you do everything through ssh/sftp (okay not everything). And if you have some reason you really want to run your own server, cloud hosting is cheap-- I've got a dedicated virtual server that runs linux on an ssd. The bandwidth is crazy fast. It boots faster than I can type an up arrow and hit Enter. And is scalable The whole setup costs between 5 and 10 bucks a month, with free backups and no electric bill.

Don't really need a peer-network solution. Even most mult-user games these days are all setup to interact through an intervening server, all setup and preconfig'd. On the other hand, if what I'm reading in this post is all true, IT will be overcrowded and cheap if/when IPv6 takes off. Even cellphones are approaching fiber-like speeds. Or at least cable.

If you do run an in-house server, and you need to hit it with the same domain-name inside or outside you network, you can always spoof it's address using a linux-based router and dnsmasq or whatever and custom entries in the hosts file to redirect you to the local address if you're on the inside.

Really, I don't think it is actually desirable to have every device have it's own address straight out there floating open on the 'net. If someone wants to obvuscate themselves while attacking you, it's going to happen regardless. But you're a sitting duck if you're just sitting there balls out in the open breeze. Nah, I'll take my IPv4 and my NAT any day. But it's good that it's there.

Anywa, falling asleep now... probably more to say but I'll check in tomorrow in case I missed something. I'm sure there's more.

  • 12
    Uhm, it is actually desirable because of stabler connections, faster speeds, cheaper internet(ISP's not having to maintain their NAT servers, IP block allocations per region/city and shuffling things around to get by on specific peak hours). Do you know how confusing it is for websockets when a user on mobile hops from one cell tower to another and gets a new IP? There's a lot of compensation code, effort and energy required to keep it running. Your answer reads like, this tower might be missing it's foundation but hasn't toppled yet, so it's fine. – Tschallacka Jan 29 '18 at 13:11
  • 11
    You have some misconceptions about NAT and security. Please read RFC 4864. – Karl Bielefeldt Jan 29 '18 at 16:09
  • 4
    At this rate it'll be more than a generation. IPv6 is 20 years old this year. – Michael Hampton Jan 29 '18 at 19:37
  • 4
    RFC 2460 was published in December 1998. Several parts of it had been published prior to this point and there had been various testbeds up. IPv6 in roughly its current form was proposed in RFC 1883 which dates to December 1995. So you could say that IPv6 is even older than 20 years. But everyone regards RFC 2460 as the point where IPv6 was mature enough to implement. – Michael Hampton Jan 29 '18 at 21:28
  • 6
    BTW, while I'm on the subject, you should be aware that there are already IPv6-only gaming platforms, such as Xbox One. An Xbox One with IPv4 and not IPv6 connectivity sets up its own Teredo tunnel in order to reach the IPv6 Internet, which of course brings with it a penalty in latency and reliability. IPv4 is in pretty sad shape when a Teredo tunnel is considered less unreliable than a typical consumer IPv4 connection. – Michael Hampton Jan 29 '18 at 23:29

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.