Internet Engineering Task Force (IETF) Z. Yan Request for Comments: 8191 CNNIC Category: Standards Track J. Lee ISSN: 2070-1721 Sangmyung University X. Lee CNNIC August 2017 Home Network Prefix Renumbering in Proxy Mobile IPv6 (PMIPv6)
AbstractIn the basic Proxy Mobile IPv6 (PMIPv6) specification, a Mobile Node (MN) is assigned with a Home Network Prefix (HNP) during its initial attachment, and the MN configures its Home Address (HoA) with the HNP. During the movement of the MN, the HNP remains unchanged to keep ongoing communications associated with the HoA. However, the current PMIPv6 specification does not specify related operations when HNP renumbering has occurred (e.g., due to change of service provider or site topology, etc.). In this document, a solution to support HNP renumbering is proposed, as an optional extension of the PMIPv6 specification. Status of This Memo This is an Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc8191.
Copyright Notice Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 2. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . . . 3 3. HNP Renumbering Procedure . . . . . . . . . . . . . . . . . . 4 4. Session Connectivity . . . . . . . . . . . . . . . . . . . . 6 5. Message Format . . . . . . . . . . . . . . . . . . . . . . . 6 6. Other Issues . . . . . . . . . . . . . . . . . . . . . . . . 7 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 9.1. Normative References . . . . . . . . . . . . . . . . . . 8 9.2. Informative References . . . . . . . . . . . . . . . . . 9 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
RFC7010]. It is thus desirable to develop tools and practices that make IPv6 renumbering a simpler process to reduce demand for IPv6 PI space [RFC6879]. In this document, we aim to support HNP renumbering when the HNP in PMIPv6 [RFC5213] is not a PI prefix. RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. RFC6463]. Scenario 3: PMIPv6 HNP renumbering MAY be caused by the rebuilding 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 Scenario 1, we assume that only the HNP is renumbered, while the serving LMA remains unchanged; this is the basic scenario considered in this document. In Scenarios 2 and 3, more complex situations MAY result; for example, HNP renumbering MAY occur due to the switchover of a serving LMA.
In the Mobile IPv6 (MIPv6) protocol, when an HNP changes, the Home Agent (HA) will actively notify its MN about the new prefix, and then the renumbering of the Home Network Address (HoA) can be well supported [RFC6275]. In basic PMIPv6, the PMIPv6 binding is triggered by a Mobile Access Gateway (MAG), which detects the attachment of the MN. A scheme is also needed for the LMA to immediately initiate the PMIPv6 binding state refreshment during the HNP renumbering process. Although this issue is also mentioned in Section 6.12 of [RFC5213], the related solution has not been specified. RFC7077] can be adopted; it specifies an asynchronous update from the LMA to the MAG about specific session parameters. This document considers the following two cases: (1) HNP is renumbered under the same LMA In this case, the LMA remains unchanged as in Scenarios 1 and 3. The steps are shown in Figure 1. +-----+ +-----+ +-----+ | MN | | MAG | | LMA | +-----+ +-----+ +-----+ | | | | | Allocate new HNP | | | | |<------------- UPN ---| | | | | | | | | | |<-----RA/DHCP --------| | | | | Address configuration | | | | | | Update binding & routing states | | | | | |--- UPA ------------->| | | | | | Update binding & routing states | | | Figure 1: Signaling Call Flow for HNP Renumbering
o When a PMIPv6 service provider renumbers the HNP set under the same LMA, the serving LMA SHOULD initiate the HNP renumbering operation. The LMA allocates a new HNP for the related MN. o 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 to allocate the address, the DHCP infrastructure MUST also be notified about the new HNP. o Once the MAG receives this UPN message, it recognizes that the related MN has the new HNP. Then, the MAG MUST notify the MN about the new HNP with a Router Advertisement (RA) message or allocate a new address within the new HNP through a DHCP procedure. o After the MN obtains the HNP information through the RA message, it deletes the old HoA and configures a new HoA with the newly allocated HNP. o When the new HNP is announced or the new address is configured to the MN successfully, the MAG MUST update the related binding and routing states. Then, the MAG sends back the Update Notification Acknowledgement (UPA) message to the LMA for the notification of successful update of the HNP, related binding state, and routing state. Then, the LMA updates the routing and binding information corresponding to the MN in order to replace the old HNP with the new one. (2) HNP renumbering is caused by the LMA switchover Since the HNP is assigned by the LMA, HNP renumbering MAY be caused by the LMA switchover, as in Scenarios 2 and 3. The LMA information is the basic configuration information of the MAG. When the LMA changes, the related profile SHOULD be updated by the service provider. In this way, the MAG initiates the binding registration to the MN's new LMA as specified in [RFC5213]. When HNP renumbering is caused in this case, the new HNP information is sent by the LMA during the new binding procedure. Accordingly, the MAG withdraws the old HNP of the MN and announces the new HNP to the MN, similar to the case when the HNP is renumbered under the same LMA.
RFC6058]. Also, the LMA MUST stop broadcasting the routing information about the old HNP if the old HNP is no longer anchored at this LMA. (2) Hard mode If HNP renumbering happens with the switchover of the LMA, hard mode is RECOMMENDED to keep the protocol simple. In this mode, the LMA deletes the binding state of the old HNP after it receives the UPA message from the MAG, and the LMA silently discards the packets destined to the old HNP. RFC5213] containing the new HNP and the Mobile Node Identifier Option [RFC4283] (which identifies the MN) are contained as Mobility Options of UPN. The order of the HNP Option and Mobile Node Identifier Option in the UPN message is not mandated here. (2) UPA message The MAG sends this message in order to acknowledge that it has received an UPN message with the (A) flag set and to indicate the status after processing the message. If the MAG did not successfully renumber the HNP, which is required in the UPN message, the UPA message has the Status Code set to 128 (FAILED- TO-UPDATE-SESSION-PARAMETERS), and the subsequent operation of the LMA is PMIPv6 service provider specific.
(3) RA message When the RA message is used by the MAG to advise the new HNP, it contains two Prefix Information Options [RFC4861] [RFC4862]. In the first Prefix Information Option, the old HNP is carried, and the related Preferred Lifetime is 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. (4) DHCP message When the DHCP is used in PMIPv6 to configure the addresses for the MN, new IPv6 address or addresses (e.g., the HoA) will be generated based on the new HNP, and the related DHCP procedure is also triggered by the reception of the UPN message [RFC3315]. RFC3007]. However, this is beyond the scope of this document. RFC5213] and [RFC7077]. When HNP renumbering is triggered, a new HNP SHOULD be allocated to the MN. The LMA MUST follow the procedure of PMIPv6 to make sure that only an authorized HNP can be assigned for the MN. In this way, the LMA is ready to be the topological anchor point of the new HNP, which is for that MN's exclusive use. Per [RFC4862], if the Valid Lifetime in a Prefix Information Option is set to less than 2 hours in an unauthenticated RA, it is ignored. Thus, when the old HNP that is being deprecated is included in an RA from the MAG, the Valid Lifetime SHOULD be set to 2 hours (and the Preferred Lifetime set to 0) for an unauthenticated RA. However, if the legality of the signaling messages exchanged between MAG and MN can be guaranteed, it MAY be acceptable to also set the Valid Lifetime to 0 for an unauthenticated RA.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>. [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic Update", RFC 3007, DOI 10.17487/RFC3007, November 2000, <http://www.rfc-editor.org/info/rfc3007>. [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 2003, <http://www.rfc-editor.org/info/rfc3315>. [RFC4283] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K. Chowdhury, "Mobile Node Identifier Option for Mobile IPv6 (MIPv6)", RFC 4283, DOI 10.17487/RFC4283, November 2005, <http://www.rfc-editor.org/info/rfc4283>. [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, DOI 10.17487/RFC4861, September 2007, <http://www.rfc-editor.org/info/rfc4861>. [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, DOI 10.17487/RFC4862, September 2007, <http://www.rfc-editor.org/info/rfc4862>. [RFC5213] Gundavelli, S., Ed., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, DOI 10.17487/RFC5213, August 2008, <http://www.rfc-editor.org/info/rfc5213>. [RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July 2011, <http://www.rfc-editor.org/info/rfc6275>. [RFC6463] Korhonen, J., Ed., Gundavelli, S., Yokota, H., and X. Cui, "Runtime Local Mobility Anchor (LMA) Assignment Support for Proxy Mobile IPv6", RFC 6463, DOI 10.17487/RFC6463, February 2012, <http://www.rfc-editor.org/info/rfc6463>.
[RFC7077] Krishnan, S., Gundavelli, S., Liebsch, M., Yokota, H., and J. Korhonen, "Update Notifications for Proxy Mobile IPv6", RFC 7077, DOI 10.17487/RFC7077, November 2013, <http://www.rfc-editor.org/info/rfc7077>. [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <http://www.rfc-editor.org/info/rfc8174>. [RFC6058] Liebsch, M., Ed., Muhanna, A., and O. Blume, "Transient Binding for Proxy Mobile IPv6", RFC 6058, DOI 10.17487/RFC6058, March 2011, <http://www.rfc-editor.org/info/rfc6058>. [RFC6879] Jiang, S., Liu, B., and B. Carpenter, "IPv6 Enterprise Network Renumbering Scenarios, Considerations, and Methods", RFC 6879, DOI 10.17487/RFC6879, February 2013, <http://www.rfc-editor.org/info/rfc6879>. [RFC7010] Liu, B., Jiang, S., Carpenter, B., Venaas, S., and W. George, "IPv6 Site Renumbering Gap Analysis", RFC 7010, DOI 10.17487/RFC7010, September 2013, <http://www.rfc-editor.org/info/rfc7010>.