Hierarchical Mobile IPv6 (HMIPv6) Mobility Management
obsoletes
- rfc-4140 — Hierarchical Mobile IPv6 Mobility Management (HMIPv6)
Extracted elements (26)
Dynamic MAP Discovery from RFC 4140 was removed in this specification because its scalability was seen as inappropriate for large-scale deployments and it was prone to routing loops. MAP configuration is now static (manual AR configuration).
HMIPv6 provides location privacy: the mobile node hides its LCoA from correspondent nodes and the home agent by using the RCoA as source address. Address-based location tracking by CNs or the HA is more difficult since they only know the RCoA, not the actual on-link address.
The default MAP selection algorithm in a distributed MAP environment selects the most distant (furthest) available MAP with non-zero preference and non-zero valid lifetime. A more distant MAP reduces the probability of frequent re-registrations, particularly important for fast-moving mobile nodes.
The MAP reduces signalling overhead by requiring only one binding update message from the mobile node when it moves within a MAP domain, regardless of the number of correspondent nodes. Only the RCoA (not the LCoA) needs to be registered with CNs and the HA, making intra-domain mobility transparent.
HMIPv6 is designed to require updates only to mobile node implementations. The home agent and correspondent node operations are completely unchanged and transparent to HMIPv6. An HMIPv6-aware mobile node with a Mobile IPv6 implementation SHOULD choose to use the MAP when discovering such capability, but may fall back to standard Mobile IPv6.
A mobile node MUST store received MAP options in order to choose at least one MAP to register with; storing is essential for comparing options received later for movement detection.
After registering with the MAP, the mobile node MUST register its new RCoA with its home agent. The binding lifetime with the HA and CNs MUST NOT be larger than the mobile node's binding lifetime with the MAP as received in the binding acknowledgement.
If the mobile node receives a MAP option with a valid lifetime of zero, it MUST NOT select that MAP. The mobile node MUST choose another MAP and create new bindings. If no other MAP is available, the mobile node MUST NOT attempt to use HMIPv6.
If the R flag is set in the MAP option, the mobile node MUST place its RCoA in place of the home address in the binding update message, causing the RCoA to be bound to the LCoA in the MAP's binding cache.
IKEv2 MUST be supported by both the mobile node and the MAP to establish the security association. Binding updates between the MAP and the mobile node MUST be protected with AH or ESP in transport mode; when ESP is used, a non-null authentication algorithm MUST be used.
Mobile nodes MUST consider the encapsulation of traffic between the node and the MAP when calculating the available MTU for upper layers, as HMIPv6 tunnelling may result in double encapsulations when a home agent also exists.
The MAP MUST be able to accept packets tunnelled from the mobile node, with the mobile node as the tunnel entry point and the MAP as the tunnel exit point.
The MAP MUST return a binding acknowledgement to the mobile node upon successful MAP registration. The binding acknowledgement MUST include a routing header type 2 containing the mobile node's RCoA.
The mobile node MUST NOT use one RCoA derived from one MAP's prefix as a care-of address in its binding update to another MAP, as this would cause multiple encapsulations and reduce protocol efficiency.
The mobile node MUST silently ignore binding acknowledgements from the MAP that do not contain a routing header type 2 including the mobile node's RCoA.
When a mobile node registers with the MAP, the M and A flags MUST be set in the binding update to distinguish MAP registration from BUs sent to the HA or correspondent nodes.
A bi-directional tunnel is established between the mobile node and the MAP after successful registration. Outbound packets use the mobile node's LCoA as outer source and MAP address as outer destination; inbound packets addressed to the RCoA are intercepted by the MAP via proxy Neighbour Advertisement and tunnelled to the LCoA.
MAP discovery is performed via Router Advertisements containing MAP options. ARs are manually configured with MAP option information. A mobile node receiving a MAP option with a changed MAP address MUST act on the change by sending binding updates to its HA and correspondent nodes.
The Mobility Anchor Point (MAP) is a new Mobile IPv6 node located in a visited network that acts as a local home agent. It intercepts packets addressed to registered mobile nodes and tunnels them to the mobile node's current on-link CoA (LCoA), limiting Mobile IPv6 signalling outside the local domain.
The Regional Care-of Address (RCoA) is an address allocated by the MAP to the mobile node, formed stateless by combining the mobile node's interface identifier with the subnet prefix received in the MAP option. The LCoA is the on-link CoA configured on the mobile node's interface based on the prefix advertised by its default router.
Binding updates between the MAP and the mobile node must be authenticated; otherwise any host could send a BU for the mobile node's RCoA and hijack the mobile node's packets. The MAP sets the SA for the RCoA using IKEv2, with the RCoA used as the identity in the IKE CHILD_SA negotiation.
Mobile node implementers must carefully select the source address of HoTI and CoTI messages for the return routability procedure. The HoTI source address SHOULD be the mobile node's home address unless the RCoA is used for route optimisation; the packet is double-encapsulated with the RCoA in the inner header source and the LCoA in the outer header source.
The security relationship between the mobile node and the MAP MUST involve mutual authentication, integrity protection, and protection against replay attacks. Without these, malicious nodes could impersonate legitimate mobile nodes or impersonate a MAP, disrupting communication with all correspondent nodes knowing the mobile node's RCoA.
Mobile node MAP selection follows an Eager-Lazy model: the mobile node eagerly registers with any new MAP advertised by the AR, and lazily releases existing bindings only when the MAP option is no longer received, received with lifetime zero, or the existing binding lifetime expires. This provides fallback during MAP failures.
The Local Binding Update extends the Mobile IPv6 Binding Update with a new M flag (bit 4 in the flags field). When set to 1, M indicates a MAP registration. Both the A and M flags MUST be set when a mobile node registers with the MAP.
The MAP Option for IPv6 Neighbour Discovery (Type=23, Length=3) contains: a 4-bit Dist field (hop count distance from MAP, starting at 1, zero MUST NOT be used), a 4-bit Pref field (operator preference, 15=highest), an R flag (RCoA allocation via RFC 4877), a 32-bit Valid Lifetime field, and a 128-bit Global IP Address for the MAP.