Chapter 3 — Security and Routing in IPv6

The first half of this chapter handles security — what the older Internet got wrong, what attacks exist, what defences are used, and how IPsec brings cryptographic protection into the IP layer itself. The second half handles routing — how IPv6 routers learn paths, the differences between IPv4 and IPv6 routing protocols, and how multicast is routed. Security and routing sit together here because IPv6's design touches both: every IPv6 node was expected to implement IPsec, and every IPv6 routing protocol had to be revisited or rebuilt for the new addressing model.

3.1 Security issues with legacy networks

The Internet's protocol foundations were built between roughly 1969 and 1995 by a small community of researchers in government and academic environments. Most of the participants knew each other. The threat model was network failure, not network attack. Security was a separate concern, handled by physical control of access to the network and by trust between the operators. The protocols that survived from that era — TCP, UDP, IP, ARP, DNS, BGP, SMTP, FTP, Telnet — all carry that inheritance.

No native authentication

IPv4 packets carry a source address, but nothing in the protocol verifies it. A node can write any source IP into a packet it sends, and the network will deliver the packet to the destination. The destination has no way to confirm where the packet actually came from. This is IP spoofing, and it underlies a long list of attacks — reflective DDoS, source-routed reconnaissance, certain forms of TCP injection. The BCP 38 (Best Current Practice 38, RFC 2827) defence — ingress filtering at the network edge to drop packets with source addresses that could not legitimately come from that direction — was published in 2000 but remains incompletely deployed across the global Internet. APNIC's Mutually Agreed Norms for Routing Security (MANRS) campaign tracks adherence and reports that as of 2025 fewer than half of operators globally implement BCP 38 effectively.

No native confidentiality

The original Internet protocols sent everything in clear text. Telnet sends every keystroke including passwords. FTP sends credentials and file contents in clear. SMTP carries email body and headers in clear. HTTP sends every request and response in clear. Anyone with access to any link the traffic crosses — an ISP employee, a Wi-Fi sniffer in a café, a compromised router — can read all of it. The shift to encrypted-by-default protocols (HTTPS, SSH replacing Telnet, IMAPS replacing IMAP, SMTP over STARTTLS, DNS-over-HTTPS) has happened gradually since the mid-2000s, but the underlying IPv4 layer still carries no encryption.

ARP spoofing on the LAN

The Address Resolution Protocol has no authentication. Any node on a LAN can claim to be the holder of any IP address by sending an unsolicited ARP reply. An attacker on a coffee-shop Wi-Fi in Thamel can send a forged ARP reply claiming that the IP of the gateway router maps to the attacker's MAC. All other devices on the network then send their gateway-bound traffic to the attacker, who reads or modifies it and forwards it on. This is the foundation of LAN-based man-in-the-middle attacks. The same flaw exists in IPv6's NDP, mitigated as Section 2.8 described.

DNS without authentication

The original DNS specification (RFC 1034/1035) had no integrity mechanism. A resolver that received a reply matching its query ID accepted the reply. Attackers learned to inject forged replies before the legitimate response arrived — cache poisoning. The 2008 Kaminsky attack made this much easier. DNSSEC was added to address the gap, but DNSSEC deployment remains uneven; APNIC measurements report DNSSEC validation by resolvers at around 30-35% globally in 2025–26.

BGP without origin validation

The Border Gateway Protocol — the inter-domain routing protocol that ties the Internet's autonomous systems together — was designed with the assumption that operators do not lie. An autonomous system can announce any prefix to its neighbours, including prefixes it does not own. Mistakes and attacks regularly cause BGP route hijacking — the most famous being the February 2008 incident where Pakistan Telecom's attempt to block YouTube domestically leaked into the global BGP table and took YouTube offline for hours. RPKI (Resource Public Key Infrastructure) provides origin validation, and adoption has reached about 50% of routes globally by 2025, but it does not solve path-validation attacks.

Plaintext management

Network devices were managed over Telnet — credentials in clear, sessions readable to anyone on a transit network. SNMP v1 and v2c send the community string in clear. TFTP has no authentication. Where these protocols still run inside operator networks (and they do, more than they should), they remain attack surface.

NAT externalities

NAT was a survival mechanism for IPv4 scarcity, but it broke parts of the security model. The end-to-end principle was broken — a host no longer had a stable globally visible address. IPsec in transport mode does not survive NAT (the IPsec NAT-Traversal RFC 3947 added UDP encapsulation to work around it). Source-IP-based access logs become ambiguous when a public IP behind CGN represents hundreds of households. Investigations into criminal activity sometimes resolve only to "one of the customers of this Carrier-Grade NAT block," which is law-enforcement's recurring complaint to operators in Nepal and elsewhere.

Unencrypted protocols still in use

Even in 2026, a non-trivial share of Internet traffic remains in clear. Many legacy industrial control systems run Modbus, DNP3, or proprietary protocols with no encryption. Many SCADA systems used by the Nepal Electricity Authority and water utilities communicate in clear over networks that are notionally air-gapped but in practice connected through engineering laptops, modems, or cellular dongles. The IT-OT boundary is one of the standard exposure points for critical infrastructure breaches globally.

3.2 Types of threats and vulnerabilities

A network attack can be classified by what the attacker wants and by how the attack works. Both classifications matter; a clean descriptive answer uses both.

By target: the CIA triad

