Understanding IPv4 and IPv6 Subnetting: Prefixes and Network Boundaries Explained

As soon as you set up a network, you quickly hit the same hurdle: workstations, servers, and guests should not broadcast into each other unhindered, but get their own dedicated segments. The moment you have to tell your router or DHCP server where these networks begin and end, you run into notations like /24 or /64.

An IP address is not just a house number. It always accomplishes two tasks at once: the leading portion specifies the network, and the trailing portion identifies the specific interface within it. The prefix draws exactly that dividing line. If you set that boundary wrong, address pools overlap or systems look for their destination on the wrong side of the gateway.

The underlying principle works identically for IPv4 and IPv6, yet daily practice differs fundamentally: with IPv4, you carve up scarce address blocks with precision and calculate how many interfaces can fit in the first place. With IPv6, you do not count host addresses at all; you take an assigned prefix and slice it directly into multiple /64 subnets.

Why Divide Networks into Subnets?

If you plug a dozen workstations, two printers, and a server into the same switch, it usually works right away. Assign sequential IP addresses, and every machine can reach every other machine. That feels convenient, but as the device count grows, the network quickly turns into an unmanageable clutter.

The primary reason for subnets lies in how the operating system decides on a packet's path. When a host wants to transmit data, the kernel compares the destination IP against its own address and configured subnet mask. How the TCP/IP protocol family structures data and routes it across interfaces forms the bedrock here. If the destination sits in the same subnet, the kernel ignores the default gateway entirely. It queries the local network directly via ARP for the destination's MAC address and dispatches the frame straight across the switch. In IPv6, this behaves similarly, though the operating system uses the Neighbor Discovery Protocol under RFC 4861 instead of ARP.

What this means in practice:

As long as workstations, guests, and internal servers reside in the same subnet, your firewall does not see a single bit of that traffic. The systems communicate directly on OSI layer 2. If you want to govern access, restrict specific services, or log connections, you have to place the devices into separate subnets. Only when the kernel realizes that the destination IP lies outside its local network does it forward the packet to the gateway — and only there do your firewall rules have any leverage.

On top of that comes constant broadcast noise.

In an unsegmented IPv4 network, every ARP request ("Who has IP 192.0.2.50?"), every DHCP request, and every automatic service discovery query is broadcast to absolutely every port. Every single network interface card has to ingest the frame and the kernel has to process it, only to determine that the query was meant for another machine entirely. With thirty devices this barely registers; with hundreds, this background chatter generates noticeable load across interfaces.

💡 A classic misconception: A subnet is purely a logical convention on layer 3, not a security barrier. If you assign 192.0.2.128/25 to the guest network and 192.0.2.0/25 to internal servers, but run both unsegmented on the same standard switch, nothing is technically protected.

Any participant with administrative privileges on their machine can manually assign themselves a second IP from the server range or capture network traffic. Subnetting only defines logical boundaries for routing — real isolation underneath requires dedicated physical interfaces or properly configured VLANs.

Subnets therefore create the logical structure that routers and packet filters build upon. They prevent systems from broadcasting unchecked across the entire segment, but they do not replace network isolation on their own.

IP Address and Prefix: Where Does the Network End?

When you look at an IP address — whether 192.0.2.45 in IPv4 or 2001:db8::45 in IPv6 —, it looks like a single, continuous string of numbers. To your operating system, however, it is anything but.

The kernel always mentally splits every address into two halves:

• The network portion: The leading bits. They determine which logical subnet the host belongs to. Every interface in the same subnet shares the exact same starting bits.
• The host portion: The remaining bits at the end. They form the unique identifier of the specific interface within that exact network.

From the bare address 192.0.2.45, however, you cannot tell where this cut occurs. Without additional information, it is simply incomplete. Only the prefix or subnet mask instructs the system how many bits counted from the left define the network, and at which bit individual hosts are addressed.

Slashes instead of number strings:

CIDR Notation

In everyday administration, you encounter the slash notation almost everywhere: CIDR notation (RFC 4632){.badge-link-text}. It saves keystrokes and states directly how many bits are reserved for the network.

An IPv4 address is exactly 32 bits long, divided into four blocks (octets) of 8 bits each:

┌───────────────────────────────────────────────────────────────┐
│  IPv4 Address Structure: 192.0.2.45/24 (CIDR / 32 Bit)        │
├─────────────────────────────────────────────┬─────────────────┤
│  Network Portion: 192.0.2                   │  Host: 45       │
│  24 Bits (3 Octets)                         │  8 Bits (Host)  │
└─────────────────────────────────────────────┴─────────────────┘

The notation /24 is an unambiguous instruction to the kernel: The first 24 bits — meaning exactly the first three numbers 192.0.2 — belong to the network. Every system whose address begins with these three numbers sits in the same segment. For your interfaces, the remaining 8 bits are left over: the values from 0 to 255 in the fourth block.

Why you still run into 255.255.255.0

In many web interfaces of routers or older configuration files, you still stumble upon 255.255.255.0 instead of /24. That is not a different mechanism; it is the exact same information in a more cumbersome format.

The subnet mask is a 32-bit filter filled with ones from left to right. Where a 1 sits, the bit belongs to the network; where a 0 sits, you are allowed to address host interfaces:

┌───────────────────────────────────────────────────────────────┐
│  Subnet Mask /24 in Binary and Decimal Comparison             │
├────────────────┬───────────────┬───────────────┬──────────────┤
│  Octet 1       │  Octet 2      │  Octet 3      │  Octet 4     │
├────────────────┼───────────────┼───────────────┼──────────────┤
│  11111111      │  11111111     │  11111111     │  00000000    │
│  255           │  255          │  255          │  0           │
└────────────────┴───────────────┴───────────────┴──────────────┘

A single octet consists of 8 bits. If you turn on all 8 bits (all ones), binary math sums them up to the maximum possible value: 255 (128 + 64 + 32 + 16 + 8 + 4 + 2 + 1). The mask 255.255.255.0 tells the operating system three times in a row: these 8 bits are fully allocated to the network — making 24 bits in total.

/24 and 255.255.255.0 mean the exact same thing. As long as the network boundary sits cleanly on a boundary between octets, you can read it with the naked eye. Things only get interesting when the dividing line cuts right through an 8-bit block.

IPv6: Same principle, cleaner edges

With IPv6, the baggage of written-out masks was eliminated entirely.

Here, only prefix notation exists.

An IPv6 address is 128 bits long (RFC 4291){.badge-link-text}. If it specifies a /64, that means: the first half (64 bits) represents the subnet, and the trailing 64 bits form the Interface Identifier for the interface. Because four hexadecimal digits always represent a 16-bit block, a /64 falls neatly behind the fourth block. You never have to calculate inside a hex digit; you have a clean, readable boundary.

IPv4 Subnetting Step by Step

So far, the boundary rested comfortably behind the third number. A /24 network offers 256 addresses — from 0 to 255. If you now divide this network, you simply take a knife and slice that block into smaller portions.

Take the official documentation network 192.0.2.0/24 (RFC 5737){.badge-link-text} as our practical example. In production corporate networks, you typically carve internal segments out of public vs. private IP addresses under RFC 1918 (such as 10.0.0.0/8 or 192.168.0.0/16). In our example, we leave the first three blocks (192.0.2.) completely untouched.

Everything that happens now takes place solely within the final octet.

Halving the Network: From /24 to /25

If you want to turn one network into two distinct segments, you slide the dividing line one bit to the right: /24 becomes /25.

A single bit has exactly two states: 0 or 1.

This cuts the previous space in half:

• Before (/24): 256 addresses in a single pool.
• Now (/25): Two separate pools with 128 addresses each.

Because the first bit in the final octet carries a value of 128, the range splits precisely at that mark: the first block runs from 0 to 127, and the second from 128 to 255. In old mask notation, 255.255.255.0 now becomes 255.255.255.128.

💡 Core rule: In an IPv4 subnet, you can never assign all available addresses to host machines. The very first and the very last address of any block are strictly reserved by the protocol.

Two addresses are always reserved:

• The network address (the first number): It identifies the subnet itself.
• The broadcast address (the last number): If you send a packet to this address, it is broadcast to every single device in the subnet (RFC 919){.badge-link-text}.

If you attempt to assign .0 or .127 as a static IP on a Linux host, the kernel either complains immediately or you run into unpredictable routing later. In practice, you partition the usable address range cleanly: gateways and servers receive static IPs, while clients are served dynamically via DHCP — how to plan this is detailed in our guide on dynamic vs. static IP addresses. Simply subtract 2 from the block size in your head, and you have your usable interfaces.

Further Division: Turning /24 into Four /26 Subnets

