Private vs Public IPv4 Addresses – RFC 1918, NAT & Special Ranges

1. The Two Categories of IPv4 Addresses

Every IPv4 address in use today falls into one of two fundamental categories: public (globally routable on the internet) or private (reserved for internal networks, not routable on the internet). Understanding this distinction is one of the most foundational concepts in networking — it explains how billions of devices access the internet using only a few hundred million public IP addresses.

  IPv4 address space (4.3 billion total):

  ┌─────────────────────────────────────────────────────────────────┐
  │  PUBLIC IP ADDRESSES (majority of space)                        │
  │  Globally unique — routable across the entire internet          │
  │  Must be registered and assigned by IANA → RIR → ISP → user    │
  │  Example: 203.0.113.1, 8.8.8.8, 142.250.190.46                 │
  ├─────────────────────────────────────────────────────────────────┤
  │  PRIVATE IP ADDRESSES — RFC 1918 (~17.9 million addresses)      │
  │  Not routable on internet — reusable by any organisation        │
  │  10.0.0.0/8 + 172.16.0.0/12 + 192.168.0.0/16                  │
  ├─────────────────────────────────────────────────────────────────┤
  │  SPECIAL PURPOSE (loopback, APIPA, multicast, TEST-NET, etc.)   │
  └─────────────────────────────────────────────────────────────────┘

  The bridge between private and public: NAT/PAT at the internet edge
  Private devices ──[NAT router]── Public internet

2. Public IP Addresses

A public IP address is an IPv4 address that is globally unique and routable across the public internet. Any device on the internet can send a packet to a public IP and it will be routed to its destination — subject to firewall and ACL policies at the destination.

Global uniqueness: No two devices on the internet can share the same public IP at the same time
Fully routable: Internet routers know how to forward packets to any public IP address via BGP routing tables
Registered ownership: Every public IP block is registered to a specific organisation — lookups via WHOIS and ARIN/RIPE/APNIC databases show who owns each block
Finite supply: IPv4 has only ~4.3 billion total addresses; public address exhaustion occurred regionally between 2011–2019

Examples of well-known public IPs:
8.8.8.8 — Google Public DNS
1.1.1.1 — Cloudflare DNS
203.0.113.x — TEST-NET-3 (documentation only — not actually public)
142.250.190.46 — Google web servers

3. Private IP Address Ranges — RFC 1918

RFC 1918 (published 1996) defines three address blocks reserved for private networks. These addresses are free for any organisation to use internally — no registration required. Internet routers are configured to drop packets with RFC 1918 source or destination addresses, preventing them from being routed on the public internet.

RFC 1918 Block	Address Range	Subnet Mask	CIDR	Host Count	Typical Use
Class A private	10.0.0.0 – 10.255.255.255	255.0.0.0	/8	16,777,214 hosts	Large enterprises, data centres, cloud VPCs — enormous space allows complex subnetting plans
Class B private	172.16.0.0 – 172.31.255.255	255.240.0.0	/12	1,048,574 hosts	Medium enterprises, Docker default bridge networks (172.17.0.0/16), VPN address pools
Class C private	192.168.0.0 – 192.168.255.255	255.255.0.0	/16	65,534 hosts	Home networks, small offices — most home routers default to 192.168.0.x or 192.168.1.x

Why these ranges can be reused: Because RFC 1918 addresses never appear on the public internet, the same 192.168.1.0/24 subnet can exist independently in millions of homes and offices simultaneously — they are completely isolated from each other. A packet to 192.168.1.1 on your home network goes to your router, not to anyone else's 192.168.1.1 next door.

4. Special-Purpose IPv4 Addresses

Beyond the three RFC 1918 private ranges, IANA has reserved several other address blocks for specific purposes. These appear in exam questions and real-world troubleshooting — knowing them prevents misidentifying them as public IPs.

