Home Network Prefix Renumbering in Proxy Mobile IPv6 (PMIPv6)
Extracted elements (26)
Hard mode (delete old HNP binding immediately after UPA) is RECOMMENDED when renumbering coincides with LMA switchover to keep the protocol simple, trading packet loss for reduced state management complexity.
Provider-Independent (PI) IPv6 addressing would minimize renumbering needs but causes BGP scaling problems (RFC 7010). This motivated developing renumbering tools and practices (RFC 6879), and specifically this extension to support HNP renumbering in PMIPv6 when the HNP is not a PI prefix.
RFC 7077 (Update Notifications for Proxy Mobile IPv6) was adopted to support the LMA-initiated asynchronous notification to the MAG during renumbering, because base PMIPv6 (RFC 5213) binding is MAG-triggered and has no mechanism for the LMA to initiate binding state refreshment.
Soft mode was introduced to reduce packet loss during renumbering by temporarily maintaining old HNP state after renumbering so the LMA can redirect in-flight packets while the MN updates its Correspondent Nodes; however, it adds complexity via transient binding state.
DNS resource records corresponding to the MN MAY need to be updated when the HNP changes (RFC 3007), but DNS update procedures are explicitly out of scope for this document.
In Mobile IPv6 (MIPv6), HNP changes are handled by the Home Agent actively notifying the MN; PMIPv6 lacks this mechanism since binding is MAG-triggered, requiring the new UPN/UPA-based extension described in this document for equivalent functionality.
If DHCP is used to allocate addresses in PMIPv6, the DHCP infrastructure MUST also be notified about the new HNP when renumbering occurs.
If HNP renumbering occurs with LMA switchover, hard mode is RECOMMENDED to keep the protocol simple; in this mode the LMA deletes the old HNP binding state after receiving the UPA message and silently discards packets to the old HNP.
In soft mode, the binding state corresponding to the old HNP SHOULD be marked as transient binding (per RFC 6058) so it can be maintained temporarily while the MN reconnects and notifies its Correspondent Node.
In soft mode, the LMA MUST stop broadcasting the routing information about the old HNP if the old HNP is no longer anchored at that LMA after HNP renumbering completes.
The LMA MUST follow the PMIPv6 procedure to ensure that only an authorized HNP can be assigned to the MN, so that the LMA serves as the topological anchor point for the MN's exclusive new HNP.
The UPN and UPA messages MUST be protected using end-to-end security associations offering integrity and data origin authentication as specified in RFC 5213 and RFC 7077.
When HNP renumbering occurs, the LMA MUST notify the MAG about the new HNP, and the MAG MUST announce the new HNP to the attached MN via Router Advertisement or DHCP. Both the LMA and MAG MUST update routing states for the HNP and related addresses.
When the new HNP is announced or a new address is configured to the MN successfully, the MAG MUST update the related binding and routing states before sending back the UPA message to the LMA.
When the old HNP being deprecated is included in an unauthenticated RA from the MAG, the Valid Lifetime SHOULD be set to 2 hours (Preferred Lifetime set to 0) per RFC 4862, which ignores lifetimes less than 2 hours in unauthenticated RAs.
Hard mode for session connectivity: the LMA deletes the binding state of the old HNP after receiving the UPA message and silently discards packets destined to the old HNP; used when HNP renumbering coincides with LMA switchover.
Soft mode for session connectivity: the LMA temporarily maintains state for the old HNP after receiving UPA to redirect packets to the MN before the MN reconnects and notifies the Correspondent Node of its new HoA, reducing packet loss during renumbering.
The HNP renumbering procedure under the same LMA uses the RFC 7077 Update Notification (UPN) / Update Notification Acknowledgement (UPA) exchange: the LMA sends UPN with the new HNP to the MAG, the MAG notifies the MN and updates bindings, then sends UPA back to the LMA to confirm successful renumbering.
When HNP renumbering is caused by LMA switchover, the MAG initiates binding registration to the MN's new LMA per RFC 5213; the new HNP is delivered by the new LMA during the new binding procedure, and the MAG withdraws the old HNP and announces the new one to the MN.
Per RFC 4862, a Valid Lifetime less than 2 hours in an unauthenticated RA is ignored; therefore the deprecated old HNP in an unauthenticated RA SHOULD use Valid Lifetime of exactly 2 hours. Setting Valid Lifetime to 0 is only acceptable when MAG-to-MN signaling legality can be guaranteed.
UPN and UPA messages must be protected with end-to-end integrity and data origin authentication per RFC 5213 and RFC 7077 to prevent unauthorized prefix assignments or spoofed renumbering events.
HNP renumbering state flow under same LMA: (1) LMA allocates new HNP; (2) LMA sends UPN to MAG; (3) MAG sends RA or DHCP to MN; (4) MN deletes old HoA and configures new HoA; (5) MAG updates bindings and routing; (6) MAG sends UPA to LMA; (7) LMA updates routing and binding to replace old HNP.
The RA message used by the MAG to announce HNP renumbering contains two Prefix Information Options: the first carries the old HNP with Preferred Lifetime set to 0 (deprecating it), the second carries the new HNP with both Valid Lifetime and Preferred Lifetime greater than 0.
The UPA message from MAG acknowledges receipt of UPN (with A flag set); if HNP renumbering failed, the Status Code is set to 128 (FAILED-TO-UPDATE-SESSION-PARAMETERS) and subsequent LMA behavior is service-provider specific.
The UPN message from LMA to MAG sets the notification reason to 2 (UPDATE-SESSION-PARAMETERS) and includes as Mobility Options: an HNP Option (RFC 5213) containing the new HNP and a Mobile Node Identifier Option (RFC 4283) identifying the MN; order of these options is not mandated.
When DHCP is used, reception of the UPN message triggers a DHCP procedure (RFC 3315) to generate a new IPv6 Home Address based on the new HNP.