Is it possible to use global IP addresses without internet?

Solution 1:

It is absolutely possible - there is nothing magical about IPV4 space, and it all works the same way. The headaches come many years down the line when this network gets integrated into the Internet.

Solution 2:

Yes its possible, but not recommended.

Instead you should use the RFC1918-allocated blocks, and a small a network as you can. Avoid using 10.0.0.0/8 for your home network with a handful of devices.

More details at https://www.rfc-editor.org/rfc/rfc1918 and its replacement https://www.rfc-editor.org/rfc/rfc6761

A good rule-of-thumb is to use a network size of 4x the maximum number of devices you could run on that network, or a /24 (254 hosts) whichever is larger. A /24 also simplies subnetting.

So use 10.yourstreetnumber.yourbirthyear.0 or 192.168.yourheightincm.0 Be creative!

If you're likely to create a site-to-site VPN, consider the 172.16-through-31.0.0 range as a candidate - because its a bit messier and is therefore less used.

Another reason for not using an existing public range, is that dns caching could mess up devices that change networks. IE laptops and phones and tablets could cache "dns.google.com" as 8.8.8.8 and keep using that record once they connect to your LAN. Or someone goes home and your hostname of "fileserver.local" resolving to 8.8.8.8 could be cached for up to the TTL of the record.

Example of stupid IP reuse - Back in the days of vmware workstation I tried using 127.99.99.0/24 as an IP network, on the basis it was more-specific than the 127.0.0.0/8 applied to loopback interfaces.

This worked perfectly for vmware, and for linux VMs. But windows (xp?) said "Stop, no" as soon as you put 127 in for the first octet of the IP address. I never tried allocating IPs via DHCP at the time.

The possibilities of unintended consequences are enormous.

And sometimes, rarely, classful networking messes you up. I used to run a network which was 192.168.0.0/16 and it had many things coexisting happily, windows 95, XP, NT4, linux, macs, printers, etc.

Then we got a bunch of Linksys WRT54GL APs, and they would not accept a netmask larger than /24 when used with 192.168. This is because originally 192.168.0.0 was defined as

256 contiguous class C networks

So network had to be 256 hosts or smaller. This only ever appeared with some linksys kit, and a flash with OpenWRT was happy to use the full /16 network.

Upshot of this is a /24 is more than enough for most users. A /8 or /16 is silly-oversized.

Solution 3:

Yes, this can be done. No, you don't want to. Unlike some other answers I see, I'm about to delve into more details of why (particularly for my second sentence).

Let's say you control a computer, and you can set it's IP address. And so you type in an IP address of 8.8.8.8. Can you do that? Yes.

Now, "routing" could be an issue (as I'm going to elaborate on in a later part of this answer). However, there may be ways around that. So, let's say that a remote end contacted your ICMP server and ran "ping 8.8.8.8". Would your ICMP server (typically built into "TCP/IP stack" software components) respond? Yup. No problem.

Let's say that you start up a server on this computer, such as a DNS server. If your computer was running a DNS server and received the response, could it respond and could everything work? Yes. No problem.

Let's say that you start up an HTTP server. If another computer opened up a web browser and ended up communicating to your computer with the IP address, then could your computer respond and everything work? Um... well... it used to be that the answer was "Yes". But, now, things got a bit more complicated due to HPKP. For more details, you can see Wikipedia's web page on HTTP Public Key Pinning]. So, that might not work so well. To summarize: popular web browsers considered this a style of attack, and came with some details about proper HTTPS certificates/connections for some of the world's top sites. Another related technique may be "HSTS preloading", which is related to HSTS ("HTTP Strict Transport Security"). So, when people install modern versions of web browsers, those browsers may come with some details about some websites. If your fake "Google" site doesn't match expectations, the browser may intervene (and presumably let the end user know of a problem).

And, as you suggested, if you do these sorts of things, the legitimate site won't be able to be contacted on this IP address.

Now, why am I saying you don't want to do this?

First, there is a better solution. Have devices rely on DHCP. Then, on your local network, have a DHCP server that points places to use your local DNS servers, at a sensible address (e.g., FEC0:0:0:ffff::/126 or an IPv6 address starting with fd or perhaps fec0:, or IPv4 using the address ranges from IETF BCP 5 ("RFC 1918")). If you standardize that for client machines, then mobile systems will likely work remotely and on your local network as desired.

The big challenge with doing things as you expect is routing. If you set up an address at 192.168.55.3/24 and another computer at 192.168.55.105/24 tries to communicate with you, then the computers will recognize the /24 (a.k.a. a subnet mask of 255.255.255.0) and figure out that anything matching the first three octets (starting with "192.168.55.") is on the local network, and will try a direct communication.