Address / Range	Name	RFC	Purpose	Notes
127.0.0.0/8 (127.0.0.1 most common)	Loopback	RFC 1122	Points back to the local device — packets sent here never leave the host's TCP/IP stack	Used to test local TCP/IP; "localhost"; ping 127.0.0.1 tests the IP stack itself
169.254.0.0/16	Link-Local / APIPA	RFC 3927	Automatic Private IP Addressing — assigned by OS when DHCP fails; allows local communication only	Seeing a 169.254.x.x address means DHCP failed — the device cannot reach the internet
192.0.2.0/24	TEST-NET-1	RFC 5737	Reserved for use in documentation, examples, and books — should never appear in real traffic	Used on this page as example addresses; same as 203.0.113.0/24 (TEST-NET-3)
198.51.100.0/24	TEST-NET-2	RFC 5737	Documentation use only	Never route in production
203.0.113.0/24	TEST-NET-3	RFC 5737	Documentation use only	Used in Cisco documentation and CCNA examples as the "public IP" of a router
224.0.0.0/4	Multicast	RFC 5771	Reserved for multicast group addresses — not assigned to individual hosts	224.0.0.5 = AllSPFRouters; 224.0.0.6 = AllDRRouters; 239.x.x.x = organisation-local multicast
240.0.0.0/4	Reserved (Class E)	RFC 1112	Reserved for future use; never allocated	Not routable; not usable in practice
0.0.0.0/8	Unspecified / This network	RFC 1122	"Any address" in routing contexts; default route = 0.0.0.0/0	0.0.0.0 used as source in DHCP discover; 0.0.0.0/0 = default route matching all destinations
255.255.255.255	Limited Broadcast	RFC 919	Broadcast to all hosts on the local subnet — not forwarded by routers	Used in DHCP Discover; OSPF all-hosts broadcast on some implementations

5. Public vs Private — Full Comparison

Criteria	Public IP Address	Private IP Address (RFC 1918)
Internet routability	Fully routable — internet routers forward packets to any public IP	Not routable — internet routers drop packets with RFC 1918 source/destination
Geographic scope	Global — reachable from anywhere on the internet	Local — reachable only within the same private network (or through VPN/tunnel)
Uniqueness requirement	Must be globally unique — no two active internet devices can share the same public IP	Only unique within the local network — the same RFC 1918 address can exist in millions of separate private networks simultaneously
Assignment authority	IANA → Regional Internet Registry (RIR) → ISP → end organisation — formal registration process	Network administrator or DHCP server — no registration required; use freely from RFC 1918 ranges
Cost	Scarce and increasingly expensive — ISPs charge per-IP or per-block	Free to use — no cost, no registration
Security exposure	Directly exposed to internet — must be protected by firewall, ACL, IPS	Hidden behind NAT by default — external hosts cannot directly initiate connections to private IPs
Services hosted	Internet-facing servers — web servers, mail servers, DNS servers, VPN endpoints	Internal users, printers, internal servers, IoT devices, IP phones, cameras
Internet access	Direct — no translation needed	Requires NAT/PAT translation at the internet edge

6. How Public IPs Are Allocated — The Hierarchy

Public IP addresses follow a strict hierarchical allocation process. Understanding this hierarchy helps explain how internet routing works and why IP addresses are scarce.

  Public IP allocation hierarchy:

  ┌─────────────────────────────────────────────────────────────────┐
  │  IANA (Internet Assigned Numbers Authority)                     │
  │  Manages entire IPv4/IPv6 address space (4.3B IPv4 addresses)   │
  │  Allocates large blocks to each Regional Internet Registry       │
  └──────────────────────┬──────────────────────────────────────────┘
                         │ Large blocks (/8 etc.)
  ┌──────────────────────▼──────────────────────────────────────────┐
  │  Regional Internet Registries (RIRs) — 5 worldwide              │
  │  ARIN (North America) | RIPE NCC (Europe/Middle East/Central Asia)│
  │  APNIC (Asia-Pacific) | LACNIC (Latin America) | AFRINIC (Africa) │
  │  Allocate smaller blocks to ISPs and large organisations         │
  └──────────────────────┬──────────────────────────────────────────┘
                         │ Smaller blocks (/16 to /24)
  ┌──────────────────────▼──────────────────────────────────────────┐
  │  ISPs (Internet Service Providers)                               │
  │  Receive address blocks; assign public IPs to customers          │
  │  Dynamic IPs: typically 1 public IP per customer (changes over time)│
  │  Static IPs: fixed public IP, paid extra — for servers/VPNs     │
  └──────────────────────┬──────────────────────────────────────────┘
                         │ Single IPs or small blocks
  ┌──────────────────────▼──────────────────────────────────────────┐
  │  End users / organisations                                       │
  │  Home users: 1 public IP (dynamic, shared via PAT internally)   │
  │  Enterprises: block of public IPs (e.g., /29 = 6 usable)        │
  │  Data centres/cloud: large blocks for servers                    │
  └─────────────────────────────────────────────────────────────────┘

IPv4 Exhaustion Timeline

