IP Addressing and Advanced Routing

Introduction

Internet Protocol addressing and routing form the logical foundation of enterprise networks, cloud infrastructures, content-delivery systems, and the public Internet. Addressing identifies interfaces and networks; routing determines how packets reach their destinations. At postgraduate level, the subject must be understood not merely as configuration syntax, but as a design problem involving scalability, failure, policy, security, performance, and governance.

IPv4 remains extensively deployed, although its 32-bit address space is limited and heavily dependent on address conservation mechanisms. IPv6 provides a 128-bit address space and a redesigned operational model, but coexistence between the two protocols will remain important for many years. Routing similarly ranges from simple static routes to distributed interior protocols and policy-driven interdomain exchange using BGP.

Learning Objectives

By the end of this chapter, a student should be able to:

• design IPv4 and IPv6 addressing plans using subnetting and summarization;
• calculate prefixes, host capacity, and allocation boundaries;
• explain NAT, route aggregation, multicast, anycast, and policy routing;
• compare distance-vector, link-state, and path-vector routing;
• configure and evaluate the conceptual operation of OSPF and BGP;
• analyse interdomain route selection, scalability, failure, and security;
• select routing approaches for enterprise, cloud, service-provider, and data-science workloads.

1. Addressing as a Hierarchical Design Problem

An IP address identifies a logical interface, but the prefix associated with it identifies a set of addresses that can be treated as a routing unit. In CIDR notation, an address is written as a.b.c.d/p for IPv4 or as a hexadecimal IPv6 address followed by a prefix length. The prefix length specifies how many leading bits represent the network portion.

For an IPv4 prefix of length p, the number of addresses is:

where N is the total number of addresses and p is between 0 and 32. If a traditional broadcast-based subnet reserves one network address and one directed-broadcast address, usable host addresses are:

This subtraction is not universally applicable: point-to-point links, modern platforms, and special-purpose prefixes may use addresses differently. Prefixes /31 are commonly used on point-to-point IPv4 links, while /32 identifies a single host or loopback route.

For IPv6, a prefix of length p contains:

IPv6 subnets are commonly assigned /64 prefixes to support Stateless Address Autoconfiguration and interface identifiers. The enormous address space makes conservation less important than aggregation, topology, privacy, and operational simplicity.

Addressing hierarchy

A scalable plan usually separates:

1. global allocation or provider-independent space;
2. regional, campus, cloud, or business-unit blocks;
3. site and security-zone prefixes;
4. VLAN, segment, loopback, and point-to-point prefixes;
5. host or interface identifiers.

Hierarchical allocation makes route summarization possible. If contiguous prefixes are assigned to one site, the site can advertise one aggregate instead of many individual routes. Address planning therefore affects routing-table size, convergence, troubleshooting, and the blast radius of failures.

2. IPv4 Subnetting and Route Aggregation

Subnetting divides a larger prefix into smaller prefixes by extending the prefix length. If q bits are borrowed from the host portion, the number of equal-sized subnets is:

Each resulting subnet has a prefix length p + q. For example, dividing 192.168.10.0/24 into four equal subnets borrows two bits, producing /26 prefixes. Each contains 64 addresses, of which 62 are conventionally usable host addresses.

The four subnet ranges are:

Variable Length Subnet Masking (VLSM) allocates different prefix sizes according to need. A point-to-point connection may need /31, a server segment may need /27, and a user network may need /23. VLSM improves address efficiency but requires disciplined documentation and non-overlapping allocation.

Longest-prefix match

When several routes match a destination, a router selects the route with the longest matching prefix. Thus, /25 is preferred over /24, and /32 is preferred over both. Longest-prefix matching enables specific exceptions within a broad aggregate, but excessive exceptions can increase operational complexity and undermine summarization.

Aggregation

Two or more contiguous prefixes can be summarized when they share an appropriate common prefix and are aligned on a valid binary boundary. For example, 10.20.0.0/24 through 10.20.3.0/24 can be represented as 10.20.0.0/22, because four aligned /24 networks contain 1,024 addresses. Aggregation reduces routing-table entries and limits propagation of internal detail.

