idnits 2.17.1 draft-ietf-mipshop-pfmipv6-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 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 (March 9, 2009) is 5517 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 3775 (Obsoleted by RFC 6275) ** Downref: Normative reference to an Experimental RFC: RFC 4988 == Outdated reference: A later version (-18) exists of draft-ietf-netlmm-pmip6-ipv4-support-09 == Outdated reference: A later version (-09) exists of draft-ietf-netlmm-grekey-option-03 Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group H. Yokota 3 Internet-Draft KDDI Lab 4 Intended status: Standards Track K. Chowdhury 5 Expires: September 10, 2009 R. Koodli 6 Starent Networks 7 B. Patil 8 Nokia 9 F. Xia 10 Huawei USA 11 March 9, 2009 13 Fast Handovers for Proxy Mobile IPv6 14 draft-ietf-mipshop-pfmipv6-03.txt 16 Status of this Memo 18 This Internet-Draft is submitted to IETF in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on September 10, 2009. 39 Copyright Notice 41 Copyright (c) 2009 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents in effect on the date of 46 publication of this document (http://trustee.ietf.org/license-info). 47 Please review these documents carefully, as they describe your rights 48 and restrictions with respect to this document. 50 Abstract 52 This document specifies the usage of Fast Mobile IPv6 (FMIPv6) when 53 Proxy Mobile IPv6 is used as the mobility management protocol. 54 Necessary extensions are specified for FMIPv6 to support the scenario 55 when the mobile node does not have IP mobility functionality and 56 hence is not involved with either MIPv6 or FMIPv6 operations. 58 Table of Contents 60 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 61 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 63 4. Proxy-based FMIPv6 Protocol Overview . . . . . . . . . . . . . 7 64 4.1. Protocol Operation . . . . . . . . . . . . . . . . . . . . 7 65 4.2. IPv4 Support Considerations . . . . . . . . . . . . . . . 13 66 5. Other Considerations . . . . . . . . . . . . . . . . . . . . . 14 67 6. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 15 68 6.1. Mobility Header . . . . . . . . . . . . . . . . . . . . . 15 69 6.1.1. Handover Initiate (HI) . . . . . . . . . . . . . . . . 15 70 6.1.2. Handover Acknowledge (HAck) . . . . . . . . . . . . . 16 71 6.2. Mobility Options . . . . . . . . . . . . . . . . . . . . . 18 72 6.2.1. Context Request Option . . . . . . . . . . . . . . . . 18 73 6.2.2. Local Mobility Anchor Address (LMAA) Option . . . . . 20 74 6.2.3. IPv4 Address Option . . . . . . . . . . . . . . . . . 20 75 6.2.4. Home Network Prefix Option . . . . . . . . . . . . . . 21 76 6.2.5. Mobile Node Interface Identifier (MN IID) Option . . . 21 77 6.2.6. Link-local Address Option . . . . . . . . . . . . . . 21 78 6.2.7. GRE Key Option . . . . . . . . . . . . . . . . . . . . 21 79 6.2.8. Vendor-Specific Mobility Option . . . . . . . . . . . 21 80 7. Security Considerations . . . . . . . . . . . . . . . . . . . 22 81 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 82 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 83 9.1. Normative References . . . . . . . . . . . . . . . . . . . 24 84 9.2. Informative References . . . . . . . . . . . . . . . . . . 24 85 Appendix A. Other Considerations . . . . . . . . . . . . . . . . 25 86 A.1. Handoff Indication . . . . . . . . . . . . . . . . . . . . 25 87 A.2. Handling of PMIPv6/MIPv6 switching . . . . . . . . . . . . 25 88 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 27 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 91 1. Requirements notation 93 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 94 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 95 document are to be interpreted as described in [RFC2119]. 97 2. Introduction 99 Proxy Mobile IPv6 [RFC5213] provides IP mobility to a mobile node 100 that does not possess Mobile IPv6 [RFC3775] mobile node 101 functionality. A proxy agent in the network performs the mobility 102 management signaling on behalf of the mobile node. This model 103 transparently provides mobility for mobile nodes within a PMIPv6 104 domain. Nevertheless, the basic performance of PMIPv6 in terms of 105 handover latency and packet loss is considered not any different from 106 that of Mobile IPv6. 108 Fast Handovers for Mobile IPv6 (FMIPv6) [RFC5268bis] describes the 109 protocol to reduce the handover latency for Mobile IPv6 by allowing a 110 mobile node to send packets as soon as it detects a new subnet link 111 and by delivering packets to the mobile node as soon as its 112 attachment is detected by the new access router. This document 113 describes necessary extensions to FMIPv6 for operations in the PMIPv6 114 domain in order to minimize handover delay and packet loss as well as 115 to transfer network-resident contexts. 117 3. Terminology 119 This document refers to [RFC5213][RFC5268bis][RFC3775] for 120 terminology. The following terms and abbreviations are additionally 121 used in this document. The reference network is illustrated in 122 Figure 1. 124 Access Network (AN): 125 A network composed of link-layer access devices such as access 126 points or base stations providing access to the Access Router 127 (AR) connected to it. 129 Previous Access Network (P-AN): 130 The access network to which the MN is attached before handover. 132 New Access Network (N-AN): 133 The access network to which the MN is attached after handover. 135 Previous Mobile Access Gateway (PMAG): 136 The MAG that manages mobility related signaling for the MN 137 before handover. In this document, the MAG and the Access 138 Router are collocated. 140 New Mobile Access Gateway (NMAG): 141 The MAG that manages mobility related signaling for the MN after 142 handover. In this document, the MAG and the Access Router (AR) 143 are collocated. 145 HO-Initiate: 146 A generic signaling that indicates the handover of the MN sent 147 from the P-AN to the PMAG. While this signaling is dependent on 148 the access technology, it is assumed that HO-Initiate can carry 149 the information to identify the MN and to assist the PAR resolve 150 the NAR (e.g., the new access point or base station to which the 151 MN is moving). Detailed definition of this message is outside 152 the scope of this document. 154 +----------+ 155 | LMA | 156 | | 157 +----------+ 158 / \ 159 / \ 160 / \ 161 +........../..+ +..\..........+ 162 . +-------+-+ .______. +-+-------+ . 163 . | PAR |()_______)| NAR | . 164 . | (PMAG) | . . | (NMAG) | . 165 . +----+----+ . . +----+----+ . 166 . | . . | . 167 . ___|___ . . ___|___ . 168 . / \ . . / \ . 169 . ( P-AN ) . . ( N-AN ) . 170 . \_______/ . . \_______/ . 171 . | . . | . 172 . +----+ . . +----+ . 173 . | MN | ----------> | MN | . 174 . +----+ . . +----+ . 175 +.............+ +.............+ 177 Figure 1: Reference network for fast handover 179 4. Proxy-based FMIPv6 Protocol Overview 181 In order to improve the performance during handover (when operations 182 such as attachment to a new network and signaling between mobility 183 agents are involved), the PFMIPv6 protocol in this document specifies 184 a bi-directional tunnel between the Previous MAG (PMAG) and the New 185 MAG (NMAG). In order to enable the NMAG to send the Proxy Binding 186 Update (PBU), the Handover Initiate (HI) and Handover Acknowledge 187 (HAck) messages in [RFC5268bis] are used for context transfer, in 188 which parameters such as MN's NAI, Home Network Prefix (HNP), IPv4 189 Home Address, are transferred from the PMAG. 191 In this document, the Previous Access Router (PAR) and New Access 192 Router (NAR) are interchangeable with the PMAG and NMAG, 193 respectively. 195 Since a MN is not directly involved with IP mobility protocol 196 operations, it follows that the MN is not directly involved with fast 197 handover procedures either. Hence, the messages involving the MN in 198 [RFC5268bis] are not used when PMIPv6 is in use. Such messages are 199 the Router Solicitation for Proxy Advertisement (RtSolPr), Proxy 200 Router Advertisement (PrRtAdv), Fast Binding Update (FBU), Fast 201 Binding Acknowledgment (FBack) and Unsolicited Neighbor Advertisement 202 (UNA). 204 4.1. Protocol Operation 206 There are two modes of operation in FMIPv6 [RFC5268bis]. In the 207 predictive mode of fast handover, a bi-directional tunnel between the 208 PAR and NAR is established prior to the MN's attachment to the NAR. 209 In the reactive mode, this tunnel establishment takes place after the 210 MN attaches to the NAR. Since the MN is not involved in IP mobility 211 signaling in PMIPv6, the sequence of events illustrating the 212 predictive fast handover are shown in Figure 2. 214 PMAG NMAG 215 MN P-AN N-AN (PAR) (NAR) LMA 216 | | | | | | 217 | Report | | | | | 218 (a) |-(MN ID,-->| | | | | 219 | New AP ID)| | | | | 220 | | HO Initiate | | | 221 (b) | |--(MN ID, New AP ID)-->| | | 222 | | | | | | 223 | | | | HI | | 224 (c) | | | |-(MN ID, ->| | 225 | | | | MN IID, LMAA) | 226 | | | | | | 227 (d) | | | |<---HAck---| | 228 | | | | (MN ID) | | 229 | | | | | | 230 | | | |HI/HAck(optional) | 231 (e) | | | |<- - - - ->| | 232 | | | #=|<===================| 233 (f) | | | #====DL data=>| | 234 | | | | | | 235 (g) ~~~ | | | | | 236 ~~~ | | | | | 237 | MN-AN connection | AN-MAG connection | | 238 (h) |<---establishment---->|<----establishment----->| | 239 | | | (substitute for UNA) | | 240 | | | | | | 241 (i) |<==================DL data=====================|<=======| 242 | | | | | | 243 (j) |===================UL data====================>|=# | 244 | | | #=|<============# | 245 | | | #=====================>| 246 / | | | | | | \ 247 |(k) | | | | |--PBU-->| | 248 | | | | | | | | 249 |(l) | | | | |<--PBA--| | 250 \ | | | | | | / 252 Figure 2: Predictive fast handover for PMIPv6 (PAR initiated) 254 The detailed descriptions are as follows: 256 (a) The MN detects that a handover is imminent and reports the 257 identifications of itself (MN ID) and the access point (New AP 258 ID) to which the MN is most likely to move. The MN ID could be 259 the NAI or a Link Layer Address (LLA), or any other suitable 260 identifier. This step is access technology specific. In some 261 cases, the P-AN will determine which AP ID the MN is moving to. 263 (b) The previous access network (P-AN), to which the MN is currently 264 attached, indicates the handover of the MN to the PAR (PMAG). 265 Detailed definition and specification of this message are 266 outside the scope of this document. 268 (c) The PAR sends the HI to the NAR. The HI message MUST include 269 the MN ID and SHOULD include the MN-HNP, the MN-IID and the 270 address of the LMA that is currently serving the MN. 272 (d) The NAR sends the HAck back to the PAR. 274 (e) If it is preferred that the timing of buffering or forwarding 275 should be later than step (c), the NAR may optionally request 276 the PAR at a later and appropriate time to buffer or forward 277 packets by setting U or F flags in the HI message, respectively. 279 (f) If the F flag is set in the previous step, a bi-directional 280 tunnel is established between the PAR and NAR and packets 281 destined for the MN are forwarded from the PAR to the NAR over 282 this tunnel. After decapsulation, those packets may be buffered 283 at the NAR. If the connection between the N-AN and NAR has 284 already been established, those packet may be forwarded towards 285 the N-AN; this is access technology specific. 287 (g) The MN undergoes handover to the New Access Network (N-AN). 289 (h) The MN establishes a connection (e.g., radio channel) with the 290 N-AN, which in turn triggers the establishment of the connection 291 between the N-AN and NAR if it has not been established already 292 (access technology specific). This can be regarded as a 293 substitute for the UNA. 295 (i) The NAR starts to forward packets destined for the MN via the 296 N-AN. 298 (j) The uplink packets from the MN are sent to the NAR via the N-AN 299 and the NAR forwards them to the PAR. The PAR then sends the 300 packets to the LMA that is currently serving the MN. 302 (k) The NAR (NMAG) sends the Proxy Binding Update (PBU) to the LMA, 303 whose address is provided in (c). Steps (k) and (l) are not 304 part of the fast handover procedure, but shown for reference. 306 (l) The LMA sends back the Proxy Binding Acknowledgment (PBA) to the 307 NAR (NMAG). From this time on, the packets to/from the MN go 308 through the NAR instead of the PAR. 310 According to Section 4 of [RFC5268bis], the PAR establishes a binding 311 between the PCoA and NCoA to forward packets for the MN to the NAR, 312 and the NAR creates a proxy NCE to receive those packets for the NCoA 313 before the MN arrives. In the case of PMIPv6, however, the only 314 address that is used by the MN is MN-HoA. Hence the PAR forwards 315 MN's packets to the NAR instead of the NCoA. FMIPv4 [RFC4988] 316 specifies forwarding when the MN uses HoA as its on-link address 317 rather than the care-of address. The usage in PMIPv6 is similar to 318 that in FMIPv4, where the address is used by the MN is based on Home 319 Network Prefix. Hence the PAR forwards MN's packets to the NAR 320 instead of the NCoA. The NAR then simply decapsulates those packets 321 and delivers them to the MN. Since the NAR obtains the LLA (MN IID) 322 and MN-HNP by the HI, it can create the NCE for the MN and deliver 323 packets to it even before the MN can perform Neighbor Discovery. For 324 the uplink packets from the MN after handover in (j), the NAR 325 forwards the packets to the PAR through the tunnel established in 326 step (f). The PAR then decapsulates and sends them to the LMA. 328 The timing of the context transfer and that of packet forwarding may 329 be different. Thus, a new flag 'F' and the Option Code values for it 330 in the HI message are defined to request forwarding. To request 331 buffering, 'U' flag has already been defined in [RFC5268bis]. If the 332 PAR receives the HI message with F flag set and the Option Code value 333 being 2, it starts forwarding packets for the MN. The HI message 334 with U flag set may be sent earlier if the timing of buffering is 335 different from that of forwarding. If packet forwarding is 336 completed, the PAR MAY send the HI message with F flag set and the 337 Option Code value being 3. By this message, the ARs on both ends can 338 tear down the forwarding tunnel synchronously. 340 The IP addresses in the headers of those user packets are summarized 341 below: 343 In (f), 345 Inner source address: IP address of the CN 347 Inner destination address: HNP or IPv4-MN-HoA 349 Outer source address: IP address of the PAR (PMAG) 351 Outer destination address: IP address of the NAR (NMAG) 353 In (i), 355 Source address: IP address of the CN 356 Destination address: HNP or IPv4-MN-HoA 358 In (j), 360 - from the MN to the NMAG, 362 Source address: HNP or IPv4-MN-HoA 364 Destination address: IP address of the CN 366 - from the NMAG to the PMAG, 368 Inner source address: HNP or IPv4-MN-HoA 370 Inner destination address: IP address of the CN 372 Outer source address: IP address of the NAR (NMAG) 374 Outer destination address: IP address of the PAR (PMAG) 376 - from the PMAG to the LMA, 378 Inner source address: HNP or IPv4-MN-HoA 380 Inner destination address: IP address of the CN 382 Outer source address: IP address of the PAR (PMAG) 384 Outer destination address: IP address of the LMA 386 In the case of the reactive handover for PMIPv6, since the MN does 387 not send either the FBU or UNA, it would be more natural that the NAR 388 sends the HI to the PAR after the MN has moved to the new link. The 389 NAR then needs to obtain the information of the PAR beforehand. Such 390 information could be provided, for example, by the MN sending the 391 AP-ID on the old link and/or by the lower-layer procedures between 392 the P-AN and N-AN. The exact method is not specified in this 393 document. Figure 3 illustrates the reactive fast handover procedures 394 for PMIPv6, where the bi-directional tunnel establishment is 395 initiated by the NAR. 397 PMAG NMAG 398 MN P-AN N-AN (PAR) (NAR) LMA 399 | | | | | | 400 (a) ~~~ | | | | | 401 ~~~ | | | | | 402 | MN-AN connection | AN-MAG connection | | 403 (b) |<--establishment-->|<-------establishment------>| | 404 |(MN ID, Old AP ID) | (MN ID, Old AP ID) | | 405 | | |(substitute for UNA and FBU)| | 406 | | | | | | 407 | | | | HI | | 408 (c) | | | |<---(MN ID) ---| | 409 | | | | | | 410 | | | | HAck | | 411 (d) | | | |---(MN ID, --->| | 412 | | | | MN IID, LMAA) | | 413 | | | | | | 414 (e) | | | #=|<=======================| 415 | | | #================>|=# | 416 |<====================DL data======================# | 417 | | | | | | 418 (f) |=====================UL data===================>|=# | 419 | | | #=|<================# | 420 | | | #=========================>| 421 | | | | | | 422 / | | | | | | \ 423 |(g) | | | | |--PBU-->| | 424 | | | | | | | | 425 |(h) | | | | |<--PBA--| | 426 \ | | | | | | / 428 Figure 3: Reactive fast handover for PMIPv6 (NAR initiated) 430 The detailed descriptions are as follows: 432 (a) The MN undergoes handover from the P-AN to the N-AN. The AP-ID 433 on the old link may be provided by the MN to help identify the 434 PMAG on the new link. 436 (b) The MN establishes a connection (e.g., radio channel) with the 437 N-AN, which triggers the establishment of the connection between 438 the N-AN and NAR. The MN ID is transferred to the NAR for the 439 subsequent procedures. The AP-ID on the old link may also be 440 provided by the MN to help identify the PMAG on the new link. 441 This can be regarded as a substitute for the UNA and FBU. 443 (c) The NAR sends the HI to the PAR. The HI message MUST include 444 the MN ID. The Context Request Option MAY be included to 445 request additional context information on the MN to the PAR. 447 (d) The PAR sends the HAck back to the NAR. The HAck message MUST 448 include the HNP and/or IPv4-MN-HoA that is corresponding to the 449 MN ID in the HI message and SHOULD include the MN-IID and the 450 LMA address that is currently serving the MN. The context 451 information requested by the NAR MUST be included. 453 (e) If F flag in the HI is set, a bi-directional tunnel is 454 established between the PAR and NAR and packets destined for the 455 MN are forwarded from the PAR to the NAR over this tunnel. 456 After decapsulation, those packets are delivered to the MN via 457 the N-AN. 459 (f) The uplink packets from the MN are sent to the NAR via the N-AN 460 and the NAR forwards them to the PAR. The PAR then sends the 461 packets to the LMA that is currently serving the MN. 463 Steps (g)-(h) are the same as (k)-(l) in the predictive fast handover 464 procedures. 466 In step (c), The IP address of the PAR needs to be resolved by the 467 NAR to send the HI to the PAR. This information may come from the 468 N-AN or some database that the NAR can access. 470 4.2. IPv4 Support Considerations 472 The motivation and usage scenarios of IPv4 protocol support by PMIPv6 473 are described in [IPv4PMIPv6]. The scope of IPv4 support covers the 474 following two features: 476 o IPv4 Home Address Mobility Support, and 478 o IPv4 Transport Support. 480 As for IPv4 Home Address Mobility Support, the MN acquires IPv4 Home 481 Address (IPv4-MN-HoA) and in the case of handover, the PMAG needs to 482 transfer IPv4-MN-HoA to the NMAG, which is the inner destination 483 address of the packets forwarded on the downlink. In order to 484 support IPv4-MN-HoA, a new option called IPv4 Address Option is 485 defined in this document. In order to provide IPv4 Transport 486 Support, the NMAG needs to know the IPv4 address of the LMA (IPv4- 487 LMAA) to send PMIPv6 signaling messages to the LMA in the IPv4 488 transport network. The above IPv4 Address Option is defined so as to 489 be able to convey IPv4-LMAA. The details of this option are 490 described in [IPv4PMIPv6]. 492 5. Other Considerations 494 The protocol specified in this document enables the NMAG to obtain 495 parameters which would otherwise be available only by communicating 496 with the LMA. For instance, the HNP and/or IPv4-MN-HoA of a MN are 497 made available to the NMAG through context transfer. This allows the 498 NMAG to perform some procedures which may be beneficial. For 499 instance, the NMAG could send a Router Advertisement (RA) with the 500 HNP option to the MN as soon as it's link attachment is detected 501 (e.g., via receipt of a Router Solicitation message). Such an RA is 502 recommended, for example, in scenarios where the MN uses a new radio 503 interface while attaching to the NMAG; since the MN does not have 504 information regarding the new interface, it will not be able to 505 immediately send packets without first receiving an RA with HNP. 506 However, if the subsequent PMIPv6 binding registration for the HNP 507 fails for some reason, then the NMAG MUST withdraw the advertised HNP 508 by sending another RA with zero prefix lifetime for the HNP in 509 question. This operation is the same as that described in Section 510 6.12 of [RFC5213]. 512 The protocol specified in this document is applicable regardless of 513 whether link-layer addresses are used between a MN and its access 514 router. A MN should be able to continue sending packets on the 515 uplink even when it changes link. When link-layer addresses are 516 used, the MN performs Neighbor Unreachability Detection (NUD) 517 [RFC4861], after attaching to a new link, probing the reachability of 518 its default router. If the new router's interface is configured to 519 respond to queries sent to link-layer addresses than its own (e.g., 520 set to promiscuous mode), then it can respond to the NUD probe, 521 providing its link-layer address in the solicited Neighbor 522 Advertisement. While the MN is performing NUD, it can continue to 523 send uplink packets. 525 6. Message Formats 527 This document defines new Mobility Header messages for the extended 528 HI and Hack and new mobility options for conveying context 529 information. 531 6.1. Mobility Header 533 6.1.1. Handover Initiate (HI) 535 This section defines extensions to the HI message in [RFC5268bis]. 536 The format of the Message Data field in the Mobility Header is as 537 follows: 539 0 1 2 3 540 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 541 +-------------------------------+ 542 | Sequence # | 543 +-+-+-+-----------+-------------+-------------------------------+ 544 |S|U|F| Reserved | Code | | 545 +-+-+-+-----------+-------------+ | 546 | | 547 . . 548 . Mobility options . 549 . . 550 | | 551 +---------------------------------------------------------------+ 553 IP Fields: 555 Source Address 557 The IP address of PMAG or NMAG 559 Destination Address 561 The IP address of the peer MAG 563 Message Data: 565 Sequence # Same as [RFC5268bis]. 567 S flag Defined in [RFC5268bis] and MUST be set to zero in this 568 specification. 570 U flag Buffer flag. Same as [RFC5268bis]. 572 F flag Forwarding flag. Used to request to forward the packets 573 for the MN. 575 Reserved Same as [RFC5268bis]. 577 Code [RFC5268bis] defines this field and its values 0 and 1. 578 In this specification, if F flag is not set, this field 579 MUST be set to zero. Otherwise, it has the following 580 meaning: 582 2: Forwarding is not requested 584 3: Request forwarding 586 4: Indicate the completion of forwarding 588 Mobility options: 590 This field contains one or more mobility options, whose encoding and 591 formats are defined in [RFC3775]. At least one mobility option MUST 592 uniquely identify the target MN (e.g., the Mobile Node Identifier 593 Option defined in RFC4283) and the transferred context MUST be for 594 one MN per message. In addition, the NAR can request necessary 595 mobility options by the Context Request Option defined in this 596 document. 598 Context Request Option 600 This option MAY be present to request context information 601 typically by the NAR to the PAR in the NAR-initiated fast 602 handover. 604 6.1.2. Handover Acknowledge (HAck) 606 This section defines extensions to the HAck message in[RFC5268bis]. 607 The format of the Message Data field in the Mobility Header is as 608 follows: 610 0 1 2 3 611 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 612 +-------------------------------+ 613 | Sequence # | 614 +-+-+-----------+---------------+-------------------------------+ 615 |U|F| Reserved | Code | | 616 +-+-+-----------+---------------+ | 617 | | 618 . . 619 . Mobility options . 620 . . 621 | | 622 +---------------------------------------------------------------+ 624 IP Fields: 626 Source Address 628 Copied from the destination address of the 629 Handover Initiate message to which this message 630 is a response. 632 Destination Address 634 Copied from the source address of the Handover 635 Initiate message to which this message is a 636 response. 638 Message Data: 640 The usages of Sequence # and Reserved fields are exactly the same as 641 those in [RFC5268bis]. 643 U, F flags Same as defined in Section 6.1.1. 645 Code 646 Code values 0 through 4 and 128 through 130 are defined 647 in [RFC5268bis]. In this specification, the meaning of 648 Code value 0 is modified, 128 through 130 are reused, and 649 5, 6, 131 and 132 are newly defined. 651 0: Handover Accepted 653 5: Context Transfer Successful or Accepted 654 6: All available Context Transferred 656 128: Handover Not Accepted, reason unspecified 658 129: Administratively prohibited 660 130: Insufficient resources 662 131: Requested Context Not Available 664 132: Forwarding Not Available 666 Mobility options: 668 This field contains one or more mobility options, whose encoding and 669 formats are defined in [RFC3775]. The mobility option that uniquely 670 identifies the target MN MUST be copied from the corresponding HI 671 message and the transferred context MUST be for one MN per message. 673 Requested option(s) All the context information requested by the 674 Context Request Option in the HI message SHOULD be present 675 in the HAck message. The other cases are described below. 677 In the case of the PAR-initiated fast handover, when the PAR sends 678 the HI message to the NAR with the context information and the NAR 679 successfully receives it, the NAR returns the HAck message with Code 680 value 5. In the case of the NAR-initiated fast handover, when the 681 NAR sends the HI message to the PAR with or without Context Request 682 Option, the PAR returns the HAck message with the requested or 683 default context information (if any). If all available context 684 information is transferred, the PAR sets the Code value in the HAck 685 message to 6. If more context information is available, the PAR sets 686 the Code value in the HAck to 5 and the NAR MAY send new HI 687 message(s) to retrieve the rest of the available context information. 688 If none of the requested context information is available, the PAR 689 returns the HAck message with Code value 131 without any context 690 information. 692 6.2. Mobility Options 694 6.2.1. Context Request Option 696 This option is sent in the HI message to request context information 697 on the MN. If a default set of context information is defined and 698 always sufficient, this option is not mandatory. This option is more 699 useful to retrieve additional or dynamically selected context 700 information. 702 Context Request Option is typically used for the reactive (NAR- 703 initiated) fast handover mode to retrieve the context information 704 from the PAR. When this option is included in the HI message, all 705 the requested context information SHOULD be included in the HAck 706 message in the corresponding mobility option(s) (e.g., HNP, LMAA or 707 MN-IID mobility options). 709 0 1 2 3 710 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 711 +---------------+---------------+---------------+---------------+ 712 | Option-Type | Option-Length | Reserved | 713 +---------------+---------------+-------------------------------+ 714 | Req-type-1 | Req-length-1 | Req-type-2 | Req-length-2 | 715 +---------------------------------------------------------------+ 716 | ... | 718 Option-Type TBD1 720 Option-Length The length in octets of this option, not including the 721 Option Type and Option Length fields. 723 Reserved This field is unused. It MUST be initialized to zero 724 by the sender and MUST be ignored by the receiver. 726 Req-type-n The type value for the n'th requested option. 728 Req-length-n The length of the n'th requested option excluding the 729 Req-type-n and Req-length-n fields. 731 In the case where there are only Req-type-n and Req-length-n fields, 732 the value of the Req-length-n is set to zero. If additional 733 information besides the Req-type-n is necessary to uniquely specify 734 the requested context, such information follows after the 735 Req-length-n. For example, when the requested context is the Vendor- 736 Specific Option described in Section 6.2.8, the requested option 737 format looks as follows: 739 | ... | 740 +---------------+---------------+-------------------------------+ 741 | Req-type-N=19 | Req-length-N=5| Vendor-ID | 742 +-------------------------------+---------------+---------------+ 743 | Vendor-ID | Sub-Type | | 744 +-----------------------------------------------+ | 745 | ... | 747 The exact values in the Vendor-ID and Sub-Type are outside the scope 748 of this document. 750 6.2.2. Local Mobility Anchor Address (LMAA) Option 752 This option is used to transfer the Local Mobility Anchor IPv6 753 Address (LMAA) or its IPv4 Address (IPv4-LMAA), with which the MN is 754 currently registered. The detailed definition of the LMAA is 755 described in [RFC5213]. 757 0 1 2 3 758 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 759 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 760 | Option-Type | Option-Length | Option-Code | Reserved | 761 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 762 | Local Mobility Anchor Address ... | 764 Option-Type TBD2 766 Option-Length 18 or 6 768 Option-Code 770 0 Reserved 772 1 IPv6 address of the LMA (LMAA) 774 2 IPv4 address of the LMA (IPv4-LMAA) 776 Reserved This field is unused. It MUST be initialized to zero 777 by the sender and MUST be ignored by the receiver. 779 Local Mobility Anchor Address 780 If Option-Code is 1, the LMA IPv6 address (LMAA) is 781 inserted. If Option-Code is 2, the LMA IPv4 address 782 (IPv4-LMA) is inserted. 784 6.2.3. IPv4 Address Option 786 As described in Section 4.2, if the MN is IPv4-only mode or dual- 787 stack mode, the MN requires IPv4 home address (IPv4-MN-HoA). This 788 option has alignment requirement of 4n. 790 0 1 2 3 791 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 792 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 793 | Option-Type | Option-Length | Option-Code | Reserved | 794 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 795 | IPv4 Address | 796 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 798 Option-Type TBD3 800 Option-Length 6 802 Option-Code 804 0 Reserved 806 1 IPv4-MN-HoA 808 Reserved This field is unused. It MUST be initialized to zero 809 by the sender and MUST be ignored by the receiver. 811 IPv4 Address IPv4 address specified in Option-Code 813 6.2.4. Home Network Prefix Option 815 This option is used to transfer the home network prefix that is 816 assigned to the MN in the P-AN. The Home Network Prefix Option 817 defined in [RFC5213] is used for this. 819 6.2.5. Mobile Node Interface Identifier (MN IID) Option 821 This option is used to transfer the interface identifier of the MN 822 that is used in the P-AN. The Mobile Node Interface Identifier 823 Option defined in [RFC5213] is used for this. 825 6.2.6. Link-local Address Option 827 This option is used to transfer the link-local address of the PAR 828 (PMAG). The Link-local Address Option defined in [RFC5213] is used 829 for this. 831 6.2.7. GRE Key Option 833 This option is used to transfer the GRE Key for the MN's data flow 834 over the bi-directional tunnel between the PAR and NAR. The message 835 format of this option follows the GRE Key Option defined in [GREKEY]. 836 The GRE Key value uniquely identifies each flow and the sender of 837 this option expects to receive packets of the flow from the peer AR 838 with this value. 840 6.2.8. Vendor-Specific Mobility Option 842 This option is used to transfer any other information defined in this 843 document. The format of this option follows the Vendor-Specific 844 Mobility Option defined in [RFC5094]. The exact values in the Vendor 845 ID, Sub-Type and Data fields are outside the scope of this document. 847 7. Security Considerations 849 Security issues for this document follow those for PMIPv6[RFC5213] 850 and FMIPv6[RFC5268bis]. In PMIPv6, MAG and LMA are assumed to share 851 security association. In FMIPv6, the access routers (i.e., the PMAG 852 and NMAG in this document) are assumed to share security association. 853 No new security risks are identified. Support for integrity 854 protection using IPsec is required and confidentiality protection 855 SHOULD be used if sensitive context related to the mobile node is 856 being transferred. 858 8. IANA Considerations 860 This document defines two new mobility options, which are described 861 in Section 6.2. The Type value for these options are assigned from 862 the same numbering space as allocated for the other mobility options, 863 as defined in [RFC3775]. 865 Mobility Options 866 Value Description Reference 867 ----- ------------------------------------- ------------- 868 TBD1 Context Request Option Section 6.2.1 869 TBD2 Local Nobility Anchor Address Option Section 6.2.2 870 TBD3 IPv4 Address Option Section 6.2.3 872 9. References 874 9.1. Normative References 876 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 877 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 879 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 880 Requirement Levels", BCP 14, RFC 2119, March 1997. 882 [RFC5268bis] 883 Koodli, R., Ed., "Mobile IPv6 Fast Handovers", 884 draft-ietf-mipshop-rfc5268bis-01.txt, March 2009. 886 [RFC3775] Johnson, D., "Mobility Support in IPv6", RFC 3775, 887 June 2004. 889 [RFC4988] Koodli, R. and C. Perkins, "Mobile IPv4 Fast Handovers", 890 RFC 4988, October 2007. 892 [RFC5094] Devarapalli, V., Patel, A., and K. Leung, "Mobile IPv6 893 Vendor Specific Option", RFC 5094, December 2007. 895 9.2. Informative References 897 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 898 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 899 September 2007. 901 [IPv4PMIPv6] 902 Wakikawa, R., Ed. and S. Gundavelli, "IPv4 Support for 903 Proxy Mobile IPv6", 904 draft-ietf-netlmm-pmip6-ipv4-support-09.txt, 905 January 2009. 907 [GREKEY] Muhanna, A., Ed., "GRE Key Option for Proxy Mobile IPv6", 908 draft-ietf-netlmm-grekey-option-03.txt, January 2009. 910 Appendix A. Other Considerations 912 A.1. Handoff Indication 914 PMIPv6 [RFC5213] defines the Handoff Indicator Option and describes 915 the type of the handoff and the values to set to the option. This 916 document proposes one approach to determining the handoff type by the 917 NMAG when the handoff of the MN is executed. 919 According to [RFC5213], the following handoff types are defined: 921 0) Reserved 923 1) Attachment over a new interface 925 2) Handoff between two different interfaces of the mobile node 927 3) Handoff between mobile access gateways for the same interface 929 4) Handoff state unknown 931 5) Handoff state not changed (Re-registration) 933 By using the MN Interface Identifier (MN IID) option, which is 934 defined in this document, the following solution can be considered. 935 When the NMAG receives the MN IID used in the P-AN from the PMAG via 936 the HI or HAck messages, the NMAG compares it with the new MN IID 937 that is obtained from the MN in the N-AN. If these two MN IIDs are 938 the same, the handover type falls into 3) and the Handoff Indicator 939 value is set to 3. If these two MN IIDs are different, the handover 940 is likely to be 2) since the HI/HAck message exchange implies that 941 this is a handover not a multi-homing, therefore the Handoff 942 Indicator value can be set to 2. If there is no HI/Hack exchange 943 performed prior to the network attachment of the MN in the new 944 network, the NMAG may infer that this is a multi-homing case and set 945 the Handoff Indicator value to 1. In the case of re-registration, 946 the MAG, to which the MN is attached, can determine if the handoff 947 state is not changed, so the MAG can set the HI value to 5 without 948 any additional information. If none of them can be assumed, the NMAG 949 may set the value to 4. 951 A.2. Handling of PMIPv6/MIPv6 switching 953 If the network that the MN has moved to does not support PMIPv6 but 954 only MIPv6 (i.e. there exists a MIPv6 HA) and the MN supports MIPv6 955 at the same time, the MN and HA can exchange BU/BA instead of PBU/PBA 956 (e.g., at steps (k) and (l) in Figure 2). If this is the case, the 957 LMA and HA will most likely be collocated and the LMA (HA) address 958 should be maintained in the new network for communication continuity. 959 Since the LMA (HA) address is transferred to the NAR in the HI/HAck 960 exchange, the MN can retrieve it at or after the handover by way of, 961 e.g., the authentication or DHCP procedure. 963 Appendix B. Change Log 965 Changes at -00 967 * Added separate sections for MH and ICMP. 969 * Clarified usage of HNP and IPv4-MN-HoA throughout the document. 971 * Added IANA Considerations. 973 * Added section on Other Considerations, including operation of 974 uplink packets when using link-layer addresses, multiple 975 interface usage and transmission of RA to withdraw HNP in the 976 event of failure of PMIP6 registration. 978 * Revised Security Considerations. 980 Changes from -00 to -01 982 * Removed ICMPv6-based message format. 984 * Clarified HI/HAck exchange in the predictive mode (step (e) in 985 Figure 2). 987 * Clarified information retrieval about the PMAG in the reactive 988 mode. 990 * Removed the extension to the GRE Key Option. 992 * Clarified the handoff type considerations in Appendix A. 994 * Home Network Prefix Option, Link-local Address Option and 995 Vendor-Specific Mobility Option are added. 997 Changes from -01 to -02 999 * Aligned HI/HAck message formats with [RFC5268bis] 1000 (draft-ietf-mipshop-rfc5268bis-00.txt). 1002 * Revised Section 8 removing the request for the type assignment 1003 of HI/HAck Mobility Headers. 1005 Changes from -02 to -03 1007 * Updated HI/HAck message formats according to 1008 draft-ietf-mipshop-rfc5268bis-01.txt. 1010 * Cleaned up Figure 2 and Figure 3. 1012 * Moved PMIP domain boundary crossing situation in Section 4.1 to 1013 Appendix A.2. 1015 * Removed the alternative protocol operation with an unsolicited 1016 HAck from Section 4.1. 1018 * Modified Code values in the HAck message in order to avoid 1019 collision with those in [RFC5268bis]. 1021 * Clarified the usage scenarios of Context Request Option. 1023 * Modified the description of Code values in the HAck message. 1025 * Changed the container for the IPv4-LMAA from IPv4 Address 1026 option to the LMAA option. 1028 * Made Confidentiality protection "SHOULD" for context transfer. 1030 Authors' Addresses 1032 Hidetoshi Yokota 1033 KDDI Lab 1034 2-1-15 Ohara, Fujimino 1035 Saitama, 356-8502 1036 JP 1038 Email: yokota@kddilabs.jp 1040 Kuntal Chowdhury 1041 Starent Networks 1042 30 International Place 1043 Tewksbury, MA 01876 1044 US 1046 Email: kchowdhury@starentnetworks.com 1048 Rajeev Koodli 1049 Starent Networks 1050 30 International Place 1051 Tewksbury, MA 01876 1052 US 1054 Email: rkoodli@starentnetworks.com 1056 Basavaraj Patil 1057 Nokia 1058 6000 Connection Drive 1059 Irving, TX 75039 1060 US 1062 Email: basavaraj.patil@nokia.com 1064 Frank Xia 1065 Huawei USA 1066 1700 Alma Dr. Suite 500 1067 Plano, TX 75075 1068 US 1070 Email: xiayangsong@huawei.com