Event	Date	Impact
IANA final /8 allocation to RIRs	February 2011	Central IANA pool exhausted — no more /8 blocks available to distribute to RIRs
APNIC (Asia-Pacific) exhaustion	April 2011	First RIR to run out of free addresses
RIPE NCC (Europe) exhaustion	September 2012	New allocations restricted to /22 blocks only
ARIN (North America) exhaustion	September 2015	Waitlist implemented for new IPv4 requests
LACNIC (Latin America) exhaustion	June 2014	Restricted allocations only
IPv4 addresses today	Ongoing	Traded on secondary market; prices reached $50–60 per IP in 2022–2024; IPv6 deployment accelerating

7. NAT — Bridging Private and Public Addresses

Network Address Translation (NAT) is the mechanism that allows devices with private (RFC 1918) IP addresses to communicate with the public internet. The NAT router maintains a translation table mapping private address+port combinations to the public IP.

  NAT/PAT at the network edge:

  Home LAN (private)           NAT Router           Internet (public)
  ─────────────────            ──────────           ─────────────────
  PC1: 192.168.1.10  ──────▶  Gi0/0 (inside)      Gi0/1 (outside)
  PC2: 192.168.1.11  ──────▶  192.168.1.1    PAT  203.0.113.1 ──────▶ Google
  Phone: 192.168.1.20 ─────▶                                           YouTube
                                                                        DNS

  What Google sees from all three devices: 203.0.113.1
  (distinguished only by different source port numbers)

  NAT translation table:
  192.168.1.10:49200 ↔ 203.0.113.1:1024  → google.com:80
  192.168.1.11:51000 ↔ 203.0.113.1:1025  → youtube.com:443
  192.168.1.20:52100 ↔ 203.0.113.1:1026  → 8.8.8.8:53

Types of NAT

NAT Type	Mapping	Port Translation	Inbound Connections	Use Case
Static NAT	One private IP → one public IP (permanent)	No	Yes — bidirectional	Web servers, mail servers, VPN endpoints that need to be reachable from internet — see Static NAT
Dynamic NAT	Many private IPs → pool of public IPs (one-to-one)	No	No — outbound only	Legacy — requires as many public IPs as concurrent users; rarely deployed today — see Dynamic NAT
PAT (NAT Overload)	Many private IPs → one public IP (using ports)	Yes — source port rewritten	No — outbound only (no port forwarding)	Standard for homes, offices, most internet connections — see PAT Lab

8. How to Identify Private vs Public IPs Instantly

On any CCNA exam question or real-world scenario, you need to instantly identify whether a given IP is private, public, or special-purpose.

  Quick identification flowchart:

  Given an IP address — ask these questions in order:

  1. Does it start with 10.?
     YES → Private (RFC 1918 Class A) — 10.0.0.0 through 10.255.255.255

  2. Does it start with 172. AND is the second octet 16–31?
     YES → Private (RFC 1918 Class B) — 172.16.x.x through 172.31.x.x
     TRAP: 172.15.x.x is PUBLIC; 172.32.x.x is PUBLIC — only 16–31 is private

  3. Does it start with 192.168.?
     YES → Private (RFC 1918 Class C) — 192.168.0.x through 192.168.255.x
     TRAP: 192.0.2.x is TEST-NET (not private, not public)

  4. Does it start with 127.?
     YES → Loopback (never leaves the device)

  5. Does it start with 169.254.?
     YES → Link-Local/APIPA (DHCP failed)

  6. Does it start with 224–239.?
     YES → Multicast (not a host address)

  7. Does it start with 240–255.?
     YES → Reserved Class E (not usable)

  8. None of the above → PUBLIC IP (globally routable)

Quick-Test Examples

IP Address	Private / Public / Special	Reason
192.168.0.1	Private (RFC 1918)	192.168.x.x range — Class C private
10.0.0.1	Private (RFC 1918)	10.x.x.x range — Class A private
172.16.0.1	Private (RFC 1918)	172.16–31.x.x range — Class B private
172.15.0.1	PUBLIC	172.15 is NOT in the private range (must be 16–31)
172.32.0.1	PUBLIC	172.32 exceeds the Class B private range (max is 172.31)
192.0.2.1	TEST-NET (Special)	Documentation/example address — not routable, not RFC 1918
127.0.0.1	Loopback (Special)	Local host — never leaves the device
169.254.1.50	Link-Local APIPA (Special)	169.254.x.x — DHCP failure indicator
8.8.8.8	Public	Not in any private or special range — Google DNS
203.0.113.1	TEST-NET-3 (Special)	RFC 5737 documentation address — not actually public despite appearing public

9. Use Cases for Private IP Addresses