An aggregate must not imply reachability to addresses for which the advertiser has no valid path unless intentional default or discard behavior is configured. A common protective technique is a null route for the aggregate, accompanied by more-specific routes for actual destinations. This prevents loops when traffic enters an aggregate for an unavailable component.

3. IPv6 Addressing

IPv6 addresses are written as eight groups of hexadecimal digits. Leading zeroes within a group may be omitted, and one contiguous sequence of all-zero groups may be compressed with ::, only once per address. IPv6 address categories include:

• Global unicast: globally routable addresses, commonly from 2000::/3.
• Link-local: fe80::/10; required on IPv6-enabled interfaces and used for neighbour discovery and many routing adjacencies.
• Unique local: fc00::/7, generally used for internal addressing, subject to local allocation practice.
• Multicast: ff00::/8, used for one-to-many delivery.
• Loopback: ::1.
• Unspecified: ::, used when an interface has no assigned address.

IPv6 replaces ARP with Neighbor Discovery Protocol, which uses ICMPv6. Router Advertisements can provide prefixes, default-router information, and configuration flags. Blocking all ICMPv6 is therefore harmful; security controls should distinguish necessary control messages from unwanted traffic.

IPv6 has no broadcast mechanism. Multicast and anycast provide more precise alternatives. Privacy extensions can generate temporary addresses for outbound client connections, while stable addresses may be retained for servers and management. Organisations should define address lifetimes, logging requirements, reverse DNS, and identity correlation before deploying privacy mechanisms at scale.

Dual stack and transition

Dual stack runs IPv4 and IPv6 simultaneously. It is conceptually straightforward but doubles monitoring, filtering, routing, and incident-response obligations. Tunnelling carries one protocol through another, whereas translation mechanisms such as NAT64 allow IPv6-only clients to reach IPv4 services. Transition design should be driven by application compatibility, operational maturity, and measurable migration goals rather than by protocol preference alone.

4. NAT and Its Design Consequences

Network Address Translation changes address or port information as packets cross a boundary. Common forms include:

• Static NAT: a stable one-to-one mapping;
• Dynamic NAT: allocation from a pool;
• PAT/NAPT: many internal flows share one public address using transport-layer ports;
• Destination NAT: commonly used for publishing an internal service;
• NAT64: translation between IPv6 and IPv4 communication domains.

PAT conserves public IPv4 addresses but introduces state. A translation table generally records an internal address and port, external address and port, protocol, and timers. Return traffic must match that state. Consequently, asymmetric routing, stateful firewall clustering, long-lived connections, and failure recovery require careful design.

NAT is not a complete security boundary. It can make unsolicited inbound connections harder, but security depends on explicit filtering, authentication, segmentation, patching, and monitoring. NAT also complicates peer-to-peer applications, IP-based access controls, forensic attribution, and protocols that embed addresses in payloads. IPv6 deployments should not assume that NAT is required for security.

5. Routing Algorithms and Control-Plane Models

A routing protocol distributes reachability information; the forwarding plane then uses the selected routes to forward packets. Three conceptual families dominate.

Distance-vector routing

A distance-vector router advertises destinations and a metric to neighbours. The classic Bellman–Ford recurrence is:

Here d_x(y) is router x's estimated distance to destination y, v is a neighbour of x, c(x,v) is the cost of the link from x to v, and d_v(y) is v's advertised distance to y. The expression assumes additive path costs and relies on iterative neighbour exchange. Problems include slow convergence and count-to-infinity; split horizon, route poisoning, triggered updates, and bounded metrics mitigate but do not eliminate them.

Link-state routing

In a link-state system, routers discover neighbours, measure link characteristics, flood link-state advertisements, and independently compute shortest paths. Dijkstra's algorithm repeatedly selects the unsettled node with the smallest tentative distance and relaxes adjacent edges. If w(u,v) is a non-negative link cost, relaxation tests whether:

If true, d(v) is replaced by the smaller value. Link-state routing provides rapid, topology-aware calculation but requires memory, processing, flooding control, and careful hierarchy.

Path-vector routing

