idnits 2.17.1 draft-yan-dmm-hnprenum-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 62 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 5 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' 1. Introduction' ) ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 4. Security Considerations' ) ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 57 instances of too long lines in the document, the longest one being 4 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (January 9, 2015) is 3394 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'RFC2119' on line 30 looks like a reference -- Missing reference section? '1' on line 186 looks like a reference -- Missing reference section? '2' on line 189 looks like a reference -- Missing reference section? '3' on line 192 looks like a reference -- Missing reference section? '4' on line 196 looks like a reference -- Missing reference section? '5' on line 199 looks like a reference -- Missing reference section? '6' on line 203 looks like a reference Summary: 4 errors (**), 0 flaws (~~), 5 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DMM Working Group Zhiwei Yan 3 Internet Draft CNNIC 4 Expires: July 2015 Jong-Hyouk Lee 5 Sangmyung University 6 Xiaodong Lee 7 CNNIC 8 January 9, 2015 10 Home Network Prefix Renumbering in PMIPv6 11 draft-yan-dmm-hnprenum-00.txt 13 Abstract 15 In the basic Proxy Mobile IPv6 (PMIPv6) specification, a Mobile Node 16 (MN) is assigned a 64-bit Home Network Prefix (HNP) during the 17 initial attachment for the Home Address (HoA) configuration. During 18 the movement of the MN, this prefix is unchanged and unnecessary for 19 the MN to reconfigure the HoA. However, the current protocol does 20 not specify related operations to support the MN to timely receive 21 and configure a new HNP when the allocated HNP changes. In this 22 draft, this problem is discussed and a possible solution is proposed 23 based on RFC 7077. 25 Requirements Language 27 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 28 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 29 document are to be interpreted as described in [RFC2119]. 31 Status of this Memo 33 This Internet-Draft is submitted to IETF in full conformance with 34 the provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF), its areas, and its working groups. Note that 38 other groups may also distribute working documents as Internet- 39 Drafts. 41 Internet-Drafts are draft documents valid for a maximum of six 42 months and may be updated, replaced, or obsoleted by other documents 43 at any time. It is inappropriate to use Internet-Drafts as 44 reference material or to cite them other than as "work in progress". 46 The list of current Internet-Drafts can be accessed at 47 http://www.ietf.org/ietf/1id-abstracts.txt 49 The list of Internet-Draft Shadow Directories can be accessed at 50 http://www.ietf.org/shadow.html 51 This Internet-Draft will expire on July, 2015. 53 Copyright Notice 55 Copyright (c) 2010 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents 60 (http://trustee.ietf.org/license-info) in effect on the date of 61 publication of this document. Please review these documents 62 carefully, as they describe your rights and restrictions with 63 respect to this document. Code Components extracted from this 64 document must include Simplified BSD License text as described in 65 Section 4.e of the Trust Legal Provisions and are provided without 66 warranty as described in the Simplified BSD License. 68 Table of Contents 70 1. Introduction ................................................ 2 71 2. HNP renumbering support...................................... 3 72 3. DNS update .................................................. 4 73 4. Security Considerations...................................... 4 74 5. References .................................................. 4 75 Authors' Addresses ............................................. 5 76 Acknowledgment ................................................. 5 78 1. Introduction 80 Network managers currently prefer to Provider Independent (PI) 81 addressing for IPv6 to attempt to minimize the need for future 82 renumbering. However, widespread use of PI may create very serious 83 BGP scaling problems. It is thus desirable to develop tools and 84 practices that may make renumbering a simpler process to reduce 85 demand for IPv6 PI space [1]. In this draft, we aims to solve the 86 HNP renumbering problem when the HNP in PMIPv6 [2] is not a PI type. 88 Then the HNP renumbering may happen at least in the following three 89 cases: 91 In the first case, the PMIPv6 service provider is assigned the HNP 92 set from the (uplink) ISP, and then the HNP renumbering will happen 93 if the PMIPv6 service provider switches to a different ISP. 95 In the second case, multiple Local Mobility Anchors (LMAs) may be 96 deployed by the same PMIPv6 service provider, and then each LMA may 97 serve for a specific HNP set. In this case, the HNP of a MN may 98 change if the current serving LMA switches to another LMA but 99 without inheriting the assigned HNP [3]. 101 In the last case, the PMIPv6 HNP renumbering may be caused by the 102 re-building of the network architecture as the companies split, 103 merge, grow, relocate or reorganize. For example, the PMIPv6 service 104 provider may reorganize its network topology. 106 For the Mobile IPv6 (MIPv6), when the home network prefix changes 107 (maybe due to the above reasons), the Home Agent (HA) will actively 108 notify the new prefix to the MN and then the renumbering of the HoA 109 can be well supported [4]. While in the basic PMIPv6, the PMIPv6 110 binding is triggered by the Mobile Access Gateway (MAG), which 111 detects the attachment of the MN. When the HNP renumbering happens 112 in the first case or the LMA and HNP both changes in the second or 113 third cases, a scheme is needed for the LMA to immediately initiate 114 the PMIPv6 binding state refreshment. Although this issue is also 115 discussed in the RFC 5213 (section 6.12), the related solution is 116 not specified. 118 2. HNP renumbering support 120 RFC 7077 [5] specifies a scheme to support the asynchronously update 121 from the LMA to the MAG about changes related to a mobility session. 122 With this protocol, the HNP renumbering can be easily supported and 123 the basic operation is summarized as following: 125 1) When the PMIPv6 service provider renumbers the HNP set or the 126 serving LMA switches to another one but does not inherit the related 127 HNP, the current LMA (or new LMA) will initiate the HNP renumbering 128 operation. Firstly, it should allocate a new HNP for the related MN. 130 2) The LMA sends the Update Notification (UPN) message to the MAG. 131 In the UPN message, the Notification reason is set to 2 (UPDATE- 132 SESSION-PARAMETERS). Besides, HNP option containing the new HNP and 133 the Mobile Node Identifier option carrying MN'ID are contained as 134 Mobility Options of UPN. 136 3) After the MAG receives this UPN message, it will recognize that 137 the related MN has a new HNP now. Then the MAG sends the old HNP in 138 the RA with zero-valued lifetime to the MN and sends the new HNP in 139 the RA with lifetime larger than zero. 141 4) Besides, the MAG sends back the Update Notification 142 Acknowledgement (UNA) to the LMA for the notification of successful 143 update of the related binding state, routing state and RA settings. 145 5) For the MN, it deletes the old HoA due to the zero-valued 146 lifetime RA advertisement and configures a new HoA with the 147 meaningful HNP. 149 The detailed protocol operation and signaling message extensions 150 will be specified further. 152 3. DNS update 154 In order to maintain the reachability of the MN, the DNS resource 155 record corresponding to this MN may need to be updated when the HNP 156 of MN changes. Although this operation in PMIPv6 has not been 157 specified by the current protocols, we here list two important 158 issues to be considered for this operation. 160 1) Since the DNS update must be performed securely in order to 161 prevent attacks or modifications from malicious ones, the node 162 performing this update must share a security association with the 163 DNS server [6]. If the MN does not share a security association with 164 the DNS server and the DNS entry update can be performed by the 165 network entities, such as Authentication, Authorization and 166 Accounting (AAA) server or LMA. 168 2) For the dynamic update, another important issue should be 169 considered is the TTL setting when the HNP renumbering is possible. 170 The TTL should be set according to the possible lifetime of the HNP. 172 4. Security Considerations 174 The security considerations in PMIPv6 protocol are enough for the 175 basic operation of this draft. 177 Besides, the security dynamic DNS should be supported whatever the 178 DNS update is executed by network entities or MN itself. In other 179 words, the security association should always be established between 180 the DNS server and updater. 182 Other security issues will be added further. 184 5. References 186 [1] S. Jiang, B. Liu, and B. Carpenter, "IPv6 Enterprise Network 187 Renumbering Scenarios and Guidelines", RFC 6879, February 2013. 189 [2] S. Gundavelli, K. Leung, V. Devarapalli, K. Chowdhury, and B. 190 Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 192 [3] J. Korhonen, S. Gundavelli, H. Yokota, and X. Cui, "Runtime 193 Local Mobility Anchor (LMA) Assignment Support for Proxy 194 Mobile IPv6", RFC 6463, February 2012. 196 [4] C. Perkins, D. Johnson, and J. Arkko, "Mobility Support in 197 IPv6", RFC 6275, July 2011. 199 [5] S. Krishnan, S. Gundavelli, M. Liebsch, H. Yokota and J. 200 Korhonen, "Update Notifications for Proxy Mobile IPv6", RFC 201 7077, November 2013. 203 [6] Wellington, B., "Secure Domain Name System (DNS) Dynamic 204 Update", RFC 3007, November 2000. 206 Authors' Addresses 208 Zhiwei Yan 209 China Internet Network Information Center 210 No.4 South 4th Street, Zhongguancun 211 Beijing, P. R. China 212 Email: yan@cnnic.cn 214 Jong-Hyouk Lee 215 Department of Computer Science and Engineering 216 Sangmyung University 217 31, Sangmyeongdae-gil, Dongnam-gu 218 Cheonan, Republic of Korea 219 E-mail: jonghyouk@smu.ac.kr 221 Xiaodong Lee 222 China Internet Network Information Center 223 No.4 South 4th Street, Zhongguancun 224 Beijing, P. R. China 225 Email: xl@cnnic.cn 227 Acknowledgment 229 Funding for the RFC Editor function is currently provided by the 230 Internet Society.