If you need more than two separate segments — say for your office, servers, guests, and management —, you halve the blocks once more. You borrow a second bit: /25 becomes /26.

• One more bit doubles the number of subnets: from 2 networks to 4.
• At the same time, the size of each block halves: from 128 addresses down to 64 addresses per network.

The block size is now 64.

You no longer have to convert anything to binary; you simply count upwards in increments of 64: 0, 64, 128, 192. Those are your four network addresses.

Let's look at the second quarter (192.0.2.64/26) in detail:

• The network address is 192.0.2.64.
• The broadcast address is the last number before the next block: 192.0.2.127.
• In between lie your usable hosts: 192.0.2.65 through 192.0.2.126 — exactly 62 addresses (64 − 2).

The Mental Quick-Check

When you spot the configuration 192.0.2.135/26 on a server in your daily work, you immediately know where it belongs:

The step size here is 64. The blocks start at 0, 64, 128, and 192. The number 135 sits cleanly in the third block between 128 and 191.

If you see 192.0.2.70/26 on another machine, it belongs to the preceding block (64 to 127). Without a router in between, the two will not exchange a single packet, even if they sit in the same room plugged into the same patch panel.

IPv6 Subnetting: Counting Prefixes Instead of Host Addresses

With IPv6, forget everything you painstakingly memorized about host ranges under IPv4. In IPv4, you scrimp on every single bit, subtract two for network and broadcast, and ponder whether 62 addresses are enough for a segment.

In IPv6, the world works completely differently:

You do not count individual interfaces — you count entire networks.

The standard for any regular subnet, whether LAN, Wi-Fi, or a server segment, is a /64 subnet. In normal operation, this is never altered. A single /64 subnet contains an astounding 2⁶⁴ (over 18 quintillion) addresses in a single segment. You might think this sounds like colossal waste. Yet it serves a direct practical purpose: autoconfiguration mechanisms such as SLAAC (Stateless Address Autoconfiguration, RFC 4862){.badge-link-text} require exactly those 64 bits for the host portion (the Interface ID). If you carve a subnet smaller than /64, automatic address assignment for end devices breaks down entirely.

Your job as an administrator in IPv6 is not to tailor a subnet to fit twenty machines. Your job is to take a larger block allocated by your provider or enterprise network team and chop it into multiple /64 slices.

A Typical Scenario

Building your network from a /56

What block size you receive is up to the provider: some business uplinks receive a generous /48, many standard connections are provisioned with a /56, and residential plans occasionally skimp with a single /64.

Assume as a practical example that your router is assigned a /56 prefix from the official documentation allocation (RFC 3849){.badge-link-text}: 2001:db8:1:1000::/56

An IPv6 address consists of eight blocks of 16 bits each, separated by colons. Every single character is a hexadecimal digit (0 to 9 and a to f) and represents exactly 4 bits:

• The first three blocks (2001:db8:1:) are completely occupied: 3 × 16 = 48 bits.
• Up to the /56 boundary, exactly 8 bits remain (56 − 48 = 8). That corresponds precisely to the first two hex digits in the fourth block.

If we inspect the fourth block in uncompressed notation with its four hex digits, the boundary is immediately obvious:

┌───────────────────────────────────────────────────────────────┐
│  IPv6 Prefix Allocation: 2001:0db8:0001:10xx::/56             │
├──────────────────────────────────┬────────────┬───────────────┤
│  2001:0db8:0001:                 │  10        │  xx::/64      │
│  48 Bit Provider Prefix          │  8 Bit     │  8 Bit Custom │
│  (Permanently Assigned)          │  Provider  │  Subnets      │
└──────────────────────────────────┴────────────┴───────────────┘

Up to the /56, the range is fixed by your provider — you cannot change it. But between your allocation (/56) and the standard subnet size (/64) lie exactly 8 free bits:

64 − 56 = 8 Bit

With these 8 bits, you can represent 2⁸ = 256 distinct values. From this single uplink, you construct exactly 256 independent /64 subnets without calculating in binary.

Incrementing the Hex Digits

Because 8 bits correspond to exactly two hex characters, you simply step the two trailing characters in the fourth block from 00 to ff (decimal 0 to 255):

Each of these 256 networks is a fully self-contained segment. You assign the firewall's VLAN interface for the guest network 2001:db8:1:1003::1/64, for instance. The router advertises the prefix 2001:db8:1:1003::/64 via Router Advertisements into the guest VLAN, and client devices generate their own interface addresses automatically.