The CIA triad is the security model that classifies attacks by which of three properties they violate — Confidentiality (information disclosure), Integrity (information modification), or Availability (denial of service).

Confidentiality attacks disclose information the attacker is not authorised to see. Passive eavesdropping on a clear-text protocol, exfiltration of customer data after a breach, side-channel attacks that leak secrets through timing, traffic analysis that infers content from packet sizes and timing — all are confidentiality attacks. The 2020 Foodmandu breach in Nepal that exposed about 50,000 customer records, and the 2020 Vianet breach that exposed about 170,000 subscriber records, are confidentiality attacks.

Integrity attacks modify data in transit or at rest. Man-in-the-middle attacks that alter a message between sender and receiver, DNS cache poisoning that returns a wrong IP for a name, the BGP hijacks that misroute traffic, and the 2017 defacements of dozens of Nepali government websites by the Paradox Cyber Ghost campaign are integrity attacks.

Availability attacks prevent legitimate access to a service. DDoS, ransomware that encrypts production data, fibre cuts (intentional or accidental), exhaustion of a server's connection table. The early 2024 DDoS that took 400+ Nepali government portals — including the Tribhuvan International Airport immigration portal — offline for several days is the canonical recent Nepal availability incident.

A fourth and fifth property are often added: Authenticity (the sender is who they claim to be — overlaps with integrity in classical CIA) and Non-repudiation (the sender cannot later deny having sent the message). Digital signatures provide non-repudiation; a symmetric MAC does not, because both sides hold the key and either could have produced the MAC.

By mode: passive vs active

Passive attacks observe traffic without modifying it. Eavesdropping, traffic analysis, port scanning (the lightest reconnaissance form). Passive attacks are hard to detect because they leave no trace on the network.

Active attacks modify, inject, or block traffic. Spoofing, replay, MITM, DDoS. Active attacks are noisier — they leave traces in logs, in performance metrics, in router counters — but they accomplish more for the attacker.

Common attack classes

Sniffing. Reading traffic on a shared medium. On a wired switched LAN this requires either port mirroring access, a hub (rare in modern networks), or a compromised switch. On a wireless LAN sniffing is much easier — any WPA2-personal network with a known passphrase exposes every connected client's traffic to anyone with the passphrase and a packet capture tool.

Spoofing. Sending packets with a forged source. IP spoofing for DDoS amplification, ARP spoofing for LAN MITM, DNS spoofing for redirection, email spoofing for phishing.

Replay. Capturing a legitimate message and re-sending it later to cause an effect. A captured authentication token re-sent to a server, a captured RFID badge swipe replayed at the door. Defences are nonces, sequence numbers, and timestamps.

Man-in-the-middle (MITM). The attacker sits between two parties, relays their messages, and may read or modify them. Mutual authentication and end-to-end encryption defeat MITM at the protocol level; TLS with certificate pinning defeats it at the application level.

Denial of Service and DDoS. Overwhelming a target with traffic or with resource-exhausting requests. The 2024 attack on the Government Integrated Data Centre that hit 400+ portals is the canonical recent Nepal example. Defences include rate limiting, scrubbing services, anycast distribution (so a single attack hits one node, not the whole service), and CDN absorption.

Session hijacking. Stealing or guessing a session identifier — a cookie, a TCP sequence number, a kerberos ticket — and using it to impersonate the legitimate user. TLS, secure cookie flags, and short session lifetimes are the defences.

Phishing and social engineering. Tricking a human into giving up credentials or running malicious code. The largest category by frequency of incidents in Nepal, by npCERT's data. The NIC Asia Bank SWIFT compromise in October 2017 had social engineering as one of the working hypotheses for initial access.

Injection. SQL injection, command injection, LDAP injection — inserting attacker-controlled content into a query the server then runs. The 2020 Foodmandu breach is widely attributed to web-application input validation failures of this general class.

Malware. Code that runs against the user's intent. Trojans, viruses, worms, ransomware, cryptojackers, banking trojans. The 2025 spread of banking trojans targeting Khalti and eSewa users — disguised as official APK installers shared via Facebook Messenger — is the recent Nepal example.

Insider threats. A legitimate user abusing their access. Some of the largest data losses globally come from insider exfiltration. The reported 2024–25 appearance of NRB internal documents on dark-web markets points to an insider or an insider's compromised account.

IPv6-specific threats

IPv6 adds and removes threats compared with IPv4. The pure replacement of IPv4 by IPv6 does not improve security on its own; it changes the attack surface.

Reconnaissance is harder. A /64 IPv6 subnet has $2^{64}$ addresses. Brute scanning the way nmap scans a /24 is computationally hopeless. This makes random-address reconnaissance impractical but does not eliminate it — attackers shift to DNS enumeration, public key servers, certificate transparency logs, and the predictable IIDs that older SLAAC produced from EUI-64.

Extension headers create evasion possibilities. A firewall that cannot parse long extension-header chains may accidentally pass an attack. Some IDS/IPS sensors handle extension-header chains incompletely. This was a known concern through the 2010s and has been partly resolved by mature inspection engines.

NDP attacks (covered in Section 2.8). Same trust model as ARP, mitigated by RA Guard and DHCPv6 Guard.