A path-vector protocol advertises reachability together with attributes and an autonomous-system path. It supports policy decisions that are not reducible to the shortest numerical path. BGP is the principal example. It is deliberately conservative: stability and administrative policy are more important than globally optimal latency.

6. OSPF: Hierarchical Interior Routing

Open Shortest Path First is a link-state Interior Gateway Protocol. OSPF forms adjacencies using Hello messages, exchanges link-state information, builds a link-state database, and runs SPF calculations. Its principal concepts include:

• areas, which constrain flooding and computation;
• Area 0, the backbone through which inter-area connectivity is normally organised;
• Router ID, a stable 32-bit identifier selected independently of the interface address format;
• cost, an administratively configured metric, historically related to reference bandwidth;
• DR and BDR, elected on broadcast multiaccess networks to reduce adjacency overhead;
• LSAs, which describe routers, networks, summaries, external routes, and other information.

OSPF route preference broadly favours intra-area over inter-area over external paths, although exact selection depends on implementation and route type. Equal-cost multipath may be used when multiple paths have equivalent cost.

OSPF design should avoid unnecessary area complexity. Summarisation at area boundaries reduces database and routing-table growth, but it can hide more-specific failures or create suboptimal paths. Point-to-point links, passive interfaces, authentication, stable router IDs, and explicit metric policy improve predictability.

OSPFv3 supports IPv6 and uses link-local addresses for many neighbour relationships. Deployments must still consider address families, authentication, filtering, and interactions with IPv4 routing.

7. BGP and Interdomain Decision Making

Border Gateway Protocol is an interdomain path-vector protocol. An autonomous system (AS) is a network under one administrative policy. BGP exchanges routes over TCP and attaches attributes such as:

• AS_PATH, which records traversed ASes and helps prevent loops;
• NEXT_HOP, the next forwarding address;
• LOCAL_PREF, commonly used within an AS to express preferred exit direction;
• MED, a suggestion about entry into an AS, usually compared within a defined neighbouring-AS context;
• ORIGIN, describing how the route entered BGP;
• COMMUNITY, a policy tag used for classification and action;
• weight or vendor-specific attributes, which are local and not standardised across all implementations.

A simplified decision process often considers local policy first, then highest local preference, shortest AS path, preferred origin type, lower MED where applicable, eBGP over iBGP, lower internal cost to the next hop, and deterministic tie-breakers. The exact sequence is implementation-dependent; engineers must consult platform documentation rather than treating a simplified list as universal law.

BGP does not necessarily select the path with the fewest physical hops or lowest latency. It selects the best path according to policy and attributes. This distinction is central to traffic engineering. Inbound traffic is influenced indirectly through advertisements, communities, prepending, selective announcements, and provider agreements; outbound traffic is more directly controlled through local preference and route policy.

eBGP and iBGP

eBGP exchanges routes between ASes. iBGP distributes externally learned routes within an AS. Traditional iBGP requires a full mesh, whose session count is:

where n is the number of iBGP speakers and C is the number of sessions. This quadratic growth motivates route reflectors and confederations. Route reflectors improve scalability but introduce path-selection and visibility considerations; clients may not see every alternative path.

Internet routing security

Route Origin Authorisation and the Resource Public Key Infrastructure allow networks to validate whether an AS is authorised to originate a prefix. RPKI-based origin validation classifies routes as valid, invalid, or not found. It does not by itself validate the entire AS path. Prefix filtering, maximum-prefix limits, authenticated sessions, route-policy review, monitoring, and controlled announcements remain necessary.

8. Multicast, Anycast, and Policy Routing

Multicast delivers one stream to multiple receivers using group addresses. Receivers join a group; local routers use protocols such as IGMP for IPv4 or MLD for IPv6; routers construct distribution trees using mechanisms such as PIM. Source-specific multicast identifies both a source and group, written conceptually as (S,G), and often provides clearer security and state management than any-source multicast.

Multicast is useful for live media, market-data distribution, software delivery, and scientific instruments, but it requires receiver-state management, replication-aware capacity planning, and controls against unwanted group membership.

