Understanding IPv4 Subnetting (Part 2)

Computers seem to be virtually limitless in their abilities – they can send and receive digital information, serve content via many defined protocols, compute algorithms much faster than a human can, and even provide countless hours of fun and entertainment. One very common use of computers is indeed serving content to consumers, a technological concept known as client / server model. A simple metaphor: a consumer (or a client) goes (makes a connection request) to a place of business (or a server) and peruses the content therein. The bottom line is that a server hosts and provides resources and content to clients requesting said resources.

The way the clients and servers communicate is in terms of protocols, or a predefined method of communication between multiple networked hosts. A prominent protocol used nowadays is the HTTP protocol in our ever-beloved usage of the Internet. Other protocols that make our lives much simpler, without diving too far into their technical details, include: TCP, or really the TCP/IP suite, that essentially allows communication between computer systems (identified by IP addresses) in a reliable manner (TCP); DHCP, which saves many network administrators the headache of manually assigning IP address to their userbase; DNS, which negates the need of humans to remember yet another numerical identifier (or multiple IP addresses of their favorite websites); NTP, that allows for proper time alignment; and ARP, which works with MAC and IP address matching on a local network. If you’re interested in other common networking protocols and a description of the above protocols and more, refer to this article.

This article is written based on the client / server architecture model and discusses perspectives based on the model, though other architectures work in similar ways. That is, any network communication you have between multiple networked hosts will more or less follow the same basis as the client / server architecture.

How Servers Serve Services

Let’s assume that a business wanted to serve certain content to their userbase. They can create a website describing the business that is accessible using the HTTP protocol. In addition, they can offer file downloads (if applicable) that are accessible via the FTP protocol, or any of the other abundant protocols available. It is also entirely possible to serve content multiple ways from the same machine to meet the needs of varying clients – some may not want to use web access and prefer downloading content via FTP, for instance.

The way a server knows which service to serve is by the requested port number indicated by an incoming connection request. A sample connection may include: source IP address, destination IP address, source port, destination port, as well as protocol being used. When the server receives the connection request over a port, that server system (physical hardware itself) should have server software with an available socket that is bound on that port. For instance: port 80 is the common port for HTTP, 443 is for HTTPS, and 21 is for FTP. Once a connection is established, that is, the kernel sends the request to the appropriate software listening on that port, the server may offload that request internally to allow for further incoming connection requests on that same port. This StackOverflow post is rather technical but provides great insight on how this is done.

Depending on what server software is configured, a web server or FTP server, then that software determines how communications will be further handled. Each protocol is designated and specified by their appropriate RFC number. Request for Comments (RFC) are standards that detail out how each protocol will allow communication between connecting clients. There are numerous special keywords used to identify what the behavior of the software should be. For instance: HTTP has a GET keyword that queries a resource on a specific host.

Fun fact, there are 65,535 TCP ports and 65,535 UDP ports on a computer! In other words, a server can serve a lot of different services over TCP or UDP. Granted each service would share the pool of available resources (RAM, CPU, storage utilizations) on the system itself, so it may not be wise to have everything hosted on a single computer system. Another consideration in this would be how many clients are accessing the server content simultaneously. If you wanted to personally have a test server setup, I wouldn’t suspect this being an issue at all. In fact, I have a single system acting as a web server and FTP server at home, among other services.

How Do Clients and Servers Communicate

Let’s expand a bit more from the above-mentioned incoming request – which takes five bits of information (source IP, destination IP, source port, destination port, protocol).

When a client makes a request to a server for HTTPS communications, the client would use a system-generated source port number to send the request out through the local router to the server on a desired port, in this case port 443 for HTTPS communications. The client’s host itself has a random source port, the router generates yet another random source port that it keeps track of, and the request continues to the respective server. That server would return the traffic request to the originating IP address and respective source port number, in which the source IP is the public IP address where the client made the request from and the router identifies which internal client made that request based on the source port. This way if multiple clients from within the same network location made multiple connections to the same remote server, the source ports determine which client the router should send the return traffic to.

Bear in mind that traffic going out onto the Internet requires a unique IP address to be able to be identified for communication requests; that is, they’re publicly routable addresses. Internal client IP addresses are distinguished and reserved based on RFC 1918. This is where NATing comes into play, where internal clients making public server requests have their IP address rewritten by their network’s router / gateway device before sending the request out onto the Internet. The way gateway devices keep track of multiple clients is via connection tables and tracking internal client IP addresses and their corresponding source ports. Return traffic is addressed to the public IP of the network along with the source port, the one generated by the gateway device. From there, the gateway device looks up which client is associated with the gateway’s generated source port maintained within its connection table, then the traffic gets sent back to the original client.

Conclusion

