idnits 2.17.1 draft-ietf-netext-pd-pmip-02.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 date (March 12, 2012) is 4427 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) ** Obsolete normative reference: RFC 3633 (Obsoleted by RFC 8415) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Netext WG X. Zhou 3 Internet-Draft ZTE Corporation 4 Intended status: Standards Track J. Korhonen 5 Expires: September 13, 2012 Nokia Siemens Networks 6 C. Williams 7 Consultant 8 S. Gundavelli 9 Cisco 10 CJ. Bernardos 11 UC3M 12 March 12, 2012 14 Prefix Delegation for Proxy Mobile IPv6 15 draft-ietf-netext-pd-pmip-02 17 Abstract 19 Proxy Mobile IPv6 enables IP mobility for a host without requiring 20 its participation in any mobility signaling, being the network 21 responsible for managing IP mobility on behalf of the host. However, 22 Proxy Mobile IPv6 does not support assigning a prefix to a router and 23 managing its IP mobility. This document specifies an extension to 24 Proxy Mobile IPv6 protocol for supporting network mobility using 25 DHCPv6-based Prefix Delegation. 27 Status of this Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on September 13, 2012. 44 Copyright Notice 46 Copyright (c) 2012 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Convention and Terminology . . . . . . . . . . . . . . . . . . 4 63 3. DHCPv6 Prefix Delegation for Proxy Mobile IPv6 . . . . . . . . 5 64 3.1. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 5 65 3.2. Network Mobility Service . . . . . . . . . . . . . . . . . 5 66 3.3. Binding association with the delegated prefix . . . . . . 5 67 3.3.1. Mobile Router initiated prefix delegation in PMIPv6 . 6 68 3.3.2. Refreshing the Delegated Prefix in Proxy Mobile 69 IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . 7 70 3.3.3. Deletion of the Delegated Prefix in Proxy Mobile 71 IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . 8 72 3.4. Mobile Access Gateway Operation . . . . . . . . . . . . . 8 73 3.4.1. Extension to Binding Update List Entry Data 74 Structure . . . . . . . . . . . . . . . . . . . . . . 8 75 3.4.2. Forwarding . . . . . . . . . . . . . . . . . . . . . . 8 76 3.4.3. Handover . . . . . . . . . . . . . . . . . . . . . . . 8 77 3.5. Local Mobility Anchor Operation . . . . . . . . . . . . . 9 78 3.5.1. Extension to Binding Cache Entry Data Structure . . . 9 79 3.5.2. Forwarding . . . . . . . . . . . . . . . . . . . . . . 9 80 4. Security Considerations . . . . . . . . . . . . . . . . . . . 10 81 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 82 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 83 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 84 7.1. Normative References . . . . . . . . . . . . . . . . . . . 13 85 7.2. Informative References . . . . . . . . . . . . . . . . . . 13 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 88 1. Introduction 90 Proxy Mobile IPv6 [RFC5213] enables an IPv6 host to move within a 91 PMIPv6-Domain without requiring its participation in any IP mobility 92 signaling. However, PMIPv6 does not support providing a network- 93 based mobility service to a complete network which is roaming within 94 a PMIPv6-Domain without requiring the mobile router of that network 95 to run the Network Mobility Basic Support protocol [RFC3963]. 97 In order to support network mobility in Proxy Mobile IPv6, the IPv6 98 prefix used by the mobile network should be topologically anchored by 99 the local mobility anchor. DHCPv6 Prefix Delegation [RFC3633] 100 (DHCPv6-PD) can be used to assign mobile network prefix(es) to a 101 mobile router (MR) as specified in DHCPv6 Prefix Delegation for 102 Network Mobility (NEMO) [RFC6276]. However, if the mobile router is 103 provided with PMIPv6 Protocol as its mobility management when 104 connecting the network and uses DHCPv6-PD [RFC3633] to obtain 105 prefix(es) for the nodes in the mobile network behind the MR, 106 currently PMIPv6 network entities (i.e., mobile access gateway and 107 local mobility anchor) are not aware of the delegated prefix(es) and 108 therefore any packets sourced from or destined to the delegated 109 prefix would be discarded by the MAG or the LMA. This document 110 describes extension to PMIPv6 for supporting prefix delegation. 112 2. Convention and Terminology 114 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 115 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 116 document are to be interpreted as described in [RFC2119]. 118 All the mobility related terms used in this document are to be 119 interpreted as defined in Mobile IPv6 (MIPv6) [RFC6275], Proxy Mobile 120 IPv6 specification [RFC5213], DHCPv6-PD for NEMO [RFC6276], DHCPv6-PD 121 [RFC3633] and Mobility Related Terminology [RFC3753]. This document 122 also provides the following context-specific explanation to the 123 following term used in this document. 125 Mobile Router (MR) 127 Throughout this document, the term mobile router is used to refer 128 to an IP router whose mobility is managed by the network. The 129 mobile router is not required to participate in any IP mobility 130 related signaling for achieving mobility for an IPv6 prefix that 131 is obtained in that Proxy Mobile IPv6 domain. 133 3. DHCPv6 Prefix Delegation for Proxy Mobile IPv6 135 3.1. Assumptions 137 This specification extends PMIPv6 to assign a mobile network prefix 138 to a mobile router for supporting network mobility. The 139 specification assumes that a MR is a regular IPv6 router without 140 extension for mobility management. The MR sends the packets from its 141 mobile network to the MAG and the MAG delivers the packets to the 142 mobile network via the MR. 144 In order to use DHCPv6-PD as mobile network prefix assignment 145 mechanism in mobile networks, this specification has following 146 assumptions. 148 o The mobile router (MR) MUST be able to function as a requesting 149 router (RR). 151 o The delegating router (DR) is located at the LMA. 153 o The MAG MUST have a DHCPv6 Relay Agent functionality (as described 154 in [RFC5213] to be able to intercept the related DHCPv6 message 155 sourced from the MR. 157 o The MR MUST either obtain the Home Network Prefix (HNP) before 158 initiating the DHCPv6-PD procedure or in case of stateful address 159 configuration simultaneously while configuring the Mobile Node 160 Home Address (MN-HoA). 162 o The MR (as a RR) SHOULD support Prefix Exclude Option for 163 DHCPv6-PD as described in [I-D.ietf-dhc-pd-exclude]. 165 3.2. Network Mobility Service 167 The network mobility service of a MR is managed by the policy profile 168 defined in [RFC5213]. During mobile router's initial attach 169 procedure, the mobile access gateway (MAG) MUST identify the MR and 170 acquire the policy profile to determine whether the network mobility 171 service is offered to the MR. If the network mobility service needs 172 to be offered to the mobile node, the mobile access gateway MUST set 173 the Mobile Router Flag (R) when sending the Proxy Binding Update 174 (PBU) message to the LMA. 176 3.3. Binding association with the delegated prefix 177 3.3.1. Mobile Router initiated prefix delegation in PMIPv6 179 +-------------+ +--------------+ +-------------------+ 180 |Mobile Router| | MAG | | LMA | 181 |(Req. Router)| |(DHCPv6 Relay)| |(Delegating Router)| 182 +-------------+ +--------------+ +-------------------+ 183 | | | 184 | |o========================o| 185 1) | | PMIPv6 tunnel | 186 | |o========================o| 187 2) |-- Solicit ------>| | 188 | | | 189 3) | |----------PBU------------>| 190 | | | 191 4) | |<---------PBA-------------| 192 | | | 193 5) | |--- Solicit ------------->| 194 - - - - <-+ 195 6) | |<-- Advertise ------------| | 196 | | | | 197 7) |<- Advertise -----| | Opt 198 | | | ion 199 8) |-- Request ------>| | al. 200 | | | | 201 9) | |--- Request ------------->| | 202 - - - - <-+ 203 10) | |<-- Reply-----------------| 204 | | | 205 11) |<-- Reply --------| | 206 | | | 208 Figure 1: Prefix Delegation in PMIPv6 during the initial attachment 209 to the PMIPv6 Domain 211 The steps of the procedures required to complete the delegation of an 212 IPv6 prefix to a mobile router that is provided with network-based 213 network mobility service in Figure 1 are as following: 215 1. The PMIPv6 tunnel is set up between the MAG and LMA as described 216 in [RFC5213]. The MAG has the function of DHCPv6 Relay Agent 217 between the MR and the DHCPv6 server and intercept all the 218 DHCPv6 related messages. 220 2. The MR, acting as a "Requesting Router" as described in 221 [RFC3633], sends a DHCPv6 SOLICIT message including one or more 222 IA_PD option(s) to the MAG to acquire the delegated prefix(es). 224 3. Upon receiving the DHCPv6 SOLICIT message, the MAG sends a PBU 225 message including a Mobile Network Prefix (MNP) mobility option 226 as defined in Section 4.3 of [RFC3963] to the LMA. All the 227 considerations from Section 5.3.1 of [RFC5213] MUST be applied 228 on the encapsulated Proxy Binding Update message. If the MAG 229 does not know the delegated prefix, then mobile network prefix 230 in the MNP option MUST be set to unspecified address "::" and 231 prefix length to 0. The LMA either assigns the MR a new 232 delegated prefix or returns an existing one. 234 4. On reception of the PBU the LMA returns the assigned prefix in 235 the MNP option carried by a Proxy Binding Acknowledgment (PBA) 236 to the MAG, unless the prefix was the IPv6 unspecified address 237 "::". The assigned prefix is the same one that will be assigned 238 via DHCPv6PD in step 6. This prefix MUST be added to the 239 delegated prefix(es) in the LMA binding cache which is extended 240 as in Section 3.5.1. 242 5. The DHCPv6 Relay Agent on the MAG as described in [RFC3315] 243 relays the DHCPv6 SOLICIT message to the delegation router. The 244 DR inserts one or more IA_PD option(s) including the delegated 245 prefix(es) to the reply message. 247 Note: steps 6 to 9 are not present if DHCPv6 Rapid Commit is 248 used. 250 6. The DR sends delegated prefix(es) in one or more IA_PD(s) to the 251 MAG (DHCPv6 Relay Agent) inside the DHCPv6 ADVERTISE message. 253 7. The MAG relays the DHCPv6 ADVERTISE message to the MR. 255 8. The MR sends DHCPv6 REQUEST message with the IA_PD option(s) 256 received from previous message to the MAG (DHCPv6 Relay Agent). 258 9. The MAG relays the DHCPv6 REQUEST message to the DR. 260 10. The DR responses to the REQUEST from the MAG using DHCPv6 REPLY 261 message. 263 11. The MR receives one or more IA_PD prefix(es) in the DHCPv6 REPLY 264 message from the MAG. 266 3.3.2. Refreshing the Delegated Prefix in Proxy Mobile IPv6 268 When the MR sends DHCPv6 Renew messages to extend the lifetime of the 269 delegated prefix, the messages are also intercepted by the MAG 270 (acting as DHCPv6 Relay Agent) and relayed to the DR. 272 3.3.3. Deletion of the Delegated Prefix in Proxy Mobile IPv6 274 If the lifetime of the delegated prefix (included in the IA_PD Prefix 275 Option carried by the DHCPv6 Reply message) is set to zero, the MAG 276 MUST trigger a PBU to remove the binding for that home mobile network 277 prefix. 279 3.4. Mobile Access Gateway Operation 281 3.4.1. Extension to Binding Update List Entry Data Structure 283 In order to support this specification, the conceptual Binding Update 284 List Entry (BULE) data structure needs to be extended with a new 285 prefix information field as [RFC3963] does. This prefix information 286 field is used to store the MNP information which is assigned to the 287 MR in the PBA. 289 3.4.2. Forwarding 291 Forwarding packets sent to the mobile router's MNP: 293 o On receiving a packet from the bi-directional tunnel established 294 with the MR's LMA, the MAG MUST first decapsulate the packet 295 (removing the outer header) and then use the destination address 296 of the (inner) packet to forward it on the interface through which 297 the destination MNP is reachable. 299 Forwarding packets sent by the mobile router: 301 o On receiving packets from a MR connected to one access link, the 302 MAG MUST ensure that there is an established binding for the MR 303 and its LMA before tunneling the packet to the MR's LMA. 305 Other considerations from Section 6.10.5 of [RFC5213] also apply 306 here. 308 3.4.3. Handover 310 When the MR moves from the previously attached MAG to the newly 311 attached target MAG, the newly attached target MAG MAY know the 312 mobile network prefix which was assigned during the previous 313 attachment from some network element, e.g. from the previous MAG. It 314 is out of scope of this specification how the newly attached MAG 315 could obtain the previously assigned mobile network prefix. After 316 handover to the new target MAG, a PBU message including the assigned 317 mobile network prefix (if available) MUST be sent from the new target 318 MAG to the LMA. The LMA MUST check the mobile network prefix in the 319 PBU message and return the same assigned mobile network prefix in the 320 PBA message. If the previously assigned mobile network prefix is not 321 available in the new target MAG, the new target MAG MUST contain the 322 mobile network prefix set to unspecified address "::" and the prefix 323 length to 0 in the PBU message. In this case, the LMA MUST return 324 the same previously assigned mobile network prefix in PBA. 326 3.5. Local Mobility Anchor Operation 328 3.5.1. Extension to Binding Cache Entry Data Structure 330 In order to support this specification, the conceptual Binding Cache 331 Entry (BCE) data structure needs to be extended with a new prefix 332 information field as [RFC3963] does. This prefix information field 333 is used to store the mobile network prefix information which is 334 assigned to the BCE in the PBA during the procedure of binding 335 association with the delegated prefix in Section 3.2 337 3.5.2. Forwarding 339 Intercepting packets sent to the MR's mobile network prefix: 341 o When the LMA is serving to the MR, it MUST be able to receive 342 packets destined to the MR's mobile network. In order to receive 343 those packets, the LMA MUST be the topological anchor of the MR's 344 MNP(s). 346 Forwarding packets to the MR: 348 o On receiving a packet from a correspondent node with the 349 destination address matching the MR's MNP(s) the LMA MUST forward 350 the packet through the bi-directional tunnel set up for the MR. 352 Other considerations from Section 5.6.2 of [RFC5213] also apply here. 354 4. Security Considerations 356 This document describes extensions to the Proxy Mobile IPv6 protocol 357 for supporting network mobility using DHCPv6-based Prefix Delegation. 358 The security considerations for DHCPv6 described in the "Security 359 Considerations" section of the DHCPv6 base specification [RFC3315], 360 the "Security Considerations" of the DHCPv6 Prefix Delegation 361 specification [RFC3633], and the security considerations from the 362 base Proxy Mobile IPv6 [RFC5213] apply when using the extensions 363 defined in this document. 365 5. IANA Considerations 367 This document reuses the mobile network prefix option defined in 368 [RFC3963] in Proxy Mobile IPv6 to assign the mobile network prefix 369 via DHCPv6 Prefix Delegation. It does not introduce any additional 370 IANA considerations. 372 6. Acknowledgments 374 The work of Carlos J. Bernardos has also been partially supported by 375 the European Community's Seventh Framework Programme (FP7-ICT-2009-5) 376 under grant agreement n. 258053 (MEDIEVAL project) and by the 377 Ministry of Science and Innovation of Spain under the QUARTET project 378 (TIN2009-13992-C02-01). 380 7. References 382 7.1. Normative References 384 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 385 Requirement Levels", BCP 14, RFC 2119, March 1997. 387 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 388 and M. Carney, "Dynamic Host Configuration Protocol for 389 IPv6 (DHCPv6)", RFC 3315, July 2003. 391 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 392 Host Configuration Protocol (DHCP) version 6", RFC 3633, 393 December 2003. 395 [RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. 396 Thubert, "Network Mobility (NEMO) Basic Support Protocol", 397 RFC 3963, January 2005. 399 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 400 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 402 [RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support 403 in IPv6", RFC 6275, July 2011. 405 [RFC6276] Droms, R., Thubert, P., Dupont, F., Haddad, W., and C. 406 Bernardos, "DHCPv6 Prefix Delegation for Network Mobility 407 (NEMO)", RFC 6276, July 2011. 409 7.2. Informative References 411 [I-D.ietf-dhc-pd-exclude] 412 Korhonen, J., Savolainen, T., Krishnan, S., and O. Troan, 413 "Prefix Exclude Option for DHCPv6-based Prefix 414 Delegation", draft-ietf-dhc-pd-exclude-04 (work in 415 progress), December 2011. 417 [RFC3753] Manner, J. and M. Kojo, "Mobility Related Terminology", 418 RFC 3753, June 2004. 420 Authors' Addresses 422 Xingyue Zhou 423 ZTE Corporation 424 No.50 Software Avenue, Yuhuatai District 425 Nanjing 426 China 428 Phone: +86-25-8801-4634 429 Email: zhou.xingyue@zte.com.cn 431 Jouni Korhonen 432 Nokia Siemens Networks 433 Linnoitustie 6 434 Espoo FIN-02600 435 Finland 437 Email: jouni.nospam@gmail.com 439 Carl Williams 440 Consultant 441 San Jose, CA 442 USA 444 Email: carlw@mcsr-labs.org 446 Sri Gundavelli 447 Cisco 448 170 West Tasman Drive 449 San Jose, CA 95134 450 USA 452 Email: sgundave@cisco.com 454 Carlos J. Bernardos 455 Universidad Carlos III de Madrid 456 Av. Universidad, 30 457 Leganes, Madrid 28911 458 Spain 460 Phone: +34 91624 6236 461 Email: cjbc@it.uc3m.es 462 URI: http://www.it.uc3m.es/cjbc/