
Back to basics #4 – NAT and private networks
NAT is the sole reason why we still can use the internet today. With IPv4 limited number of IP addresses, introduction of private networks saved the day. At least until IPv6 takes over the world. Today I am going to take a quick look at what this whole NAT is all about.
Table of Contents
ToggleNAT scene setup
In the previous post about IP, I have mentioned classes of IP addresses. All the limitations that they have, and the ways of identifying which part of the address is related to the network segment, and which identifies the target host. I have promised back then, to revisit the solution that was introduced to bypass IPv4 limitations. Here it is.
Lots of hosts do not need to be publicly available on the internet. We want to securely browse our favorite social media, but we don’t want to have outside automated bots tampering with our computers or mobiles. The solution to this problem is simple. Several IP addressing ranges were excluded from the overall pool of available addresses. By pure convention, they became somehow “invisible” in the public sphere of the internet. With that move, network administrators and ISPs got their holy grail. They were able to structure internal/private networks using all the power of the class A/B/C addressing.
Private networks IP ranges
Depending on the configuration provided by the administrators, private networks can use one of three ranges.
- 10.0.0.0 to 10.255.255.255 – should be treated as A class
- 172.16.0.0 to 172.31.255.255 – should be treated as B class
- 192.168.0.0 to 192.168.255.255 – should be treated as C class – it’s the most popular setup for home networks, and that’s also the one I am using right now
Those IP ranges are filtered out/excluded from usage on the internet. ISPs/network hardware just skips routing for those addresses if they are used outside of private networks. Every time you see an IP address, that falls within the above range – it’s a private network address. All righty, let’s go forth.
NAT – Network Address Translation
Hosts remaining inside private networks still can access the internet. However, in the public, all those hosts are identified with a single – public – IP address. To make things easier let’s look at the example. I am writing this post sitting by my desktop computer. It connects to my local router. The same as my smart TVs, two mobile phones, and printer. All of these devices have their own separate IP addresses (starting with 192.168.1 prefix in my case). All that comes from the private network IP range that my router manages. Every time I make even the smallest request outside my network, my router does its job – is serves as a NAT.
Every time I make a request to the host that lies outside of my local network (listening to some killer beat on Spotify now) my router checks the target IP I want to reach. It knows that this address does not fall within local network range, so it sends it outside. How that happens – that will be the topic of a separate post. My router stores my desktop IP address for future (re)use. The actual request going out of my router, has the IP of my router. Not the one that my desktop host has. When the response from the outside comes (e.g. from Spotify), my router “knows” where it should be redirected back.
How does this whole private network work?
Pretty easy I would say. Router, which serves as a gateway for the private network, usually also acts as a DHCP provider. What is DHCP? It stands for Dynamic Host Configuration Protocol. It is a service, and a protocol at the same time, that assigns hosts specific IP addresses. Every time my desktop computer boots, it sends a specific request to the whole private network. This type of request sent to every machine in the network is called multicast/broadcast. The last available host identifier in the IP is used as an address for that. So in my case – whatever is sent to 192.168.1.255 – will be sent to every host in my network.
Let’s get back to our request. In simple terms, the request says: “Hey. That’s my MAC address. Can you give me an IP address?”. When my mobile phone or printer gets that request, they just drop it. However, when it reaches my router, which acts as a DHCP server, things get interesting. Router knows his job, and keeps in memory ARP Table – which maps specific MAC addresses from within the network to the IP address. The router also keeps a list of free IP addresses that it can assign to the hosts. Upon getting my request for an IP, it finds the first free address, and sends it back to the requester. Of course – updating its own ARP Table along the way.
Is this the end?
Obviously that’s a very simplistic model, and I did not cover everything here. Two reasons for that. First is the fact that these blog posts are a mere reminder for myself – not a full-blown networking course. If you want to get more info – please find it in more specialized sources. Look for phrases like ARP, RARP and ICMP. Second reason is more serious – I will cover tracing and routing using IP in the next blog post in the series. Stay tuned!
Leave a Reply
You must be logged in to post a comment.