Study IPv4, IPv6, CIDR & Subnetting for Network+ (N10-009)
Use public and private ranges, special addresses, CIDR, VLSM, and IPv6 addressing logic in design and support questions.
Subnetting is one of the highest-leverage Network+ topics because it shows up in design, routing, DHCP scope planning, and troubleshooting. CompTIA is not just checking whether you can recite a prefix length. It is checking whether you can read an address plan, recognize which hosts belong together, and spot when the mask, range, or gateway assumption is what is breaking the network.
APIPA: Automatic Private IP Addressing in the
169.254.0.0/16range when a host cannot reach DHCP.VLSM: Variable-length subnet masking, using different prefix lengths inside the same larger address space so the design fits the host counts more efficiently.
What CompTIA is really testing
The real exam move is usually one of these:
- identify whether the host is on the correct network at all
- choose a prefix that fits the required host count without wasting space badly
- recognize what the default gateway should be for the subnet
- tell whether the problem is addressing, naming, or routing
The address decisions that matter most
| Question type | What to decide first |
|---|---|
| host cannot reach anything | valid IP, valid mask, valid gateway |
| host reaches local devices but not remote ones | likely gateway or routing, not DNS |
| two devices should talk directly | same subnet or routed path required |
| design asks for efficient address use | host count first, then prefix |
| IPv6 question mentions router advertisements | SLAAC and prefix behavior matter |
Fast IPv4 range lens
| Range type | Examples | Why it matters |
|---|---|---|
| private | 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 |
internal addressing that normally needs routing or NAT at the edge |
| loopback | 127.0.0.0/8 |
host self-test, not real network reachability |
| link-local / APIPA | 169.254.0.0/16 |
often signals DHCP failure on IPv4 |
| public | everything not reserved/private | routable on the internet when allowed and advertised |
A practical subnetting workflow
- Start with the number of usable hosts needed.
- Add room for the network and broadcast boundaries on IPv4.
- Pick the smallest prefix that still fits the host count.
- Verify the network address, usable range, and broadcast address.
- Choose the default gateway from the usable range.
Worked example:
1Need: about 50 hosts
2/27 gives 32 total addresses -> too small
3/26 gives 64 total addresses -> 62 usable hosts
4
5Example subnet: 192.168.10.64/26
6Network: 192.168.10.64
7Usable: 192.168.10.65 - 192.168.10.126
8Broadcast: 192.168.10.127
9Gateway: choose one usable address, for example 192.168.10.65
What to notice:
- host count decides the prefix, not the other way around
- the gateway must sit inside the usable range
- many Network+ wrong answers hide an impossible gateway or host address inside an otherwise plausible subnet
IPv6 without overcomplicating it
Network+ does not expect deep IPv6 theory. It expects operational clarity:
- know that IPv6 addresses are larger and written in hexadecimal
- know that SLAAC uses router advertisements to help clients build addresses
- know that link-local addresses are normal on IPv6
- know that a host can have multiple IPv6 addresses for different purposes
- know that prefix length still defines the network boundary
Common traps
- treating APIPA as normal internet connectivity
- forgetting that a bad gateway can break off-subnet access even when the local IP looks fine
- mixing up total addresses with usable IPv4 host addresses
- assuming DNS is the issue before proving the subnet and gateway are correct
- treating IPv6 as unrelated to the same boundary logic
What strong answers usually do
- calculate the network boundary before reading too much into the symptom
- rule out impossible masks, host addresses, and gateways quickly
- keep local-reachability problems separate from routing or naming problems
- use prefix length as a design tool, not as a memorization stunt
Quiz
Continue with 2. Network Implementation if your subnetting logic is solid, or revisit 1.4 Ports, Protocols, Services & Application Flows if address and service behavior are still blurring together.