Dual-stack complexity. Most networks run IPv4 and IPv6 in parallel. A firewall rule written for IPv4 has no effect on IPv6 traffic. A host listening on both stacks for the same service must be defended on both. The most common operational mistake during IPv6 rollout is leaving the IPv6 stack open while the IPv4 stack is firewalled.

Transition mechanisms. 6to4, Teredo, ISATAP, and similar tunnels were used during early IPv6 transition. Many of these tunnels carried IPv6 traffic across IPv4 infrastructure that the IPv4 firewall could not inspect — effectively a covert channel. Most transition mechanisms are now deprecated or strongly discouraged, in favour of native dual stack.

3.3 Security techniques

The defensive toolkit divides into cryptographic primitives, identity and authentication mechanisms, network-layer controls, and operational practices. This section covers the cryptographic and identity primitives that IPsec rests on; later sections cover the IPsec construction itself.

Symmetric encryption

Symmetric encryption is the class of encryption schemes where the same key is used to encrypt and decrypt, providing confidentiality but requiring that the key be shared in advance between the parties.

The standard algorithms in current use are AES (Advanced Encryption Standard, FIPS 197) with key sizes of 128, 192, or 256 bits, and ChaCha20 in performance-sensitive software contexts where AES hardware acceleration is missing.

Symmetric ciphers are fast — modern CPUs encrypt and decrypt AES at gigabits per second per core thanks to dedicated AES-NI instructions. They are the workhorse for bulk data encryption. The challenge is key distribution: how do two parties agree on the same secret key without an attacker learning it? This is what asymmetric cryptography solves.

Asymmetric (public-key) encryption

Asymmetric encryption is the class of encryption schemes where each party holds a key pair — a public key shared freely and a private key kept secret — such that data encrypted with the public key can only be decrypted by the matching private key.

The standard algorithms are RSA (Rivest-Shamir-Adleman, 2048 or 3072-bit keys for current use, 4096-bit for long-term security), ECC (Elliptic Curve Cryptography, with curves like P-256 or Curve25519 providing comparable security at much smaller key sizes), and EdDSA (a modern elliptic-curve signature scheme).

Asymmetric encryption is much slower than symmetric — about three orders of magnitude. In practice, asymmetric crypto is used to authenticate and to exchange a fresh symmetric key, after which the actual data is encrypted with the symmetric key.

Hashing

A cryptographic hash function is a one-way function that takes an arbitrary-length input and produces a fixed-length output (the hash or digest) such that finding two inputs with the same output, or finding any input matching a given output, is computationally infeasible.

Current standards: SHA-256 and SHA-384 for general use, SHA-3 for new designs, BLAKE2 in performance-sensitive software. Older hashes — MD5 (broken since 2004, full collision attack since 2008) and SHA-1 (broken since 2017) — must not be used for security purposes, though they still appear in legacy protocols and file integrity checks.

Hashes are the building block for integrity checks, password storage (with a salt and many rounds, via PBKDF2, bcrypt, or Argon2), digital signatures (sign the hash, not the message), and HMACs.

Message Authentication Codes (MACs)

A MAC (Message Authentication Code) is a fixed-length value computed from a message and a shared secret key, attached to the message, and verified by the recipient to confirm both that the message has not been altered and that it came from someone holding the same secret key.

The standard construction is HMAC (RFC 2104) — HMAC(K, M) = H((K ⊕ opad) || H((K ⊕ ipad) || M)) where H is a hash function. AES-CMAC and GMAC (used inside AES-GCM) are alternatives.

A MAC provides integrity and authentication, but not non-repudiation: either party with the key could have produced the MAC, so neither can prove to a third party that the other side sent the message.

Digital signatures

A digital signature is a cryptographic value, computed from a message and the signer's private key, that lets any holder of the matching public key verify both the integrity of the message and the identity of the signer, while preventing the signer from later denying having signed it.

A signature is computed by hashing the message and applying the private-key operation to the hash. Verification applies the public-key operation to the signature and compares with a fresh hash of the message.

The current algorithms are RSA-PSS (RSA Probabilistic Signature Scheme), ECDSA (Elliptic Curve Digital Signature Algorithm), and EdDSA. Signatures appear in TLS certificates, software updates, digital documents, blockchain transactions, and DNSSEC records.

Key exchange — Diffie-Hellman

Diffie-Hellman is a key-agreement protocol in which two parties exchange public values over an insecure channel and each independently computes a shared secret that an eavesdropper cannot derive from the exchanged values.

The classical construction uses modular exponentiation: each side picks a private exponent, raises a public generator to that exponent modulo a large prime, and sends the result to the other side. Each side then raises the received value to its own private exponent. Both arrive at the same shared secret. Elliptic Curve Diffie-Hellman (ECDH) uses point multiplication on an elliptic curve instead of modular exponentiation, with much smaller numbers for the same security level.

Diffie-Hellman is the workhorse for perfect forward secrecy — a property that ensures that even if long-term keys are later compromised, previously recorded sessions cannot be decrypted. Every modern TLS handshake (TLS 1.3) and IKEv2 exchange uses Ephemeral Diffie-Hellman.

Public Key Infrastructure (PKI)

A PKI (Public Key Infrastructure) is the system of certificate authorities, registration procedures, and revocation mechanisms that issues, distributes, and validates the X.509 certificates that bind public keys to identities.