The above may seem complicated, and the technical details surely are, but the concept of what it does is simple. Any computer system can be a server if appropriate software is installed on that system. This server software interacts with the hardware itself by means of system calls. In simple terms, system calls are basically API (application programming interface) calls or libraries that operating systems offer to software installed on it. The software uses the libraries, or API, that the OS offers to reach the kernel and have access to the hardware stack. Check the references for more insight on this.

One more example of Internet-bound connection requests. Suppose a local network is assigned 10.0.1.0/24. Any client (let’s say 10.0.1.50) on that network that makes a request has a random port (example, 55,087) assigned to the request and is sent alongside its IP address in the form of a packet. The gateway device accepts the request, granted it matches any preset rules for Internet traffic, rewrites the packet with its own source port (55,087 is changed to 53,798) as well as the public IP address assigned to the physical site by the ISP; for example, let’s assume it was WatchGuard.com’s IP address of 54.212.248.139. Since the public IP address is routable, the return traffic knows where to go and gets analyzed by the gateway device once again.

I added some references that greatly expand on all of this and recommend reading it, if you’re interested in the technical details at least. The complexity of computers and how they truly work on the inside, compared to the ease of use offered to consumers is just fascinating to me. My hopes are to break down complex details into easy-to-digest chunks of information.

References

Chase, J. Sockets and Client/Server Communication. Retrieved from https://users.cs.duke.edu/~chase/cps196/slides/sockets.pdf

Examcollection.com contributors. How do Common Networking Protocols Function. Retrieved from https://www.examcollection.com/certification-training/network-plus-how-do-common-networking-protocols-function.html

Mozilla.org contributors. What is a web server? Retrieved from https://developer.mozilla.org/en-US/docs/Learn/Common_questions/What_is_a_web_server

Computers are a great tool and provide many perks to their users; they can perform tasks in a rather impressively fast manner, potentially offer paperless offices, and you’re even able to play computer games…of course not during working time! Aside from these great benefits, however, how useful would they be if we typed something up, had to print it (thus negating the “paperless” aforementioned attribute) and fax / mail / hand-deliver it to the respective recipient?

This is where the ever-loved “network” aspect comes in. There is history to how this concept began, was revised, and came to be what it is today; read this if you’re interested in its history. Regardless of its ancestry, I am confident that most anyone is thankful to the many contributors to this awesome ability. How else could we send emails virtually versus the above-mentioned manual methods? What about the massive online gaming platforms that allow virtual users to face each other in combat, or team up and conquer dungeons and whatnot? Or in the case of our team’s admiration for “Neopets,” how would we be able to access their awesome website to do whatever we wanted to do?

The goal of this post is to clarify what a network is, some different types of networks used in today’s world, different devices used in networking, as well as how data is carried between the devices in terms of network media. Perhaps in the future I will build on this and dive into the Open Systems Interconnection (OSI) model where I will break down each of the seven layers. Stay tuned for that, but for the time being let’s dive into the basics of networking.

What Is Networking?

To be clear, networking refers to the ability for multiple network nodes to communicate with each other and share resources. Network nodes refer to any network-connected electronic device; network-capable gaming devices, cellular devices, laptops, computers, etc. Any sort of interaction from one network node reaching out to another network node is considered a network, regardless if there is Internet access available or not.

Two common implementations include peer-to-peer (P2P) and client/server set-ups. As the names may imply, a P2P connection is one where network nodes are able to connect to each other and share resources. Workloads are shared between nodes and no one has more privileges than the other. Think of this as a way for any number of nodes to share files with one another, but not designated to do so. In contrast to this is client / service architecture, which dictates one server to be the storehouse of whatever content. With this set-up, you have one computer that may have more resources and is a bit faster at processing requests.

The key difference between the two architectures is that in P2P set-ups, all nodes are equal in privileges in accordance what the other nodes allow access to. Client / server architectures allow for more granular, centralized control. The two can seem ambiguous depending on your perception, but there is definitely a difference between them.

Types of Networks

On a smaller scale, local area networks (LAN) entail networked electronic devices that are within the same vicinity, generally. An example of this would be a home or smaller office. You can obviously get way broader than this, an example would be a wide area network (WAN), which is essentially what the Internet is. Regardless what set-up you have, chances are you have an Internet service provider (ISP) running some sort of cable (copper wired Ethernet or glass-based fiber optics) from their datacenter to your home or office. From there, you’d connect a modem to modulate outgoing network signals, and demodulate incoming network signals. The modem then connects to your router that may connect to a switch, which allows multiple devices to connect – thus creating a LAN. I’ll cover network devices a tad more in another section.

