idnits 2.17.1 draft-liebsch-netlmm-proxymip6ct-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 508. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 519. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 526. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 532. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust 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 seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 31, 2007) is 6112 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: 'ATT' is mentioned on line 412, but not defined == Missing Reference: 'CR' is mentioned on line 407, but not defined == Missing Reference: 'CA' is mentioned on line 409, but not defined == Missing Reference: 'PHT' is mentioned on line 405, but not defined == Unused Reference: 'RFC3775' is defined on line 459, but no explicit reference was found in the text == Unused Reference: 'RFC4301' is defined on line 465, but no explicit reference was found in the text == Unused Reference: 'RFC4303' is defined on line 468, but no explicit reference was found in the text == Outdated reference: A later version (-18) exists of draft-ietf-netlmm-proxymip6-01 ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) ** Downref: Normative reference to an Experimental RFC: RFC 4067 ** Downref: Normative reference to an Informational RFC: RFC 4831 Summary: 4 errors (**), 0 flaws (~~), 11 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NetLMM Working Group M. Liebsch 3 Internet-Draft NEC 4 Expires: February 1, 2008 C. Vogt 5 Ericsson 6 July 31, 2007 8 Context Transfer for Proxy MIPv6 9 draft-liebsch-netlmm-proxymip6ct-00.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on February 1, 2008. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2007). 40 Abstract 42 The IETF is specifying a protocol for network-based localized 43 mobility management, which takes basic operation for registration, 44 tunnel management and de-registration into account. This document 45 specifies how the IETF's Context Transfer Protocol, which is 46 specified in RFC 4067, can be used with protocols for network-based 47 mobility management, taking proactive and reactive handover scenarios 48 into account. The protocol Proxy Mobile IPv6 is suitable to support 49 network-based mobility management, which is the reference protocol 50 solution for the integration of the context transfer mechanisms in 51 this document. 53 Table of Contents 55 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 56 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 3. Terminology and Functional Components . . . . . . . . . . . . 5 58 4. Protocol Design . . . . . . . . . . . . . . . . . . . . . . . 6 59 4.1. Reference Architecture . . . . . . . . . . . . . . . . . . 6 60 4.2. Deployment Options . . . . . . . . . . . . . . . . . . . . 7 61 5. Protocol Operation . . . . . . . . . . . . . . . . . . . . . . 9 62 5.1. Reactive Handover - Case 1 . . . . . . . . . . . . . . . . 9 63 5.2. Reactive Handover - Case 2 . . . . . . . . . . . . . . . . 10 64 5.3. Proactive Handover - Case 1 . . . . . . . . . . . . . . . 11 65 5.4. Proactive Handover - Case 2 . . . . . . . . . . . . . . . 12 66 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 67 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 68 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 16 69 9. Normative References . . . . . . . . . . . . . . . . . . . . . 17 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 71 Intellectual Property and Copyright Statements . . . . . . . . . . 19 73 1. Requirements notation 75 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 76 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 77 document are to be interpreted as described in [RFC2119]. 79 2. Introduction 81 The NetLMM WG is specifying a protocol for network-based localized 82 mobility management (NetLMM), taking basic support for registration, 83 de-registration and handover into account in a first protocol 84 release. The specification of extensions and optimization is for 85 further study and subject for either being incorporated into future 86 versions of the protocol or specified in separate documents. In 87 scope of the base protocol specification is the set up and 88 maintenance of a forwarding tunnel between an MN's Mobility Access 89 Gateway (MAG) and its selected Local Mobility Anchor (LMA). 91 The protocol Proxy Mobile IPv6 [I-D.ietf-netlmm-proxymip6] is being 92 designed to suit basic operation of network-based localized mobility 93 management. According to [RFC4831], mobility management should not 94 depend on mobility-related signaling from mobile nodes (MNs), such as 95 location updates. However, it's considered as beneficial to support 96 transfer of an MN's context between the MN's previous and new access 97 routers in case the MN changes its point of attachment and this 98 change implies a change in the MN's access router. Other mechanisms 99 than receiving an explicit indication from the MN must be used to 100 initiate the transfer of context between access routers. 102 This document specifies, how context transfer can be achieved in a 103 Proxy MIPv6 enabled network. [RFC4067] is referred to as base and 104 generic protocol operation between access routers to perform context 105 transfer. The associated functional components for context transfer 106 are embedded into the Proxy MIPv6 architecture and protocol operation 107 to support context transfer efficiently by means of reusing Proxy 108 MIPv6 protocol elements and event indications, without the need to 109 rely on explicit indication from MNs. 111 This document first discusses different scenarios for context 112 transfer in a Proxy-MIPv6 enabled network, taking context push and 113 context pull operation, as well as support for proactive and reactive 114 handover into account. Subsequently, the integrated protocol 115 operation is described. Extensions to the Proxy MIPv6 protocol are 116 described in case they are required to support some of the reference 117 scenarios. If the integrated protocol operation relies on 118 information, which is not available on the relevant network 119 component, the source and means to retrieve such information is 120 described. 122 3. Terminology and Functional Components 124 o MAG - Mobility Access Gateway. PMIPv6 functional component 125 defined in [I-D.ietf-netlmm-proxymip6]. The MAG function is 126 assumed to be located on the PMIPv6 domain's access routers. 128 o LMA - Local Mobility Anchor. PMIPv6 functional component defined 129 in [I-D.ietf-netlmm-proxymip6]. 131 o pAR - Previous Access Router. Equivalent to current access 132 router. In a layer 3 handover situation, the access router which 133 the mobile node is leaving. 135 o nAR - New Access Router. Equivalent to handover target access 136 router. In a layer 3 handover situation, the access router 137 towards which the mobile node is moving. 139 o pMAG - previous MAG. In a layer 3 handover situation, the MAG 140 function located on the previous access router 142 o nMAG - new MAG. In a layer 3 handover situation, the MAG function 143 located on the new access router. 145 o CT - Context Transfer. Means the transfer of any mobile node 146 related context from the mobile's previous access router to its 147 handover target access router. 149 o CR - Context Ready. Describes a state on an access router, 150 indicating that the router is ready to activate a context as soon 151 as it's available. 153 o CA - Context Activation. Describes a state on an access router, 154 indicating that the router has the complete context received and 155 activated. 157 o PHT - Proactive Handover Trigger. Describes an event on an access 158 router, which indicates the preparation or execution of a 159 proactive handover. Such indication provides further information 160 about the handover target access router, such as its IP address or 161 an unambiguous identifier. 163 o ATT - Attach. Describes an event on an access router, which 164 indicates that a mobile node has attached to the router and has a 165 fully functional layer-2 link established for bi-directional 166 traffic. Such indication provides further information, which is 167 required for the network-based mobility management protocol to 168 operate. 170 4. Protocol Design 172 This section describes the integration of the IETF's Context Transfer 173 protocol [RFC4067] with Proxy Mobile IPv6 174 [I-D.ietf-netlmm-proxymip6]. The reference architecture is described 175 in Figure 1. 177 4.1. Reference Architecture 179 The reference architecture covers a mobile node (MN), which is 180 attached to a local domain operating Proxy Mobile IPv6. The MN's 181 Local Mobility Anchor (LMA) tracks the MN's location and maintains 182 associated forwarding states towards the MN's current MAG. MAGs are 183 assumed to be colocated with the domain's access routers. In case 184 the MN changes its MAG due to a handover, the procedure implies that 185 the MN detaches from its current access router, which implements the 186 MN's previous MAG (pMAG) and attaches to a handover target access 187 router, which implements the MN's new MAG (nMAG). The context 188 transfer (CT) protocol is supposed to transfer the MN's context from 189 its previous access router to its new access router. The reference 190 architecture is illustrated in Figure 1. 192 Internet Backbone 193 : 194 : 195 | 196 +-----+ 197 | LMA | 198 +-----+ 199 | | 200 | | 201 +-------+ +--------+ 202 | | 203 | | 204 +-------+ +-------+ 205 |+-----+| |+-----+| 206 ||pMAG || ||nMAG || 207 |+-----+| CT |+-----+| 208 | AR |--------->| AR | 209 +-------+ +-------+ 210 : .: 211 : .........: 212 . ....: 213 :: 214 +--+ 215 |MN|---------> 216 +--+ 218 Figure 1: Reference architecture for context transfer in Proxy MIPv6. 220 Note: Within the context of the description in this document, pMAG 221 always refers to the network component, which is the MN's previous 222 access router, whereas nMAG refers to the MN's new access router. 224 4.2. Deployment Options 226 The integrated context transfer protocol leaves network operators 227 deployment liberties along three orthogonal axes: 229 1. Context transfer may happen reactively or proactively. 231 2. Context transfer may be initiated by the pMAG or by the nMAG. 233 3. The initiating pMAG/nMAG may obtain the IP address of the 234 correspondent nMAG/pMAG from any third entity. 236 Reactive context transfer is initiated either by the pMAG after the 237 mobile node has detached from the pMAG, or by the nMAG after the 238 mobile node has attached to the nMAG. Proactive context transfer is 239 initiated either by the pMAG before the mobile node detaches from the 240 pMAG, or by the nMAG before the mobile node attaches to the nMAG. 242 Context transfer requires a trigger for the initiating MAG to 243 indicate when the transfer should start. In case the context 244 transfer is reactive, this trigger may be a notification from the 245 link layer. If the context transfer happens proactively, the trigger 246 is likely to originate from a handover prediction algorithm that runs 247 on the initiating MAG. 249 Context transfer furthermore requires a "MAG resolution mechanism" 250 through which the initiating MAG can obtain the IP address of the 251 correspondent MAG. If the IP address of the correspondent MAG is to 252 be obtained from the LMA, the MAG resolution mechanism may use 253 options to Proxy Mobile IPv6 messages. The IP address of the 254 correspondent MAG may also be obtained through a proprietary 255 mechanism from the policy store, or via a local trigger. The nature 256 of the MAG resolution mechanism determines whether the context 257 transfer begins in parallel with the corresponding proxy binding 258 update or afterwards. 260 5. Protocol Operation 262 This section describes the operation of the integrated context 263 transfer protocol. The protocol operation is described for reactive 264 as well as proactive handover and assumes the required information 265 for context transfer is made available either through Proxy Mobile 266 IPv6 signaling or by means of a local event, which provides the 267 required information. The reactive handover can distinguish two 268 different scenarios. In one scenario, all information required to 269 operate Context Transfer on MAGs will be retrieved from the MN's LMA. 270 A different scenario might support the provision of some required 271 information from a local event, such as an ATTACH indication. The 272 proactive handover requires the pMAG to learn about the network 273 entity, which implements the MN's nMAG. 275 One general issue to be referred to is context deactivation and 276 deletion on an MN's previous access router. It needs to be ensured 277 that the context is not deleted before it has been completely 278 transferred to the MN's new access router. This could be achieved by 279 means of linking the lifetime of context information to the Proxy 280 Mobile IPv6 binding update list (BUL) on a MAG. If the MN's entry 281 expires in the BUL, the context can be deleted. This is somehow 282 save, as a BUL entry is not explicitly deleted under control of an 283 LMA, but has soft state characteristics, which expires. Deactivation 284 of context on the pMAG should be coordinated by the individual 285 component, which maintains the context. 287 5.1. Reactive Handover - Case 1 289 Figure 2 covers the integrated protocol operation for a reactive 290 handover, where the nMAG can initiate context transfer only after the 291 required information about the pMAG has been retrieved from the MN's 292 LMA. 294 As the LMA is aware of the MN's pMAG, it can inform the nMAG about 295 the pMAG's IP address. This information can be conveyed in a 296 Mobility Option of the Proxy BACK message. Possible option is a 297 pMAG_Address option, which carries the pMAG's IP address. 298 Alternatively, the pMAG can be identified by means of an identifier, 299 which can be resolved on the nMAG into the pMAG's IP address. For 300 this purpose, a pMAG_ID option can be specified. The nMAG is ready 301 to receive and activate context after the reception of the Proxy 302 BACK. The context can be activated after context data has been 303 transferred completely from the pMAG. 305 +----+ +----+ +---+ 306 |pMAG| |nMAG| |LMA| 307 +----+ +----+ +---+ 308 | | | 309 | [ATT] | 310 | |-------- Proxy BU ------->| 311 | | | 312 | |<------ Proxy BACK -------| 313 | [CR] | 314 |<----- CT-Req ------| | 315 | | | 316 |-------- CTD ------>| | 317 | [CA] | 318 |<-------CTDR*-------| | 319 | | | 320 | | | 321 *Optional 323 Figure 2: Reactive Handover - Case 1 325 5.2. Reactive Handover - Case 2 327 Figure 3 covers the integrated protocol operation for a reactive 328 handover, where the nMAG retrieves information about the MN's pMAG 329 through a local event, which also triggers the Proxy BU. This 330 approach does not require any additional information from Proxy 331 Mobile IPv6 operation. The context transfer can be performed in 332 parallel to the Proxy Mobile IPv6 registration. The context can be 333 activated on the nMAG after the reception of the context data. 335 +----+ +----+ +---+ 336 |pMAG| |nMAG| |LMA| 337 +----+ +----+ +---+ 338 | | | 339 | [ATT] | 340 | |-------- Proxy BU ------->| 341 |<----- CT-Req ------| | 342 | |<-------Proxy BACK--------| 343 | [CR] | 344 |-------- CTD ------>| | 345 | [CA] | 346 |<-------CTDR*-------| | 347 | | | 348 | | | 349 *Optional 351 Figure 3: Reactive Handover - Case 2 353 5.3. Proactive Handover - Case 1 355 Figure 4 covers the integrated protocol operation for a proactive 356 handover, where the pMAG can push an MN's context data to its target 357 access router even before the MN attaches to the pMAG. The pMAG 358 receives information about the MN's target access router through a 359 local indication. This approach does not require any additional 360 information from Proxy Mobile IPv6 operation. Advantageous of this 361 approach is, that the nMAG can learn about the MN's LMA even before 362 the MN attache MN attaches to the nMAG. 364 The nMAG is in this scenario permanently in CR mode for a set of 365 potential pMAGs. In a typical deployment scenario, MAGs that may 366 exchange contexts have preconfigured security associations. A 367 permanent CR mode between those MAGs that can authenticate each other 368 does not introduce new security risks. Garbage collection at the 369 nMAG ensures that transferred context will be removed automatically 370 in case the mobile node to which the context belongs never arrives at 371 the nMAG. 373 +----+ +----+ +---+ 374 |pMAG| |nMAG| |LMA| 375 +----+ +----+ +---+ 376 | | | 377 [PHT] | | 378 |------- CTD ------->| | 379 | | | 380 |<------CTDR*--------| | 381 | [ATT] | 382 | |-------- Proxy BU ------->| 383 | | | 384 | |<------ Proxy BACK -------| 385 | | | 386 | | | 387 *Optional 389 Figure 4: Proactive Handover - Case 1 391 5.4. Proactive Handover - Case 2 393 Figure 5 covers the integrated protocol operation for a proactive 394 handover, where the nMAG retrieves information about the MN's pMAG 395 through a local event. This approach does not require additional 396 information from Proxy Mobile IPv6 operation. The context can be 397 activated on the nMAG after the reception of the context data. The 398 nMAG initiates the Proxy Mobile IPv6 registration once the mobile 399 node attaches to it. 401 +----+ +----+ +---+ 402 |pMAG| |nMAG| |LMA| 403 +----+ +----+ +---+ 404 | | | 405 | [PHT] | 406 |<----- CT-Req ------| | 407 | [CR] | 408 |-------- CTD ------>| | 409 | [CA] | 410 |<-------CTDR*-------| | 411 | | | 412 | [ATT] | 413 | |-------- Proxy BU ------->| 414 | | | 415 | |<------ Proxy BACK -------| 416 | | | 417 | | | 418 *Optional 420 Figure 5: Proactive Handover - Case 2 422 6. Security Considerations 424 The integrated scenario as described in this document must meet the 425 security requirements of the two individual protocol components, 426 namely context transfer [RFC4067] and Proxy MIPv6 427 [I-D.ietf-netlmm-proxymip6]. 429 Information about an MN's previous access router must be 430 authenticated on the nMAG. If such information is retrieved from a 431 policy store, the access router which implements the nMAG should 432 share a security association with the policy store. Other mechanisms 433 to protect such information must be applied in case there is no 434 security association available between these network entities. The 435 same applies for information about the new access router, which is 436 used on the MN's pMAG to initiate context transfer in case of a 437 proactive handover scenario. 439 7. IANA Considerations 441 This documents includes no request to IANA. 443 8. Contributors 445 This document comprises valuable contributions from Julien Abeille 446 (abeille@netlab.nec.de). 448 9. Normative References 450 [I-D.ietf-netlmm-proxymip6] 451 Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 452 and B. Patil, "Proxy Mobile IPv6", 453 draft-ietf-netlmm-proxymip6-01 (work in progress), 454 June 2007. 456 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 457 Requirement Levels", BCP 14, RFC 2119, March 1997. 459 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 460 in IPv6", RFC 3775, June 2004. 462 [RFC4067] Loughney, J., Nakhjiri, M., Perkins, C., and R. Koodli, 463 "Context Transfer Protocol (CXTP)", RFC 4067, July 2005. 465 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 466 Internet Protocol", RFC 4301, December 2005. 468 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 469 RFC 4303, December 2005. 471 [RFC4831] Kempf, J., "Goals for Network-Based Localized Mobility 472 Management (NETLMM)", RFC 4831, April 2007. 474 Authors' Addresses 476 Marco Liebsch 477 NEC Laboratories Europe 478 NEC Europe Ltd. 479 Kurfuersten-Anlage 36 480 69115 Heidelberg, 481 Germany 483 Phone: +49 6221 4342146 484 Email: liebsch@netlab.nec.de 486 Christian Vogt 487 Ericsson Research, NomadicLab 488 Hirsalantie 11 489 02420 Jorvas 490 Finland 492 Email: christian.vogt@ericsson.com 494 Full Copyright Statement 496 Copyright (C) The IETF Trust (2007). 498 This document is subject to the rights, licenses and restrictions 499 contained in BCP 78, and except as set forth therein, the authors 500 retain all their rights. 502 This document and the information contained herein are provided on an 503 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 504 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 505 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 506 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 507 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 508 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 510 Intellectual Property 512 The IETF takes no position regarding the validity or scope of any 513 Intellectual Property Rights or other rights that might be claimed to 514 pertain to the implementation or use of the technology described in 515 this document or the extent to which any license under such rights 516 might or might not be available; nor does it represent that it has 517 made any independent effort to identify any such rights. Information 518 on the procedures with respect to rights in RFC documents can be 519 found in BCP 78 and BCP 79. 521 Copies of IPR disclosures made to the IETF Secretariat and any 522 assurances of licenses to be made available, or the result of an 523 attempt made to obtain a general license or permission for the use of 524 such proprietary rights by implementers or users of this 525 specification can be obtained from the IETF on-line IPR repository at 526 http://www.ietf.org/ipr. 528 The IETF invites any interested party to bring to its attention any 529 copyrights, patents or patent applications, or other proprietary 530 rights that may cover technology that may be required to implement 531 this standard. Please address the information to the IETF at 532 ietf-ipr@ietf.org. 534 Acknowledgment 536 Funding for the RFC Editor function is provided by the IETF 537 Administrative Support Activity (IASA).