A certificate is a document signed by a CA stating "this public key belongs to this entity," along with validity dates, an identifier, and other attributes. The recipient verifies the CA's signature using the CA's public key (which the recipient already trusts). The web's TLS ecosystem rests on PKI — Let's Encrypt, DigiCert, GlobalSign, Sectigo, and the like issue billions of certificates. Certificate Transparency logs (RFC 6962) provide public, append-only logs of issued certificates, so misissuance can be detected.

Authentication mechanisms

Authentication answers "who is this?" The methods are commonly classified by factor:

• Something you know — password, PIN, security question
• Something you have — hardware token, phone with OTP, smart card
• Something you are — fingerprint, face, voice
• Somewhere you are — location, network address
• Something you do — typing rhythm, gait

Multi-factor authentication (MFA) combines factors from different categories. The eSewa and Khalti OTP flows — password plus a one-time code sent to the registered mobile number — are MFA examples. The IME Pay biometric login (fingerprint or face plus device binding) is also MFA.

Specific protocols include Kerberos for enterprise SSO, RADIUS for network access (Wi-Fi, VPN, dial-up legacy), TACACS+ for device administration, SAML and OpenID Connect for web SSO, FIDO2/WebAuthn for passwordless authentication using device-bound keys.

Network-layer controls

Firewalls filter traffic at network boundaries. Stateless firewalls match each packet against a rule set without considering connection state. Stateful firewalls track connection state and only allow return traffic that belongs to an established connection. Next-generation firewalls add application-layer inspection (deep packet inspection), TLS decryption with operator-installed root CAs, and integration with threat-intelligence feeds.

Intrusion Detection and Prevention Systems (IDS/IPS). IDS watches traffic and alerts on suspicious patterns; IPS sits inline and actively blocks. Signature-based detection matches known attack patterns; anomaly-based detection flags deviations from learned baselines.