Environment	Private Range Typically Used	How Internet Access Works
Home network	192.168.0.0/24 or 192.168.1.0/24 (default on most routers)	Home router performs PAT — all devices share the single dynamic public IP assigned by the ISP
Small business	192.168.x.x or 10.x.x.x for larger offices	Edge firewall/router performs PAT; may have static public IPs for hosted servers
Enterprise campus	10.0.0.0/8 subdivided per site/VLAN — e.g., 10.1.0.0/16 per building	PAT at internet edge; MPLS WAN connects branches using private addresses; VPNs for remote access
Cloud VPC (AWS, Azure, GCP)	172.16.0.0/12 or 10.0.0.0/8 — cloud providers default to these for Virtual Private Cloud subnets	Cloud NAT gateway for outbound; Elastic/Public IPs for internet-facing resources
Devices with no internet need	Any RFC 1918 range appropriate for the site	No NAT needed — printers, IP cameras, IoT sensors, internal servers communicate only within the LAN

10. Private IP Addressing Challenges

Overlapping RFC 1918 Ranges

Because any organisation can independently use the same private IP range, conflicts arise when two private networks need to communicate directly — typically during mergers, acquisitions, or VPN connections.

  Overlapping RFC 1918 problem:

  Company A (192.168.1.0/24) ──[VPN]── Company B (192.168.1.0/24)

  Both companies use 192.168.1.x !
  A's router sees traffic to 192.168.1.50 → is this B's server or a local host?
  Routing is AMBIGUOUS — packets may loop or be misrouted

  Solutions:
  1. NAT on one side — translate Company B's 192.168.1.x to a different range
     before it crosses the VPN
  2. Double-NAT — translate both sides to unique address ranges in the tunnel
  3. Redesign one side to use non-overlapping address range
     (best long-term solution — use 10.0.0.0/8 for large enterprises
      to reduce overlap risk)

APIPA — When DHCP Fails

When a device cannot reach a DHCP server, Windows and other operating systems automatically assign a link-local address from the 169.254.0.0/16 range (APIPA — Automatic Private IP Addressing). The device can communicate with other APIPA hosts on the same segment but cannot reach the internet or other subnets.

Seeing 169.254.x.x on a device is a clear diagnostic signal: DHCP is not reachable
Common causes: DHCP server down, wrong VLAN, missing DHCP relay (ip helper-address)
Fix: resolve the DHCP issue; force renewal with ipconfig /renew (Windows) or dhclient (Linux)

11. Security: Private IPs, Public IPs, and NAT

Security Aspect	Private IP	Public IP
Direct internet exposure	None by default — internal devices invisible to internet scanners as long as NAT is in place	Full exposure — any internet host can attempt connections; must be protected by firewall and ACLs
What NAT provides security-wise	NAT hides internal IPs — unsolicited inbound connections are dropped because no NAT entry exists for them. This is often called "NAT as a firewall" but it is NOT a substitute for a real firewall
What NAT does NOT provide	NAT does not inspect packet content; does not block malware in allowed traffic; does not prevent connections initiated from inside the network (e.g., a compromised host calling home). A dedicated firewall with stateful inspection and IPS is required for real security
Audit and logging	All activity behind PAT appears as one public IP — logs on external servers show only the public IP, making forensic attribution harder	Each public IP is uniquely identifiable and traceable via WHOIS/BGP to the owning organisation

12. IPv6 and Private Addressing

IPv6 (128-bit addresses, 2¹²⁸ total) provides enough addresses to give every device on earth multiple globally unique addresses — address scarcity is eliminated, and NAT is no longer needed for address conservation.

Concept	IPv4 Equivalent	IPv6 Version
Private addresses	RFC 1918 (10/8, 172.16/12, 192.168/16)	ULA — Unique Local Addresses (fc00::/7, most commonly fd00::/8) — same concept; not routed on internet; self-assigned; analogous to RFC 1918
Loopback	127.0.0.1	::1/128 — compressed from 0:0:0:0:0:0:0:1
Link-local	169.254.0.0/16 (APIPA)	fe80::/10 — automatically generated from MAC; always present on IPv6 interfaces; used for neighbour discovery
NAT requirement	Mandatory for internet access	Not needed — every device can have a global unicast address; NAT66 exists but is considered poor practice
Privacy	NAT hides internal IPs as a side effect	IPv6 privacy extensions (RFC 4941) generate temporary random global addresses for outbound connections

See IPv6 Fundamentals for complete IPv6 addressing coverage.

13. Cisco IOS — Working with Private and Public IPs

! ── Checking interface IP addresses ────────────────────────────────────────
Router# show ip interface brief
Interface           IP-Address      OK? Method Status    Protocol
GigabitEthernet0/0  192.168.1.1     YES NVRAM  up        up       ← Private (inside)
GigabitEthernet0/1  203.0.113.1     YES NVRAM  up        up       ← Public (outside)
Loopback0           10.0.0.1        YES NVRAM  up        up       ← Private loopback

