Home Network Prefix Renumbering in PMIPv6

Network managers currently prefer Provider Independent (PI) addressing for IPv6 to attempt to minimize the need for future possible renumbering. However, widespread use of PI addresses may cause Border Gateway Protocol (BGP) scaling problems. It is thus desirable to develop tools and practices that may make IPv6 renumbering a simpler process to reduce demand for IPv6 PI space . In this draft, we aim to solve the HNP renumbering problem when the HNP in PMIPv6 is not the type of PI.

There are a number of reasons why the HNP renumbering support in PMIPv6 is useful and a few are identified below: Scenario 1: the PMIPv6 service provider is assigned with the HNP set from the (uplink) Internet Service Provider (ISP), and then the HNP renumbering may happen if the PMIPv6 service provider switches to a different ISP. Scenario 2: multiple Local Mobility Anchors (LMAs) may be deployed by the same PMIPv6 service provider, and then each LMA may serve for a specific HNP set. In this case, the HNP of an MN may change if the current serving LMA switches to another LMA but without inheriting the assigned HNP set . Scenario 3: the PMIPv6 HNP renumbering may be caused by the re-building of the network architecture as the companies split, merge, grow, relocate or reorganize. For example, the PMIPv6 service provider may reorganize its network topology. In the scenario 1, we assume that only the HNP is renumbered while the serving LMA remains unchanged and this is the basic scenario of this document. In the scenario 2 and scenario 3, more complex results may be caused, for example, the HNP renumbering may happen due to the switchover of serving LMA. In the Mobile IPv6 (MIPv6) protocol, when the home network prefix changes (may also be caused by the above reasons), the Home Agent (HA) will actively notify the new prefix to the MN and then the renumbering of the HoA can be well supported . While in the basic PMIPv6, the PMIPv6 binding is triggered by the Mobile Access Gateway (MAG), which detected the attachment of the MN. When the HNP renumbering happens, a scheme is also needed for the LMA to immediately initiate the PMIPv6 binding state refreshment. Although this issue is also discussed in Section 6.12 of , the related solution has not been specified.

When the HNP renumbering happens in PMIPv6, the LMA has to notify the new HNP to the MAG and then the MAG has to announce the new HNP to the MN accordingly. Also, the LMA and the MAG must update the routing states for the prefixes. To support this procedure, can be adopted which specifies asynchronously update from the LMA to the MAG about the session parameters. This document considers the following two cases: (1) HNP is renumbered in the same LMA In this case, the LMA remains unchanged as in the scenario 1 and scenario 3. The operation steps are shown in Figure 1.

| | | | | | Update routing state | | | ]]> When the PMIPv6 service provider renumbers the HNP set in the same LMA, the serving LMA will initiate the HNP renumbering operation. The LMA allocates a new HNP for the related MN. The LMA sends the Update Notification (UPN) message to the MAG to update the HNP information. If the Dynamic Host Configuration Protocol (DHCP) is used in PMIPv6 to allocate the HoA, the new HNP should be also notified to the DHCP infrastructure. After the MAG receives this UPN message, it recognizes that the related MN has a new HNP. Then the MAG should notify the MN about the new HNP with a Router Advertisement (RA) message or allocate a new address within the new HNP with a DHCP message. When the MN obtains the new HNP information, it deletes the old HoA and configures a new HoA with the newly allocated HNP. The MAG sends back the Update Notification Acknowledgement (UNA) to the LMA for the notification of successful update of the HNP, related binding state, and routing state. Then the LMA updates the routing information corresponding to the MN to replace the old HNP with the new one. (2) HNP renumbering caused by LMA switchover Because the HNP is assigned by the LMA, the HNP renumbering may be caused by the LMA switchover, as in the scenario 2 and scenario 3. The information of LMA is the basic configuration information of MAG. When the LMA changes, the related profile should be updated by the service provider. In this way, the MAG will initiate the re-registration to the new LMA as specified in . When the HNP renumbering is caused in this case, the new HNP information will be sent by the LMA during the new binding procedure. Accordingly, the MAG will withdraw the old HNP information of the MN and advise the new HNP to the MN as the 3rd Step in Section 3(1).

HNP renumbering may cause the disconnection of the ongoing communications of the MN. Basically, there are two modes to manage the session connectivity during the HNP renumbering. (1) Soft-mode The LMA will temporarily maintain the state of the old HNP during the HNP renumbering (after the UNA reception) in order to redirect the packets to the MN before the MN reconnects the ongoing session and notifies its new HoA to the Correspondent Node (CN). This mode is aiming to reduce the packet loss during the HNP renumbering but the binding state and routing entry corresponding to the old HNP should be marked for example as transient binding . This temporary binding should only be used for the downwards packet transmission and the LMA should not broadcast the routing information about the old HNP if it is no longer anchored at this LMA. (2) Hard-mode If the HNP renumbering happens with the switchover of the LMA, the hard-mode is recommended to keep the protocol simple and efficient.In this mode, the LMA will delete the state of the old HNP after it receives the UNA message from MAG and the LMA will silently discard the packets destined to the old HNP.

(1) UPN message In the UPN message sent from the LMA to the MAG, the notification reason is set to 2 (UPDATE-SESSION-PARAMETERS). Besides, the HNP option containing the new HNP and the Mobile Node Identifier option carrying Identifier of MN are contained as Mobility Options of UPN. (2) RA Message When the RA message is used by the MAG to advise the new HNP, two Prefix Information options are contained in the RA message . In the first Prefix Information option, the old HNP is carried but both the related Valid Lifetime and Preferred Lifetime are set to 0. In the second Prefix Information option, the new HNP is carried with the Valid Lifetime and Preferred Lifetime set to larger than 0. (3) DHCP Message When the DHCP is used in PMIPv6 to configure the HoA for the MN, a new IPv6 HoA is generated based on the new HNP. Trigged by the UPN message, the MAG will request the new HoA from the DHCP server first and then the MAG updates the allocated HoA to the MN through the DHCP server-initiated configuration exchange .

In order to maintain the reachability of the MN, the Domain Name System (DNS) resource record corresponding to this MN may need to be updated when the HNP of MN changes . However, this is out the scope of this draft.

This extension causes no further security problem. The security considerations in and are enough for the basic operation of this draft.