When writing IPv6 addresses, leading zeros within a 16-bit block may be omitted (turning :0001: into :1:). In our example, the fourth block contains 1001 — the leading one remains in place, keeping the visual structure of your subnets clean and instantly recognizable.

No Broadcast Address, No Headaches

A tangible operational advantage:

In IPv6, there is no broadcast address. Nobody has to remember which address is the last in the range to avoid assigning it to a host. Network-wide broadcasts no longer exist; when systems need to reach all neighbors, they use targeted multicast groups (RFC 4291){.badge-link-text}.

The very first address of a subnet (all zeros in the interface portion, such as 2001:db8:1:1001::0) is formally reserved as Subnet-Router Anycast, but in production you do not have to deliberate over it. You pragmatically assign ::1 to your gateway, give static servers clean endings like ::10 or ::53, and leave the rest of the addressing to autoconfiguration.

Rule of Thumb: One More Bit, Twice as Many Networks

If you want to remember a single rule of thumb permanently for subnetting, make it this: If you move the boundary one bit to the right, the number of networks doubles — and every single network becomes exactly half the size.

This is not a coincidence, but the fundamental logic of the binary system. An additional bit has exactly two states (0 or 1). As soon as you borrow that bit, it cuts every existing block in half.

The Rule Applied to Our Examples

Notice how what we calculated in previous sections follows the exact same mechanics across both protocols:

• IPv4: You start with a /24 (256 addresses).
• Turning it into a /25 (+1 bit) doubles your networks from 1 to 2. The block size halves from 256 to 128.
• Moving to a /26 (+2 bits compared to /24) doubles it again: 4 networks with 64 addresses each.

• IPv6: Your router receives a /56.
• A target subnet uses /64. The distance is 64 − 56 = 8 bits.
• Shifting the boundary by 8 bits doubles the space eight times in succession: 2 × 2 × 2 × 2 × 2 × 2 × 2 × 2 = 256 subnets.

The Most Common Pitfall: Higher Number Equals Larger Network?

Beginners regularly fall for an optical illusion here:

They see a /28 and instinctively assume it must be 'larger' or 'more' than a /24.

The number behind the slash counts the bits reserved for the network — not the room left for your hosts. A larger number means: the network claims more bits for itself, leaving less space for interfaces. A /28 is not a large network; it is a tiny quarter of a /26, offering just 16 total addresses (14 usable hosts).

💡 Picture the slash as a barrier across a 32- or 128-lane highway: the further the barrier shifts to the right (higher number), the narrower the remaining corridor left for your host devices.

Test Yourself: Two Typical Real-World Traps

On paper, subnetting often looks straightforward. It only gets exciting when you sit at the shell or web interface and have to key in an IP. Here are two classic real-world scenarios to test your grasp of network boundaries immediately.

Case 1: The New Server in an IPv4 Segment

Imagine you need to connect a new backup server to an existing server VLAN. In the predecessor's documentation, the entry for this segment simply reads: 198.51.100.128/27

Because you prefer memorable numbers, you want to give the new server the round IP 198.51.100.160. At first glance, that looks like a free, innocuous address.

Before writing the IP into your network configuration:

• Does this work in this subnet?
• And where do the boundaries lie?

The resolution at the prompt:

When you see the /27, you run the same mental calculation as before:

1. Determine the step size: Up to a full /24, exactly 3 bits are missing (27 − 24 = 3). Counting down bit weights in the octet (128 → 64 → 32), you land on a step size of 32. That means: all subnets in this range span exactly 32 addresses.
2. Mark the boundaries: The subnet starts at .128 per documentation. Adding 32, the next subnet starts at 198.51.100.160 (128 + 32).
3. The usable range:

• The very first address (.128) is the network address.
• The last number before the next block (.159) is the broadcast address.
• Your usable server IPs span from 198.51.100.129 through 198.51.100.158 — exactly 30 addresses (32 − 2).

Why .160 would cause a crash landing:

The .160 does not belong in this subnet at all. It is the official network address of the subsequent /27 block. If you configure 198.51.100.160/27 on the server, its kernel assumes it is sitting in an entirely different network. When it attempts to reach the server segment's default gateway (which typically sits on .129) directly via ARP, the network stack refuses: from its perspective, the gateway sits in a remote subnet, and without an intermediate router handling traffic, not a single packet leaves the host.