Anycast assigns the same address to multiple distributed instances. Routing directs a client toward one topologically preferred instance. Anycast is widely used for DNS, content delivery, and resilient service front ends. It is unsuitable for applications that require a stable conversational endpoint unless session state is shared or traffic is engineered consistently. A route change can move a client between instances.

Policy-based routing selects paths according to attributes such as source address, application class, interface, or firewall mark rather than destination alone. It is powerful for multi-homing, service insertion, and differentiated traffic engineering. However, policy routing can violate the assumptions of symmetric stateful devices, create loops, and complicate troubleshooting. Policies should be explicit, ordered, logged, tested, and paired with a safe default.

9. Practical Design Method

A robust addressing and routing project normally follows these steps:

1. Gather requirements: sites, users, services, growth, availability, compliance, cloud regions, and traffic flows.
2. Define administrative boundaries: ASes, routing domains, security zones, and ownership.
3. Allocate hierarchical address space: reserve expansion blocks and prevent overlap with partners or cloud providers.
4. Choose subnet sizes: use VLSM for IPv4 and consistent /64 LANs for IPv6 unless a documented exception exists.
5. Design summarisation points: ensure aggregates are aligned and do not conceal unacceptable failures.
6. Select protocols: static routing for simple stable edges; OSPF or another IGP internally; BGP for interdomain policy and large-scale control.
7. Specify failure behaviour: convergence targets, default routes, blackholing, graceful restart, and withdrawal policy.
8. Implement controls: prefix filters, RPKI validation, authentication, maximum-prefix limits, logging, and configuration review.
9. Test: verify reachability, isolation, failover, asymmetric paths, MTU, DNS, and IPv6 control traffic.
10. Document and monitor: maintain an IP address management system, topology records, route analytics, and ownership metadata.

Worked Example: Enterprise Dual-Stack Allocation

An organisation receives 10.40.0.0/16 for internal IPv4 use and 2001:db8:4400::/48 as documentation IPv6 space for an illustrative design. It has four sites, each requiring up to 900 IPv4 endpoints, eight departmental segments per site, and growth capacity.

A /22 provides 1,024 total IPv4 addresses and 1,022 conventional host addresses, so one /22 per site satisfies the endpoint requirement. Four sites consume four /22 blocks. The organisation may allocate:

• Site A: 10.40.0.0/22
• Site B: 10.40.4.0/22
• Site C: 10.40.8.0/22
• Site D: 10.40.12.0/22

These four aligned /22 blocks can be summarised as 10.40.0.0/20, provided the routing domain owns and safely advertises the entire range. Within each site, /24, /26, or smaller prefixes can be assigned according to departmental need. The site should advertise its aggregate toward the core while retaining internal specifics.

For IPv6, the /48 can be divided into 256 /56 site allocations because 56 − 48 = 8 bits and 2⁸ = 256. Each /56 can provide 256 /64 LAN prefixes because 64 − 56 = 8. This supports departmental separation without address scarcity. The design should reserve blocks for loopbacks, infrastructure, guest networks, laboratories, and future sites.

The arithmetic demonstrates a key principle: IPv4 planning is constrained by host counts, while IPv6 planning is primarily structured around hierarchical delegation and operational clarity.

Applied Case: Illustrative Multi-Cloud Research Organisation

Background

A research organisation operates laboratories in three cities, a private data centre, and workloads in two public clouds. Data pipelines generate high-volume transfers, while identity, experiment control, and storage services have different availability requirements.

Problem

The organisation used overlapping RFC 1918 IPv4 ranges acquired independently by different teams. Cloud VPNs failed intermittently, traffic crossed the wrong security appliances, and BGP advertisements were manually changed during incidents. IPv6 was enabled only in the public cloud, creating inconsistent application behaviour.

Analysis

The network team mapped ownership, service dependencies, and failure domains. It found that address overlap, rather than raw bandwidth, was the primary cause of inter-site complexity. It also found that the existing policy routing rules were undocumented and that route advertisements lacked maximum-prefix protection.

Approach