! ── Checking DHCP scope (what private IPs will be assigned) ────────────────
Router# show ip dhcp pool
Pool LAN-Pool:
 Network: 192.168.1.0/24
 Default router: 192.168.1.1
 Lease 1 days
 Utilization: 23 out of 253 available addresses

! ── Check if an IP is routable (route lookup) ────────────────────────────
Router# show ip route 192.168.1.10
! Private IP — will show "connected" or null route (not forwarded to internet)

Router# show ip route 8.8.8.8
! Public IP — will show the default route or specific route via ISP

! ── Checking NAT translations (private ↔ public) ────────────────────────
Router# show ip nat translations
Pro  Inside global       Inside local        Outside local      Outside global
tcp  203.0.113.1:1024    192.168.1.10:49200  8.8.8.8:80         8.8.8.8:80

! ── Verify private IP DHCP assignment on a host ─────────────────────────
C:\> ipconfig
Ethernet adapter:
  IPv4 Address: 192.168.1.100       ← Private IP assigned by DHCP
  Default Gateway: 192.168.1.1      ← Router's private IP (performs NAT)

! ── Check what public IP the network uses (from outside perspective) ─────
! From any internal host, browse to: https://whatismyip.com
! Or from router: ping public-ip-checker website
! Or from router CLI (if DNS configured):
Router# ping 8.8.8.8 source GigabitEthernet0/1

14. Key Points & Exam Tips

RFC 1918 private ranges (memorise all three):
10.0.0.0/8 — Class A, 16.7M hosts
172.16.0.0/12 — Class B, second octet 16–31 only
192.168.0.0/16 — Class C, most common for homes
Exam trap: 172.15.x.x and 172.32.x.x are public IPs. Only 172.16–31.x.x are private.
Private IPs are not globally unique — the same 192.168.1.0/24 exists in millions of separate networks simultaneously.
Public IPs are globally unique — managed by IANA → RIR → ISP hierarchy.
Devices with private IPs require NAT or PAT to reach the internet. PAT (overload) allows thousands of hosts to share one public IP.
Special addresses to know: 127.x = loopback; 169.254.x.x = APIPA (DHCP failure); 224–239.x.x = multicast; 192.0.2.x/198.51.100.x/203.0.113.x = TEST-NET (documentation only).
IPv4 exhaustion: IANA pool exhausted 2011; public IPs now traded on secondary market — NAT/PAT remains critical for IPv4 conservation.
NAT is NOT a security solution: it hides internal IPs but does not inspect traffic, block malware, or prevent outbound attacks from compromised hosts. Always deploy a firewall alongside NAT.
IPv6 ULA (fc00::/7) is the IPv6 equivalent of RFC 1918 — not internet-routed; used for private networks. IPv6 link-local (fe80::/10) is equivalent to IPv4 APIPA/169.254.
Overlapping private ranges cause routing ambiguity when connecting two private networks via VPN — resolve with double-NAT or address redesign.

15. Private vs Public IP Addresses Quiz

1. A network engineer is configuring a new branch office. She assigns IP addresses from the 172.20.0.0/24 subnet to branch workstations. A colleague challenges this, saying 172.20.x.x addresses are public IPs and shouldn't be used internally. Who is correct and why?

A. The colleague is correct — 172.x.x.x addresses are always public B. The colleague is correct — only 192.168.x.x is valid for private use C. The engineer is correct — 172.16.0.0 through 172.31.255.255 are reserved by RFC 1918 as private addresses. 172.20.0.0 falls within this range (second octet = 20, which is between 16 and 31) and is perfectly valid for internal use D. Both are wrong — 172.20.x.x requires ISP registration

Correct answer is C. This tests precise knowledge of the RFC 1918 Class B private range. The range 172.16.0.0 – 172.31.255.255 is defined in RFC 1918 as private. This is a /12 block that spans from second octet 16 to 31. To check: 172.20.x.x → second octet is 20 → 16 ≤ 20 ≤ 31 → PRIVATE. The colleague is making a common error: assuming only 10.x.x.x and 192.168.x.x are private. The Class B private range (172.16–31) is the most commonly confused on exams. Important boundary cases: 172.15.x.x is public (15 < 16), 172.31.255.255 is private (last address in range), 172.32.x.x is public (32 > 31). Always check: is the second octet between 16 and 31 inclusive?

