How common is for companies to let many users share only one public ip address?
I hope the answer is "not very common" since I'm developing software that depends on the ip number being pretty much unique.
How common is for companies to let many users share only one public ip address?
I hope the answer is "not very common" since I'm developing software that depends on the ip number being pretty much unique.
Only one of the companies I've worked for since 1995, and that's quite a lot of companies, uses public IP addresses for desktop clients. So for me, the answer is: very common indeed.
I would very strongly advise against deploying software that makes the assumption that ipv4 addresses are unique to end-users, at this stage of the v4 deployment.
ipv6, that's a different kettle of ball games.
I have never seen any company use public IPs for their desktops or internal servers, and these days it is also very rare for externally facing servers (eg webservers) to have a public IP address - usually these are NATed behind load balancers, or ever more commonly, are virtual servers in a dynamic server pool, so don't even really exist.
The NAT'ing may not be down to the level of all internal IP's to one external, usually there are ranges, however it is the overwhelming norm for NAT'ing to be used in one form or another.
While one-to-one IP to user association is laughably uncommon for internet communications, they're a lot more common for intranet communication. Multiple NAT gateways inside a network are not common, but also not unheard of. In the cases where you run into internal NAT, it's likely because two entities (perhaps due to mergers) have their own independent Internet access and maintain a dedicated link for talking to the other entity, and that link is likely to be guarded by a firewall/NAT.
Even if a company has loads of public IP addresses, they now prefer to NAT them to hide their internal network structure for security reasons. Most companies will use combination boxes that provide both NAT and firewall functionality. Hence, you can safely assume NAT's in companies networks 99.99% of the time. If you are developing applications that require connecting to computers inside a company, then you definitely need to consider one of the various "NAT Traversal" techniques .. see http://en.wikipedia.org/wiki/NAT_traversal (not very easy to work with, but an evil necessity).
It is extremely common. If it is already an integral part of your application then perhaps you could alter it to use the socket (ie the IP address and port number that nat has assigned)?
Well if you are writing a web application you can at least try to get the X-Forwarded-For
HTTP Header that proxies (usually) set for their internal clients. It's not uncommon for the same organizations that are using NAT to use HTTP proxies for external access so you can work with an External IP:Internal IP
pair or hash.
But yeah, don't count on uniqueness of IP address on today's word, NAT is pretty common and proxies will continue to be when ipv6 become fully implemented.
It used to be a lot more common, back in the early days of the internet, to have a large external block of IPs. My own company just finished migrating off a /16 block. I used to work at a university that had two /8 blocks.
But these days, it's very uncommon for a company to not use a NAT. Big external IP blocks just aren't that useful. My current company, (the one that just moved off the /16), set up an internal WAN on 10.0.0.0/8, and that allows for every computer in the company to have a "unique" IP (though, admittedly, not an externally accessible one), at a much lower cost than we paid for our original block.
There is something that is unique - the combination of IP address and port number. In a NAT'ed environment, multiple internal clients appear to have the same IP when viewed from the outside, but they each have a different port number, paired with that IP address. (All this is speaking about IPv4.)
But be careful, because that pairing (address, port) is only valid as long as the connection is established. If the connection is closed and re-opened, then a new port may be paired even though for the same client.
There are systems that use this, such as LogMeIn, that require the client to contact a central server, then route all communications through the central server and back to the client through the open connection on that port.
Whilst NAT is common, another scenario that's also commonly found is the requirement to proxy all HTTP traffic through a single set of proxies, so that all HTTP/HTTPS traffic appears to come from a small set of IP addresses.
An office I have worked in for a large (50,000+ employee) company had every single desktop assigned a public IP address. However, all traffic inbound was blocked (except established) and all traffic outbound on ports 80/443 were also blocked. So whilst I could SSH out to any IP address on the internet directly from my desktop, all web browsing on the regular ports had to be conducted via the proxy.
A different company I've seen took a different approach - every internal client had an RFC1918 address allocated but there was zero routability to the internet. As before, web proxies were used to get HTTP traffic to the clients, but there was no NAT routing going on.