idnits 2.17.00 (12 Aug 2021) /tmp/idnits38213/draft-ietf-dmm-hnprenum-07.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 issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (March 13, 2017) is 1888 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) ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DMM Working Group Z. Yan 3 Internet-Draft CNNIC 4 Intended status: Standards Track J. Lee 5 Expires: September 14, 2017 Sangmyung University 6 X. Lee 7 CNNIC 8 March 13, 2017 10 Home Network Prefix Renumbering in PMIPv6 11 draft-ietf-dmm-hnprenum-07 13 Abstract 15 In the basic Proxy Mobile IPv6 (PMIPv6) specification, a Mobile Node 16 (MN) is assigned with a Home Network Prefix (HNP) during its initial 17 attachment and the MN configures its Home Address (HoA) with the HNP. 18 During the movement of the MN, the HNP remains unchanged to keep 19 ongoing communications associated with the HoA. However, the current 20 PMIPv6 specification does not specify related operations when an HNP 21 renumbering has happened (e.g. due to change of service provider, 22 change of site topology, etc.). In this document, a solution to 23 support the HNP renumbering is proposed, as an optional extension of 24 the PMIPv6 specification. 26 Requirements Language 28 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL","SHALL NOT", 29 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 30 document are to be interpreted as described in [RFC2119] 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at http://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on September 14, 2017. 49 Copyright Notice 51 Copyright (c) 2017 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 67 2. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . . . 2 68 3. HNP Renumbering Procedure . . . . . . . . . . . . . . . . . . 3 69 4. Session Connectivity . . . . . . . . . . . . . . . . . . . . 5 70 5. Message Format . . . . . . . . . . . . . . . . . . . . . . . 5 71 6. Other Issues . . . . . . . . . . . . . . . . . . . . . . . . 6 72 7. Security Considerations . . . . . . . . . . . . . . . . . . . 6 73 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 74 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 75 9.1. Normative References . . . . . . . . . . . . . . . . . . 7 76 9.2. Informative References . . . . . . . . . . . . . . . . . 8 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 79 1. Introduction 81 Network managers currently prefer Provider Independent (PI) 82 addressing for IPv6 to attempt to minimize the need for future 83 possible renumbering. However, a widespread use of PI addresses will 84 cause Border Gateway Protocol (BGP) scaling problems [RFC7010]. It 85 is thus desirable to develop tools and practices that make IPv6 86 renumbering a simpler process to reduce demand for IPv6 PI space 87 [RFC6879]. In this document, we aim to solve the HNP renumbering 88 problem when the HNP in PMIPv6 [RFC5213] is a PI prefix. 90 2. Usage Scenarios 92 There are a number of reasons why the HNP renumbering support in 93 PMIPv6 is useful and some scenarios are identified below: 95 o Scenario 1: the HNP set used by a PMIPv6 service provider is 96 assigned by a different Internet Service Provider (ISP), and then 97 the HNP renumbering MAY happen if the PMIPv6 service provider 98 switches to a different ISP. 100 o Scenario 2: multiple Local Mobility Anchors (LMAs) MAY be deployed 101 by the same PMIPv6 service provider, and then each LMA MAY serve 102 for a specific HNP set. In this case, the HNP of an MN MAY change 103 if the current serving LMA switches to another LMA but without 104 inheriting the assigned HNP set [RFC6463]. 106 o Scenario 3: the PMIPv6 HNP renumbering MAY be caused by the re- 107 building of the network architecture as the companies split, 108 merge, grow, relocate, or reorganize. For example, the PMIPv6 109 service provider MAY reorganize its network topology. 111 In the scenario 1, we assume that only the HNP is renumbered while 112 the serving LMA remains unchanged and this is the basic scenario 113 considered in this document. In the scenario 2 and scenario 3, more 114 complex results MAY be caused, for example, the HNP renumbering MAY 115 happen due to the switchover of a serving LMA. 117 In the Mobile IPv6 (MIPv6) protocol, when a home network prefix 118 changes, the Home Agent (HA) will actively notify the new prefix to 119 its MN and then the renumbering of the Home Network Address (HoA) can 120 be well supported [RFC6275]. In the basic PMIPv6, the PMIPv6 binding 121 is triggered by a Mobile Access Gateway (MAG), which detects the 122 attachment of the MN. A scheme is also needed for the LMA to 123 immediately initiate the PMIPv6 binding state refreshment during the 124 HNP renumbering process. Although this issue is also mentioned in 125 Section 6.12 of [RFC5213], the related solution has not been 126 specified. 128 3. HNP Renumbering Procedure 130 When the HNP renumbering happens in PMIPv6, the LMA MUST notify a new 131 HNP to the MAG and then the MAG MUST announce the new HNP to the 132 attached MN accordingly. Also, the LMA and the MAG MUST update the 133 routing states for the HNP and the related addresses. To support 134 this procedure, [RFC7077] can be adopted which specifies an 135 asynchronous update from the LMA to the MAG about specific session 136 parameters. This document considers the following two cases: 138 (1) HNP is renumbered under the same LMA 140 In this case, the LMA remains unchanged as in the scenario 1 and 141 scenario 3. The operation steps are shown in Figure 1. 143 +-----+ +-----+ +-----+ 144 | MN | | MAG | | LMA | 145 +-----+ +-----+ +-----+ 146 | | | 147 | | Allocate new HNP 148 | | | 149 | |<------------- UPN ---| 150 | | | 151 | | | 152 | | | 153 |<-----RA/DHCP --------| | 154 | | | 155 Address configuration | | 156 | | | 157 | Update binding&routing states | 158 | | | 159 | |--- UPA ------------->| 160 | | | 161 | | Update binding&routing states 162 | | | 164 Figure 1: Signaling call flow of the HNP renumbering 166 o When a PMIPv6 service provider renumbers the HNP set under the 167 same LMA, the serving LMA SHOULD initiate the HNP renumbering 168 operation. The LMA allocates a new HNP for the related MN. 170 o The LMA sends the Update Notification (UPN) message to the MAG to 171 update the HNP information. If the Dynamic Host Configuration 172 Protocol (DHCP) is used to allocate the address, the new HNP MUST 173 be also notified to the DHCP infrastructure. 175 o Once the MAG receives this UPN message, it recognizes that the 176 related MN has the new HNP. Then the MAG MUST notify the MN about 177 the new HNP with a Router Advertisement (RA) message or allocate a 178 new address within the new HNP through a DHCP procedure. 180 o After the MN obtains the HNP information through the RA message, 181 it deletes the old HoA and configures a new HoA with the newly 182 allocated HNP. 184 o When the new HNP is announced or the new address is configured to 185 the MN successfully, the MAG MUST update the related binding and 186 routing states. Then the MAG sends back the Update Notification 187 Acknowledgement (UPA) message to the LMA for the notification of 188 successful update of the HNP, related binding state, and routing 189 state. Then the LMA updates the routing and binding information 190 corresponding to the MN to replace the old HNP with the new one. 192 (2) HNP renumbering caused by the LMA switchover 194 Since the HNP is assigned by the LMA, the HNP renumbering MAY be 195 caused by the LMA switchover, as in the scenario 2 and scenario 3. 197 The information of LMA is the basic configuration information of MAG. 198 When the LMA changes, the related profile SHOULD be updated by the 199 service provider. In this way, the MAG initiates the registration to 200 the new LMA as specified in [RFC5213]. When the HNP renumbering is 201 caused in this case, the new HNP information is sent by the LMA 202 during the new binding procedure. Accordingly, the MAG withdraws the 203 old HNP of the MN and announces the new HNP to the MN as like the 204 case of the HNP is renumbered under the same LMA. 206 4. Session Connectivity 208 The HNP renumbering may cause the disconnection of the ongoing 209 communications of the MN. Basically, there are two modes to manage 210 the session connectivity during the HNP renumbering. 212 (1) Soft-mode 214 The LMA will temporarily maintain the state of the old HNP during the 215 HNP renumbering (after the UPA reception) in order to redirect the 216 packets to the MN before the MN reconnects the ongoing session and 217 notifies its new HoA to the Correspondent Node (CN). This mode is 218 aiming to reduce the packet loss during the HNP renumbering but the 219 binding state corresponding to the old HNP should be marked for 220 example as transient binding [RFC6058]. And the LMA MUST stop 221 broadcasting the routing information about the old HNP if the old HNP 222 is no longer anchored at this LMA. 224 (2) Hard-mode 226 If the HNP renumbering happens with the switchover of the LMA, the 227 hard-mode is recommended to keep the protocol simple. In this mode, 228 the LMA deletes the binding state of the old HNP after it receives 229 the UPA message from the MAG and the LMA silently discards the 230 packets destined to the old HNP. 232 5. Message Format 234 (1) UPN message 236 In the UPN message sent from the LMA to the MAG, the notification 237 reason is set to 2 (UPDATE-SESSION-PARAMETERS). Besides, the HNP 238 Option [RFC5213] containing the new HNP and the Mobile Node 239 Identifier Option [RFC4283] carrying identifier of MN are contained 240 as Mobility Options of UPN. The order of HNP Option and Mobile Node 241 Identifier Option in the UPN message is not mandated here. 243 (2) UPA message 245 The MAG sends this message in order to acknowledge that it has 246 received an UPN message with the (A) flag set and to indicate the 247 status after processing the message. When the MAG did not 248 successfully renumber the HNP which is required in the UPN message, 249 the Status Code of 128 is set in the UPA message and the following 250 operation of LMA is PMIPv6 service provider specific. 252 (3) RA Message 254 When the RA message is used by the MAG to advise the new HNP, two 255 Prefix Information Options are contained in the RA message [RFC4861] 256 [RFC4862]. In the first Prefix Information Option, the old HNP is 257 carried and the related Preferred Lifetime is set to 0. In the 258 second Prefix Information Option, the new HNP is carried with the 259 Valid Lifetime and Preferred Lifetime set to larger than 0. 261 (4) DHCP Message 263 When the DHCP is used in PMIPv6 to configure the addresses for the 264 MN, new IPv6 address(es) (e.g., HoA) will be generated based on the 265 new HNP and the related DHCP procedure is also triggered by the 266 reception of UPN message [RFC3315]. 268 6. Other Issues 270 In order to maintain the reachability of the MN, the Domain Name 271 System (DNS) resource record corresponding to this MN may need to be 272 updated when the HNP of MN changes [RFC3007]. However, this is 273 beyond the scope of this document. 275 7. Security Considerations 277 This document causes no further security problem for the signaling 278 exchanges. The UPN and UPA messages in this document MUST be 279 protected using end-to-end security association(s) offering integrity 280 and data origin authentication as speficied in [RFC5213] and 281 [RFC7077]. 283 When the HNP renumbering is triggered, a new HNP SHOULD be allocated 284 to the MN. The LMA MUST follow the procedure of PMIPv6 to make sure 285 that only an authorized HNP can be assigned for the MN. In this way, 286 LMA is ready to be the topological anchor point of the new HNP and 287 the new HNP is for that MN's exclusive use. 289 [RFC4862] requires an RA to be authenticated for the Valid Lifetime 290 in a Prefix Information Option to be set to less than 2 hours. Thus, 291 when the old HNP that is being deprecated is included in an RA from 292 the MAG, it will normally be expected that the Valid Lifetime SHOULD 293 be set to 2 hours (and the Preferred Lifetime set to 0) for a non- 294 authenticated RA. However, if the legality of the signaling messages 295 exchanged between MAG and MN can be guaranteed, it MAY be acceptable 296 to also set the Valid Lifetime to 0 for a non-authenticated RA. 298 8. IANA Considerations 300 This document presents no IANA considerations. 302 9. References 304 9.1. Normative References 306 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 307 Requirement Levels", BCP 14, RFC 2119, 308 DOI 10.17487/RFC2119, March 1997, 309 . 311 [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic 312 Update", RFC 3007, DOI 10.17487/RFC3007, November 2000, 313 . 315 [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, 316 C., and M. Carney, "Dynamic Host Configuration Protocol 317 for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 318 2003, . 320 [RFC4283] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K. 321 Chowdhury, "Mobile Node Identifier Option for Mobile IPv6 322 (MIPv6)", RFC 4283, DOI 10.17487/RFC4283, November 2005, 323 . 325 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 326 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 327 DOI 10.17487/RFC4861, September 2007, 328 . 330 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 331 Address Autoconfiguration", RFC 4862, 332 DOI 10.17487/RFC4862, September 2007, 333 . 335 [RFC5213] Gundavelli, S., Ed., Leung, K., Devarapalli, V., 336 Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", 337 RFC 5213, DOI 10.17487/RFC5213, August 2008, 338 . 340 [RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility 341 Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July 342 2011, . 344 [RFC6463] Korhonen, J., Ed., Gundavelli, S., Yokota, H., and X. Cui, 345 "Runtime Local Mobility Anchor (LMA) Assignment Support 346 for Proxy Mobile IPv6", RFC 6463, DOI 10.17487/RFC6463, 347 February 2012, . 349 [RFC7077] Krishnan, S., Gundavelli, S., Liebsch, M., Yokota, H., and 350 J. Korhonen, "Update Notifications for Proxy Mobile IPv6", 351 RFC 7077, DOI 10.17487/RFC7077, November 2013, 352 . 354 9.2. Informative References 356 [RFC6058] Liebsch, M., Ed., Muhanna, A., and O. Blume, "Transient 357 Binding for Proxy Mobile IPv6", RFC 6058, 358 DOI 10.17487/RFC6058, March 2011, 359 . 361 [RFC6879] Jiang, S., Liu, B., and B. Carpenter, "IPv6 Enterprise 362 Network Renumbering Scenarios, Considerations, and 363 Methods", RFC 6879, DOI 10.17487/RFC6879, February 2013, 364 . 366 [RFC7010] Liu, B., Jiang, S., Carpenter, B., Venaas, S., and W. 367 George, "IPv6 Site Renumbering Gap Analysis", RFC 7010, 368 DOI 10.17487/RFC7010, September 2013, 369 . 371 Authors' Addresses 373 Zhiwei Yan 374 CNNIC 375 No.4 South 4th Street, Zhongguancun 376 Beijing 100190 377 China 379 EMail: yan@cnnic.cn 380 Jong-Hyouk Lee 381 Sangmyung University 382 31, Sangmyeongdae-gil, Dongnam-gu 383 Cheonan 31066 384 Republic of Korea 386 EMail: jonghyouk@smu.ac.kr 388 Xiaodong Lee 389 CNNIC 390 No.4 South 4th Street, Zhongguancun 391 Beijing 100190 392 China 394 EMail: xl@cnnic.cn