Every desktop computer, mobile phone, refrigerator, and any other device in the world when connected to the internet has their own Internet Protocol (IP) address. It’s function is exactly the same as a residential address used by the postal service in that it is a unique identifier tied to location. All data traveling through the internet, like packages in the postal service, has a source (from) IP address and a destination (to) IP address. The command “ping” can be a useful tool to practice addressing computers by their IP addresses. With it, you can send test messages to devices by their IP addresses and get a response back. Getting a response back is also useful information to check whether the device is connected to the internet or not. As the number of devices connected to the internet has exploded in recent years – with some estimates approaching 22 billion1 devices or more – IP addresses have been forced to expand to ensure there are enough numbers for all. The following figure goes over the two versions of Internet Protocol addresses.
Even though IPv6 is the new standard, the changeover has been slow and support for the older IPv4 standard is still widespread. Therefore, a supporting IPv4 protocol will be briefly discussed: Dynamic Host Configuration Protocol (DHCP). The reason for this protocol is the total number of unique IP addresses with the IPv4 format is just over 4 billion. Not only is this number far too small (well..it didn’t look so small back in the 1980s), but those 4 billion addresses were allocated in a very inefficient manner with many being reserved for special situations. Therefore, DHCP was developed to allow devices on private networks to share the same public IPv4 address. To the rest of the internet, DHCP makes all the traffic coming from a coffee shop or a household appear to come from a single device; freeing up scores of IPv4 addresses. It accomplishes this by having the DHCP server – typically the router – act as a middleman between the network and the internet. All devices connected to the DHCP server get their own private IP address to be used between the device and the DHCP server.This private IP address then gets turned into the shared public IP address as the data passes through the DHCP server and out into the internet. The DHCP server will then make a note of where the data is going so that when the response comes back it knows which private IP address to forward the response to. As the available address pool for IPv6 is just over 340 billion billion billion billion, DHCP is not implemented in IPv6 networks…for now. The following graphic may help illustrate how DHCP works.
While you could type a public IPv4 or IPv6 address into the address bar of any web browser and still arrive at the website, it’s far easier for everyone to remember and type domains like “google.com”, “yahoo.com”, or “iastate.edu.” Therefore, another protocol is necessary to translate the human-friendly domains we provide into the IP addresses computers require to get the data to the right destination. This protocol is known as Domain Name System (DNS) and is provided by DNS servers. After typing in a domain like “hackerville.org”, the computer will ask the nearest available DNS server – typically the router – for the corresponding IP address. If the nearest available DNS server already knows the answer, maybe from another connected device asking for the same information earlier, then it will return this cached answer and that will be the end of it. If the DNS server doesn’t know the answer, then it will be responsible for asking other DNS servers until the answer is found. This is why the first time connecting to a website may take a little while. The first time is delayed by the long search for the IP address matching the provided domain. For subsequent visits, the DNS server has already cached the answer and can immediately provide that information. The command “nslookup”, an abbreviation of “name service look-up”, for Windows operating systems and “host” for Linux operating systems are useful to visualize this process because they allows us to request our own domain name resolution.
Once a device has the IP address of the destination, either by typing in the IP address or getting it through DNS, the device consults a routing table. Each row of the routing table contains a couple items, but the most important for our purposes is the following two: IP address and interface. As shown in the image below, the device has numerous spots for ethernet cords called interfaces. This particular networking device has 5 such interfaces. If you’ll recall from chapter 1, a networking device will escalate to another device covering a larger area if the final destination is not in its network. This escalation is done through a very special interface called the default interface. This interface is so special, it will usually be: colored, separated, labeled differently – usually as “WAN” or “Internet”, or all of the above so as to not be confused with the other interfaces.
Each of these interfaces could have a different wire plugged in, so the routing table tells the device which IP address is at the end of which wire. That is, which IP address is at the end of which interface. Should the connection be wireless, then the interface of the routing table for those IP addresses will indicate to use the antenna – not the wires. The command “netstat”, an abbreviation of “network statistics”, is useful to visualize the routing table used by a device.
Lastly, in addition to IP addresses, every device has at least one physical address. A physical address, sometimes called a MAC (Media Access Control) address, is used to help the physical hardware and is only used between immediately connected nodes. Any time data moves from one piece of hardware to another piece of hardware, say from the device to the router, or from the router to the modem, the data will have a source and destination physical address in addition to the source and destination IP address. The reason for this being that the IP addresses help identify the ultimate source and destination, whereas the physical address is concerned with the source and destination for just this next hop. It can be useful for computers to know this because issues like dropped or missing data happen when moving from one local node to another. To resolve the IP addresses the device knows are at the end of an interface via its routing tables to the physical address it needs to reliably get the data to the next hop, another protocol is needed. This protocol is known as ARP (Address Resolution Protocol) and is significantly simpler than its related protocol DNS. DNS resolves domains to IP addresses, but ARP takes it one more level down and resolves IP addresses to physical addresses. ARP does this by sending a request for the physical address down the interface it wishes to use and waits for the reply. That’s it. Once it gets the reply, it will save the response for future use and send the data on its merry way. ARP needs to be this quick and simple because while a DNS query will only happen at the very start to get that ultimate destination IP address, an ARP query could happen every single time it needs to move from one piece of hardware to another if it doesn’t already have that answer. As shown in chapter 1, this could be a lot of hops before finally reaching the destination.
To learn more about actually connecting a device to an interface, continue to the next chapter.