Summary

  • RFC 6276 requires an away-from-home mobile router to register with its home agent before it begins the DHCPv6 exchange for prefix delegation, even though it may not yet know the prefixes it will receive.
  • A valid DHCPv6 Prefix Delegation lease is the condition for adding a prefix to the mobile router's binding-cache entry; neither the earlier registration nor the later prefix record alone proves traffic forwarding or reachability.

The most misleading line in a mobility log may be the one that says “registered.” It seems to settle the question: a mobile router sent a Binding Update, a home agent accepted the registration, and a network is now mobile. But RFC 6276 places another decision after that line. The router must register before it starts DHCPv6 Prefix Delegation, precisely because it may not yet know the mobile-network prefixes it will ask to use.

That order matters. The July 2011 Standards Track RFC, DHCPv6 Prefix Delegation for Network Mobility (NEMO), lists Wassim Haddad among its authors. Its problem is configuration of prefixes for links behind a mobile router. It does not make a Binding Acknowledgement a universal receipt for every prefix, every attached node, or every packet that might later traverse a tunnel.

The first state is Mobile IPv6 registration. An away-from-home router MUST send a Binding Update to its home agent before it initiates DHCPv6 messages for prefix delegation. The RFC calls for implicit Binding Update signaling because the router may not yet have requested any prefixes. A registration answers one limited question: the home-agent relationship required to begin this process exists under the protocol's terms. It does not answer which prefix will be delegated.

The second state is DHCPv6 delegation. The mobile router is the requesting router and the home agent the delegating router. If the router has no active delegated prefixes, it sends Solicit; the home agent responds with Advertise; the router sends Request; and the delegating router includes delegated prefixes in Reply. RFC 3633 supplies the broader model: a delegating router chooses a prefix, returns it to the requesting router, and the requesting router is responsible for it within its assigned lifetime. A Reply records delegation.

It is not an observation that an attached device used the prefix, that a tunnel carried traffic, or that a remote service replied.

The third state is narrower still. RFC 6276 says that once DHCPv6 signaling is complete, the home agent MUST add the delegated prefixes to the binding cache. Its security section sharpens that instruction. The home agent MUST add a prefix only when the mobile router has a valid DHCPv6 Prefix Delegation lease for that prefix; without that lease, it MUST NOT add it. The stated purpose is to avoid forwarding traffic addressed to prefixes that have not yet been delegated to the mobile router.

This is a prefix-specific authorization edge, not a packet receipt. It says what the home agent is permitted to place in the binding cache after the defined delegation condition. It does not show that an intercept occurred, that encapsulation succeeded, that the mobile router was still reachable, that a downstream link had a node, or that an application completed work. Those propositions need different observations at different points.

The distinction also prevents the inverse error. A DHCPv6 Reply should not be treated as proof that forwarding was already enabled. RFC 6276 places the binding-cache action after completion of DHCPv6 signaling and ties it to the valid lease. An investigation should preserve the joins: router identity, home-agent identity, Binding Update and acknowledgement, DHCPv6 transaction, exact prefix, IA_PD identity where available, lease lifetime, binding-cache change, and a separate packet observation if traffic is the question.

RFC 6275 gives the surrounding restraint. Mobile IPv6 does not attempt to solve every problem of mobile computers or wireless networks, including partial reachability, access control, service discovery and mobile routers. RFC 6276 adds a defined prefix-delegation path for Network Mobility; it does not turn an RFC diagram into proof that a real foreign access network, tunnel, customer or service has operated successfully.

That is the practical reading of Heng Lu's Running-Code Primacy and Minimum Initial Specification. Record the smallest observable fact that each mechanism supports. A registration record belongs to registration. A DHCPv6 record belongs to delegation. A valid-lease binding-cache record belongs to home-agent forwarding authorization for one prefix. Runtime packet evidence and service evidence retain their own owners. Combining the records may support a bounded operational conclusion; replacing one with another erases the condition the RFC preserved.

Haddad's contribution can be described without borrowing authority from the networks the RFC coordinates. He is one author of a collective standard that keeps the prefix decision after registration and makes the lease condition explicit. That authorship does not identify a current Ericsson deployment, a live mobile router, a home agent, a route, a traffic flow or an outcome.

Sources