2. A user calls the helpdesk reporting they cannot access the internet or any internal servers. The technician runs `ipconfig` and sees the user's IP is 169.254.43.201. What does this immediately tell the technician, and what should be checked first?

A. The user has a valid private IP — the problem is the default gateway B. 169.254.x.x is an APIPA address — the device failed to get a DHCP lease. Check: is the DHCP server reachable? Is the switch port in the correct VLAN? Is a DHCP relay (ip helper-address) needed? Is the DHCP pool exhausted? C. The IP is in the public range — the user accidentally connected to an external network D. The IP is a loopback — the network adapter needs to be replaced

Correct answer is B. 169.254.0.0/16 is the APIPA (Automatic Private IP Addressing) / link-local range defined in RFC 3927. When a Windows device fails to receive a DHCP response, it automatically assigns itself an address from 169.254.1.0–169.254.254.255 using ARP to avoid conflicts with other APIPA devices on the same segment. 169.254.43.201 is a textbook DHCP failure symptom. Common causes to investigate: (1) DHCP server is down or unreachable. (2) The switch port is in the wrong VLAN — traffic not reaching the DHCP server's VLAN. (3) No DHCP relay configured — if the DHCP server is on a different subnet, a router/switch needs ip helper-address to forward DHCP broadcasts. (4) DHCP pool exhausted — all leases allocated, no IPs available. (5) Physical connectivity issue on the port. Fix: resolve the root cause, then run ipconfig /release and ipconfig /renew.

3. A company is merging with another organisation. Both companies currently use 10.0.0.0/8 internally. They need to connect their networks via a VPN so users in each company can reach servers in the other. What fundamental problem must be solved, and what are the available approaches?

A. No problem — both companies can use 10.x.x.x simultaneously since private IPs are reusable B. Replace all IPs with public addresses to avoid private IP conflicts C. Use VLAN segmentation to keep both 10.x.x.x networks separate D. Overlapping RFC 1918 ranges cause routing ambiguity — both networks have identically addressed hosts and routers cannot determine which 10.x.x.x is local vs remote. Solutions: NAT on one or both sides of the VPN to translate one company's range to a unique address space; or long-term redesign of one network to use non-overlapping subnets

Correct answer is D. This is the classic private IP overlap problem that occurs in mergers, acquisitions, and partner VPN connections. While RFC 1918 addresses can be reused in separate networks, they CANNOT be used simultaneously on both sides of a direct VPN tunnel. When Company A's router sees a packet destined for 10.5.0.100, it cannot determine whether this is a local Company A host or a Company B host across the VPN — the routing is ambiguous. Solutions: (1) NAT at the VPN boundary — Company B's traffic appears with a translated address (e.g., 192.168.100.x) when entering Company A's network. (2) Double-NAT — both sides translate to a neutral address space in the tunnel. (3) Subnet redesign — change one company's internal addressing plan to use non-overlapping subnets (e.g., Company A uses 10.1.x.x, Company B uses 10.2.x.x) — the best long-term solution but requires re-addressing all devices. This is a well-known reason to use 10.0.0.0/8 carefully in enterprises — plan subnetted ranges per department/site to leave room for future integration.

4. Which of the following IP addresses is a valid public (globally routable) IPv4 address that could legitimately be assigned to an internet-facing server?

A. 172.32.0.1 — this is public because the second octet (32) exceeds the RFC 1918 Class B private range maximum (31), making it a globally routable address B. 192.168.100.50 — Class C private range C. 10.255.255.254 — Class A private range D. 172.31.255.255 — still within Class B private range

Correct answer is A. This is a boundary test question for the RFC 1918 Class B private range. The Class B private range is 172.16.0.0 through 172.31.255.255. The last private address in this range is 172.31.255.255. The first public address after the range is 172.32.0.0. Therefore: 172.32.0.1 has second octet = 32, which is greater than 31 (the maximum for the private range), making it a public IP. Option B: 192.168.100.50 is RFC 1918 Class C private. Option C: 10.255.255.254 is RFC 1918 Class A private (all 10.x.x.x addresses are private). Option D: 172.31.255.255 is the very LAST address in the RFC 1918 Class B private range — still private. The exam frequently tests these boundary cases — knowing that the private range ends at 172.31.x.x (not 172.16.x.x or 172.32.x.x) is essential.

5. An enterprise uses 10.0.0.0/8 internally. The network team reviews router logs and finds packets with source IP 192.0.2.15 arriving from the internet destined for their public web server. A junior engineer flags this as a suspicious external attack from a legitimate-looking IP. Should this traffic be trusted?