If a DNS client is at 192.168.55.105/24 and try to communicate with 8.8.8.8, then the computer will recognize that 8.8.8.8 does not match the first three octets, and so the computer will attempt send the traffic to a gateway device, most commonly a "default gateway" which sends information to the Internet. (This "gateway" device needs to be on the local network. Using more technical terms, the gateway needs to be in the same subnet.)

So, there are three approaches that could be done to still get your computers to communicate with 8.8.8.8

You could make your client systems illegitimately use the 8.8.8.0/24 range. Then 8.8.8.8 would seem close. Note that this would break valid communications to 8.8.8.8, and you couldn't simultaneously use this strategy to also have your local computers be in the same close IP range as a different address.
You could make your local system use 192.168.55.105/0 instead of 192.168.55.105/24. This means you're using a subnet mask of 0.0.0.0, so now you've effectively convinced your computer that 8.8.8.8 is a local address. So communications won't go to your "default gateway", but instead communications will try to reach 8.8.8.8 directly on your local network. If both the client and server are doing this, that will likely work.
- However, using the extreme example shown here, what you've effectively done is convince your computer that all IP addresses are part of your local network. So, this illegitimate method has now convinced the affected computer that the entire Internet is to be treated like it is on your local network. Now instead of breaking communications with the legitimate Google site at 8.8.8.8, you've effectively broken communications with all legitimate IP addresses on the Internet. Ouch. Bad.
You could set up some custom routing on your "default gateway" device, so that information sent to 8.8.8.8 gets redirected to the local IP address of your desires, instead of getting passed onto your Internet service provider.

While the third approach could theoretically work without too many problems or unwanted side effects, the biggest drawback is that it requires that you muck around with traffic routing. If you're going to muck with something, I suggest that you understand it well first.

As someone who does understand traffic routing, I would suggest that you may need some amount of expertise to successfully break the legitimate connections that you want (to the real 8.8.8.8) while not also breaking legitimate connections that you don't want broken. And if you have that much expertise to pull that off, then you probably also have some expertise to simply run a DNS server on an established private address. So, why not do things in the standardized way which is less likely to cause weird rare side effects that are harder to foresee and troubleshoot?

In answer to what you asked and how you asked it, yes, technically something like this could be possible. But do also keep in mind that if communication isn't going to where it should go, then that is often described as a "Man In The Middle" ("MITM") attack. Web browser connections have already evolved to support HKPK to defeat such shenanigans. A lesser-known fact is that DNS has largely been replaced with using EDNS (using "Extension mechanisms for DNS"), and a more widely known fact is that there are some newer enhancements to DNS security called DNSSec. If you were unaware of any of this, then realize that the current maintainers of popular Internet-based software code might already be way ahead of you, so you might want to keep that in mind before trying to include an "MITM-attack" as a critical part of some sort of fancy new design of any network you oversee.

So, to summarize, the main reason I think you don't want to do this for a real network (rather than a test lab where you're exploring possibilities) is simply that, to accomplish useful legitimate goals, there is a better way. Which is, when you're trying to design how your network behaves, do things the right way. You're likely to experience less pain overall.

To re-clarify in case this was forgotten, the "right way" I am referring to is to just operate your local DNS server on a private address, fooling nobody, and encourage computers to use the local private address or to rely on DHCP, and have your local DHCP servers tell devices to rely on your local DNS server. It is a more honest style of design which doesn't break the ability to communicate with a public site, and is widely supported so maintainers of Internet standards are less likely to do something that breaks such a legitimate design on many local networks used throughout the world.

Solution 4:

Not only it can be done, but I have seen a few networks made by illiterate admins featuring global IP addresses AND connected to the Internet (via NAT firewall).

The only real problem is being unable to access the legitimate network having the same IP range. Not a big deal for some 256 IP addresses somewhere on the big, big Internet.

Solution 5:

In theory, that should be fine.

In practice:

May break third-party assumptions.
You might use software/hardware that assumes certain well-known IP conventions will hold, causing unintended behaviors when you break these assumptions.
May trigger hidden bugs.
Some buggy software works fine in most cases, but weird specifics might trigger them. Such bugs can get fixed when noticed, but if you use a non-standard configuration, the potential to encounter bugs no one else has had a chance to run into before may increase.
May confuse others working with your network.
Even if you're cool with remembering that 8.8.8.8 means something else in your internal network, this could potentially confuse others. Coworkers, tech support, folks reading a log you might share on a help-forum, etc., might have trouble with it.
May create contradictions in caches.
If any devices on your network were previously connected to the global internet, they may have IPv4 addresses stored in their settings, firewall rules, etc., potentially causing undesired collisions when they join the local network.

In theory, poor third-party designs and bugs might not be your fault. But in practice, you might start to believe in ghosts.