Case 2: The Branch Office Uplink with a /60 Prefix

A colleague is setting up a branch office. The local ISP does not provide a generous /56, but a tighter /60 prefix from the documentation range: 2001:db8:beef:00a0::/60

Your task is to establish four segregated zones for the location:

• Management
• Workstations
• Guest Wi-Fi
• Security Cameras

The question is: Does the allocated /60 suffice to build four full /64 subnets? And what are the concrete prefixes for each zone?

The resolution without math gymnastics:

In IPv6, immediately discard any thought of counting host addresses and focus exclusively on the distance to /64:

1. The available bits: Assigned is a /60; your target subnets require a /64 for proper routing and SLAAC. The difference is exactly:

64 − 60 = 4 Bit

1. Number of available subnets: Each extra bit doubles the space. For 4 bits, that means: 2⁴ = 16. You can effortlessly carve 16 independent /64 subnets out of this uplink. Four zones are easily covered.
2. Forming the prefixes: 4 bits correspond to exactly one hexadecimal character (2⁴ = 16, from 0 to f). In the fourth block (00a0), the final character is your subnet index.

Writing out the zones cleanly (omitting leading zeros as usual, 00a0 becomes a0):

• Management: 2001:db8:beef:a0::/64 (index 0)
• Workstations: 2001:db8:beef:a1::/64 (index 1)
• Guest Wi-Fi: 2001:db8:beef:a2::/64 (index 2)
• Cameras: 2001:db8:beef:a3::/64 (index 3)

Up to 2001:db8:beef:af::/64, you have headroom for twelve additional networks. You see: as soon as you think in hex digits, IPv6 requires neither powers of two nor mask arithmetic — you simply increment the final digit.

Command Reference (Cheatsheet)

When you sit before a Linux machine and want to know which network the host actually landed in, colorful web UIs will not help you. On the console, you see directly what the kernel configured and where its routing boundaries lie.

The old net-tools (ifconfig, route) have been retired for years. On modern Linux, iproute2 handles everything exclusively. Here are the core commands you actually need to diagnose subnets and interfaces:

Quick Inspection: What Does the Kernel See?

🔧 Verify Interface Details

If you want to confirm whether the netmask on interface eth0 is correct, query that device specifically:

ip address show dev eth0

A typical, clean output looks like this:

eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    inet 198.51.100.130/27 brd 198.51.100.159 scope global dynamic eth0
       valid_lft 86340sec preferred_lft 86340sec
    inet6 2001:db8:beef:a1::10/64 scope global dynamic mngtmpaddr 
       valid_lft 86340sec preferred_lft 14340sec
    inet6 fe80::5054:ff:fe12:3456/64 scope link 
       valid_lft forever preferred_lft forever

Here you see clearly how the components fit together:

• For IPv4, the kernel automatically derived the matching broadcast address 198.51.100.159 (brd) from /27.
• For IPv6, you see your global address with /64 — without a broadcast entry, because broadcast does not exist in IPv6.

🔧 Verify Routes: Does the Packet Stay Local or Hit the Gateway?

If you are unsure which path the kernel chooses for a specific IP, you do not have to guess or manually parse routing tables. Ask the stack directly:

ip route get 198.51.100.140

If the destination IP sits in the same subnet, Linux responds with a direct connection over the interface:

198.51.100.140 dev eth0 src 198.51.100.130 uid 1000 
    cache

If you query an address that lies outside your /27 (such as 198.51.100.170 in the adjacent subnet), the output changes immediately:

ip route get 198.51.100.170

198.51.100.170 via 198.51.100.129 dev eth0 src 198.51.100.130 uid 1000 
    cache

The kernel states unambiguously: "Not known locally, routes via 198.51.100.129 to the gateway." In practice, you cannot verify network boundaries faster or more reliably than this. If packets are dropped despite a correct mask or routes get stuck, our guide on how to systematically analyze network problems on Linux walks you through the entire diagnosis from link status to packet traces.

Further Resources

When you need certainty on network boundaries, address standards, or protocol details, do not rely on forum rumors or outdated blog posts. In networking operations, IETF standards — Requests for Comments (RFCs) — remain the ultimate source of truth.

Here are the foundational primary specifications that govern how subnetting, documentation address pools, and prefix mechanics operate under the hood: