Chapter 2 — IPv6 Addressing

The Internet Protocol is what makes the network a single network. Every device that participates in the global Internet — whether a 5G handset on Ncell, an FTTH router at a Subisu customer's home, a server at the Government Integrated Data Centre, or a Raspberry Pi running an air-quality sensor in Pokhara — speaks the Internet Protocol. There are two deployed versions: IPv4 from 1981, and IPv6 from 1998 (RFC 2460) as currently defined by RFC 8200 (2017). This chapter establishes the addressing model of both, then concentrates on IPv6 in the depth a network engineer needs.

2.1 IPv4 addressing overview, challenges, and issues

The IPv4 address

An IPv4 address is a 32-bit number, written as four decimal octets separated by dots, that uniquely identifies a network interface on the IPv4 Internet under the rules of RFC 791 and its successors.

The address 202.51.84.45 is a typical IPv4 address — four decimal numbers, each in the range 0–255, separated by dots. The same address in binary is 11001010.00110011.01010100.00101101, and in hex is CA.33.54.2D. Thirty-two bits is the limit: $2^{32}$ ≈ 4.29 billion addresses.

An IPv4 address has two logical parts — a network portion that identifies which network the interface belongs to, and a host portion that identifies the interface within that network. The split between the two parts is determined by the subnet mask or, equivalently, the prefix length in CIDR notation. The address 202.51.84.45/24 means the first 24 bits (202.51.84) are the network portion and the last 8 bits (.45) are the host portion. The interface is on the 202.51.84.0/24 network, which has $2^8 - 2 = 254$ usable host addresses (the all-zeros and all-ones host portions are reserved for the network address and the broadcast address).

Classful addressing (historical)

Before 1993, IPv4 used classful addressing. The class of an address was determined by its leading bits:

Class	Leading bits	First octet range	Default mask	Network bits	Host bits	Typical use
A	0	0–127	255.0.0.0 (/8)	8	24	Very large networks
B	10	128–191	255.255.0.0 (/16)	16	16	Large networks
C	110	192–223	255.255.255.0 (/24)	24	8	Small networks
D	1110	224–239	—	—	—	Multicast
E	1111	240–255	—	—	—	Experimental, reserved

Classful addressing was a poor fit for most real networks. A company that needed 500 addresses was too large for a single Class C (254 hosts) but wasted most of a Class B (65,534 hosts). By the early 1990s the Internet was hitting two crises at once — the IP address pool was being consumed faster than expected, and the global routing table was growing alarmingly because every Class C network needed its own routing entry.

Classless Inter-Domain Routing (CIDR) and VLSM

CIDR, standardised in RFC 1519 (1993) and now in RFC 4632 (2006), removed the rigid class boundaries. The prefix length can now be any value from /0 to /32, allowing networks to be sized to actual need.

CIDR (Classless Inter-Domain Routing) is the address allocation and routing scheme that replaced classful addressing in 1993, expressing the network portion of an IPv4 address as a variable-length prefix written as a slash followed by the number of network bits.

CIDR allows two things that classful addressing did not. First, address aggregation — an ISP holding the block 202.51.0.0/16 advertises a single routing table entry covering all 65,536 addresses, rather than 256 separate /24 entries. This kept the global BGP routing table from exploding. Second, Variable Length Subnet Masking (VLSM) — different subnets inside an organisation can have different sizes. A point-to-point WAN link uses a /30 (4 addresses, 2 usable), a small office uses a /28 (16 addresses, 14 usable), a large server VLAN uses a /23 (512 addresses, 510 usable).

A worked subnetting example. The block 192.168.10.0/24 is to be divided into four equal subnets:

• Number of subnets needed: 4. To get 4 subnets, borrow 2 bits from the host portion: $2^2 = 4$.
• New prefix length: /24 + 2 = /26.
• Each subnet has $2^{32-26} = 64$ addresses, of which 62 are usable.

The four subnets are:

Subnet	Network	Usable range	Broadcast
1	192.168.10.0/26	.1 – .62	.63
2	192.168.10.64/26	.65 – .126	.127
3	192.168.10.128/26	.129 – .190	.191
4	192.168.10.192/26	.193 – .254	.255

Private addressing and NAT

RFC 1918 (1996) reserved three IPv4 ranges for private use — addresses that are not routable on the public Internet:

• 10.0.0.0/8 — about 16.7 million addresses
• 172.16.0.0/12 — about 1 million addresses
• 192.168.0.0/16 — 65,536 addresses

Combined with Network Address Translation (NAT), private addresses allow many devices behind a NAT gateway to share a single public IPv4 address. Every home router in Nepal does this: the laptop, phones, smart TV, and Internet-connected fridge on the home Wi-Fi all have addresses in 192.168.1.0/24, and the home router rewrites the source address of each outgoing packet to the single public IPv4 address assigned by the ISP. Reply packets are rewritten back to the original private address using a state table that the NAT box maintains.

NAT bought IPv4 a decade or more of additional life. It also became one of the central issues IPv6 was designed to remove.

Why IPv4 ran out, and what "ran out" really means

The IPv4 free pool exhausted in stages. IANA — which holds the master pool — assigned the last five /8 blocks (one to each RIR) on 3 February 2011, marking the end of the IANA pool. APNIC, the registry for Asia-Pacific, ran out of its general pool on 15 April 2011 and has since operated under a strict policy of allocating at most a /22 (1,024 addresses) to each new member, drawn from a small reserve. RIPE NCC exhausted its general pool in September 2012, LACNIC in June 2014, ARIN in September 2015. AFRINIC was the last, in April 2020.

What "ran out" does not mean is that no IPv4 addresses remain anywhere. ISPs and large organisations still hold large blocks. A secondary market in IPv4 addresses now exists, with /24 blocks trading for $40–$60 per address as of 2025–26. A new ISP in Nepal that wants its own public IPv4 space either buys it on this market or relies entirely on Carrier-Grade NAT.

Other issues with legacy IPv4

Address exhaustion is the most visible problem, but several others matter:

No native security. The IPv4 specification has no built-in authentication or encryption. Any host can spoof the source address of a packet it sends. IPsec exists, but it was added later and is rarely used end-to-end.

Broadcast burden. IPv4 uses broadcasts for ARP, DHCP, and several other functions. Every device on a LAN must process every broadcast, even if the broadcast is irrelevant to it. On a large flat LAN, broadcast traffic consumes CPU and battery on every connected device.

Header complexity. The IPv4 header is variable in length (20 to 60 bytes) because of options. Every router must check whether options are present and process them. The header checksum must be recomputed at every router because the TTL field decrements at every hop. This adds processing overhead.

Router-performed fragmentation. If an IPv4 packet is too large for the next link, the router fragments it. Fragmentation is expensive, fragile (fragments can be lost independently of the whole), and a security hazard (fragment-overlap attacks).

Limited multicast support. IPv4 multicast exists but is rarely deployed across the public Internet because of complex inter-domain multicast routing.

NAT externalities. While NAT extends IPv4 life, it breaks end-to-end addressing, complicates protocols that carry IP addresses inside their payload (FTP, SIP, certain online games), and undermines IPsec in transport mode. Every large operator in Nepal — WorldLink, Subisu, Vianet, NTC FTTH — operates Carrier-Grade NAT for residential subscribers, which means a Nepali user's true public IP is shared across hundreds of households. This affects abuse tracking (a law-enforcement request to identify the user behind a public IP returns dozens of households) and breaks any application that needs an inbound connection.

These structural problems, not just address exhaustion, are why IPv6 exists.

2.2 Introduction to IPv6 networking

Origin and standardisation

By 1992 the IETF was certain IPv4 would run out within the next 15 years. The "IP Next Generation" (IPng) effort considered several proposals and selected what became IPv6 in 1995. RFC 1883 was the first draft of IPv6 in December 1995. RFC 2460 became the long-standing IPv6 specification in 1998. RFC 8200 (July 2017) is the current Internet Standard.

The IPv6 design goal was not just more addresses. It was a chance to fix the structural problems of IPv4 in one coordinated revision. Anything that did not need to be in the protocol's mandatory mechanism was moved out — fragmentation, options, error detection by the IP layer itself. Anything that needed to be in but was missing from IPv4 was added — link-local addressing as a first-class citizen, address auto-configuration, mandatory multicast scoping, easier extensibility.

The IPv6 address

An IPv6 address is a 128-bit number, written as eight groups of four hexadecimal digits separated by colons, that uniquely identifies a network interface on the IPv6 Internet under RFC 8200.

A full IPv6 address looks like:

2001:0db8:85a3:0000:0000:8a2e:0370:7334

The address space is $2^{128} ≈ 3.4 \times 10^{38}$. The number is large enough to be effectively unbounded for human-scale networking. Every square millimetre of the Earth's surface could be allocated about 660 trillion addresses without exhausting the space.

Two notation rules compress long addresses:

Rule 1 — Leading zeros within a group may be omitted. The address above becomes:

2001:db8:85a3:0:0:8a2e:370:7334

Rule 2 — A single run of consecutive all-zero groups may be replaced by ::. Only one such replacement is allowed in a single address (otherwise the address would be ambiguous):

2001:db8:85a3::8a2e:370:7334

A few more examples:

Full form	Compressed form
2001:0db8:0000:0000:0000:0000:0000:0001	2001:db8::1
0000:0000:0000:0000:0000:0000:0000:0001	::1 (loopback)
0000:0000:0000:0000:0000:0000:0000:0000	:: (unspecified)
fe80:0000:0000:0000:0202:b3ff:fe1e:8329	fe80::202:b3ff:fe1e:8329 (link-local)

An IPv6 address with a port is written with the address in square brackets to disambiguate the colons:

[2001:db8::1]:443

Prefix notation

The CIDR prefix notation carries over. 2001:db8:85a3::/48 describes the prefix where the first 48 bits are 2001:0db8:85a3 and the remaining 80 bits are unspecified. The standard allocation hierarchy is roughly:

• IANA holds the IPv6 unicast space 2000::/3.
• IANA assigns /12s to the RIRs.
• An RIR (APNIC for Nepal) assigns blocks ranging from /29 to /32 to large LIRs and ISPs.
• An ISP commonly receives /32 and assigns /48 to each enterprise customer and /56 or /64 to each residential customer.
• Within a customer, individual LAN segments are typically /64.

This is a far more generous hierarchy than IPv4. A residential Nepali household on a WorldLink or Subisu IPv6-enabled connection receives a /56, which contains 256 /64 LAN segments — enough for the main LAN, a guest network, a separate IoT VLAN, and many more without ever revisiting the question of subnet sizing.

Current adoption position

IPv6 adoption is uneven globally. As of April 2026, Google's measurement of users reaching its services over native IPv6 crossed 50% on 28 March 2026. APNIC Labs measures global IPv6 capability at about 42% at the same time. The difference reflects measurement methodology — APNIC samples end-user capability, while Google measures actual connections.

Nepal's position has changed sharply in a short time. APNIC's measurement of Nepal's IPv6 capability was about 3% in early 2020 and 12.7% by January 2021. By March 2025 Nepal crossed 50% IPv6 capability and became the 19th country worldwide to do so. WorldLink, Nepal's largest ISP by subscribers, runs at about 51% IPv6 on its customer base. Ncell measures around 58% IPv6 preference among its mobile subscribers. Nepal Telecom remains at around 27% — the largest gap, since NTC has the widest national reach. The Nepal Network Operators' Group (npNOG) has run training programmes since the mid-2010s, and APNIC ran a free IPv6 certification bootcamp in Nepal in 2025 to accelerate the transition.

The reason for the rapid jump is one of policy and necessity. APNIC's IPv4 rationing left new ISPs with no realistic path other than IPv6-by-default for new customer deployments, and the regulator (NTA) and the National Information Technology Centre have applied steady pressure for government services to enable IPv6 access.

2.3 Features of IPv6

The features below are the working benefits of IPv6 over IPv4. Each is a deliberate design choice made during the IPng work in the mid-1990s, and each addresses one of the problems listed in Section 2.1.

Vast address space

The shift from 32 bits to 128 bits is the headline feature. $2^{128}$ addresses ends the practical conversation about address scarcity. The change also enables the design choices that follow — auto-configuration, hierarchical allocation, easy renumbering — because there is no longer a reason to allocate parsimoniously.

Simplified, fixed-size header

The IPv6 main header is exactly 40 bytes. It always has the same eight fields in the same positions. A router can parse the header at line rate without conditional logic for variable-length options. Section 2.6 compares the headers in detail.

No broadcasts

IPv6 has no broadcast address. Functions that IPv4 implemented as broadcasts — ARP, DHCP discovery, routing protocol announcements on a LAN — use multicast addresses instead. A node only processes the multicast groups it has joined, which saves CPU and battery on every other device on the link. This is especially valuable on a wireless LAN, where every broadcast is transmitted at the slowest supported rate to reach every potential listener.

Stateless Address Auto-Configuration (SLAAC)

A node can derive a working global IPv6 address by itself, with no DHCP server, using the prefix advertised by the local router and an interface identifier it generates locally. This is covered in Section 2.5.

Built-in support for IPsec

IPsec was originally specified as mandatory for any IPv6 implementation in RFC 2460. RFC 6434 (2011) relaxed this to recommended (SHOULD), reflecting the practical reality that not every device — a battery-constrained sensor, for instance — can afford the IPsec processing. The pre-allocated extension-header positions for AH and ESP mean IPv6 nodes can apply IPsec without the protocol awkwardness IPv4 required.

Better support for mobility

Mobile IPv6 (RFC 6275) lets a mobile node retain its home address while moving across networks. The mobile node tells its home agent its current care-of address; the home agent tunnels traffic to it. The mechanism is cleaner than Mobile IPv4 because IPv6's vast address space allows every mobile node a stable home address, and because IPv6 routing headers handle the indirection naturally. In practice 5G mobile networks use their own mobility primitives rather than Mobile IPv6, but the IP-layer mobility primitives exist for systems that need them.

Anycast as a first-class addressing mode

An anycast address is held by multiple nodes, and a packet sent to it reaches the topologically nearest one. IPv6 makes anycast a defined addressing mode equal to unicast and multicast. The DNS root servers, public DNS resolvers like 1.1.1.1, and large content-delivery networks all rely on anycast — for IPv4 too, but it required carrier cooperation rather than protocol support.

Improved Quality of Service through the Flow Label

The 20-bit Flow Label field in the IPv6 header lets a source mark all packets of a single application flow (a single voice call, a single video stream) with the same value. Routers can then make per-flow decisions — pinning the flow to a single path through an equal-cost group, applying a particular QoS treatment — without needing to look inside the transport-layer header. IPv4 has no equivalent.

Easier renumbering

Renumbering an IPv4 network — changing its prefix because the upstream ISP changed, for instance — is painful: DHCP scopes, firewall rules, static configurations, application server hardcoded addresses all need updating. IPv6 was designed to make renumbering routine: nodes get their prefix dynamically from router advertisements, ULAs cover internal stable references, and applications are expected to use DNS rather than literal addresses. Renumbering remains operationally tricky in practice, but the protocol does not stand in the way.

No header checksum

IPv6 has no header checksum. The Ethernet frame at Layer 2 and the transport-layer checksum (TCP, UDP) at Layer 4 both detect corruption. Removing the IP-layer checksum means routers do not recompute a checksum on every hop, saving processing time.

Multicast scoping in the address

IPv6 multicast addresses carry their scope inside the address itself — link-local, site-local, organisation-local, global. A multicast packet cannot accidentally escape the intended scope because the forwarding rules read the scope directly from the destination address.

2.4 IPv6 addressing types: unicast, anycast, and multicast

IPv6 has three address categories. Broadcast does not exist in IPv6 — any function that needed broadcast in IPv4 uses multicast in IPv6.

Unicast

A unicast address identifies a single network interface, and a packet sent to a unicast address is delivered to that one interface.

Several kinds of unicast address exist, distinguished by their leading bits:

Global unicast. The IPv6 equivalent of a public IPv4 address. Currently allocated from 2000::/3. The first 48 bits typically come from the ISP allocation, the next 16 bits identify the subnet inside the customer site, and the last 64 bits identify the interface. A subscriber prefix on a WorldLink IPv6 connection might be 2400:1a00:bf00::/48.

Link-local. A link-local address is a unicast address in the range fe80::/10 that is valid only on a single link and is never forwarded by a router. Every IPv6 interface has a link-local address, generated automatically when the interface comes up. Link-local addresses are used for neighbour discovery, router discovery, and routing protocol messages between neighbours. A typical link-local address looks like fe80::1a2b:3cff:fe4d:5e6f. Because the same link-local address can be in use on different interfaces, link-local communication uses a zone identifier appended with % — fe80::1%eth0 means "fe80::1, reached through interface eth0."

Unique Local Address (ULA). Specified by RFC 4193, ULAs occupy fc00::/7 (in practice fd00::/8 for randomly generated prefixes). They are the IPv6 equivalent of RFC 1918 private addresses — usable inside an organisation, not routable on the public Internet. A typical ULA prefix is fd6f:42a1:b8c7::/48 where the bits after fd are chosen randomly to avoid collisions when networks merge.

Loopback. The single address ::1/128 is the loopback, used by a host to talk to itself. The equivalent of 127.0.0.1 in IPv4.

Unspecified. The single address ::/128 (all zeros) represents "no address" and is used, for instance, as the source address in DAD (Duplicate Address Detection) probes before the interface has confirmed its address.

IPv4-mapped IPv6. Addresses of the form ::ffff:a.b.c.d represent an IPv4 address inside an IPv6 framework. Used by dual-stack sockets — a Linux server listening on [::]:80 accepts both IPv6 connections natively and IPv4 connections that arrive translated into ::ffff: form.

IPv4-compatible IPv6. Of the form ::a.b.c.d. Used in early transition mechanisms; now deprecated.

Anycast

An anycast address is a unicast-format address assigned to multiple network interfaces, and a packet sent to it is delivered to the topologically nearest one according to the routing protocol's distance metric.

An anycast address is syntactically indistinguishable from a unicast address. The difference is administrative — the network operator chooses to advertise the same prefix from multiple locations. The routing protocol carries each advertisement, and a packet follows the path the router decides is shortest.

Use cases include:

• DNS resolution. A public DNS resolver like Cloudflare's 2606:4700:4700::1111 is anycast — the actual server reached by a Nepali user is in Mumbai or Singapore, while a user in Frankfurt reaches a different physical server with the same address.
• Content delivery. Akamai, Cloudflare, and Google all use anycast IPv6 to direct users to nearby content nodes.
• Subnet-router anycast. RFC 4291 reserves the lowest interface ID within a subnet (the all-zeros interface ID, e.g., 2001:db8:1234:5678::) as an anycast address shared by all routers on the link.

Multicast

An IPv6 multicast address identifies a group of interfaces, and a packet sent to it is delivered to every interface that has joined the group.

Every multicast address begins with ff (eight leading 1 bits), which makes the entire ff00::/8 range multicast. The format of the rest of the address carries the scope and the group identifier:

| 8 bits | 4 bits | 4 bits |       112 bits        |
| 11111111 | flgs  | scope  |       group ID        |

The scope field limits how far the multicast packet may travel:

Scope	Value	Range
Interface-local	1	Same node only
Link-local	2	Same physical link only
Admin-local	4	Administratively defined region
Site-local	5	One site
Organization-local	8	One organisation
Global	E	Entire IPv6 Internet

A router refuses to forward a multicast packet outside its scope. This is a meaningful improvement over IPv4 multicast, where the TTL field is used as a coarse scope proxy.

Several well-known multicast addresses are reserved:

Address	Meaning
ff02::1	All nodes on the link
ff02::2	All routers on the link
ff02::5	OSPFv3 all routers
ff02::6	OSPFv3 DR routers
ff02::9	RIPng routers
ff02::a	EIGRP routers
ff02::d	PIM routers
ff02::16	MLDv2-capable routers
ff02::1:ff00:0/104	Solicited-node multicast prefix

The solicited-node multicast address is worth singling out. Every IPv6 interface automatically joins a multicast group derived from its own unicast address — specifically, ff02::1:ff concatenated with the last 24 bits of its unicast address. When another node needs to resolve the link-layer address for a unicast IPv6 address, it sends a Neighbour Solicitation to that target's solicited-node multicast address instead of broadcasting. Only the few nodes whose last 24 address bits happen to collide need to wake up and check the message; the rest are not bothered. This replaces ARP and removes the broadcast burden ARP placed on every node.

2.5 IPv6 address auto-configuration and SLAAC

One of IPv6's defining features is that a host can come up on a new network and acquire a working global address without administrative configuration. Two mechanisms exist — SLAAC (Stateless Address Autoconfiguration) and DHCPv6 — and they are commonly used together.

SLAAC mechanism

SLAAC (Stateless Address Autoconfiguration) is the mechanism defined in RFC 4862 by which an IPv6 host derives a global unicast address by combining the network prefix advertised by the local router with an interface identifier it generates itself, requiring no server-side state.

The process when an interface comes up:

1. Generate a link-local address. The interface picks an interface identifier — historically via modified EUI-64 from the MAC address, now usually a random 64-bit value (RFC 7217 stable privacy addresses). It prepends fe80::/64. The candidate link-local address is, say, fe80::a2:c4ff:fe5d:1a90.

2. Run Duplicate Address Detection (DAD). Before claiming the candidate address, the node sends a Neighbour Solicitation to the candidate's solicited-node multicast address with source address :: (unspecified) and target address the candidate. If any other node already holds the candidate address, it responds with a Neighbour Advertisement and the candidate is abandoned. If no response arrives within a short time, the candidate is claimed.

3. Send a Router Solicitation (RS). The node sends an ICMPv6 Router Solicitation (type 133) to ff02::2 (all routers on the link).

4. Receive a Router Advertisement (RA). Each router on the link periodically sends RAs (type 134) anyway, and additionally responds to RS messages. The RA contains the network prefix (typically a /64), the default gateway address, MTU, and various flags. Two key flags:

   • M (Managed) flag — if set, the host should use stateful DHCPv6 to obtain its address.
   • A (Autonomous) flag — if set, the host can use SLAAC to form an address from the announced prefix.

5. Form the global address. Combine the prefix from the RA with the interface identifier from step 1. If the prefix is 2400:1a00:bf00:42::/64 and the IID is a2:c4ff:fe5d:1a90, the host's global address is 2400:1a00:bf00:42:a2:c4ff:fe5d:1a90.

6. Run DAD on the global address. Same procedure as step 2, now on the global address.

7. Configure default route and DNS. The default gateway is the source of the RA. DNS server addresses come either via the RA's RDNSS option (RFC 8106) or via stateless DHCPv6.

Interface identifier generation

Two methods are used for the 64-bit interface identifier.

Modified EUI-64. Take the 48-bit MAC address, insert ff:fe in the middle, flip the universal/local bit (bit 6 of the first octet). MAC 00:1B:63:84:45:E6 becomes IID 021b:63ff:fe84:45e6. This was the original method. It has a serious privacy problem: the MAC address travels with the device. Anyone watching network traffic across multiple networks can correlate the same device at different locations by its IID. A laptop's MAC stays the same in a Kathmandu café and at a Bharatpur hotel, so the laptop's IPv6 address has the same lower 64 bits at both, and an observer can link the two sessions.

RFC 7217 stable privacy addresses (current default). The IID is generated by hashing the prefix, interface, and a host secret. The IID is stable for a given network (so a server reaches it reliably) but different across networks (so observers cannot correlate). This is the current default on modern Linux, Windows, macOS, iOS, and Android.

RFC 8981 temporary addresses. In addition to the stable IID, the node generates short-lived random IIDs to use as the source address for outgoing connections. A temporary address typically lives one day. Outbound web browsing uses the temporary address; inbound connections (servers, peer-to-peer) use the stable address. This prevents tracking of outgoing connections across time.

SLAAC vs DHCPv6

Both can coexist. The RA flags tell the host which to use.

Scenario	RA flags	Address source	DNS, NTP, etc.
Pure SLAAC	M=0, A=1	SLAAC from prefix	From RA options (RDNSS)
Stateless DHCPv6	M=0, O=1, A=1	SLAAC from prefix	From DHCPv6 (no address assignment)
Stateful DHCPv6	M=1, A=0	DHCPv6 server	From DHCPv6
Both	M=1, A=1	Both (one SLAAC + one DHCPv6)	From DHCPv6

In residential ISP deployments in Nepal — WorldLink, Subisu, Vianet — the standard is DHCPv6 prefix delegation between ISP and home router, and SLAAC on the LAN between the home router and connected devices. The ISP delegates a /56 to the home router, which then advertises /64s on each of its LAN segments via RA.

A worked SLAAC example

A new laptop joins the Wi-Fi of a small office in Lalitpur. The office router is 2400:1a00:bf00:42::1, advertising the prefix 2400:1a00:bf00:42::/64.

1. Laptop's interface comes up. It picks a random IID 1f:9c2b:8e4a:7d15.
2. Candidate link-local: fe80::1f:9c2b:8e4a:7d15. DAD passes.
3. Laptop sends RS to ff02::2.
4. Router replies with RA containing prefix 2400:1a00:bf00:42::/64, lifetime 86400 s, A flag set.
5. Laptop forms global: 2400:1a00:bf00:42:1f:9c2b:8e4a:7d15.
6. DAD on the global passes.
7. Laptop installs default route via the router's link-local address (the RA source).

Throughout this sequence, no central server was contacted. The laptop now has connectivity.

2.6 IPv4 and IPv6 header comparison

The IPv6 header is one of the cleanest demonstrations of what the IPng designers fixed about IPv4. Everything optional was moved out, everything redundant was removed, and the remaining fields were ordered for fast hardware parsing.

The IPv4 header

The IPv4 header is between 20 and 60 bytes long, depending on whether options are present. The 20-byte base form looks like:

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version|  IHL  |    DSCP   |ECN|         Total Length          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         Identification        |Flags|     Fragment Offset     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     TTL       |   Protocol    |        Header Checksum        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        Source Address                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                     Destination Address                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    Options + Padding (if IHL > 5)             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Twelve fields:

Field	Bits	Purpose
Version	4	Always 4 for IPv4
IHL (Internet Header Length)	4	Header length in 32-bit words (5 to 15)
DSCP	6	Differentiated Services class
ECN	2	Explicit Congestion Notification
Total Length	16	Header + data in bytes (max 65,535)
Identification	16	Used during fragmentation
Flags	3	DF (Don't Fragment), MF (More Fragments), reserved
Fragment Offset	13	Position of this fragment in original packet
TTL	8	Hop count; decremented at every router
Protocol	8	Next-layer protocol (TCP=6, UDP=17, ICMP=1)
Header Checksum	16	Computed over the IPv4 header only
Source Address	32	Sender's IPv4
Destination Address	32	Recipient's IPv4
Options	0–320	Optional extensions

The IPv6 header

The IPv6 header is exactly 40 bytes. Always. Eight fields:

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Traffic Class |             Flow Label                |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         Payload Length        |  Next Header  |   Hop Limit   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                                                               +
|                                                               |
+                        Source Address                         +
|                          (128 bits)                           |
+                                                               +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                                                               +
|                                                               |
+                     Destination Address                       +
|                          (128 bits)                           |
+                                                               +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Field	Bits	Purpose
Version	4	Always 6 for IPv6
Traffic Class	8	DSCP + ECN (same role as IPv4 DSCP+ECN)
Flow Label	20	Identifies a flow for per-flow routing/QoS
Payload Length	16	Length of everything after this header, in bytes
Next Header	8	Either an extension header type or a transport protocol number
Hop Limit	8	Decremented at every router (replaces TTL)
Source Address	128	Sender's IPv6
Destination Address	128	Recipient's IPv6

Field-by-field comparison

Function	IPv4	IPv6	Comment
Header size	20–60 bytes, variable	40 bytes, fixed	IPv6 is faster to parse
Address size	32 bits	128 bits	$4 \times$ larger
Header length field	IHL needed	Not needed	IPv6 header has fixed size
Header checksum	Yes, recomputed at every hop	Removed	Saves router CPU
Fragmentation	Done by router or sender	Done only by sender	Routers never fragment in IPv6
Identification / Flags / Fragment Offset	In the main header	In a Fragment extension header (only when used)	Out of fast path
Options	In the main header (variable)	In extension headers (chained after main header)	Out of fast path
TTL → Hop Limit	TTL (semantically same)	Hop Limit (better name)	Same function, clearer name
Protocol → Next Header	Protocol field points to next-layer protocol	Next Header points to next extension header OR next-layer protocol	More flexible
Type of Service → Traffic Class	8-bit ToS, later split into DSCP+ECN	8-bit Traffic Class, same DSCP+ECN	Same semantics
Flow Label	Not present	20 bits	New, enables per-flow handling

Key design improvements

Router-side fragmentation is gone. In IPv4, if a packet was too large for the next link's MTU, the router fragmented it. This required the router to allocate buffers, copy header information across multiple fragments, and add per-fragment overhead. In IPv6, if a packet is too large, the router drops it and sends an ICMPv6 Packet Too Big message back to the source. The source learns the path MTU and resizes its packets. This makes routers simpler and faster, but it requires that ICMPv6 messages flow back to the source — administrators who blindly block all ICMP break IPv6 path-MTU discovery, leading to silent connection hangs.

No checksum. The IPv4 header checksum had to be recomputed at every hop because the TTL changes at every hop. Removing it saves router cycles. Data integrity now relies on Layer 2 frame checksums (Ethernet FCS) and Layer 4 checksums (UDP and TCP). In IPv6, the UDP checksum is also mandatory — in IPv4, it was optional.

Options moved out. Putting options in extension headers (Section 2.7) means the router's fast path can be optimised for the common case (no extension headers) and only the slow path handles the rare case.

Bigger addresses, fewer header changes. The address fields are four times larger, but the rest of the header has fewer fields than IPv4. The total header size is only twice as large despite the address fields being four times as large.

2.7 IPv6 extension headers

Anything optional that would have been an IPv4 option is now in an extension header. Extension headers chain after the main IPv6 header in a linked list. The main header's Next Header field tells what follows; each extension header has its own Next Header field telling what follows it; the last extension header's Next Header field gives the transport-layer protocol number (TCP = 6, UDP = 17, ICMPv6 = 58).

A packet with two extension headers looks like:

+----------------------+----------------------+----------------------+----------------+
| IPv6 Main Header     | Routing Header       | Fragment Header      | TCP Segment    |
| Next Header = 43     | Next Header = 44     | Next Header = 6      |                |
+----------------------+----------------------+----------------------+----------------+

The six extension headers

RFC 8200 defines six extension headers and recommends a specific order when more than one is present:

1. Hop-by-Hop Options Header (Next Header = 0). Examined by every router on the path. Used for jumbo packets (greater than 65,535 bytes) and Router Alert. Performance-sensitive — placing options here forces every router to look beyond the main header.

2. Destination Options Header (Next Header = 60). Examined only by the packets destination(s). Used for mobile IPv6 home address option and for tunnel-related options. Two instances can appear in one packet — one for intermediate destinations (before a Routing header) and one for the final destination.

3. Routing Header (Next Header = 43). Lists a sequence of intermediate nodes the packet must visit on the way to the final destination. The original Type 0 routing header (RH0) had the same security flaws as IPv4 source routing — an attacker could ping-pong traffic between two nodes to amplify a DoS attack. RH0 was deprecated by RFC 5095 (2007). The currently usable forms are Type 2 (used by Mobile IPv6) and Type 4 (the Segment Routing Header (SRH) used in SRv6).

4. Fragment Header (Next Header = 44). Carries the Identification, Fragment Offset, and More Fragments fields needed to reassemble a fragmented packet. Only the sender can fragment in IPv6, so this header is added by the sender and consumed by the final destination's reassembly engine.

5. Authentication Header (AH) (Next Header = 51). Provides connectionless integrity and data origin authentication, but no confidentiality. Part of IPsec. The AH covers the IP header itself (except mutable fields like Hop Limit) and the entire payload. Section 3.5 covers IPsec in detail.

6. Encapsulating Security Payload (ESP) (Next Header = 50). Provides confidentiality (encryption) and optionally integrity and authentication. Also part of IPsec. ESP does not protect the outer IP header, but it can protect everything after it.

Recommended order

When multiple extension headers appear in one packet, RFC 8200 recommends the order:

1. IPv6 main header
2. Hop-by-Hop Options
3. Destination Options (for intermediate destinations)
4. Routing
5. Fragment
6. Authentication
7. Encapsulating Security Payload
8. Destination Options (for final destination)
9. Upper-layer header (TCP, UDP, ICMPv6, etc.)

The order matters because of who processes each header — routers along the path, the intermediate destination, then the final destination — and how IPsec covers what comes after it.

Practical problems with extension headers

Extension headers were a clean idea on paper. In practice they have caused trouble.

Middlebox handling is inconsistent. Many firewalls, load balancers, and DDoS-scrubbing appliances cannot reach the transport-layer port number when extension headers are present. The path-MTU discovery may break, the firewall may pass the packet without filtering, or it may simply drop the packet. A 2016 measurement study (RFC 7872) found that 10–30% of paths drop packets carrying any non-fragmentation extension header.

Hop-by-Hop is the worst offender. RFC 7872 reported that around 40–50% of paths dropped packets with a Hop-by-Hop Options header. The reason is that processing Hop-by-Hop options is on the router's slow path, and operators commonly configure their routers to drop packets that would push them onto the slow path. RFC 8200 itself acknowledges this and softens the requirement — routers MAY skip Hop-by-Hop options unless explicitly configured to process them.

Extension header chains can hide ports. A long extension-header chain pushes the transport header out beyond what a stateless firewall can inspect. Some implementations refuse to process packets where the upper-layer header is not within the first packet of a fragment, which has caused interoperability problems with IPsec.

Practical advice: in production deployments, avoid extension headers other than Fragment, AH, and ESP unless the design specifically needs them, and test middleboxes for compatibility.

2.8 NDP and ICMPv6

ICMPv6

ICMPv6 (Internet Control Message Protocol version 6) is the diagnostic, error-reporting, and signalling protocol for IPv6 defined in RFC 4443, used for the same purposes as ICMP in IPv4 plus the address-resolution and neighbour-management functions that ARP performed in IPv4.

ICMPv6 has Next Header value 58. Messages fall into two broad categories — error messages (types 0–127) and informational messages (types 128–255).

Error message types (selected):

Type	Name	When sent
1	Destination Unreachable	No route, port unreachable, etc.
2	Packet Too Big	Next link's MTU is smaller than packet
3	Time Exceeded	Hop Limit reached zero or fragment reassembly timed out
4	Parameter Problem	Bad field in header

Informational message types (selected):

Type	Name	Purpose
128	Echo Request	The IPv6 ping
129	Echo Reply	Response to ping
130	Multicast Listener Query	MLD — multicast group management
131	Multicast Listener Report	MLD
132	Multicast Listener Done	MLD
133	Router Solicitation	NDP — ask routers to send RAs
134	Router Advertisement	NDP — announce router presence, prefix
135	Neighbour Solicitation	NDP — ask for link-layer address, DAD
136	Neighbour Advertisement	NDP — respond with link-layer address
137	Redirect	NDP — tell host of a better next hop

ICMPv6 is fundamental to IPv6 in a way ICMPv4 never was to IPv4. Blocking ICMPv6 at a firewall breaks IPv6. The minimum messages that must be allowed are Packet Too Big (for path-MTU discovery), the NDP messages (for basic address resolution), and Destination Unreachable. RFC 4890 gives detailed guidance on which ICMPv6 messages to permit at a firewall.

Neighbour Discovery Protocol (NDP)

NDP (Neighbour Discovery Protocol) is the ICMPv6-based protocol defined in RFC 4861 that performs link-local discovery, address resolution, router discovery, prefix discovery, parameter discovery, address autoconfiguration support, neighbour reachability tracking, and redirection on an IPv6 link.

NDP replaces what was scattered across ARP, ICMP Router Discovery, and ICMP Redirect in IPv4, plus adds several new functions. The five message types:

Router Solicitation (RS, type 133). Sent by a host when its interface comes up, to prompt routers on the link to send Router Advertisements immediately rather than waiting for the next scheduled one. Destination is ff02::2 (all routers on the link).

Router Advertisement (RA, type 134). Sent periodically by every router on the link, and additionally in response to RS messages. Carries:

• The router's link-layer address (so hosts know the gateway's MAC)
• One or more Prefix Information Options advertising prefixes for SLAAC
• The current hop limit hosts should use
• MTU for the link
• The M flag (use DHCPv6 for address) and O flag (use DHCPv6 for other configuration)
• A flag indicating whether the prefix may be used for SLAAC
• A router lifetime (zero means the router is not a default router)

Neighbour Solicitation (NS, type 135). Sent to ask "what is the link-layer address of the host holding this IPv6 address?" Destination is the solicited-node multicast address of the target. Also used for Duplicate Address Detection — the prober sends an NS with the candidate address as the target, source ::.

Neighbour Advertisement (NA, type 136). Reply to an NS. Contains the link-layer address of the responder. Can also be sent unsolicited when a node's link-layer address changes.

Redirect (type 137). Sent by a router to inform a host that a better first hop exists for a particular destination — typically used when two routers share a link and the sending host is using the wrong one.

NDP functions in detail

Address resolution. Replaces ARP. When host A needs the link-layer address corresponding to IPv6 address 2400:1a00::5, it sends an NS to the solicited-node multicast ff02::1:ff00:5 containing the target 2400:1a00::5. Only nodes whose last 24 address bits match 00:00:05 process the message. The owner of the target address replies with an NA carrying its MAC.

Router discovery. Replaces ICMP Router Discovery. RAs sent to ff02::1 (all nodes on the link) tell hosts which routers exist on the link.

Prefix discovery. RAs advertise the prefix(es) used on the link. Hosts use these for SLAAC and to know which destinations are on-link versus off-link.

Parameter discovery. RAs carry link parameters like MTU and the hop limit hosts should use.

Duplicate Address Detection (DAD). Before claiming a tentative address, a node sends an NS with target = the tentative address, source = ::. If anyone replies, the tentative address is abandoned.

Neighbour Unreachability Detection (NUD). A node keeps a Neighbour Cache for each peer it talks to, with states REACHABLE, STALE, DELAY, PROBE, INCOMPLETE. If a peer stops sending traffic and a unicast probe (a fresh NS) gets no response, the entry transitions to FAILED and the node tries to re-resolve. This catches a peer that has rebooted or moved without telling the network.

Redirect. When a router on the link knows another router has a better path for a particular destination, it sends a Redirect to the sending host. The host adds an entry to its destination cache so future packets to that destination go to the better router.

NDP security issues

NDP has the same trust assumption as ARP in IPv4 — any node on the link can claim to be the owner of any address. Several attacks follow:

• RA spoofing. An attacker on the link sends an RA claiming to be the router. Hosts update their default route to the attacker. This is the IPv6 equivalent of DHCP/ARP-spoofing man-in-the-middle attacks.
• Neighbour cache poisoning. An attacker responds to NS messages with false bindings, redirecting traffic intended for a victim.
• DAD denial-of-service. An attacker responds to every DAD probe claiming to already own the candidate address, preventing new hosts from joining the network.
• Router Lifetime = 0 attack. An attacker sends an RA with router lifetime zero, claiming the legitimate router is no longer a default router. Hosts remove the default route and lose connectivity.

Two mitigations are deployed:

SEND (SEcure Neighbour Discovery, RFC 3971). Uses Cryptographically Generated Addresses (CGAs) and digital signatures to authenticate NDP messages. SEND is technically clean but has very limited deployment — it needs PKI infrastructure for routers and CPU on every host.

RA Guard (RFC 6105). A Layer-2 feature on the switch. The switch is configured to expect RAs only from specified ports (the ones routers connect to) and drops RAs arriving on other ports. Widely deployed on enterprise switches and a practical defence against accidental and malicious rogue RAs. Cisco, Juniper, and Arista all support it. Several Nepali ISPs and enterprise networks now enable RA Guard by default on access ports.

DHCPv6 Guard does the same thing for spoofed DHCPv6 server responses.

Beyond these, the standard mitigation is the same as for IPv4 link-layer attacks: control which devices can connect to the link (802.1X authentication, MAC-based port security), and monitor for unexpected NDP traffic patterns.

A worked NDP exchange

Host A (2400:1a00:bf00:42::100, MAC aa:bb:cc:11:22:33) wants to ping Host B (2400:1a00:bf00:42::200). The two are on the same link. A has never talked to B before.

1. A checks its destination cache. No entry for B.
2. A checks its neighbour cache for B. No entry.
3. A computes B's solicited-node multicast address: ff02::1:ff00:200.
4. A sends an NS to ff02::1:ff00:200 with target 2400:1a00:bf00:42::200 and option "source link-layer address = aa:bb:cc:11:22:33".
5. The Ethernet destination address of the NS is the multicast MAC 33:33:ff:00:02:00 (derived from the solicited-node multicast IPv6 address).
6. Only Host B and any other nodes whose last 24 IPv6 bits collide process the frame. B sees its address is the target.
7. B sends an NA to A's unicast address with target 2400:1a00:bf00:42::200, the Solicited flag set, and option "target link-layer address = dd:ee:ff:44:55:66".
8. A adds B to its neighbour cache: 2400:1a00:bf00:42::200 → dd:ee:ff:44:55:66, state REACHABLE.
9. A sends the original ping (ICMPv6 Echo Request) directly to B's MAC.

This is the same logical flow as IPv4 ARP, but it uses multicast instead of broadcast, runs over the regular ICMPv6 / IPv6 stack instead of a separate ARP protocol, and naturally extends to advanced features like neighbour unreachability detection. It is one of the design victories of IPv6 over IPv4.