The organisation adopted a central IP address management process, assigned non-overlapping regional blocks, and introduced summarised site advertisements. OSPF was retained inside each major site, while eBGP was used at cloud and inter-site boundaries. Local preference controlled outbound cloud selection; communities classified routes for export and backup behaviour. IPv6 /48 allocations were divided into site /56s and operational /64s. RPKI validation and prefix filters were introduced on external sessions. A route-monitoring system alerted operators to unexpected origin changes and aggregate withdrawals.

Outcome

The number of inter-site routes fell substantially, failover became predictable, and cloud connectivity could be tested without changing application addressing. IPv6 was introduced in parallel rather than as an isolated overlay. The organisation also documented exceptions, including stateful services that required symmetric paths.

Learning points

The case illustrates that routing problems often originate in address governance. Summarisation cannot repair overlapping space, and sophisticated policy cannot compensate for missing ownership records. Technical design, operational process, and security controls must be treated as one system.

Challenges, Limitations, and Governance

Routing protocols distribute control information; they do not guarantee application performance. A selected path may have low administrative cost but high latency, congestion, or packet loss. Measurement systems should therefore correlate routing state with active probes, flow records, interface counters, and application telemetry.

Automation improves consistency but can amplify an error rapidly. BGP automation should include policy linting, approval boundaries, canary announcements, rollback, and maximum-prefix controls. Artificial intelligence may assist anomaly detection and capacity forecasting, but automated route changes require explainability, bounded authority, and human escalation. Training data can also reflect abnormal or malicious routing states.

Privacy and governance issues include the exposure of organisational topology, retention of source addresses, lawful interception obligations, and attribution when NAT or shared addresses are used. IPv6 temporary addresses and encrypted transport can improve privacy but may complicate investigation and service policy. Logs should be minimised, access-controlled, time-synchronised, and retained according to documented legal and operational requirements.

Best Practices

• Allocate addresses hierarchically and reserve growth space.
• Prefer aggregation, but verify that aggregates do not mask critical failures.
• Use stable loopback addresses for router identification and management.
• Treat IPv4 and IPv6 as separate operational control planes during transition.
• Filter BGP announcements by prefix, origin, maximum count, and policy.
• Use RPKI validation as one layer of routing security, not as a complete solution.
• Document every policy-routing rule and test ordering and fallback behaviour.
• Monitor convergence, route churn, latency, loss, and application impact.
• Test multicast, anycast, NAT state, and asymmetric-failure scenarios explicitly.
• Make IP address management and configuration ownership part of governance.

Chapter Summary

IP addressing and routing are hierarchical systems designed to scale logical reachability across administrative and technical boundaries. IPv4 subnetting, VLSM, CIDR, and longest-prefix matching provide efficient allocation and forwarding, while aggregation controls routing-table growth. IPv6 expands address capacity and uses multicast, Neighbor Discovery, and structured prefix delegation rather than broadcast-based operation. NAT conserves IPv4 space but introduces state and should not be confused with security.

Distance-vector, link-state, and path-vector protocols embody different assumptions about information, computation, and policy. OSPF provides topology-based interior routing with areas and SPF calculation. BGP provides policy-driven interdomain routing through attributes, AS paths, and controlled advertisement. Multicast supports one-to-many delivery, anycast supports distributed service instances, and policy routing enables source- or application-sensitive decisions at the cost of complexity. Effective designs combine technical mechanisms with address governance, security validation, monitoring, automation controls, and documented operational responsibility.

Key Terms

CIDR: Classless Inter-Domain Routing; notation that represents a network with a prefix length.

VLSM: Variable Length Subnet Masking; allocation of different subnet sizes within an address block.

Prefix: The leading bits that identify a network or route block.

Longest-prefix match: Selection of the matching route with the greatest prefix length.

Route aggregation: Combining contiguous routes into a shorter summary prefix.

NAT: Network Address Translation; modification of address information across a boundary.

PAT: Port Address Translation; many flows sharing an address through transport ports.

IPv6 link-local: An address used for local-link communication, commonly from fe80::/10.

OSPF: Open Shortest Path First, a link-state interior gateway protocol.

LSA: Link-State Advertisement, information flooded in OSPF.

SPF: Shortest Path First calculation used by link-state routing.