A. Yes — 192.0.2.x is a valid public IP range used for production traffic B. Yes — 192.0.2.x is a private range similar to 192.168.x.x C. No — 192.0.2.0/24 is TEST-NET-1 (RFC 5737), reserved for documentation and examples only. Packets with this source address arriving from the internet are spoofed or misconfigured traffic — a border firewall/ACL should drop all packets with TEST-NET source addresses D. No — 192.0.2.x is a multicast range and should never arrive as unicast traffic

Correct answer is C. 192.0.2.0/24 (TEST-NET-1), 198.51.100.0/24 (TEST-NET-2), and 203.0.113.0/24 (TEST-NET-3) are all reserved by RFC 5737 for documentation use only — they appear in textbooks, RFCs, vendor documentation, and lab examples (including throughout this website). These ranges should NEVER appear as source or destination addresses in real internet traffic. If a router receives a packet from the internet with source IP 192.0.2.15, it is either: (1) spoofed traffic (attacker crafting packets with fake source IPs to evade logging), (2) misconfigured equipment accidentally using documentation addresses, or (3) a misconfigured lab device leaking packets. Border routers and firewalls should implement ingress filtering (BCP 38/RFC 2827) that drops packets arriving from the internet with source IPs in RFC 1918, TEST-NET, loopback (127.x.x.x), APIPA (169.254.x.x), and other reserved ranges — this prevents IP spoofing attacks.

6. An organisation has been assigned a /29 public IP block from their ISP: 203.0.113.0/29. How many of these addresses can be assigned to internet-facing devices, and how would the organisation enable internet access for its 200 internal users using private IPs?

A. 8 usable public IPs; assign one to each user B. 6 usable public IPs (8 total minus network and broadcast); configure PAT on the edge router to allow all 200 internal users to share the public IPs via port translation. Static NAT entries for servers that need inbound access C. Only 1 public IP can be used — /29 means one subnet with one host D. 30 usable public IPs — /29 gives 30 host addresses

Correct answer is B. A /29 subnet has 2³ = 8 total IP addresses. Subtract the network address (203.0.113.0) and the broadcast address (203.0.113.7), leaving 6 usable host addresses (203.0.113.1–203.0.113.6). These 6 public IPs are used for: the router's outside interface (1 IP), and up to 5 internet-facing servers (web server, mail server, etc.). For the 200 internal users, PAT (NAT Overload) is configured: all 200 hosts use private IPs (e.g., 10.0.0.0/24) and share the public IPs via port translation. Each public IP can support ~64,000 simultaneous sessions — 6 public IPs × 64,000 = 384,000 possible sessions, more than enough for 200 users. The combination of a small public IP block + PAT for users + static NAT for servers is the standard enterprise edge design. /29 = 8 addresses, /30 = 4 addresses (2 usable — point-to-point links), /28 = 16 addresses (14 usable).

7. Two Cisco routers are connected back-to-back via a serial link. The network administrator assigns 10.0.0.1/30 to Router A and 10.0.0.2/30 to Router B on this link. A colleague says these are private addresses and shouldn't be used on WAN links — only public IPs should be used between routers. Is this correct?

A. Yes — WAN links must always use public IPs B. Yes — private IPs cannot be used on router interfaces C. Yes — 10.0.0.0 is reserved and cannot be assigned to interfaces D. No — private IPs are perfectly valid on WAN point-to-point links, MPLS networks, and any internal infrastructure. Private IPs only cannot be used as source/destination addresses on the public internet — router interconnect links are internal infrastructure

