DMM Working Group Z. Yan Internet-Draft CNNIC Intended status: Standards Track J. Lee Expires: January 2, 2017 Sangmyung University X. Lee CNNIC July 1, 2016 Home Network Prefix Renumbering in PMIPv6 draft-ietf-dmm-hnprenum-03 Abstract In 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 is remained unchanged to keep ongoing communications associated with the HoA. However, the current PMIPv6 specification does not specify related operations when an HNP renumbering is happened. In this document, a solution to support the HNP renumbering is proposed, as an update of the PMIPv6 specification. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL","SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on January 2, 2017. Yan, et al. Expires January 2, 2017 [Page 1] Internet-Draft PMIPv6 HNP Renumbering July 2016 Copyright Notice Copyright (c) 2016 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . . . 2 3. PMIPv6 Extensions . . . . . . . . . . . . . . . . . . . . . . 3 4. Session Connectivity . . . . . . . . . . . . . . . . . . . . 5 5. Message Format . . . . . . . . . . . . . . . . . . . . . . . 6 6. Other Issues . . . . . . . . . . . . . . . . . . . . . . . . 6 7. Security Considerations . . . . . . . . . . . . . . . . . . . 6 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 9.1. Normative References . . . . . . . . . . . . . . . . . . 7 9.2. Informative References . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 1. Introduction Network managers currently prefer Provider Independent (PI) addressing for IPv6 to attempt to minimize the need for future possible renumbering. However, a widespread use of PI addresses may cause Border Gateway Protocol (BGP) scaling problems. 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 solve the HNP renumbering problem when the HNP in PMIPv6 [RFC5213] is not the type of PI. 2. Usage Scenarios There are a number of reasons why the HNP renumbering support in PMIPv6 is useful and some scenarios are identified below: o Scenario 1: the HNP set used by a PMIPv6 service provider is assigned by a different Internet Service Provider (ISP), and then Yan, et al. Expires January 2, 2017 [Page 2] Internet-Draft PMIPv6 HNP Renumbering July 2016 the HNP renumbering may happen if the PMIPv6 service provider switches to a different ISP. o 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 [RFC6463]. o 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 considered in 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 a serving LMA. In the Mobile IPv6 (MIPv6) protocol, when a home network prefix changes, the Home Agent (HA) will actively notify the new prefix to its MN and then the renumbering of the Home Network Address (HoA) can be well supported [RFC6275]. In the 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. 3. PMIPv6 Extensions When the HNP renumbering happens in PMIPv6, the LMA has to notify a new HNP to an MAG and then the MAG has to announce the new HNP to the attached MN accordingly. Also, the LMA and the MAG must update the routing states for the HNP and the related addresses. To support this procedure, [RFC7077] can be adopted which 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 the scenario 1 and scenario 3. The operation steps are shown in Figure 1. Yan, et al. Expires January 2, 2017 [Page 3] Internet-Draft PMIPv6 HNP Renumbering July 2016 +-----+ +-----+ +-----+ | 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 of the HNP renumbering o When a PMIPv6 service provider renumbers the HNP set under the same LMA, the serving LMA will 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 new HNP should be also notified to the DHCP infrastructure. o Once the MAG receives this UPN message, it recognizes that the related MN has the 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 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 updates 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 Yan, et al. Expires January 2, 2017 [Page 4] Internet-Draft PMIPv6 HNP Renumbering July 2016 state. Then the LMA updates the routing and binding information corresponding to the MN to replace the old HNP with the new one. (2) HNP renumbering caused by the LMA switchover Since 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 initiates the registration to the new LMA as specified in [RFC5213]. When the 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 as like the case of the HNP is renumbered under the same LMA. 4. Session Connectivity The 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 UPA 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 corresponding to the old HNP should be marked for example as transient binding [RFC6058]. This temporary binding should only be used for the downwards packet transmission and the LMA should stop broadcasting the routing information about the old HNP if the old HNP 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. 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. Yan, et al. Expires January 2, 2017 [Page 5] Internet-Draft PMIPv6 HNP Renumbering July 2016 5. Message Format (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 [RFC5213] containing the new HNP and the Mobile Node Identifier Option [RFC4283] carrying identifier of MN are contained as Mobility Options of UPN. The order of HNP Option and Mobile Node Identifier Option in the UPN message is not mandated in this draft. (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. When the MAG did not successfully renumber the HNP which is required in the UPN message, the Status Code of 128 is set in the UPA message and the following operation of LMA is PMIPv6 service provider specific. (3) 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 [RFC4861]. 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. (4) DHCP Message When the DHCP is used in PMIPv6 to configure the addresses for the MN, new IPv6 address(es) (e.g., HoA) will be generated based on the new HNP and the related DHCP procedure is also triggered by the reception of UPN message [RFC3315]. 6. Other Issues 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 [RFC3007]. However, this is beyond the scope of this document. 7. Security Considerations The protection of UPN and UPA messages in this document follows [RFC5213] and [RFC7077]. This extension causes no further security problem. Yan, et al. Expires January 2, 2017 [Page 6] Internet-Draft PMIPv6 HNP Renumbering July 2016 8. IANA Considerations This document presents no IANA considerations. 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic Update", RFC 3007, DOI 10.17487/RFC3007, November 2000, . [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, . [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, . [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, . [RFC5213] Gundavelli, S., Ed., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, DOI 10.17487/RFC5213, August 2008, . [RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July 2011, . [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, . Yan, et al. Expires January 2, 2017 [Page 7] Internet-Draft PMIPv6 HNP Renumbering July 2016 [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, . 9.2. Informative References [RFC6058] Liebsch, M., Ed., Muhanna, A., and O. Blume, "Transient Binding for Proxy Mobile IPv6", RFC 6058, DOI 10.17487/RFC6058, March 2011, . [RFC6879] Jiang, S., Liu, B., and B. Carpenter, "IPv6 Enterprise Network Renumbering Scenarios, Considerations, and Methods", RFC 6879, DOI 10.17487/RFC6879, February 2013, . Authors' Addresses Zhiwei Yan CNNIC No.4 South 4th Street, Zhongguancun Beijing 100190 China EMail: yan@cnnic.cn Jong-Hyouk Lee Sangmyung University 31, Sangmyeongdae-gil, Dongnam-gu Cheonan 31066 Republic of Korea EMail: jonghyouk@smu.ac.kr Xiaodong Lee CNNIC No.4 South 4th Street, Zhongguancun Beijing 100190 China EMail: xl@cnnic.cn Yan, et al. Expires January 2, 2017 [Page 8]