For corporations or businesses with multiple offices in remote areas, the HQ office can connect to these offices via a virtual private network (VPN). A VPN is essentially an encrypted tunnel that is created over the unencrypted Internet pipeline. Bottom line is, if you want to be secure between HQ and remote sites or home-based employees, use a VPN. Another important set-up to touch on is virtual LAN, or VLAN. In short, VLAN refers to creating segmented networks, thus allowing a segregation between user sets. Essentially you can have a VLAN domain for servers, one for the HR department, another for your IT team, and a general user VLAN. There are many other types of networks, but these are the main varieties.

Networking Devices

Starting from the gateway, that is the device that allows access to and from the Internet. There are devices that combine both modem and router capabilities into a single device. As stated previously, a modem’s job is to modulate outgoing network traffic, and demodulate incoming traffic – hence modem. On the other hand, a router is what routes traffic from one network node to another – whether on the local network or somewhere out on the Internet. It is important to note that routers specifically route between different network segmentations. As an example, if node A has an IP address of 192.168.1.5 and wants to connect to node B’s IP address of 10.0.1.5, then a router would assist in this.

Some routers possess the ability to broadcast wireless frequencies, thus allowing mobile devices, laptops, and other electronic devices to connect via wireless means. Some devices don’t even have network interface cards (NICs), so wireless connectivity is crucial in order to get online. If your router doesn’t have this ability, then a separate access point (AP) would allow for this functionality. In this case then the AP itself would be hardwired to the router. Wireless frequencies have gotten better and stronger over the years, but they still do face obstruction the further away your wireless device is compared to the AP; walls, plumbing, or whatever may be between the line of sight are other examples of this.

Let’s back up a bit to routers and connecting devices to them, such as the AP above. Routers have few Ethernet ports, thus limiting the number of hardwired devices. If you don’t have many devices, no worries, but if you do, then you may want to consider a switch. Modern technologies have paved the way for switches, which are generally faster than the predecessors they’ve replaced – hubs. Seeing that hubs are pretty much a thing of the past, I’ll explain switches but leave it up to you to research hubs more if you’re into the history of older devices. Switches essentially extend the router’s NICs to more than what is integrated on the router itself. Further, they also remember networked devices based on media access control (MAC) addresses to negate the need to send data frames to all devices, are able to send and receive transmissions simultaneously (known as full-duplex), and have the ability to send more data per second than hubs.

Networking Media

I touched on this throughout the article a bit but wanted to have a section for this as well. Network nodes communicate in terms of network media. Physical media refers to the more common Ethernet cables, optical fiber, and coaxial cables. Wireless technologies include infrared and radio waves, which introduces Bluetooth options, as well as satellite connections and the wireless capabilities of cellular devices.

Conclusion

This article covers only the basics of what networking is, different network implementations, as well as network devices and media. If you’re a more technical person, what this post covers can translate into a few layers of the OSI model – mainly layers one (Bluetooth & NICs) and two (switches & APs), but a tad into three when covering routing between networks (routers). By no means is this a super technical break down of the layers, though potentially one day in a future post I will go there.

by Rik Farrow, updates by Corey Nachreiner

[Editor's note: If the difference between a bit and a byte stumps you, or if the term "IP addressing" seems foggy to you, you'll understand and enjoy this article much more if you first read "Understanding IP Addresses and Binary."]

Sure, you've heard of subnets. But if a crazed IT veteran glared at you and demanded, "Explain subnetting right now, or I'll have you fired for incompetence!," could you tell him much more than the vague idea that subnets have to do with TCP/IP networks? This Security Fundamentals article explains what IPv4 subnets are, what a subnet mask is, and how you might use them within your own network. In brief, subnets have to do with routing, but it'll take some explaining getting to that point -- enough that this will be a two-part article. (So try to avoid crazed IT veterans until you've read both parts.) By the way, subnets apply (in much the same way) to the more modern IPv6 protocol as well, but these articles will focus on IPv4 since that’s what most administrators still use.

Long ago, in a project far away...

Once upon a time, the entire Internet was very small. It was so small, in fact, that the entire Internet (then called the ARPANET) could use one byte, with a maximum value of 255, for addressing every connected computer. During this time, a group of graduate students working on a project at Stanford began writing a replacement for NCP, the early ARPANET protocol. They called their protocol TCP/IP, and allowed what they considered a generous size for addresses, four bytes.

What's more, they formatted the addresses so that the beginning of each address indicated which of three "classes" an address belonged to. The students had the notion that the Internet would be composed of a few very large networks (which they dubbed Class A), a larger number of medium sized networks (Class B), and many small networks (Class C). In the students' scheme, there were 126 Class A network addresses, 64,000 Class B network addresses, and almost 2 million Class C network addresses.