Correct answer is D. This is a common misconception. RFC 1918 private addresses can be used on ANY interface within a private network, including serial WAN links, loopbacks, and point-to-point connections. The restriction is only that these addresses cannot appear as source or destination in packets traversing the public internet. An MPLS WAN backbone, a leased line between two company sites, or a back-to-back serial link between lab routers are all private infrastructure — private IPs are entirely appropriate. In fact, using /30 subnets from RFC 1918 space for point-to-point links is industry best practice because it conserves public IP space. Only the customer-facing internet interface (the one connecting to the ISP's public infrastructure) needs a public IP. Routers use their public IP as the source when communicating with internet hosts, but their internal interface IPs (which private hosts route through) can and should be private.

8. A security engineer reviews firewall logs and notices regular outbound connections from an internal host (10.5.0.44) to 8.8.8.8 on UDP port 53, but also unexpected outbound connections to 203.0.113.99 on TCP port 4444. The connections to 203.0.113.99 were not initiated by any user application. What concern does the private vs public IP context raise here?

A. The internal host (10.5.0.44) has a private IP and should not be initiating outbound connections to public IPs without a user application. Connections to 203.0.113.99:4444 (an unusual public IP on a non-standard port) with no user-initiated application strongly suggest malware communicating with a Command and Control (C2) server — NAT hides the private source IP but does not block this outbound traffic B. Both connections are normal — DNS and web traffic are expected C. The concern is that 10.5.0.44 is using a private IP — it should be assigned a public IP for security monitoring D. The connections to 203.0.113.99 are fine — 203.0.113.x is a reserved TEST-NET address that cannot be reached from the internet

Correct answer is A. This scenario illustrates the critical point that NAT does NOT provide security for outbound traffic. The private host 10.5.0.44 making DNS queries (UDP 53) to 8.8.8.8 is normal. However, connections to 203.0.113.99 on TCP 4444 (a common malware/RAT port) with no corresponding user application are a serious security indicator. Private IPs behind NAT can still initiate outbound connections to any public IP — PAT happily translates them. The internal device could be infected with malware beaconing to a C2 server. This is exactly why NAT alone is insufficient for security — a firewall with application-layer inspection, egress filtering (blocking unknown outbound ports), and SIEM/IDS monitoring is required. Regarding option D: 203.0.113.0/24 IS a TEST-NET (documentation-only range) — but in this scenario, this specific IP is representing a real attack destination. In actual attacks, the C2 server would be on a real public IP; 203.0.113.x is used here as an example address following documentation convention.

9. A company's network administrator asks: "Can we just use public IP addresses internally to avoid NAT complexity?" What are the fundamental reasons this is not recommended?

A. It is technically possible and commonly done for large enterprises B. Public IPs cannot be configured on router LAN interfaces C. Public IPs are scarce and expensive — using them internally wastes registered IP space (you'd need to own the block); internal devices become directly internet-reachable (security risk); RFC 1918 provides free, unlimited address space for internal use; and changing to a new public block later requires re-addressing all devices D. Private IPs are faster than public IPs due to shorter routing paths

Correct answer is C. Using public IPs internally is technically possible if you own the block — some large organisations with legacy infrastructure do use their own public IP blocks internally. However, it creates multiple problems: (1) Cost and scarcity — public IPv4 addresses now sell for $50–60 each on the secondary market; assigning them to internal printers and workstations is wasteful and expensive when RFC 1918 provides 17.9 million free addresses. (2) Security — internal devices with routable public IPs can potentially be reached from the internet if firewall rules are misconfigured or bypassed; private IPs with NAT provide a natural barrier. (3) Operational complexity — if you're using an ISP's public block and change providers, you must re-address all internal devices. RFC 1918 space is provider-independent. (4) Routing confusion — public IPs assigned internally may conflict with actual internet routes if the routing is not carefully managed. Private IPs + NAT is the overwhelmingly standard design for all but the largest operators.

10. IPv6 is designed to make NAT unnecessary. What is the IPv6 equivalent of RFC 1918 private addresses, and why does IPv6 still include them even though IPv6 has enough global addresses for every device?

A. IPv6 has no private address concept — all IPv6 addresses are global B. IPv6 ULA (Unique Local Addresses, fc00::/7, practically fd00::/8) are the RFC 1918 equivalent. They exist because some networks genuinely need addresses that are not internet-reachable for security isolation, air-gapped networks, or internal-only services — the abundance of global addresses doesn't eliminate the architectural need for private segments C. IPv6 link-local (fe80::/10) is the RFC 1918 equivalent D. IPv6 uses 2001:db8::/32 as its private range

Correct answer is B. IPv6 Unique Local Addresses (ULA) defined in RFC 4193 are the closest IPv6 equivalent to RFC 1918. The ULA block is fc00::/7, which in practice means fd00::/8 (the "fd" prefix is used for locally assigned ULA, while "fc" is reserved but currently unused). Like RFC 1918 addresses, ULAs are: not routed on the global internet; free to use without registration; and intended for internal communication only. Even though IPv6 provides enough global addresses for every device, ULA serves several legitimate needs: (1) Air-gapped or isolated networks (industrial control systems, military networks) that should never have internet connectivity. (2) Internal services (Active Directory, internal DNS) that should only be reachable within the organisation. (3) Predictable internal addressing — global unicast addresses depend on the ISP's assignment (which changes if you switch ISPs); ULA provides stable internal addressing independent of the ISP. Note: Option C (fe80::/10) is IPv6 link-local, which is equivalent to APIPA (169.254.x.x) — automatically assigned, used only on the local segment, not routable. Option D (2001:db8::/32) is documentation-only, equivalent to 192.0.2.0/24 TEST-NET.

← Back to Home