Loading learning content...
In the previous page, we established that mobile devices face a fundamental problem: their IP address, which identifies them to the world, changes when they move between networks. Existing connections break, and correspondents can no longer reach them at their known address.
The Home Agent (HA) is the solution to this problem. It acts as a permanent, stable anchor point for mobile nodes—a trusted entity that always knows where the mobile node currently resides and can redirect traffic accordingly.
Think of the Home Agent like a post office in your hometown. When you travel abroad, mail sent to your permanent address doesn't get lost—the post office forwards it to your temporary location. When you return home, the forwarding stops. The Home Agent performs exactly this function for IP packets.
By the end of this page, you will understand the Home Agent's architecture, its role in packet interception and tunneling, the registration protocols that keep it informed of the mobile node's location, and the critical security mechanisms that prevent attacks on mobility infrastructure.
The Home Agent (HA) is a router on a mobile node's home network that has been designated and configured to provide mobility services. It maintains information about mobile nodes that have registered with it and handles traffic destined for those mobile nodes when they are away from home.
Formal Definition (RFC 5944):
A Home Agent is a router on a mobile node's home network which tunnels datagrams for delivery to the mobile node when it is away from home, and maintains current location information for the mobile node.
Core Responsibilities:
A Home Agent is not merely a standard router with extra configuration—it contains specialized components that work together to provide mobility services. Understanding this architecture is essential for deployment, troubleshooting, and security analysis.
Key Architectural Components:
| Component | Function | Implementation Details |
|---|---|---|
| Binding Cache | Stores MN location mappings | Hash table indexed by home address, contains CoA, lifetime, security associations |
| Mobility Agent Advertiser | Announces HA presence | Sends Agent Advertisements via ICMP Router Discovery extensions |
| Registration Processor | Handles MN registrations | UDP listener on port 434, validates requests, updates binding cache |
| Packet Interceptor | Captures MN-destined packets | Proxy ARP responder, modifies ARP cache to attract traffic |
| Tunnel Manager | Handles encapsulation/decapsulation | Manages tunnel interfaces, IP-in-IP or GRE encapsulation |
| Security Module | Authentication and replay protection | IPsec SA management, sequence number tracking, key management |
The Binding Cache in Detail:
The binding cache is the heart of the Home Agent. It maintains authoritative knowledge about where each registered mobile node currently resides:
Binding Cache Entry Structure:
├── Home Address: 10.0.1.50 # MN's permanent identity
├── Care-of Address: 172.16.5.23 # MN's current location
├── Registration Lifetime: 600 sec # Time until binding expires
├── Time Registered: 1705312200 # Unix timestamp of registration
├── Sequence Number: 4523 # For replay protection
├── Security Association:
│ ├── SPI: 0x12345678
│ ├── Algorithm: HMAC-SHA256
│ └── Key: [encrypted storage]
└── Flags:
├── Simultaneous Bindings: false
├── Broadcast Datagrams: true
└── Reverse Tunnel Required: true
The binding cache must support fast lookup (O(1) hash-based) since every packet destined for a mobile node requires a cache check. Modern implementations use thread-safe concurrent hash tables to support high throughput.
A single Home Agent may serve thousands of mobile nodes simultaneously. Binding cache memory consumption is approximately 200-500 bytes per entry, meaning 1 GB of RAM can theoretically support 2-5 million mobile nodes. However, packet processing rate is typically the bottleneck, not memory.
When a mobile node leaves its home network, packets from correspondent nodes continue arriving at the home network—after all, the CN still knows only the mobile node's home address. The Home Agent must somehow intercept these packets before they're dropped as undeliverable.
The Challenge:
The home network's router will deliver packets to the mobile node's home address by first performing an ARP request: "Who has 10.0.1.50?" Normally, the mobile node itself would respond. But the mobile node is gone—it's on a foreign network. Without intervention, the ARP request goes unanswered, and packets are dropped.
Solution: Proxy ARP
The Home Agent performs Proxy ARP for registered mobile nodes. When it hears an ARP request for a home address in its binding cache, it responds with its own MAC address:
ARP Request (from gateway router):
Who has 10.0.1.50? Tell 10.0.1.1
ARP Reply (from Home Agent, NOT the mobile node):
10.0.1.50 is at AA:BB:CC:DD:EE:FF ← Home Agent's MAC
Now, all layer-2 traffic destined for the mobile node is delivered to the Home Agent instead.
Gratuitous ARP for Immediate Binding:
When a mobile node first registers (or updates its registration), the Home Agent sends a Gratuitous ARP announcement to immediately update all ARP caches on the home network:
Gratuitous ARP:
Sender IP: 10.0.1.50 ← Mobile node's home address
Sender MAC: AA:BB:CC:DD:EE:FF ← Home Agent's MAC
Target IP: 10.0.1.50
Target MAC: 00:00:00:00:00:00
This unsolicited ARP causes all devices on the home network to update their ARP cache with the Home Agent's MAC for the mobile node's IP. Traffic is immediately redirected.
When the Mobile Node Returns Home:
If the mobile node returns to its home network and deregisters, the Home Agent stops proxying for that address. The mobile node sends its own Gratuitous ARP to reclaim its address, and traffic flows directly again.
Proxy ARP is functionally similar to ARP spoofing—a technique used in attacks. The difference is authorization: the Home Agent is legitimately configured to proxy for the mobile node. However, this means ARP-based attacks could potentially hijack mobile node traffic if the home network lacks proper security controls.
Once the Home Agent intercepts a packet destined for a mobile node, it must deliver that packet to the mobile node's current location. It cannot simply forward the packet normally—the packet's destination address is the home address, and routers would just send it back to the home network.
The Solution: IP-in-IP Encapsulation
The Home Agent wraps the original packet inside a new IP packet, with:
This is called IP-in-IP tunneling (RFC 2003) or alternatively GRE tunneling (RFC 2784).
Packet Structure After Encapsulation:
Original Packet:
┌─────────────────────────────────────────┐
│ IP Header │
│ Source: 203.0.113.100 (CN) │
│ Dest: 10.0.1.50 (MN home addr) │
│ Protocol: TCP (6) │
├─────────────────────────────────────────┤
│ TCP Header + Payload │
└─────────────────────────────────────────┘
After Encapsulation (sent by Home Agent):
┌─────────────────────────────────────────┐
│ Outer IP Header │
│ Source: 10.0.1.1 (Home Agent) │
│ Dest: 172.16.5.23 (MN Care-of Addr) │
│ Protocol: IPIP (4) or GRE (47) │
├─────────────────────────────────────────┤
│ Original IP Header │
│ Source: 203.0.113.100 (CN) │
│ Dest: 10.0.1.50 (MN home addr) │
│ Protocol: TCP (6) │
├─────────────────────────────────────────┤
│ TCP Header + Payload │
└─────────────────────────────────────────┘
| Protocol | IP Protocol Number | Overhead | Features |
|---|---|---|---|
| IP-in-IP | 4 | 20 bytes | Minimal overhead, no additional features |
| GRE | 47 | 24-28 bytes | Supports sequencing, checksums, key field |
| IPsec ESP | 50 | Variable (40+ bytes) | Encryption, authentication, replay protection |
| GRE over IPsec | 50 → 47 | Variable (60+ bytes) | Both GRE features and IPsec security |
MTU Considerations:
Encapsulation adds header overhead, which reduces the effective Maximum Transmission Unit (MTU). If the original packet was already near MTU size (e.g., 1500 bytes on Ethernet), adding 20+ bytes of encapsulation would exceed the link MTU, requiring fragmentation.
Solutions:
Typical effective MTU:
High-performance Home Agents use hardware offload for tunnel encapsulation/decapsulation. Network Interface Cards (NICs) with GRE or IPsec offload can process millions of packets per second without CPU involvement, essential for carrier-grade deployments.
For the Home Agent to tunnel packets correctly, it must know the mobile node's current Care-of Address. The Registration Protocol is how the mobile node informs the Home Agent of its location.
Registration Message Flow:
Mobile IPv4 uses UDP-based registration messages between the mobile node and Home Agent. The messages travel through the Foreign Agent (which we'll cover in the next page) in most deployments:
Registration Request Message Format:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type |S|B|D|M|G|R|T|x| Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Agent Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Care-of Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extensions ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Key Fields:
Registration Reply Codes:
The Home Agent responds with a status code indicating acceptance or rejection:
| Code | Meaning | Common Cause |
|---|---|---|
| 0 | Registration accepted | Successful registration |
| 1 | Registration accepted but simultaneous bindings unsupported | HA doesn't support S flag |
| 64 | Reason unspecified | Generic rejection |
| 65 | Administratively prohibited | Policy rejection |
| 66 | Insufficient resources | HA binding cache full |
| 67 | Mobile node failed authentication | Invalid MN-HA authenticator |
| 68 | Home agent failed authentication | HA doesn't recognize MN |
| 69 | Requested lifetime too long | HA accepts shorter lifetime |
| 80 | Poorly formed request | Malformed message |
| 133 | Identification mismatch | Replay protection triggered |
Bindings are not permanent. The mobile node must re-register before the lifetime expires to maintain connectivity. Typical lifetimes range from 300-600 seconds (5-10 minutes). This ensures stale bindings don't persist if a mobile node disappears without explicit deregistration.
Security is critical for Mobile IP. Without proper authentication, an attacker could register a false Care-of Address with the Home Agent, redirecting all traffic destined for a mobile node to the attacker's machine—a devastating attack.
The Attack Scenario:
Mobile IPv4 Authentication:
To prevent this, Mobile IP requires a pre-shared security association between each mobile node and its Home Agent. Every Registration Request must include an authentication extension:
MN-HA Authentication Extension:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | SPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Authenticator (variable) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fields:
Authenticator Computation:
The authenticator is computed using HMAC-MD5 (historical) or HMAC-SHA-1/SHA-256 (recommended):
Authenticator = HMAC-SHA256(key, Registration_Request_Data)
Where Registration_Request_Data includes:
- All fields from Type through Identification
- Any extensions preceding the authentication extension
Replay Protection Detail:
The 64-bit Identification field contains a timestamp (NTP format) or monotonically increasing counter. The Home Agent tracks the last seen Identification for each mobile node and rejects any registration with an Identification that isn't newer:
Replay Check Algorithm:
1. Receive Registration Request with Identification I
2. Look up last_seen_identification for this MN
3. If I <= last_seen_identification:
- Reject with code 133 (Identification Mismatch)
4. Else:
- Update last_seen_identification = I
- Process registration normally
This prevents an attacker from capturing and replaying an old valid registration.
For enhanced security, Mobile IP can require IPsec protection for both registration messages and tunneled data. RFC 4555 (IKEv2 Mobility) and RFC 5266 describe mechanisms for establishing IPsec SAs that support mobility.
In production deployments, the Home Agent is a critical piece of infrastructure. If it fails, all registered mobile nodes become unreachable. High availability (HA) is therefore essential for carrier-grade deployments.
Single Point of Failure Problem:
If there's only one Home Agent and it fails:
High Availability Architectures:
| Architecture | Mechanism | Failover Time | Complexity |
|---|---|---|---|
| VRRP/HSRP | Virtual IP shared between primary/backup | 1-3 seconds | Low |
| Active-Standby Cluster | State replication, automatic failover | Sub-second | Medium |
| Active-Active Load Balancing | Multiple HAs share load, any can serve | Zero (no failover) | High |
| DNS-based | Multiple A records, client retry | 10-60 seconds | Low |
| Anycast | Same IP announced from multiple locations | 1-3 seconds (BGP convergence) | Medium |
Binding State Synchronization:
For seamless failover, the backup Home Agent must have current binding cache state. Options include:
Real-time Replication:
Periodic Sync:
No Sync (MN Re-registration):
Dynamic Home Agent Discovery:
Mobile nodes can be configured to discover Home Agents dynamically rather than using a single fixed address. RFC 5765 defines mechanisms for:
Telecommunications carriers typically require 99.999% availability ('five nines'), meaning less than 5 minutes of downtime per year. Achieving this for Home Agent infrastructure requires active-active architectures with geographic distribution and sub-second failover.
The Home Agent is the cornerstone of Mobile IP architecture. It provides the stable anchor point that makes mobility transparent to correspondent nodes and enables seamless handoffs for mobile devices.
What's Next: The Foreign Agent
Now that we understand the Home Agent, we need to explore its counterpart on the visited network: the Foreign Agent. This entity assists mobile nodes in gaining connectivity on foreign networks and often serves as the other tunnel endpoint.
In the next page, we'll examine:
You now understand the Home Agent's architecture, functions, and critical role in Mobile IP. The HA provides the stable anchor point that makes mobility possible by intercepting packets and tunneling them to wherever the mobile node currently resides.