This construct didn't work out too well, because a Class C network could only contain 254 individual device addresses—a number restrictive enough that any medium-sized organization wanted a Class B all for its very own. By the early '90s, just as the Internet was becoming commercialized, the American Registry for Internet Numbers (ARIN) was running out of Class B network addresses.

Addressing the issues

(when addressing is the issue)

In the students' scheme, some of the four bytes of an IP address identified a network. The remainder of the address identified a particular machine, or host, on that network. In other words, any IP address is composed of one part network address and one part host address. In that sense, you could compare IP addresses to phone numbers. For example, if you wanted to call the US White House from Japan, you would dial 001 1 202 456 1414. The 001 1 represents the code to call from Japan to the US, 202 the area code, and 456 1414 the specific phone number. 001 1 202 corresponds to a network address, and 456 1414 to a host address.

But how much of a 32-bit IP address is the network address, and how much is the host address? The answer is a hearty "it depends." The student's addressing scheme split IP addresses into network and host addresses on byte boundaries. For example, a Class A address used the first byte to identify the network, and the remaining three bytes to identify individual hosts. Thus, in the address 126.10.11.12, the first byte (126.) is the network, and 10.11.12 is a host on the 126 network. Class B IP addresses, like 128.16.7.4, use the first two bytes (128.16) as the network address, and the last two bytes (.7.4) as the host address. In a Class C address, like 204.176.22.1, the network portion of the address takes up three bytes (204.176.22), leaving only a single byte for the host portion (.1).

Note that using a Class A address, you could address a mammoth number of hosts. Remember from the "Understanding IP Addresses and Binary" article that one byte can represent any value from 0 to 255? That means if you have three bytes available for identifying hosts, you could assign hosts IP addresses of 0.0.1, 0.0.2, 0.0.3, and so on, up to 255 (at least in theory; in practice, 255 is reserved for a special purpose). Then you could start over using 0.1.1, 0.1.2, et cetera. Working through all the possible combinations, the total amount of unique host IDs available in a Class A address is roughly 255 x 255 x 255 -- well over 16,000,000 available addresses! Following the same logic, a Class B network has two bytes left for host addresses, and two bytes allow us to address more than 65,000 hosts (255 x 255). And now you probably can grasp why a Class C address, using only one byte for addressing individual hosts, can only handle 254 devices. Why not 255 devices? I'll explain that in Part 2 of this article.

Given a generic IP address nnn.nnn.nnn.nnn (where "n" equals a number):

Now that you understand the history of IP address classes and how they're divided on byte boundaries, you're ready to grasp slash notation, a shorthand way of expressing network information. A Class A network address uses one byte, or eight bits, for the network address portion. To indicate this explicitly, administrators write /8, appended to the end of an IP address. When you see 126.10.11.12/8, you know it's a Class A address. A Class B uses two bytes, or 16 bits, written as /16. Class C appears as /24 (three eight-bit bytes). The important concept here is that in slash notation, the number after the slash tells you how many bits of an IP address is the network portion of the address. (You can readily calculate how many bits that leaves for the host portion of the address by subtracting the number of network bits from 32, the total number of bits in an IP address.)

How the Internet lost its class

When I left off my history of the Internet a few paragraphs ago, we had just seen that ARIN was running out of Class B network addresses. The Internet Engineering Task Force (IETF) eventually came up with a workaround. Instead of the original, rigid, network class splits on full-byte boundaries (/8, /16, and /24), they allowed Classless Internet Domain Routing (CIDR, pronounced like 'cider'). This birthed the modern way of talking about IP addresses, which ignores classes, and uses network notation instead. So if an organization wanted enough IP address space for one thousand systems, ARIN's choices were no longer limited to dispensing either four Class Cs (/24) or a Class B (/16) network. They could assign, for example, a /22. Twenty-two bits of the IP address would be used as the network address, and the remaining 10 bits would be used for host addresses, which would permit 1,024 addresses.

Another problem with IP addressing had surfaced in the mid-eighties. Some organizations wanted multiple network addresses, one for each network within their organization. Instead of giving out multiple network addresses, RFC 950 recommends the use of subnetworking, that is, using some portion of the IP address to indicate internal network addresses.

The problem with both using a CIDR (classless) network address, and splitting a network into subnetworks (abbreviated as subnets), was that TCP/IP was designed with the rigid Class system in mind. Certain addresses were assumed to have one, two or three bytes of network address. Specifically:

CIDR throws those assumptions away. In fact, this entire discussion of "classful" IP addresses is only necessary because of its long legacy on the Internet (and to help you understand Internet veterans who often use the old terminology). The problem was, in order to split IP addresses on any bit you wanted, there had to be some way of defining where that split in the IP address occurred. The answer for how to define subnets: use a subnet mask. It's a very important networking concept, and it's where we'll resume our discussion in "Understanding IPv4 Subnetting, Part 2".