IP Addressing and Subnetting Questions

Direct answer

There are four ways to bridge IPv4 and IPv6: dual stack (run both protocols side by side), tunnelling (carry IPv6 packets inside IPv4), translation (convert packets between the two; NAT64 does the packet conversion and DNS64 makes the DNS answers that point clients at it, both explained below), and application-layer proxying (a load balancer, reverse proxy or content delivery network, CDN, that speaks IPv6 on one side and IPv4 on the other). For an IPv4-only enterprise whose partners are moving to IPv6, the practical order is: put a dual-stack front door (load balancer or CDN) on the services partners consume, route outbound access to IPv6-only partners through a dual-stack proxy, and dual-stack the internal network later on a schedule. Tunnels are for pilots and translation is for IPv6-only segments. Of the techniques named below, dual stack, a dual-stack front end and NAT64/DNS64 are the ones to plan around; 6in4, 6rd, 6to4 and 464XLAT are narrower tools you meet in specific situations.

The two directions are different problems

• Partners reaching your IPv4 services. The partner has IPv6 and your servers do not. Fix this at the edge: an IPv6 address on the load balancer or CDN that forwards to IPv4 servers behind it.
• Your IPv4 users reaching an IPv6-only partner service. Your clients have no IPv6. NAT64 does not help here, because it lets IPv6-only clients reach IPv4 servers, the opposite direction. The workable options are a dual-stack forward proxy (clients speak IPv4 to the proxy, the proxy speaks IPv6 to the partner) or giving clients IPv6 (dual stack).

Comparison

Worked example: what DNS64 does

An IPv6-only client asks for the AAAA record (the DNS record type that holds an IPv6 address; an A record holds an IPv4 one) of a name that only has an IPv4 address, 93.184.216.34. DNS64 builds an IPv6 address by placing the IPv4 address in the low 32 bits of the well-known prefix 64:ff9b::/96. The client sends to that address, and the NAT64 gateway extracts the IPv4 address and forwards the packet. Computed with Python's ipaddress module:

import ipaddress as ip
wkp = ip.ip_network("64:ff9b::/96")
v4 = ip.IPv4Address("93.184.216.34")
synth = ip.IPv6Address(int(wkp.network_address) | int(v4))
print("DNS64 synthesised AAAA for", v4, "->", synth)
print("embedded v4 recovered:", ip.IPv4Address(int(synth) & 0xFFFFFFFF))
print("is 10.1.2.3 global?", ip.IPv4Address("10.1.2.3").is_global, "| is 93.184.216.34 global?", ip.IPv4Address("93.184.216.34").is_global)
print("IPv6 minimum MTU 1280; 6in4 adds 20-byte IPv4 header ->", 1500 - 20, "max tunnel MTU on a 1500 link")

DNS64 synthesised AAAA for 93.184.216.34 -> 64:ff9b::5db8:d822
embedded v4 recovered: 93.184.216.34
is 10.1.2.3 global? False | is 93.184.216.34 global? True
IPv6 minimum MTU 1280; 6in4 adds 20-byte IPv4 header -> 1480 max tunnel MTU on a 1500 link

The third line matters: RFC 6052 forbids using the well-known prefix for non-global IPv4 addresses such as RFC 1918 ranges, and a translator must drop those packets. To reach internal IPv4 servers through NAT64 you need a prefix of your own from the organisation's address space, not 64:ff9b::/96.

Pitfalls that cause real incidents

• Publishing an AAAA record before the IPv6 path works end to end. Clients try IPv6 first. Happy Eyeballs (RFC 8305, the client behaviour of racing IPv6 and IPv4 connections) falls back to IPv4 after a connection attempt delay (250 ms is the recommended default), which hides the fault from users but adds latency to every connection; test from outside before publishing.
• Blocking ICMPv6 wholesale. IPv6 needs it for neighbour discovery and path MTU discovery, and routers do not fragment, so tunnels and translators fail silently for large packets if it is filtered (the sender never learns its packet was too big).
• Rule parity. A server with an IPv6 address that nobody put in the firewall policy is reachable in ways the IPv4 policy never allowed.
• Tooling that only parses IPv4. SIEM (security information and event management) parsers, IPAM, monitoring and ACL automation need IPv6 support before the first AAAA record goes live.

Recommendation and what would change it

Commit to the dual-stack edge plus an outbound proxy first, because it changes only a few devices and every step can be backed out by removing an AAAA record or a proxy rule. Move to dual stack on user networks when a measurable share of destinations is IPv6-only. Introduce NAT64/DNS64 only for a segment you decide to make IPv6-only (guest Wi-Fi is a common first candidate). If the partner can only be reached over an IPv6-only private link, dual stack on the affected user group is needed sooner.

Direct answer

An IPAM (IP address management) system is the single database of record for who owns which address space. Record, for every prefix: the CIDR (classless inter-domain routing, the /24 style of notation) block, its parent, its routing context (VRF, a separate routing table; see below), status, role, location and VLAN, owner, and links to the DHCP scope and DNS zone. For every address: the address, status, DNS name, the device and interface it belongs to, owner, and the date and ticket that assigned it. Add a change history on everything. Five fields prevent collisions on their own: for a prefix, the CIDR block, its parent, its VRF, its status and an owner; the remaining fields answer troubleshooting and audit questions. Each field exists to answer a question someone asks daily ("who owns this?", "is this free?") or an auditor asks yearly ("who approved this and when?").

Per prefix

Per address

System behaviours that matter as much as fields

• Overlap prevention on write, VRF-aware: refuse a new active prefix that overlaps another active prefix in the same VRF, unless the parent is a container.
• Change history (who, what, when, before and after values) and an API, so changes are made from tickets and automation rather than by hand.
• Role-based access: all can read; only the allocating team can write.
• Discovery and reconciliation: compare recorded addresses with DHCP leases, ARP tables and cloud inventories; flag drift, and stale or unrecorded addresses.
• Integration with DNS and DHCP so records are created from IPAM, not retyped.

Migrating from spreadsheets: find the conflicts first

Run an overlap check over the existing sheet before importing. This script (all inputs inline) treats a prefix as legal inside a container parent and flags overlaps only within the same VRF:

import csv, io, ipaddress, itertools
from collections import defaultdict

SHEET = """prefix,vrf,site,status
10.20.0.0/16,corp,HQ,container
10.20.5.0/24,corp,HQ,active
10.20.5.128/25,corp,HQ,active
10.30.0.0/24,corp,Branch-A,active
10.30.0.0/24,guest,Branch-A,active
10.30.0.0/25,corp,Branch-B,active
"""

by_vrf = defaultdict(list)
for row in csv.DictReader(io.StringIO(SHEET)):
    by_vrf[row["vrf"]].append((ipaddress.ip_network(row["prefix"]), row["site"], row["status"]))

conflicts = 0
for vrf, rows in sorted(by_vrf.items()):
    for (a, sa, ta), (b, sb, tb) in itertools.combinations(rows, 2):
        if not a.overlaps(b):
            continue
        parent_status = ta if a.prefixlen <= b.prefixlen else tb
        if a != b and parent_status == "container":
            continue
        conflicts += 1
        print(f"CONFLICT vrf={vrf}: {a} ({sa}) overlaps {b} ({sb})")
print(f"{conflicts} conflicts")

It prints:

CONFLICT vrf=corp: 10.20.5.0/24 (HQ) overlaps 10.20.5.128/25 (HQ)
CONFLICT vrf=corp: 10.30.0.0/24 (Branch-A) overlaps 10.30.0.0/25 (Branch-B)
2 conflicts

How the test works: a.overlaps(b) is true when two prefixes share any addresses, and two prefixes that overlap are always nested, so the one with the shorter prefix length (a.prefixlen <= b.prefixlen) is the parent and parent_status is that parent's status. If the parent is a container, a child inside it is expected and the pair is skipped. The extra test a != b means two identical prefixes are always a conflict, even if marked container, because a block cannot be its own child. Anything else (an active block containing another active block) is counted. Rows in different VRFs are never compared, because they are grouped by VRF first.

The /16 container holding both /24 and /25 is fine, the 10.30.0.0/24 present in both corp and guest is fine (different VRFs), and the two real conflicts are the HQ /25 inside an active /24 and the Branch-B /25 inside Branch-A's active /24.

Audit and daily-operations uses

• Operations: allocate the next free block safely, find the owner of an address during an incident, size a subnet from real utilisation, and decommission a site and know which blocks, DNS records and reservations go with it.
• Audit: show that every allocation has an approver and ticket, that history is complete and not editable, and that recorded space matches what discovery sees (reconciliation evidence). The review date field supports periodic attestation (each block owner formally confirming that their records are still correct).

Pitfalls

• Importing the spreadsheet as-is: duplicate and overlapping rows become permanent.
• Free-text fields for status and role: reports then cannot be trusted; use controlled lists.
• Letting engineers edit IPAM and devices independently: without reconciliation, the database is a stale copy within months.

Direct answer

An IPv6 address is 128 bits written as eight groups of four hexadecimal digits separated by colons, usually split into a 64-bit network prefix and a 64-bit interface identifier (the part that names the host on that network). A single interface normally holds several addresses at once: a link-local address, one or more global (or unique local) addresses, and a set of multicast group memberships. IPv4 usually gives an interface one address and uses broadcast.

Notation

Full form: 2001:0db8:0000:0000:0000:ff00:0042:8329. Two rules shorten it:

1. Leading zeros in each group can be dropped: 2001:db8:0:0:0:ff00:42:8329.
2. One run of consecutive all-zero groups becomes ::, only once per address: 2001:db8::ff00:42:8329.

The recommended text form (RFC 5952, the standard that defines one canonical way to write an address so logs and searches agree) is lowercase, shortens the longest zero run (the first if tied) and never uses :: for a single zero group. Prefix length is written like IPv4: 2001:db8:0:1::/64.

Structure

• A /64 is the standard subnet size. The low 64 bits are the interface identifier, which stateless address autoconfiguration (SLAAC, where a host builds its own address from the prefix a router announces in a router advertisement message) relies on.
• Typical allocation: an ISP gives a site a /48 or /56, and each VLAN gets a /64 from it.

Address types an interface holds

Temporary addresses (RFC 8981) are randomized and by default prefer a 1-day lifetime and expire after 2 days, used for outgoing connections to resist tracking.

In daily work the link-local address, the global unicast address and the all-nodes multicast membership are present on essentially every interface; ULA and loopback appear in specific designs.

Worked example

A laptop on VLAN 20 (illustrative addresses) might show: fe80::1c2b:3dff:fe44:5566 (link-local), 2001:db8:0:20:1c2b:3dff:fe44:5566 or a stable-random variant (global), 2001:db8:0:20:9a7e:41d2:6b0c:e5f1 (temporary), plus ff02::1 and the solicited-node groups described below. In the two addresses ending 1c2b:3dff:fe44:5566, the first four groups are the network part (fe80:0:0:0 for link-local, 2001:db8:0:20 for global) and the last four groups, 1c2b:3dff:fe44:5566, are the interface identifier. Here the identifier comes from the NIC's MAC address 1e:2b:3d:44:55:66: ff:fe is inserted in the middle and one bit in the first byte is flipped (1e becomes 1c), which is the modified EUI-64 method. The stable-random variant and the temporary address use random identifiers instead, so they show no ff:fe. The solicited-node group for the first two addresses is ff02::1:ff44:5566, the fixed prefix plus the last 24 bits (44:5566). Because the group is derived from each address's own last 24 bits, the temporary address (ending 6b0c:e5f1) joins a different group, ff02::1:ff0c:e5f1, so this interface holds two solicited-node memberships (one shared by the first two addresses, one for the temporary address) next to ff02::1. That is three unicast addresses plus the multicast memberships on one interface, which is normal.

Difference from IPv4

• Multiple addresses per interface by design, versus usually one.
• No broadcast: multicast and NDP (Neighbor Discovery Protocol, the neighbor discovery described above) replace broadcast and ARP.
• Address scarcity disappears, so NAT is not needed for conservation, and routers do not fragment packets in transit.
• Autoconfiguration (SLAAC) or DHCPv6 instead of DHCP alone.

Pitfalls

• Using :: twice in one address (ambiguous and invalid), or writing the same address in different compressed forms, which makes searching logs unreliable.
• Subnetting smaller than /64 and breaking SLAAC.
• Blocking all ICMPv6 at a firewall, which breaks neighbor discovery.

Direct answer

A 169.254.x.x address means the workstation asked for an address with DHCP (Dynamic Host Configuration Protocol), got no offer, and gave itself an IPv4 link-local address. Microsoft calls this Automatic Private IP Addressing (APIPA), and the standard behind it is RFC 3927. The address is only valid on the local network segment: the host has no default gateway, no DNS server, and routers will not forward it, so users cannot reach anything beyond their own VLAN. Because several machines on one floor fail together, suspect something they share on the path between the floor and the DHCP server (the VLAN, the uplink, the relay, or the server's scope) rather than the machines. Step 1 below uses the pattern of who fails to tell which of those it is.

What the address tells you

• The host picks an address at random from 169.254.1.0 to 169.254.254.255 (the first and last 256 addresses of 169.254.0.0/16 are reserved, leaving 65,536 minus 512 = 65,024), then sends three ARP probes (Address Resolution Protocol, "does anyone own this address?") before using it. The mask is /16.
• Link still works at layer 2 (the local-network level of switches and MAC addresses, below IP), so the NIC, cable and switch port are probably fine. The failure is in getting a DHCP reply.
• A host keeps retrying. How often is implementation-dependent (RFC 3927 cites Mac OS checking for a DHCP server every five minutes as an example), so hosts recover on their own, usually within minutes, once DHCP works again.

What still works and what does not

• Works: other hosts in the same VLAN that also hold 169.254 addresses can reach each other by IP (ping, file shares by IP). Hosts and servers with static addresses or unexpired leases keep working, which is why the outage looks patchy.
• Fails: anything off the segment, because there is no gateway and routers must not forward link-local traffic. DNS names fail (no DNS server). Local name resolution by multicast may still resolve names between neighbours.
• Why "suddenly": existing leases survive. With an 8-day lease, a client first tries to renew at T1 (50 percent of the lease, day 4) and rebinds at T2 (87.5 percent, day 7) per RFC 2131. A DHCP outage that began days ago becomes visible only as machines reach those points or are newly plugged in, so ask when the problem actually began.

Narrowing it down, in order

1. Scope the blast radius. Is it every machine on that floor or a subset, and one VLAN or several? Do the same model of PC on another floor work? If only new or rebooting machines fail while machines holding valid leases keep working, the problem is the DHCP service, scope or relay (existing leases hide it). If machines that already had a lease also lose connectivity together, the floor's own network (the VLAN, the uplink) has failed as well as DHCP.
2. Separate "no DHCP" from "no network". On an affected PC set a temporary static address in the floor's subnet with its gateway and ping the gateway. If that works, layer 2 and the gateway are healthy and only the DHCP path is broken. If it fails, check the access port's VLAN, the trunk's allowed-VLAN list on the uplink (the list of VLANs a switch-to-switch link is permitted to carry, so a VLAN missing from it is cut off from the rest of the network), and port authentication (a network access control system checks a device before giving its port normal access, and can hold it in a restricted VLAN).
3. Watch the DHCP exchange from the client. A normal lease is a four-step conversation: the client broadcasts a DISCOVER ("any DHCP server here?"), a server answers with an OFFER (an address on loan), the client broadcasts a REQUEST accepting it, and the server confirms with an ACK. Capture with Wireshark (display filter dhcp) or tcpdump -ni eth0 'udp port 67 or udp port 68' on Linux. Three outcomes:
   • No DISCOVER leaves the PC: a client-side or port-authentication problem.
   • DISCOVERs leave and no OFFER returns: the problem is between the floor and the server. Go to step 4.
   • An OFFER arrives but the host still uses 169.254: rare, a host firewall or NIC problem.
     A healthy capture shows DISCOVER, OFFER, REQUEST and ACK in that order within about a second; a broken one shows DISCOVER repeated every few seconds with nothing coming back.
4. Check the floor's gateway and switches. The router or layer-3 switch interface for that VLAN must relay DHCP broadcasts to the server (a "helper address" setting, which forwards the client's broadcast as a direct message to the server because broadcasts do not cross routers); check it points at the current server's IP and that the relay was not lost when the VLAN was changed or merged. If DHCP snooping (a switch feature that drops DHCP replies from untrusted ports) is on, check that the uplink toward the server is marked trusted and look at the snooping drop counters and binding table for the VLAN.
5. Check the server. Is the DHCP service running, is the scope active and not exhausted, does the server's log show DISCOVERs arriving from this relay, and is a failover partner healthy? On Windows Server these two commands show scope use and which servers are authorised in Active Directory (only an authorised server leases addresses):

Get-DhcpServerv4ScopeStatistics -ComputerName dhcp01.example.com -ScopeId 10.30.0.0
Get-DhcpServerInDC

Get-DhcpServerv4ScopeStatistics reports in-use and free counts and PercentageInUse for the scope; an exhausted scope has no free addresses, so a healthy result for a floor scope is a free count well above zero and a low percentage, while a scope stuck near 100 percent explains new clients getting no offer. Get-DhcpServerInDC should list this server; if it is missing, an Active Directory-joined server will not lease addresses. Worked example: a floor VLAN 10.30.0.0/24 whose scope covers .10 to .250 has 250 - 10 + 1 = 241 addresses. A floor with 150 desk PCs and 120 IP phones needs 270, so 29 devices go without an address once leases are full. The fix is a larger subnet or scope, shorter leases for transient devices, or splitting phones into their own VLAN.
6. Fix and verify. Restore the broken element (relay target, trunk VLAN, snooping trust, service or scope). Force a client with ipconfig /release then ipconfig /renew (Windows) and confirm with ipconfig /all that it shows a normal DHCP lease from the right server and a default gateway, then ping the gateway and a name. Check that the server's lease table now lists the floor's machines, and add a monitor on scope percentage in use so exhaustion alerts before users do.

Pitfalls

A static-address test that works proves the wire is fine but not that DHCP is fine, so always do both. Do not renew leases on the whole floor until the cause is fixed, because hosts with valid leases are the ones still working. A rogue DHCP server gives a wrong address rather than a 169.254 one, so it is a different symptom with a different fix. Linux hosts often show no address at all rather than a 169.254 address unless link-local fallback is configured, so the same fault looks different on mixed fleets.

Direct answer

Classful addressing was the original IPv4 scheme in which the first bits of an address fixed its class and therefore its network size, with no separate mask. The internet abandoned it because it wasted address space and bloated routing tables, and replaced it in 1993 with CIDR (Classless Inter-Domain Routing, RFC 1519) where the prefix length is explicit. Calling 172.16.5.0/24 "a Class B subnet" is misleading because the mask, not the first octet, defines the network, and this one is a /24 inside a private block.

What classful addressing was

To see how the first bits fix the class, take 172.16.5.0: the first octet 172 is 10101100 in binary, which starts with 10, so it is Class B and the classful network was 172.16.0.0 with a /16 mask. By contrast 192.168.1.0 starts 11000000, leading bits 110, so Class C and /24. Routing protocols of the time (RIPv1 and IGRP, early routing protocols that exchange route lists between routers) sent no mask in updates and inferred it from the class.

Why it was abandoned

1. Wasted addresses. Class C (254 hosts) was too small and Class B (65,534) too large, so an organization needing 2,000 addresses took a Class B and left more than 63,000 unused.
2. Routing table growth. Organizations needing more than a Class C received several, each its own route, so the global table grew toward unmanageable size.
3. Rigid sizes with no way to carve or combine blocks.
   CIDR allows any prefix length and supernetting (advertising one shorter prefix that covers many contiguous blocks), which fixed both.

Why the label misleads today

• 172.16.5.0/24 has a 24-bit mask, 254 usable hosts, not Class B's 65,534. Its class only tells you the first octet falls in 128 to 191.
• 172.16.0.0/12 (172.16.0.0 to 172.31.255.255) is the RFC 1918 private block, which is 16 old Class B ranges, so "a Class B" is not even a correct name for it.
• Modern gear and protocols (OSPF, BGP, EIGRP, static routes) carry explicit prefixes, so the class changes nothing in forwarding or planning. Assuming a /16 mask for a "Class B" causes real mistakes, for instance when configuring ACLs, summaries or firewall objects.
• Class D (multicast, 224.0.0.0/4) and E (reserved, 240.0.0.0/4) survive as ranges, which is the only part of the vocabulary still in use.

What to say to the colleague

Say "172.16.5.0/24, inside the 172.16.0.0/12 private range". Always quote the prefix length.

Pitfalls

• Defaulting to the classful mask when a device or script omits one.
• Believing old automatic summarization at classful boundaries still applies. That was the behaviour of early routers, which advertised a subnet such as 172.16.5.0/24 to other networks as the whole classful network 172.16.0.0/16; modern protocols advertise the exact prefix.