DMM Working Group Zhiwei Yan Internet Draft CNNIC Expires: July 2015 Jong-Hyouk Lee Sangmyung University Xiaodong Lee CNNIC January 9, 2015 Home Network Prefix Renumbering in PMIPv6 draft-yan-dmm-hnprenum-00.txt Abstract In the basic Proxy Mobile IPv6 (PMIPv6) specification, a Mobile Node (MN) is assigned a 64-bit Home Network Prefix (HNP) during the initial attachment for the Home Address (HoA) configuration. During the movement of the MN, this prefix is unchanged and unnecessary for the MN to reconfigure the HoA. However, the current protocol does not specify related operations to support the MN to timely receive and configure a new HNP when the allocated HNP changes. In this draft, this problem is discussed and a possible solution is proposed based on RFC 7077. 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 to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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". The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Yan et al. Expires Jul,2015 [Page 1] Internet-Draft HNP Renumbering in PMIPv6 January 9, 2015 This Internet-Draft will expire on July, 2015. Copyright Notice Copyright (c) 2010 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. HNP renumbering support...................................... 3 3. DNS update .................................................. 4 4. Security Considerations...................................... 4 5. References .................................................. 4 Authors' Addresses ............................................. 5 Acknowledgment ................................................. 5 1. Introduction Network managers currently prefer to Provider Independent (PI) addressing for IPv6 to attempt to minimize the need for future renumbering. However, widespread use of PI may create very serious BGP scaling problems. It is thus desirable to develop tools and practices that may make renumbering a simpler process to reduce demand for IPv6 PI space [1]. In this draft, we aims to solve the HNP renumbering problem when the HNP in PMIPv6 [2] is not a PI type. Then the HNP renumbering may happen at least in the following three cases: In the first case, the PMIPv6 service provider is assigned the HNP set from the (uplink) ISP, and then the HNP renumbering will happen if the PMIPv6 service provider switches to a different ISP. Yan et al. Expires July,2015 [Page 2] Internet-Draft HNP Renumbering in PMIPv6 January 9, 2015 In the second case, 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 a MN may change if the current serving LMA switches to another LMA but without inheriting the assigned HNP [3]. In the last case, 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. For the Mobile IPv6 (MIPv6), when the home network prefix changes (maybe due to 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 [4]. While in the basic PMIPv6, the PMIPv6 binding is triggered by the Mobile Access Gateway (MAG), which detects the attachment of the MN. When the HNP renumbering happens in the first case or the LMA and HNP both changes in the second or third cases, a scheme is needed for the LMA to immediately initiate the PMIPv6 binding state refreshment. Although this issue is also discussed in the RFC 5213 (section 6.12), the related solution is not specified. 2. HNP renumbering support RFC 7077 [5] specifies a scheme to support the asynchronously update from the LMA to the MAG about changes related to a mobility session. With this protocol, the HNP renumbering can be easily supported and the basic operation is summarized as following: 1) When the PMIPv6 service provider renumbers the HNP set or the serving LMA switches to another one but does not inherit the related HNP, the current LMA (or new LMA) will initiate the HNP renumbering operation. Firstly, it should allocate a new HNP for the related MN. 2) The LMA sends the Update Notification (UPN) message to the MAG. In the UPN message, the Notification reason is set to 2 (UPDATE- SESSION-PARAMETERS). Besides, HNP option containing the new HNP and the Mobile Node Identifier option carrying MN'ID are contained as Mobility Options of UPN. 3) After the MAG receives this UPN message, it will recognize that the related MN has a new HNP now. Then the MAG sends the old HNP in the RA with zero-valued lifetime to the MN and sends the new HNP in the RA with lifetime larger than zero. Yan et al. Expires July,2015 [Page 3] Internet-Draft HNP Renumbering in PMIPv6 January 9, 2015 4) Besides, the MAG sends back the Update Notification Acknowledgement (UNA) to the LMA for the notification of successful update of the related binding state, routing state and RA settings. 5) For the MN, it deletes the old HoA due to the zero-valued lifetime RA advertisement and configures a new HoA with the meaningful HNP. The detailed protocol operation and signaling message extensions will be specified further. 3. DNS update In order to maintain the reachability of the MN, the DNS resource record corresponding to this MN may need to be updated when the HNP of MN changes. Although this operation in PMIPv6 has not been specified by the current protocols, we here list two important issues to be considered for this operation. 1) Since the DNS update must be performed securely in order to prevent attacks or modifications from malicious ones, the node performing this update must share a security association with the DNS server [6]. If the MN does not share a security association with the DNS server and the DNS entry update can be performed by the network entities, such as Authentication, Authorization and Accounting (AAA) server or LMA. 2) For the dynamic update, another important issue should be considered is the TTL setting when the HNP renumbering is possible. The TTL should be set according to the possible lifetime of the HNP. 4. Security Considerations The security considerations in PMIPv6 protocol are enough for the basic operation of this draft. Besides, the security dynamic DNS should be supported whatever the DNS update is executed by network entities or MN itself. In other words, the security association should always be established between the DNS server and updater. Other security issues will be added further. 5. References [1] S. Jiang, B. Liu, and B. Carpenter, "IPv6 Enterprise Network Renumbering Scenarios and Guidelines", RFC 6879, February 2013. Yan et al. Expires July,2015 [Page 4] Internet-Draft HNP Renumbering in PMIPv6 January 9, 2015 [2] S. Gundavelli, K. Leung, V. Devarapalli, K. Chowdhury, and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. [3] J. Korhonen, S. Gundavelli, H. Yokota, and X. Cui, "Runtime Local Mobility Anchor (LMA) Assignment Support for Proxy Mobile IPv6", RFC 6463, February 2012. [4] C. Perkins, D. Johnson, and J. Arkko, "Mobility Support in IPv6", RFC 6275, July 2011. [5] S. Krishnan, S. Gundavelli, M. Liebsch, H. Yokota and J. Korhonen, "Update Notifications for Proxy Mobile IPv6", RFC 7077, November 2013. [6] Wellington, B., "Secure Domain Name System (DNS) Dynamic Update", RFC 3007, November 2000. Authors' Addresses Zhiwei Yan China Internet Network Information Center No.4 South 4th Street, Zhongguancun Beijing, P. R. China Email: yan@cnnic.cn Jong-Hyouk Lee Department of Computer Science and Engineering Sangmyung University 31, Sangmyeongdae-gil, Dongnam-gu Cheonan, Republic of Korea E-mail: jonghyouk@smu.ac.kr Xiaodong Lee China Internet Network Information Center No.4 South 4th Street, Zhongguancun Beijing, P. R. China Email: xl@cnnic.cn Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Yan et al. Expires July,2015 [Page 5]