VPN (Virtual Private Network). A VPN encrypts traffic between endpoints, making a logically private network across a shared infrastructure. IPsec VPNs, TLS-based VPNs (OpenVPN, WireGuard's predecessors), and WireGuard itself are the deployed variants. NTC, Subisu, and several enterprise providers in Nepal offer IPsec site-to-site VPN services to corporate customers.

Zero Trust Architecture. Section 1.1 introduced the model. The mechanisms are mutual TLS for every service-to-service call, identity-aware proxies for user-to-service access, micro-segmentation that limits the blast radius of any compromise, and continuous evaluation of trust based on device posture, user behaviour, and access patterns.

The next sections turn from these primitives to how they fit together inside IPsec.

3.4 Tunnel and transport mode of authentication and encryption

IPsec applies cryptographic protection to IP packets. It supports two modes — transport mode and tunnel mode — distinguished by how much of the original packet is protected and how the packet is reshaped on the wire.

Transport mode

Transport mode is the IPsec mode in which the IPsec protection (AH or ESP) is inserted between the original IP header and the transport-layer payload, encrypting and/or authenticating the payload while leaving the original IP header in clear.

The packet layout for transport mode with ESP:

Before:
+----------------+----------------+-------------------+
| Original IP    | TCP/UDP header | Application data  |
| header         |                |                   |
+----------------+----------------+-------------------+

After (ESP in transport mode):
+----------------+--------+---------+-----------------+--------+-----+
| Original IP    | ESP    | TCP/UDP | Application     | ESP    | ESP |
| header         | header | header  | data            | trailer| auth|
+----------------+--------+---------+-----------------+--------+-----+
                          <---- encrypted ----------->
                 <-------- authenticated ------------->

The original IP header stays intact. The original IP source and destination remain visible. Only the upper-layer header and payload are inside the protected envelope.

Use case: Host-to-host protection between two endpoints that both run IPsec. Two servers exchanging sensitive data within a data centre, or a user's laptop connecting to a server with IPsec end-to-end.

Limits: Transport mode does not survive NAT cleanly, because NAT rewrites the IP header but the IPsec authentication may cover header fields the NAT changes (in AH's case) or the TCP/UDP checksum may not work after rewriting (in ESP's case). RFC 3947 (NAT-Traversal) adds UDP encapsulation to work around this.

Tunnel mode

Tunnel mode is the IPsec mode in which the entire original IP packet (header and payload) is encapsulated inside a new outer IP packet whose payload is the IPsec-protected original, hiding the original source and destination addresses and allowing IPsec gateways to protect traffic on behalf of other hosts.

The packet layout for tunnel mode with ESP:

Before:
+----------------+----------------+-------------------+
| Original IP    | TCP/UDP header | Application data  |
| header         |                |                   |
+----------------+----------------+-------------------+

After (ESP in tunnel mode):
+----------------+--------+----------------+----------------+-------------------+--------+-----+
| New IP header  | ESP    | Original IP    | TCP/UDP header | Application data  | ESP    | ESP |
| (gateway-to-   | header | header         |                |                   | trailer| auth|
|  gateway)      |        |                |                |                   |        |     |
+----------------+--------+----------------+----------------+-------------------+--------+-----+
                          <---------- encrypted ----------------------------->
                 <-------- authenticated ------------------------------------->

The original IP packet — including its IP header — is hidden inside an encrypted ESP payload. A new IP header on the outside addresses the IPsec gateway-to-gateway flow. An observer on the wire sees only that gateway A is talking to gateway B; the actual internal addresses behind each gateway are concealed.

Use case: Site-to-site VPN between two networks. A branch office in Pokhara and a head office in Kathmandu connect their internal networks across the public Internet by running an IPsec tunnel between their two edge routers. Internal hosts at the branch see internal hosts at the head office as if both were on the same private network. The encryption protects the traffic; the encapsulation hides the internal topology from the public Internet.

Tunnel mode is also the standard for the remote-access VPN that a user's IPsec client establishes with a corporate gateway.

Transport vs tunnel — when to use which

	Transport	Tunnel
Endpoints	Host-to-host	Gateway-to-gateway (most common) or gateway-to-host
Outer IP header	Original	New, addressing the tunnel endpoints
What is encrypted	Payload	Entire original packet
Hides internal topology	No	Yes
Survives NAT	Difficult (needs NAT-T)	Easier (NAT-T still helps)
Overhead	Lower (no extra IP header)	Higher (extra IP header + ESP)
Typical use	End-to-end IPsec between two hosts	Site-to-site and remote-access VPNs

Authentication-only vs encryption

IPsec supports authentication without encryption (AH), encryption without authentication (ESP without integrity, which is now discouraged), and authentication-plus-encryption (ESP with integrity, the modern default).

AH provides integrity and origin authentication, no confidentiality. A packet authenticated with AH can be read by anyone on the path, but it cannot be modified or forged without the receiver detecting. AH covers the IP header itself — except for fields that legitimately change in transit, like the Hop Limit. AH does not coexist with NAT, because NAT rewrites IP header fields that AH covers.

ESP provides confidentiality, integrity, and origin authentication (when configured with an authentication algorithm or when using an authenticated-encryption mode like AES-GCM). ESP protects the payload only — not the outer IP header — which is what lets ESP work across NAT.

Almost all modern IPsec deployments use ESP with AES-GCM — an AEAD (Authenticated Encryption with Associated Data) construction that delivers encryption and integrity in a single algorithm with hardware acceleration on most server CPUs.

3.5 IPSec framework

IPsec is not a single protocol. It is a framework of protocols, algorithms, and management mechanisms that together provide cryptographic protection at the IP layer. The framework is specified in a family of RFCs — RFC 4301 defines the architecture, RFC 4302 defines AH, RFC 4303 defines ESP, RFC 7296 defines IKEv2, plus a long list of algorithm-specific RFCs.

Components of the IPsec architecture

Security Association (SA). A Security Association is the set of cryptographic parameters — algorithms, keys, sequence number state, lifetimes — that two IPsec peers agree on for a one-way flow of protected traffic between them.

An SA is unidirectional. Two-way protected communication needs two SAs — one for each direction. An SA is identified by three values:

• The Security Parameter Index (SPI) — a 32-bit value carried in the AH or ESP header that lets the receiver look up the right SA.
• The destination IP address — the address of the receiving end of the SA.
• The security protocol — AH or ESP.

Security Policy Database (SPD). The set of rules that tells the IPsec stack which traffic must be protected, by which means, and which traffic must be dropped or passed in clear. The SPD is consulted for every packet entering or leaving the IPsec stack.

Security Association Database (SAD). The runtime table of active SAs, indexed by SPI. When a packet arrives bearing an AH or ESP header, the receiver looks up the SPI in the SAD to find the SA and apply the correct cryptographic processing.

Authentication Header (AH). Provides integrity, data origin authentication, and replay protection. AH is identified by protocol number 51 in the IPv4 Protocol field or the IPv6 Next Header field.

Encapsulating Security Payload (ESP). Provides confidentiality and optionally integrity. ESP is identified by protocol number 50.

Internet Key Exchange (IKE), currently IKEv2. The protocol used by two peers to authenticate each other and to negotiate the SAs and their cryptographic parameters. IKEv2 uses Diffie-Hellman for key agreement and supports pre-shared keys, RSA signatures, ECDSA signatures, or EAP for authentication.

How a protected packet flows

A host wants to send a packet to a peer. The IPsec stack acts as follows:

1. The host's IP stack hands the packet to IPsec.
2. IPsec consults the SPD. The SPD entry for the destination says "protect with ESP using SA X."
3. IPsec looks up SA X in the SAD. The SA gives the encryption algorithm (e.g., AES-256-GCM), the integrity algorithm (built into GCM), the keys, the current sequence number, and the mode (tunnel or transport).
4. IPsec encrypts and integrity-protects the packet as specified, increments the sequence number, and emits the protected packet on the wire.
5. At the receiver, the IPsec stack sees the ESP header, reads the SPI, looks up the matching SA in its SAD.
6. The receiver checks the sequence number against its anti-replay window. If the number is too old or already seen, the packet is dropped.
7. The receiver verifies the integrity tag, decrypts the payload, and passes the cleartext packet up the stack.

If no SA exists when the SPD demands protection, IPsec invokes IKEv2 to negotiate one. IKEv2 itself runs over UDP/500 (or UDP/4500 for NAT-Traversal) and has two phases — IKE_SA_INIT to set up an authenticated, encrypted channel between the peers, and IKE_AUTH to mutually authenticate and to create the first child SA for protecting user traffic.

IKEv2 message exchange

The minimum IKEv2 exchange is four messages — two pairs:

Initiator                                  Responder
---------                                  ---------
IKE_SA_INIT request                      
(proposals, KE, nonce)             ----->
                                           IKE_SA_INIT response
                                   <-----  (chosen proposal, KE, nonce)

IKE_AUTH request 
(identity, AUTH, SA-child, TS)     ----->
                                           IKE_AUTH response
                                   <-----  (identity, AUTH, SA-child, TS)

After this exchange both peers have a parent IKE SA (for further IKE messages) and one child SA pair (the actual IPsec SAs that protect user traffic). Additional child SAs can be created on demand with a single CREATE_CHILD_SA exchange.

The cryptographic suite an IPsec deployment chooses today is typically:

• Encryption: AES-128-GCM or AES-256-GCM (authenticated encryption, no separate integrity algorithm needed)
• Pseudorandom function (PRF) and key derivation: HMAC-SHA-256 or HMAC-SHA-384
• Diffie-Hellman group: Group 19 (ECP-256) or Group 20 (ECP-384) for modern ECDH; Group 14 (MODP-2048) for legacy compatibility
• Authentication: Certificates (RSA or ECDSA) for site-to-site VPNs; EAP for remote-access VPNs that hook into existing identity stores

A worked IPsec scenario

A bank in Kathmandu has a head office and a branch in Biratnagar. Both offices have internal networks 10.10.0.0/16 (head office) and 10.20.0.0/16 (branch). The internal networks must communicate as if directly connected, but the link between them runs over the public Internet through an NTC fibre and a backup link from Subisu.

Configuration:

• Both edge routers run IKEv2 with a pre-shared key or certificates.
• The SPD on each router has a policy: "traffic between 10.10.0.0/16 and 10.20.0.0/16 must use IPsec ESP in tunnel mode."
• The child SAs use AES-256-GCM with replay protection.
• The outer tunnel endpoints are the public IPv4 addresses of the two edge routers.

When a workstation in the branch (10.20.50.5) sends a packet to a server in the head office (10.10.10.20), the branch router sees the packet, consults its SPD, matches the policy, and consults the SAD for the matching SA. The original packet is encrypted, encapsulated in an outer IP header from the branch router's public IP to the head office router's public IP, and sent. The head office router decrypts and delivers the packet to the server. The reverse flow uses the symmetric SA.

To an observer on the public Internet (the operator's transit network, a passive sniffer), this is opaque traffic between two public IPv4 addresses. The internal addresses, the server identities, and the application payload are all hidden.

3.6 Introduction to IPv6 routing

Routing in IPv6 follows the same principles as routing in IPv4 — routers exchange information about reachable destinations, run an algorithm to choose the best path to each, and install forwarding entries. The protocols that carry the information have been updated for IPv6 addresses, but the algorithms (distance vector, link state) are the same.

Static routing vs dynamic routing

Static routing is manually configured. The operator tells the router "to reach prefix X, send packets to next-hop Y." Static routes are simple, predictable, and have no protocol overhead. They suit small networks, stub sites (a branch office with only one path out), and default routes pointing at an upstream ISP.

Dynamic routing has routers exchange information automatically. They detect new neighbours, learn about new prefixes, recompute paths when topology changes. Dynamic routing scales to large networks but introduces protocol traffic, convergence delays after a failure, and the possibility of misbehaving advertisements.

Interior vs exterior gateway protocols

Interior Gateway Protocols (IGPs) run inside a single autonomous system. They optimise for fast convergence and detailed knowledge of internal topology. The current IGPs in IPv6 deployments are:

• RIPng (RIP next generation, RFC 2080) — distance vector. Simple, slow, limited to 15-hop diameter. Suited to small networks only.
• OSPFv3 (RFC 5340) — link state. Industry-standard IGP for enterprise and ISP networks.
• IS-IS with IPv6 extensions (RFC 5308) — link state, originally designed for OSI and adapted for IP. Widely used in large ISP cores.
• EIGRPv6 — Cisco's hybrid protocol, adapted for IPv6. Now open-standard since 2013 (RFC 7868) but mostly deployed in Cisco-only networks.

Exterior Gateway Protocols (EGPs) run between autonomous systems. They optimise for policy expressiveness, scalability across the whole Internet, and operator independence. There is exactly one EGP in current use:

• BGP-4 with multiprotocol extensions for IPv6 (MP-BGP, RFC 4760) — the protocol that ties the Internet's autonomous systems together. Every operator with its own AS number — NTC (AS17501), Ncell (AS38565), WorldLink (AS17501 historically, now its own), Subisu (AS17501 historically) — runs BGP with its upstream providers and at the Nepal Internet Exchange (NPIX).

Routing in IPv6 vs IPv4 — practical differences

The routing protocols are similar in spirit but updated in important ways for IPv6.

	IPv4 routing	IPv6 routing
RIP	RIP v1/v2	RIPng (RFC 2080)
OSPF	OSPFv2 (RFC 2328)	OSPFv3 (RFC 5340)
IS-IS	IS-IS for IP	IS-IS with IPv6 TLVs (RFC 5308)
BGP	BGP-4	MP-BGP for IPv6
EIGRP	EIGRP	EIGRPv6
Use of multicast	224.0.0.0/24 range	ff02::/16 range
Next-hop addressing	IPv4 next-hop	Usually link-local IPv6 next-hop
Authentication	Built into protocols (often)	Often relies on IPsec underneath

A common surprise during IPv6 rollout is that IPv6 dynamic routing protocols typically use link-local addresses as their next-hop value. The OSPFv3 neighbour adjacency runs on link-local addresses, and the next hop in OSPFv3 LSAs is the neighbour's link-local. This works because routing-protocol adjacencies are always between directly connected neighbours, and link-local is the natural address space for that.

3.7 Unicast routing in IPv6 — RIPng and OSPFv3

RIPng

RIPng (RIP next generation) is a distance-vector interior gateway protocol defined in RFC 2080 that adapts RIP version 2 for IPv6 by using IPv6 addresses, IPv6 multicast for periodic updates, and UDP port 521.

RIPng inherits RIP's structure:

• Routers periodically (every 30 seconds by default) send their routing table to neighbours.
• Each route is described by its destination prefix and a hop count (1 to 15, where 16 means unreachable).
• A router selects the shortest-hop path to each destination.
• Triggered updates are sent when routes change.
• Split horizon and route poisoning prevent simple routing loops.

RIPng differs from RIPv2 in details:

• Uses IPv6 multicast ff02::9 (all RIPng routers on the link) instead of IPv4 broadcast.
• Uses UDP port 521 (not 520, which is RIPv2).
• The next hop in an update is a link-local IPv6 address.
• Authentication is not part of RIPng itself — it relies on IPsec AH/ESP underneath.

RIPng's strengths are simplicity and minimal configuration. Its weakness is the slow convergence inherent in distance-vector — count-to-infinity scenarios still appear, mitigated only by the 15-hop diameter limit, split horizon, and triggered updates.

Practical deployment of RIPng is rare in serious networks today. It survives in education, in very small networks (one or two routers), and as a fallback. Any network with more than a handful of routers uses OSPFv3 or IS-IS.

OSPFv3

OSPFv3 (Open Shortest Path First version 3) is the link-state interior gateway protocol defined in RFC 5340 that extends OSPFv2 for IPv6 by removing addressing from the protocol's core packet formats, making it run per-link rather than per-subnet, and adding support for both IPv4 and IPv6 address families.

OSPFv3 retains the core OSPFv2 design — Dijkstra's shortest-path-first algorithm on a topology database that every router in an area shares. The main changes:

Per-link, not per-subnet. OSPFv2 ran an instance per IPv4 subnet on each link. OSPFv3 runs an instance per link, regardless of how many IPv6 prefixes share that link. This better matches IPv6's design.

Addressing removed from the protocol's core. OSPFv3 packets no longer carry IPv6 addresses in their headers; addressing information is in specific LSAs. This let OSPFv3 add support for multiple address families — IPv4 and IPv6 can both be carried by the same OSPFv3 instance through address-family extensions.

Adjacencies form on link-local addresses. Hello and DBD packets use link-local source addresses. The router's OSPF Router ID is still a 32-bit value (typically written in dotted-decimal like an IPv4 address), but it has no relationship to actual addresses on the router.

Authentication relies on IPsec. OSPFv3 has no built-in authentication; instead, AH or ESP is used to authenticate the OSPFv3 packets at the IP layer (RFC 4552 originally, RFC 7166 the current way).

LSAs are renamed and expanded. OSPFv3 has new LSA types — Link LSA (carries link-local addresses and IPv6 prefixes for the link), Intra-Area Prefix LSA (carries prefixes within an area). The Router LSA and Network LSA still exist but no longer carry IPv6 prefixes directly.

OSPFv3 runs over IPv6 with protocol number 89 (same as OSPFv2). It uses multicast addresses ff02::5 (all OSPFv3 routers) and ff02::6 (all OSPFv3 designated routers).

OSPFv3 deployment

A typical OSPFv3 deployment:

• The network is divided into areas — Area 0 (the backbone) plus other areas connected to the backbone through Area Border Routers (ABRs). Areas limit the scope of detailed LSA flooding.
• Each router has a unique Router ID.
• On each multi-access link (e.g., an Ethernet LAN), routers elect a Designated Router (DR) and Backup DR (BDR) to reduce the number of adjacencies.
• Hello packets every 10 seconds establish and maintain adjacencies.
• LSAs flood through the area, building each router's link-state database.
• Each router independently runs Dijkstra's algorithm on the database to compute shortest paths.

A worked example for two routers on an Ethernet link:

Router A (Router ID 1.1.1.1, link-local fe80::a)
  |
  +-- Ethernet --+
  |              |
Router B (Router ID 2.2.2.2, link-local fe80::b)

1. Both routers send Hello to ff02::5. Each learns of the other.
2. They elect a DR — the router with the highest priority (or, on ties, highest Router ID). Suppose B becomes DR.
3. A and B exchange Database Description (DBD) packets summarising their LSDBs.
4. They exchange Link State Request (LSR) for any LSAs they lack.
5. They exchange Link State Update (LSU) carrying the actual LSAs.
6. Adjacency is now FULL. Both routers have synchronised LSDBs.
7. Each runs Dijkstra and installs forwarding entries for all destinations.

IS-IS for IPv6 (brief)

IS-IS is a link-state IGP originally designed for OSI's CLNS protocol stack. RFC 1195 (1990) adapted it for IPv4; RFC 5308 adds IPv6 TLVs. IS-IS runs directly over Layer 2 (not over IP), which makes it more flexible across address-family transitions. Most large ISP cores worldwide use IS-IS rather than OSPF, partly for historical reasons (Cisco-Juniper interoperability) and partly because IS-IS's TLV-based encoding extends more cleanly than OSPF's. The choice between OSPFv3 and IS-IS in a large network is more about operator preference and existing skill than about technical superiority.

BGP for IPv6

BGP carries IPv6 reachability through the multiprotocol extensions of RFC 4760. The same BGP-4 protocol that carries IPv4 routes carries IPv6 routes — typically on the same TCP session, with the address family encoded in the route announcements.

When an ISP in Nepal — WorldLink, for instance — peers at NPIX with another Nepali operator, the BGP session carries both IPv4 and IPv6 prefixes. WorldLink advertises its IPv6 prefix 2400:1a00::/32 to its peers, who add it to their routing tables. The same session carries WorldLink's IPv4 prefixes.

3.8 Multicast routing in IPv6 — PIM-SM

Multicast delivers a single packet from one source to many receivers across a network. Used for IPTV distribution, real-time stock-price feeds, multi-party video conferencing, large-scale software updates, and certain control-plane protocols. IPv6 has built-in multicast support; the question is how to route multicast packets from the source to the receivers efficiently.

Group membership management

MLD (Multicast Listener Discovery) is the IPv6 equivalent of IGMP, used by hosts to tell their first-hop router that they want to receive a particular multicast group, and used by routers to track which groups have listeners on each link.

MLDv2 (RFC 3810) is the current version, with source-specific membership filters. The host sends an MLD Report to indicate interest in a group; the router periodically sends MLD Queries to confirm which hosts are still listening. MLD runs as a set of ICMPv6 message types (types 130, 131, 132, 143).

MLD only handles the host-to-router signalling. The router-to-router multicast routing is a separate problem, and PIM is the answer.

PIM-SM

PIM-SM (Protocol Independent Multicast — Sparse Mode) is the multicast routing protocol defined in RFC 7761 that builds explicit multicast distribution trees from receivers towards a Rendezvous Point shared with sources, suited to scenarios where multicast receivers are sparsely distributed across the network.

"Protocol Independent" means PIM does not run its own topology discovery — it uses whatever unicast routing table the underlying IGP/BGP has built. PIM operates on top of that table to compute reverse-path forwarding for multicast.

"Sparse Mode" means PIM-SM uses an explicit join model — receivers must signal interest before traffic is delivered. The alternative is Dense Mode, where traffic is flooded everywhere first and then pruned, suited only to dense receiver distributions.

Rendezvous Point and the shared tree

PIM-SM uses a Rendezvous Point (RP) — a designated router that serves as the meeting point between sources and receivers for a given multicast group.

The mechanism:

1. A receiver joins. A host sends an MLD Report for group G to its first-hop router. The router sends a PIM Join message towards the RP for group G. Every router along the path installs forwarding state for (*, G) — "any source to group G goes downstream this way."
2. A source sends. The source's first-hop router (called the Designated Router for the source's LAN) encapsulates the source's multicast packets in PIM Register messages and unicasts them to the RP.
3. The RP de-encapsulates the packets and forwards them down the shared tree to all known receivers.
4. The RP sends a Source-Specific Join towards the source. A native multicast path is built from source to RP, eliminating the Register-encapsulation overhead.
5. Tree optimisation. Once receivers see traffic flowing through the shared tree, the last-hop routers may switch to a Shortest Path Tree (SPT) rooted at the source — a (S, G) tree — for better efficiency. The original shared tree (*, G) remains as a fallback for new sources.

RP discovery

Routers must know which RP handles which group. Three mechanisms exist:

• Static configuration. Every router is told the RP address for each group range. Simple but inflexible.
• Bootstrap Router (BSR), RFC 5059. A dynamic election protocol among candidate RPs. One router becomes the BSR for the network, collecting RP advertisements and distributing the RP-to-group mapping.
• Embedded RP, RFC 3956. The RP's address is encoded inside the multicast group address itself. Any router seeing a packet for that group can extract the RP from the group address. Unique to IPv6.

PIM-SM in practice

A typical IPTV deployment by a Nepali ISP carrying multiple TV channels over its IPv6 access network:

• Each channel is mapped to an IPv6 multicast group, for example ff3e::1:8001 for channel 1, ff3e::1:8002 for channel 2.
• The IPTV head-end is the source. Its first-hop router is the DR for the LAN.
• A subscriber's set-top box joins the relevant group via MLD when the user changes channels.
• The DSL/FTTH router (the last-hop router for the subscriber's home) sends a PIM Join to the RP.
• After the SPT switch-over, the multicast packets follow the most direct path from head-end to subscriber.

The combination — MLD at the access edge, PIM-SM in the core, IGP-based RPF check at every hop — is the IPv6 equivalent of the IGMP+PIM model that has carried IPv4 multicast for two decades. The protocols are slightly different in their packet formats and their addressing, but the fundamentals are the same.

Source-Specific Multicast (SSM)

PIM-SSM, defined in RFC 4607, simplifies multicast for cases where receivers know in advance which sources they want. A receiver expresses interest in a specific (S, G) pair, and the network builds an SPT directly from the source without involving a shared tree or RP. SSM uses the IPv6 group range ff3x::/32 (where x is the scope), and is the recommended mode for one-to-many applications where the source is well-known — Internet TV, software-update distribution, financial data feeds. SSM removes the operational complexity of RP discovery and election.