3.1 Public, Private, and Local Addressing

Public, private, and local address roles

The Cisco Certified Support Technician (CCST) Networking exam (number 100-150) lists comparing private and public addresses as a core objective because most first-line tickets begin with address context. A public IP address is globally unique and routable across the internet. Any device that must accept inbound traffic from internet clients — a web server, VPN gateway, cloud load balancer, or a home router's outside interface — needs a public address. Public space is coordinated by Regional Internet Registries (ARIN, RIPE, APNIC, and others) so two organizations do not advertise the same globally routed address.

A private IPv4 address is reserved for internal use by RFC 1918 and is never routed across the public internet. Memorize the three blocks exactly — the exam tests them directly:

Notice the /12 boundary: 172.16.x.x through 172.31.x.x are private, but 172.15.x.x and 172.32.x.x are public. A device with a private address can talk inside networks where routes exist, but an internet router silently drops packets aimed directly at a private destination.

NAT, special addresses, and the IPv6 parallels

Because private addresses cannot cross the internet, NAT (Network Address Translation) — usually PAT (Port Address Translation), also called NAT overload — runs at the network edge. A laptop using 192.168.1.25 appears to websites as the public address on the router or ISP edge; PAT lets hundreds of inside hosts share one public IPv4 address by tracking Layer 4 port numbers. The exam-relevant effect: private clients can start outbound sessions freely, but unsolicited inbound access requires a deliberate rule — port forwarding, static NAT, a VPN tunnel, or a published service.

Several ranges are special-purpose and should never be treated as ordinary host addresses:

• 127.0.0.1 (127.0.0.0/8) — IPv4 loopback; a host talking to itself.
• 169.254.0.0/16 — IPv4 link-local / APIPA (Automatic Private IP Addressing), auto-assigned when DHCP fails.
• 0.0.0.0 — "this host / unspecified," not a valid host address.
• 255.255.255.255 — limited broadcast.

If a Windows or macOS client shows 169.254.x.x when it should be on 192.168.1.x or 10.x.x.x, investigate the DHCP server, cabling, Wi-Fi association, or VLAN assignment — never accept it as a corporate address just because it has four decimal octets.

IPv6 mirrors all of this with different ranges. Global unicast addresses (publicly routable) live in 2000::/3 and commonly begin with 2 or 3. Unique local addresses (ULA) sit in fc00::/7, with fd00::/8 used in practice — the private-network equivalent. Link-local IPv6 addresses begin fe80::/10 and exist on every IPv6-enabled interface for neighbor discovery and router discovery, analogous to APIPA but always present.

IP versus MAC at the edge

A technician must also separate the IP address (Layer 3, logical, routable) from the MAC (Media Access Control) address (Layer 2, a 48-bit hardware address such as 00:1A:2B:3C:4D:5E). On the same LAN a host uses ARP (Address Resolution Protocol) for IPv4 or Neighbor Discovery for IPv6 to learn the destination MAC. For a remote destination, the frame is sent to the default gateway's MAC while the IP packet still carries the remote IP. This is why swapping a NIC changes local switching but not the server's IP, and why a wrong gateway breaks remote access even when the cable and MAC are perfectly fine.

Common trap: candidates pick 8.8.8.8 (Google public DNS) or 203.0.113.x (a documentation/public range) as "private." Anchor on the three RFC 1918 blocks and the /12 boundary above.

Why this matters on the job and in the exam

Think about the order of reasoning a help-desk technician follows when a user says "I can't get online." The very first question is whether the client even holds a usable address. A 169.254.x.x value means the machine never reached a DHCP server, so chasing browser settings or DNS is wasted effort — the right move is to check the physical link, the switch port, the VLAN, and the DHCP scope. A 192.168.x.x or 10.x.x.x value means addressing succeeded and the fault is more likely the gateway, NAT, or an upstream service.

The public-versus-private distinction also explains a recurring user complaint: "I set up my web server but nobody outside can reach it." If that server sits on 192.168.1.50, the internet cannot route to it at all. The fix is not on the server — it is a deliberate inbound rule on the edge device: a port-forward, a static NAT mapping, or publishing the service behind a public address. Outbound browsing works because PAT builds a translation entry when the client initiates the session; inbound has no such entry until an administrator creates one.

A final reasoning aid is to keep the IPv4 and IPv6 role tables side by side. Whenever you see an address, classify it first by role before doing anything else: is it routable on the internet (public / global unicast), reserved for inside use (RFC 1918 / unique local), local-only (link-local / APIPA), or a special function (loopback, broadcast, unspecified)? That single classification step routes you to the correct branch of troubleshooting and is exactly the discriminating skill 100-150 tests when it shows you an address and asks what it is.