Autonomous System: A network under a common administrative routing policy.

BGP: Border Gateway Protocol, the principal interdomain path-vector protocol.

AS_PATH: BGP attribute recording traversed autonomous systems.

Local preference: An attribute commonly used to choose an outbound path within an AS.

Multicast: One-to-many or many-to-many packet delivery using group addresses.

Anycast: Advertisement of one address from multiple locations.

Policy routing: Routing decisions based on criteria beyond destination prefix.

RPKI: Public-key infrastructure supporting validation of authorised route origins.

Route reflector: An iBGP device that reduces the need for a full mesh of sessions.

Review Questions

Short Answer Questions

1. Why is hierarchical address allocation important for route aggregation?
2. Distinguish a global unicast IPv6 address from a link-local address.
3. What problem does PAT solve, and what state does it introduce?
4. What is the purpose of the AS_PATH attribute in BGP?
5. Why can policy routing complicate stateful firewall operation?

Long Answer Questions

1. Explain IPv4 VLSM and route summarisation using a suitable numerical example.
2. Compare distance-vector, link-state, and path-vector routing models.
3. Describe OSPF areas, LSAs, SPF calculation, and the trade-offs of summarisation.
4. Explain how BGP attributes support interdomain traffic engineering.
5. Discuss dual-stack IPv6 migration, including operational, security, and governance concerns.

Analytical / Application Questions

1. Design an IPv4 and IPv6 allocation for an organisation with six sites, 500 users per site, three server zones, and projected doubling within five years. Justify prefix sizes and summarisation boundaries.
2. A multihomed enterprise receives two Internet routes: one has higher local preference but higher measured latency; the other has lower local preference but lower latency. Analyse which route BGP will select and propose a policy that incorporates performance without causing instability.
3. An anycast service intermittently moves client sessions between sites during a link failure. Analyse the likely causes and recommend routing, state-management, and monitoring changes.

Multiple Choice Questions with Answers

Question 1

How many total IPv4 addresses are contained in a /26 prefix?

A. 32

B. 64

C. 128

D. 256

Correct Answer: B. 64

Question 2

Which routing principle selects a /25 route over a matching /24 route?

A. Lowest interface number

B. Shortest AS path

C. Longest-prefix match

D. Highest MED

Correct Answer: C. Longest-prefix match

Question 3

Which OSPF mechanism reduces link-state flooding and SPF scope?

A. Areas

B. PAT

C. AS_PATH

D. Route poisoning

Correct Answer: A. Areas

Question 4

What is the principal purpose of BGP AS_PATH?

A. Encrypting route updates

B. Preventing interdomain routing loops

C. Assigning IPv6 link-local addresses

D. Measuring packet delay

Correct Answer: B. Preventing interdomain routing loops

Question 5

How many /64 IPv6 prefixes can be formed from one /56 prefix?

A. 8

B. 64

C. 128

D. 256

Correct Answer: D. 256

Question 6

Which statement best describes anycast?

A. One address is advertised from multiple locations

B. One packet is encrypted for one receiver

C. All routers receive every packet

D. A private address is translated to a public port

Correct Answer: A. One address is advertised from multiple locations

Question 7

What does PAT primarily allow?

A. Multiple private flows to share one public IPv4 address

B. IPv6 routers to use broadcast

C. OSPF to avoid SPF calculation

D. BGP to ignore route policy

Correct Answer: A. Multiple private flows to share one public IPv4 address

Question 8

Which BGP attribute is commonly used to prefer an outbound exit within an autonomous system?

A. TTL

B. Local preference

C. EtherType

D. Hop Limit

Correct Answer: B. Local preference

Question 9

Which protocol replaces ARP's role in IPv6 neighbour discovery?

A. ICMPv6

B. TCP

C. BGP

D. IGMP

Correct Answer: A. ICMPv6

Question 10

What is a principal operational risk of undocumented policy-based routing?

A. It guarantees symmetric paths

B. It eliminates route loops

C. It can create unexpected paths and complicate troubleshooting

D. It prevents all route aggregation

Correct Answer: C. It can create unexpected paths and complicate troubleshooting