idnits 2.17.1 draft-ietf-mipshop-pfmipv6-11.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC3775], [RFC5213], [RFC5568]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 28, 2009) is 5256 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) == Outdated reference: A later version (-18) exists of draft-ietf-netlmm-pmip6-ipv4-support-17 Summary: 3 errors (**), 0 flaws (~~), 2 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: June 1, 2010 R. Koodli 6 Starent Networks 7 B. Patil 8 Nokia 9 F. Xia 10 Huawei USA 11 November 28, 2009 13 Fast Handovers for Proxy Mobile IPv6 14 draft-ietf-mipshop-pfmipv6-11.txt 16 Abstract 18 Mobile IPv6 (MIPv6) [RFC3775] provides a mobile node with IP mobility 19 when it performs a handover from one access router to another and 20 fast handovers for Mobile IPv6 (FMIPv6) [RFC5568] are specified to 21 enhance the handover performance in terms of latency and packet loss. 22 While MIPv6 (and FMIPv6 as well) requires the participation of the 23 mobile node in the mobility-related signaling, Proxy Mobile IPv6 24 (PMIPv6) [RFC5213] provides IP mobility to mobile nodes that either 25 have or do not have MIPv6 functionality without such involvement. 26 Nevertheless, the basic performance of PMIPv6 in terms of handover 27 latency and packet loss is considered not any different from that of 28 MIPv6. 30 When the fast handover is considered in such an environment, several 31 modifications are needed to FMIPv6 to adapt to the network-based 32 mobility management. This document specifies the usage of Fast 33 Mobile IPv6 (FMIPv6) when Proxy Mobile IPv6 is used as the mobility 34 management protocol. Necessary extensions are specified for FMIPv6 35 to support the scenario when the mobile node does not have IP 36 mobility functionality and hence is not involved with either MIPv6 or 37 FMIPv6 operations. 39 Status of this Memo 41 This Internet-Draft is submitted to IETF in full conformance with the 42 provisions of BCP 78 and BCP 79. 44 Internet-Drafts are working documents of the Internet Engineering 45 Task Force (IETF), its areas, and its working groups. Note that 46 other groups may also distribute working documents as Internet- 47 Drafts. 49 Internet-Drafts are draft documents valid for a maximum of six months 50 and may be updated, replaced, or obsoleted by other documents at any 51 time. It is inappropriate to use Internet-Drafts as reference 52 material or to cite them other than as "work in progress." 54 The list of current Internet-Drafts can be accessed at 55 http://www.ietf.org/ietf/1id-abstracts.txt. 57 The list of Internet-Draft Shadow Directories can be accessed at 58 http://www.ietf.org/shadow.html. 60 This Internet-Draft will expire on June 1, 2010. 62 Copyright Notice 64 Copyright (c) 2009 IETF Trust and the persons identified as the 65 document authors. All rights reserved. 67 This document is subject to BCP 78 and the IETF Trust's Legal 68 Provisions Relating to IETF Documents 69 (http://trustee.ietf.org/license-info) in effect on the date of 70 publication of this document. Please review these documents 71 carefully, as they describe your rights and restrictions with respect 72 to this document. Code Components extracted from this document must 73 include Simplified BSD License text as described in Section 4.e of 74 the Trust Legal Provisions and are provided without warranty as 75 described in the BSD License. 77 This document may contain material from IETF Documents or IETF 78 Contributions published or made publicly available before November 79 10, 2008. The person(s) controlling the copyright in some of this 80 material may not have granted the IETF Trust the right to allow 81 modifications of such material outside the IETF Standards Process. 82 Without obtaining an adequate license from the person(s) controlling 83 the copyright in such materials, this document may not be modified 84 outside the IETF Standards Process, and derivative works of it may 85 not be created outside the IETF Standards Process, except to format 86 it for publication as an RFC or to translate it into languages other 87 than English. 89 Table of Contents 91 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 4 92 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 93 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 94 4. Proxy-based FMIPv6 Protocol Overview . . . . . . . . . . . . . 7 95 4.1. Protocol Operation . . . . . . . . . . . . . . . . . . . . 8 96 4.2. Inter-AR Tunneling Operation . . . . . . . . . . . . . . . 15 97 4.3. IPv4 Support Considerations . . . . . . . . . . . . . . . 17 98 5. PMIPv6-related Fast Handover Issues . . . . . . . . . . . . . 18 99 5.1. Manageability Considerations . . . . . . . . . . . . . . . 18 100 5.2. Expedited Packet Transmission . . . . . . . . . . . . . . 18 101 6. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 20 102 6.1. Mobility Header . . . . . . . . . . . . . . . . . . . . . 20 103 6.1.1. Handover Initiate (HI) . . . . . . . . . . . . . . . . 20 104 6.1.2. Handover Acknowledge (HAck) . . . . . . . . . . . . . 22 105 6.2. Mobility Options . . . . . . . . . . . . . . . . . . . . . 24 106 6.2.1. Context Request Option . . . . . . . . . . . . . . . . 24 107 6.2.2. Local Mobility Anchor Address (LMAA) Option . . . . . 25 108 6.2.3. Mobile Node Link-local Address Interface 109 Identifier (MN LLA-IID) Option . . . . . . . . . . . . 26 110 6.2.4. Home Network Prefix Option . . . . . . . . . . . . . . 27 111 6.2.5. Link-local Address Option . . . . . . . . . . . . . . 27 112 6.2.6. GRE Key Option . . . . . . . . . . . . . . . . . . . . 27 113 6.2.7. IPv4 Address Option . . . . . . . . . . . . . . . . . 27 114 6.2.8. Vendor-Specific Mobility Option . . . . . . . . . . . 27 115 7. Security Considerations . . . . . . . . . . . . . . . . . . . 28 116 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 117 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 30 118 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31 119 10.1. Normative References . . . . . . . . . . . . . . . . . . . 31 120 10.2. Informative References . . . . . . . . . . . . . . . . . . 31 121 Appendix A. Applicable Use Cases . . . . . . . . . . . . . . . . 32 122 A.1. PMIPv6 Handoff Indication . . . . . . . . . . . . . . . . 32 123 A.2. Local Routing . . . . . . . . . . . . . . . . . . . . . . 32 124 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 34 125 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 40 127 1. Requirements notation 129 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 130 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 131 document are to be interpreted as described in [RFC2119]. 133 2. Introduction 135 Proxy Mobile IPv6 [RFC5213] provides IP mobility to a mobile node 136 that does not support Mobile IPv6 [RFC3775] mobile node 137 functionality. A proxy agent in the network performs the mobility 138 management signaling on behalf of the mobile node. This model 139 transparently provides mobility for mobile nodes within a PMIPv6 140 domain. Nevertheless, the basic performance of PMIPv6 in terms of 141 handover latency and packet loss is considered not any different from 142 that of Mobile IPv6. 144 Fast Handovers for Mobile IPv6 (FMIPv6) [RFC5568] describes the 145 protocol to reduce the handover latency for Mobile IPv6 by allowing a 146 mobile node to send packets as soon as it detects a new subnet link 147 and by delivering packets to the mobile node as soon as its 148 attachment is detected by the new access router. This document 149 describes necessary extensions to FMIPv6 to minimize handover delay 150 and packet loss as well as to transfer network-resident context for a 151 PMIPv6 handover. 153 3. Terminology 155 This document reuses terminology from [RFC5213], [RFC5568] and 156 [RFC3775]. The following terms and abbreviations are additionally 157 used in this document. 159 Access Network (AN): 160 A network composed of link-layer access devices such as access 161 points or base stations providing access to an Access Router 162 (AR) connected to it. 164 Previous Access Network (P-AN): 165 The access network to which the Mobile Node (MN) is attached 166 before handover. 168 New Access Network (N-AN): 169 The access network to which the Mobile Node (MN) is attached 170 after handover. 172 Previous Mobile Access Gateway (PMAG): 173 The MAG that manages mobility related signaling for the MN 174 before handover. In this document, the MAG and the Access 175 Router are co-located. 177 New Mobile Access Gateway (NMAG): 178 The MAG that manages mobility related signaling for the MN after 179 handover. In this document, the MAG and the Access Router (AR) 180 are co-located. 182 Local Mobility Anchor (LMA) 183 The topological anchor point for the mobile node's home network 184 prefix(es) and the entity that manages the mobile node's binding 185 state. This specification does not alter any capability or 186 functionality defined in [RFC5213]. 188 HO-Initiate: 189 A generic signaling message, sent from the P-AN to the PMAG that 190 indicates a MN handover. While this signaling is dependent on 191 the access technology, it is assumed that HO-Initiate can carry 192 the information to identify the MN and to assist the PMAG 193 resolve the NMAG and the new access point or the base station to 194 which the MN is moving to. The details of this message are 195 outside the scope of this document. 197 4. Proxy-based FMIPv6 Protocol Overview 199 This specification describes fast handover protocols for the network- 200 based mobility management protocol called Proxy Mobile IP (PMIPv6) 201 [RFC5213]. The core functional entities defined in PMIPv6 are the 202 LMA and the MAG. The LMA is the topological anchor point for the 203 MN's home network prefix(es). The MAG acts as an access router (AR) 204 for the MN and performs the mobility management procedures on its 205 behalf. The MAG is responsible for detecting the MN's movements to 206 and from the access link and for initiating binding registrations to 207 the MN's LMA. If the MAGs can be informed of the detachment and/or 208 attachment of the MN in a timely manner via e.g., the lower layer 209 signaling, it will become possible to optimize the handover 210 procedure, which involves establishing a connection on the new link 211 and signaling between mobility agents, compared to the baseline 212 specification of PMIPv6. 214 In order to further improve the performance during the handover, the 215 PFMIPv6 protocol in this document specifies a bi-directional tunnel 216 between the Previous MAG (PMAG) and the New MAG (NMAG) to tunnel 217 packets meant for the mobile node. In order to enable the NMAG to 218 send the Proxy Binding Update (PBU), the Handover Initiate (HI) and 219 Handover Acknowledge (HAck) messages in [RFC5568] are extended for 220 context transfer, in which parameters such as MN's Network Access 221 Identifier (NAI), Home Network Prefix (HNP), IPv4 Home Address, are 222 transferred from the PMAG. New flags 'P' and 'F' are defined for the 223 HI and HAck messages to distinguish from those in [RFC5568] and to 224 request packet forwarding, respectively. 226 In this document, the Previous Access Router (PAR) and New Access 227 Router (NAR) are interchangeable with the PMAG and NMAG, 228 respectively. The reference network is illustrated in Figure 1. The 229 access networks in the figure (i.e., P-AN and N-AN) are composed of 230 Access Points (APs) defined in [RFC5568], which are often referred to 231 as base stations in cellular networks. 233 Since a MN is not directly involved with IP mobility protocol 234 operations, it follows that the MN is not directly involved with fast 235 handover procedures either. Hence, the messages involving the MN in 236 [RFC5568] are not used when PMIPv6 is in use. More specifically, the 237 Router Solicitation for Proxy Advertisement (RtSolPr), the Proxy 238 Router Advertisement (PrRtAdv), Fast Binding Update (FBU), Fast 239 Binding Acknowledgment (FBack) and the Unsolicited Neighbor 240 Advertisement (UNA) messages are not applicable in the PMIPv6 241 context. 243 +----------+ 244 | LMA | 245 | | 246 +----------+ 247 / \ 248 / \ 249 / \ 250 +........../..+ +..\..........+ 251 . +-------+-+ .______. +-+-------+ . 252 . | PMAG |()_______)| NMAG | . 253 . | (PAR) | . . | (NAR) | . 254 . +----+----+ . . +----+----+ . 255 . | . . | . 256 . ___|___ . . ___|___ . 257 . / \ . . / \ . 258 . ( P-AN ) . . ( N-AN ) . 259 . \_______/ . . \_______/ . 260 . | . . | . 261 . +----+ . . +----+ . 262 . | MN | ----------> | MN | . 263 . +----+ . . +----+ . 264 +.............+ +.............+ 266 Figure 1: Reference network for fast handover 268 4.1. Protocol Operation 270 There are two modes of operation in FMIPv6 [RFC5568]. In the 271 predictive mode of fast handover, a bi-directional tunnel between the 272 PMAG (PAR) and NMAG (NAR) is established prior to the MN's attachment 273 to the NMAG. In the reactive mode, this tunnel establishment takes 274 place after the MN attaches to the NMAG. In order to alleviate the 275 packet loss during a MN's handover (especially when the MN is 276 detached from both links), the downlink packets for the MN need to be 277 buffered either at the PMAG or NMAG, depending on when the packet 278 forwarding is performed. It is hence required that all MAGs have the 279 capability and enough resources to buffer packets for the MNs 280 accommodated by them. The buffer size to be prepared and the rate at 281 which buffered packets are drained are addressed in Section 5.4 of 282 [RFC5568]. Note that the protocol operation specified in the 283 document is transparent to the LMA, hence there is no new functional 284 requirement or change on the LMA. 286 Unlike MIPv6, the MN in the PMIPv6 domain is not involved with IP 287 mobility signaling; therefore, in order for the predictive fast 288 handover to work effectively, it is required that the MN is capable 289 of reporting lower-layer information to the AN at a short enough 290 interval, and the AN is capable of sending the HO-initiate to the 291 PMAG at an appropriate timing. The sequence of events for the 292 predictive fast handover are illustrated in Figure 2. 294 PMAG NMAG 295 MN P-AN N-AN (PAR) (NAR) LMA 296 | | | | | | 297 | Report | | | | | 298 (a) |-(MN ID,-->| | | | | 299 | New AP ID)| | | | | 300 | | HO Initiate | | | 301 (b) | |--(MN ID, New AP ID)-->| | | 302 | | | | | | 303 | | | | | | 304 (c) | | | |----HI---->| | 305 | | | | | | 306 | | | | | | 307 (d) | | | |<---HAck---| | 308 | | | | | | 309 | | | | | | 310 | | | |HI/HAck(optional) | 311 (e) | | | |<- - - - ->| | 312 | | | #=|<===================| 313 (f) | | | #====DL data=>| | 314 | | | | | | 315 (g) ~~~ | | | | | 316 ~~~ | | | | | 317 | MN-AN connection | AN-MAG connection | | 318 (h) |<---establishment---->|<----establishment----->| | 319 | | | (substitute for UNA) | | 320 | | | | | | 321 (i) |<==================DL data=====================| | 322 | | | | | | 323 (j) |===================UL data====================>|=# | 324 | | | #=|<============# | 325 | | | #=====================>| 326 / | | | | | | \ 327 |(k) | | | | |--PBU-->| | 328 | | | | | | | | 329 |(l) | | | | |<--PBA--| | 330 | |<==================DL data=====================|<=======| | 331 | | | | | | | | 332 \ |===================UL data====================>|=======>| / 334 Figure 2: Predictive fast handover for PMIPv6 (PAR initiated) 336 The detailed descriptions are as follows: 338 (a) The MN detects that a handover is imminent and reports the 339 identifications of itself (MN ID) and the New Access Point 340 Identifier (New AP ID) [RFC5568] to which the MN is most likely 341 to move. The MN ID could be the NAI or a Link Layer Address 342 (LLA), or any other suitable identifier. This step is access 343 technology specific. In some cases, the P-AN will determine 344 which AP ID the MN is moving to. 346 (b) The previous access network (P-AN), to which the MN is currently 347 attached, indicates the handover of the MN to the PMAG (PMAG). 348 Detailed definition and specification of this message are 349 outside the scope of this document. 351 (c) The PMAG sends the HI to the NMAG. The HI message MUST have the 352 P flag set and include the MN ID, the HNP(s) and the address of 353 the LMA that is currently serving the MN. If there is a valid 354 (non-zero) MN Link-layer Identifier (MN LL-ID), that information 355 MUST also be included. With some link layers, the MN Link-local 356 Address IID (MN LLA-IID) can also be included (see 357 Section 6.2.3). 359 (d) The NMAG sends the HAck back to the PMAG with the P flag set. 361 (e) If it is preferred that the timing of buffering or forwarding 362 should be later than step (c), the NMAG may optionally request 363 the PMAG at a later and appropriate time to buffer or forward 364 packets by setting U flag [RFC5568] or F flag in the HI message, 365 respectively. 367 (f) If the F flag is set in the previous step, a bi-directional 368 tunnel is established between the PMAG and NMAG and packets 369 destined for the MN are forwarded from the PMAG to the NMAG over 370 this tunnel. After decapsulation, those packets may be buffered 371 at the NMAG. If the connection between the N-AN and NMAG has 372 already been established, those packets may be forwarded towards 373 the N-AN, which then becomes responsible for them (e.g., 374 buffering or delivering depending on the condition of the MN's 375 attachment); this is access technology specific. 377 (g) The MN undergoes handover to the New Access Network (N-AN). 379 (h) The MN establishes a physical link connection with the N-AN 380 (e.g., radio channel assignment), which in turn triggers the 381 establishment of a link-layer connection between the N-AN and 382 NMAG if not yet established. An IP layer connection setup may 383 be performed at this time (e.g., PPP IPv6CP) or at a later time 384 (e.g., stateful or stateless auto address configuration). This 385 step can be a substitute for the UNA in [RFC5568]. If the NMAG 386 acquires a valid new MN LL-ID via the N-AN and a valid old MN 387 LL-ID from the PMAG at step (c), these IDs SHOULD be compared to 388 determine whether the same interface is used before and after 389 handover. When the connection between the MN and NMAG is PPP 390 and the same interface is used for the handover, the NMAG SHOULD 391 confirm that the same interface identifier is used for the MN's 392 link-local address (this is transferred from PMAG using the MN 393 LLA-IID option at step (c), and sent to the MN during the 394 Configure-Request/Ack exchange). 396 (i) The NMAG starts to forward packets destined for the MN via the 397 N-AN. 399 (j) The uplink packets from the MN are sent to the NMAG via the N-AN 400 and the NMAG forwards them to the PMAG. The PMAG then sends the 401 packets to the LMA that is currently serving the MN. 403 (k) The NMAG (NAR) sends the Proxy Binding Update (PBU) to the LMA, 404 whose address is provided in (c). Steps (k) and (l) are not 405 part of the fast handover procedure, but shown for reference. 407 (l) The LMA sends back the Proxy Binding Acknowledgment (PBA) to the 408 NMAG (NMAG). From this time on, the packets to/from the MN go 409 through the NMAG instead of the PMAG. 411 According to Section 4 of [RFC5568], the PMAG establishes a binding 412 between the Previous Care-of Address (PCoA) and New Care-of Address 413 (NCoA) to forward packets for the MN to the NAR, and the NMAG creates 414 a proxy neighbor cache entry to receive those packets for the NCoA 415 before the MN arrives. In the case of PMIPv6, however, the only 416 address that is used by the MN is MN-HoA (Mobile Node's Home 417 Address), so the PMAG forwards MN's packets to the NMAG instead of 418 the NCoA. The NMAG then simply decapsulates those packets and 419 delivers them to the MN. FMIPv4 [RFC4988] specifies forwarding when 420 the MN uses the home address as its on-link address rather than the 421 care-of address. The usage in PMIPv6 is similar to that in FMIPv4, 422 where the address(es) used by the MN is/are based on its HNP(s). 423 Since the NMAG can obtain the Link-layer address (MN LL-ID) and 424 HNP(s) via the HI message (also the interface identifier of the MN's 425 link-local address (MN LLA-ID) if available), it can create a 426 neighbor cache entry for the Link-local Address and the routes for 427 the whole HNP(s) even before the MN performs Neighbor Discovery. For 428 the uplink packets from the MN after handover in (j), the NMAG 429 forwards the packets to the PMAG through the tunnel established in 430 step (f). The PMAG then decapsulates and sends them to the LMA. 432 The timing of the context transfer and that of packet forwarding may 433 be different. Thus, a new flag 'F' and Option Code values for it in 434 the HI and HAck messages are defined to request forwarding. To 435 request buffering, 'U' flag has already been defined in [RFC5568]. 436 If the PMAG receives the HI message with the F flag set, it starts 437 forwarding packets for the MN. The HI message with the U flag set 438 may be sent earlier if the timing of buffering is different from that 439 of forwarding. If packet forwarding is completed, the PMAG MAY send 440 the HI message with the F flag set and the Option Code value being 2. 441 By this message, the ARs on both ends can tear down the forwarding 442 tunnel synchronously. 444 The IP addresses in the headers of those user packets are summarized 445 below: 447 In Step (f), 449 Inner source address: IP address of the CN 451 Inner destination address: HNP or Mobile Node's IPv4 Home 452 Address (IPv4-MN-HoA) 454 Outer source address: IP address of the PMAG (PAR) 456 Outer destination address: IP address of the NMAG (NAR) 458 In Step (i), 460 Source address: IP address of the CN 462 Destination address: HNP or IPv4-MN-HoA 464 In Step (j), 466 - from the MN to the NMAG, 468 Source address: HNP or IPv4-MN-HoA 470 Destination address: IP address of the CN 472 - from the NMAG to the PMAG, 474 Inner source address: HNP or IPv4-MN-HoA 476 Inner destination address: IP address of the CN 478 Outer source address: IP address of the NMAG (NAR) 479 Outer destination address: IP address of the PMAG (PAR) 481 - from the PMAG to the LMA, 483 Inner source address: HNP or IPv4-MN-HoA 485 Inner destination address: IP address of the CN 487 Outer source address: IP address of the PMAG (PAR) 489 Outer destination address: IP address of the LMA 491 In the case of the reactive handover for PMIPv6, since the MN does 492 not send either the FBU or UNA, it would be more natural that the 493 NMAG sends the HI to the PMAG after the MN has moved to the new link. 494 The NMAG then needs to obtain the information of the PMAG beforehand. 495 Such information could be provided, for example, by the MN sending 496 the AP-ID on the old link and/or by the lower-layer procedures 497 between the P-AN and N-AN. The exact method is not specified in this 498 document. Figure 3 illustrates the reactive fast handover procedures 499 for PMIPv6, where the bi-directional tunnel establishment is 500 initiated by the NMAG. 502 PMAG NMAG 503 MN P-AN N-AN (PAR) (NAR) LMA 504 | | | | | | 505 (a) ~~~ | | | | | 506 ~~~ | | | | | 507 | MN-AN connection | AN-MAG connection | | 508 (b) |<--establishment-->|<-------establishment------>| | 509 |(MN ID, Old AP ID) | (MN ID, Old AP ID) | | 510 | | |(substitute for UNA and FBU)| | 511 | | | | | | 512 | | | | | | 513 (c) | | | |<-----HI-------| | 514 | | | | | | 515 | | | | | | 516 (d) | | | |-----HAck----->| | 517 | | | | | | 518 | | | | | | 519 (e) | | | #=|<=======================| 520 | | | #================>|=# | 521 |<====================DL data======================# | 522 | | | | | | 523 (f) |=====================UL data===================>|=# | 524 | | | #=|<================# | 525 | | | #=========================>| 526 | | | | | | 527 / | | | | | | \ 528 |(g) | | | | |--PBU-->| | 529 | | | | | | | | 530 |(h) | | | | |<--PBA--| | 531 | |<====================DL data====================|<=======| | 532 | | | | | | | | 533 \ |=====================UL data===================>|=======>| / 535 Figure 3: Reactive fast handover for PMIPv6 (NAR initiated) 537 The detailed descriptions are as follows: 539 (a) The MN undergoes handover from the P-AN to the N-AN. The AP-ID 540 on the old link may be provided by the MN to help identify the 541 PMAG on the new link. 543 (b) The MN establishes a connection (e.g., radio channel) with the 544 N-AN, which triggers the establishment of the connection between 545 the N-AN and NMAG. The MN ID is transferred to the NMAG for the 546 subsequent procedures. The AP-ID on the old link may also be 547 provided by the MN to help identify the PMAG on the new link. 548 This can be regarded as a substitute for the UNA and FBU. 550 (c) The NMAG sends the HI to the PMAG. The HI message MUST have the 551 P flag set and include the MN ID. The Context Request Option 552 MAY be included to request additional context information on the 553 MN to the PMAG. 555 (d) The PMAG sends the HAck back to the NMAG with the P flag set. 556 The HAck message MUST include the HNP(s) and/or IPv4-MN-HoA that 557 is corresponding to the MN ID in the HI message and SHOULD 558 include the MN LL-ID, only if it is valid (non zero), and the 559 LMA address that is currently serving the MN. The context 560 information requested by the NMAG MUST be included. If the 561 requested context is not available for some reason, the PMAG 562 MUST return the HAck with the Code value 131. If the F flag is 563 set in the HI at step (c) and forwarding is nevertheless not 564 executable for some reason, the PMAG MUST return the HAck with 565 the Code value 132. 567 (e) If the F flag in the HI is set at step (c), a bi-directional 568 tunnel is established between the PMAG and NMAG and packets 569 destined for the MN are forwarded from the PMAG to the NMAG over 570 this tunnel. After decapsulation, those packets are delivered 571 to the MN via the N-AN. 573 (f) The uplink packets from the MN are sent to the NMAG via the N-AN 574 and the NMAG forwards them to the PMAG. The PMAG then sends the 575 packets to the LMA that is currently serving the MN. 577 Steps (g)-(h) are the same as (k)-(l) in the predictive fast handover 578 procedures. 580 In step (c), The IP address of the PMAG needs to be resolved by the 581 NMAG to send the HI to the PMAG. This information may come from the 582 N-AN or some database that the NMAG can access. 584 4.2. Inter-AR Tunneling Operation 586 When the PMAG (PAR) or NMAG (NAR), depending on the fast handover 587 mode, receives the HI message with the F flag set, it prepares to 588 send/receive the MN's packets to/from the other MAG and returns the 589 HAck message with the same sequence number. The both MAGs SHOULD 590 support the following encapsulation modes for the user packets, which 591 are also defined for the tunnel between the LMA and MAG: 593 o IPv4-or-IPv6-over-IPv6 [IPv4PMIPv6] 595 o IPv4-or-IPv6-over-IPv4 [IPv4PMIPv6] 596 o IPv4-or-IPv6-over-IPv4-UDP [IPv4PMIPv6] 598 o TLV-header UDP tunneling [GREKEY] 600 o GRE tunneling with or without GRE key(s) [GREKEY] 602 The PMAG and the NMAG MUST use the same tunneling mechanism for the 603 data traffic tunneled between them. The encapsulation mode to be 604 employed SHOULD be configurable. This specification recommends the 605 following: 607 1. As the default behavior, the inter-MAG tunnel uses the same 608 encapsulation mechanism as that for the PMIPv6 tunnel between the 609 LMA and the MAGs. The PMAG and NMAG automatically start using 610 the same encapsulation mechanism without a need for a special 611 configuration on the MAGs or a dynamic tunneling mechanism 612 negotiation between them. 614 2. Configuration on the MAGs can override the default mechanism 615 specified in #1 above. The PMAG and NMAG MUST be configured with 616 the same mechanism and this configuration is most likely to be 617 uniform throughout the PMIPv6 domain. If the packets on the 618 PMIPv6 tunnel cannot be uniquely mapped on to the configured 619 inter-MAG tunnel, this scenario is not applicable and scenario #3 620 below SHOULD directly be applied. 622 3. An implicit or explicit tunnel negotiation mechanism between the 623 MAGs can override the default mechanism specified in #1 above. 624 The employed tunnel negotiation mechanism is outside the scope of 625 this document. 627 The necessary information MUST be transferred in the HI/HAck messages 628 to distinguish MN's packets for forwarding in advance or at this 629 time. Such information includes the HNP(s) (or IPv4-MN-HoA) and/or 630 GRE key(s). In the case of GRE tunneling with GRE keys being used, 631 for each mobility session, the NMAG selects the GRE key for the 632 downlink packets and the PMAG selects the GRE key for the uplink 633 packets. These GRE keys are exchanged between the PMAG and the NMAG 634 using the GRE Key option as described in [GREKEY], e.g., In the case 635 of the reactive mode as shown in Figure 3, the DL GRE key is 636 communicated in the HI message while the UL GRE key is sent in the 637 HAck message. For the downlink packets, the PMAG redirects MN's 638 packets from the LMA towards the NMAG and if the MN is ready to 639 receive those packets or the N-AN can handle them regardless of the 640 state of the MN, the NMAG should immediately send them towards the 641 N-AN; otherwise it should buffer them until the MN is ready. For the 642 uplink packets, the NMAG SHOULD reverse-tunnel them from the MN 643 towards the PMAG and the PMAG sends them to the LMA. 645 When the PMAG or NMAG receives the HI message with the U flag set, it 646 prepares to buffer the MN's packets and returns the HAck message with 647 the same sequence number. It MUST be followed by another HI message 648 with the F flag set at an appropriate time to forward the buffered 649 packets. 651 If the MAG that received the HI message encounters an erroneous 652 situation (e.g., insufficient buffer space), it SHOULD immediately 653 send the HAck message with the cause of the error and cancel all 654 tunneling operation. 656 4.3. IPv4 Support Considerations 658 The motivation and usage scenarios of IPv4 protocol support by PMIPv6 659 are described in [IPv4PMIPv6]. The scope of IPv4 support covers the 660 following two features: 662 o IPv4 Home Address Mobility Support, and 664 o IPv4 Transport Support. 666 As for IPv4 Home Address Mobility Support, the MN acquires IPv4 Home 667 Address (IPv4-MN-HoA) and in the case of handover, the PMAG needs to 668 transfer IPv4-MN-HoA to the NMAG, which is the inner destination 669 address of the packets forwarded on the downlink. For this purpose, 670 IPv4 Address Option described in Section 6.2.7 is used. In order to 671 provide IPv4 Transport Support, the NMAG needs to know the IPv4 672 address of the LMA (IPv4-LMAA) to send PMIPv6 signaling messages to 673 the LMA in the IPv4 transport network. For this purpose, a new 674 option called LMA Address (LMAA) Option is defined in Section 6.2.2 675 so as to convey IPv4-LMAA from the PMAG to NMAG. 677 5. PMIPv6-related Fast Handover Issues 679 5.1. Manageability Considerations 681 This specification does not require any additional IP-level 682 functionality on the LMA and the MN running in the PMIPv6 domain. A 683 typical network interface that the MN could be assumed to have is one 684 with the cellular network, where the network controls the movement of 685 the MN. Different types of interfaces could be involved such as 686 different generations (3G and 3.9G) or different radio access 687 systems. This specification supports a MN with the single radio 688 mode, where only one interface is active at any given time. The 689 assigned IP address is preserved whether the physical interface 690 changes or not and the MN can identify which interface should be used 691 if there are multiple ones. 693 5.2. Expedited Packet Transmission 695 The protocol specified in this document enables the NMAG to obtain 696 parameters which would otherwise be available only by communicating 697 with the LMA. For instance, the HNP(s) and/or IPv4-MN-HoA of a MN 698 are made available to the NMAG through context transfer. This allows 699 the NMAG to perform some procedures that may be beneficial. The 700 NMAG, for example, could send a Router Advertisement (RA) with the 701 HNP option to the MN as soon as its link attachment is detected 702 (e.g., via receipt of a Router Solicitation message). Such an RA is 703 recommended, for example, in scenarios where the MN uses a new radio 704 interface while attaching to the NMAG; since the MN does not have 705 information regarding the new interface, it will not be able to 706 immediately send packets without first receiving an RA with HNP(s). 707 Especially, in the reactive fast handover, the NMAG gets to know the 708 HNP(s) assigned to the MN on the previous link at step (d) in 709 Figure 3. In order to reduce the communication disruption time, the 710 NMAG SHOULD expect the MN to keep using the same HNP and to send 711 uplink packets before that step upon the MN's request. However, if 712 the HAck from the PMAG returns a different HNP or the subsequent 713 PMIPv6 binding registration for the HNP fails for some reason, then 714 the NMAG MUST withdraw the advertised HNP by sending another RA with 715 zero prefix lifetime for the HNP in question. This operation is the 716 same as described in Section 6.12 of [RFC5213]. 718 The protocol specified in this document is applicable regardless of 719 whether link-layer addresses are used between a MN and its access 720 router. A MN should be able to continue sending packets on the 721 uplink even when it changes link. When link-layer addresses are 722 used, the MN performs Neighbor Unreachability Detection (NUD) 723 [RFC4861], after attaching to a new link, probing the reachability of 724 its default router. The new router should respond to the NUD probe, 725 providing its link-layer address in the solicited Neighbor 726 Advertisement, which is common in the PMIPv6 domain. Implementations 727 should allow the MN to continue to send uplink packets while it is 728 performing NUD. 730 6. Message Formats 732 This document defines new Mobility Header messages for the extended 733 HI and Hack and new mobility options for conveying context 734 information. 736 6.1. Mobility Header 738 6.1.1. Handover Initiate (HI) 740 This section defines extensions to the HI message in [RFC5568]. The 741 format of the Message Data field in the Mobility Header is as 742 follows: 744 0 1 2 3 745 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 746 +-------------------------------+ 747 | Sequence # | 748 +-+-+-+-+-------+---------------+-------------------------------+ 749 |S|U|P|F|Resv'd | Code | | 750 +-+-+-+-+-------+---------------+ | 751 | | 752 . . 753 . Mobility options . 754 . . 755 | | 756 +---------------------------------------------------------------+ 757 (Note:P=1) 759 IP Fields: 761 Source Address 763 The IP address of PMAG or NMAG 765 Destination Address 767 The IP address of the peer MAG 769 Message Data: 771 Sequence # Same as [RFC5568]. 773 S flag Defined in [RFC5568] and MUST be set to zero in this 774 specification. 776 U flag Buffer flag. Same as [RFC5568]. 778 P flag Proxy flag. Used to distinguish the message from that 779 defined in [RFC5568] and MUST be set in all new message 780 formats defined in this document when using this protocol 781 extension. 783 F flag Forwarding flag. Used to request to forward the packets 784 for the MN. 786 Reserved Same as [RFC5568]. 788 Code [RFC5568] defines this field and its values 0 and 1. In 789 this specification, with the P flag set, this field can 790 be set to zero by default or the following values: 792 2: Indicate the completion of forwarding 794 3: All available context transferred 796 Code value 3 is set when the transfer of all necessary 797 context information is completed with this message. This 798 Code value is used in both cases where the context 799 information is fragmented into several pieces and the 800 last fragment is contained in this message and where the 801 whole information is transferred in one piece. 803 Mobility options: 805 This field contains one or more mobility options, whose encoding and 806 formats are defined in [RFC3775]. 808 Requested option 809 In order to uniquely identify the target MN, the MN 810 Identifier MUST be contained in the Mobile Node Identifier 811 Option. 813 The transferred context MUST be for one MN per message. In addition, 814 the NMAG can request necessary mobility options by the Context 815 Request Option defined in this document. 817 Context Request Option 819 This option MAY be present to request context information 820 typically by the NMAG to the PMAG in the NAR-initiated fast 821 handover. 823 6.1.2. Handover Acknowledge (HAck) 825 This section defines extensions to the HAck message in[RFC5568]. The 826 format of the Message Data field in the Mobility Header is as 827 follows: 829 0 1 2 3 830 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 831 +-------------------------------+ 832 | Sequence # | 833 +-+-+-+---------+---------------+-------------------------------+ 834 |U|P|F|Reserved | Code | | 835 +-+-+-+---------+---------------+ | 836 | | 837 . . 838 . Mobility options . 839 . . 840 | | 841 +---------------------------------------------------------------+ 842 (Note:P=1) 844 IP Fields: 846 Source Address 848 Copied from the destination address of the 849 Handover Initiate message to which this message 850 is a response. 852 Destination Address 854 Copied from the source address of the Handover 855 Initiate message to which this message is a 856 response. 858 Message Data: 860 The usages of Sequence # and Reserved fields are exactly the same as 861 those in [RFC5568]. 863 U flag Same as defined in Section 6.1.1. 865 P flag Used to distinguish the message from that defined in 866 [RFC5568] and MUST be set in all new message formats 867 defined in this document when using this protocol 868 extension. 870 F flag Same as defined in Section 6.1.1. 872 Code 873 Code values 0 through 4 and 128 through 130 are defined 874 in [RFC5568]. In this specification, the meaning of Code 875 value 0 is modified, 128 through 130 are reused, and 5, 876 6, 131 and 132 are newly defined. 878 0: Handover Accepted or Successful 880 5: Context Transfer Accepted or Successful 882 6: All available Context Transferred 884 128: Handover Not Accepted, reason unspecified 886 129: Administratively prohibited 888 130: Insufficient resources 890 131: Requested Context Not Available 892 132: Forwarding Not Available 894 Mobility options: 896 This field contains one or more mobility options, whose encoding and 897 formats are defined in [RFC3775]. The mobility option that uniquely 898 identifies the target MN MUST be copied from the corresponding HI 899 message and the transferred context MUST be for one MN per message. 901 Requested option(s) All the context information requested by the 902 Context Request Option in the HI message SHOULD be present 903 in the HAck message. The other cases are described below. 905 In the case of the PAR-initiated fast handover, when the PMAG sends 906 the HI message to the NMAG with the context information and the NMAG 907 successfully receives it, the NMAG returns the HAck message with Code 908 value 5. In the case of the NAR-initiated fast handover, when the 909 NMAG sends the HI message to the PMAG with or without Context Request 910 Option, the PMAG returns the HAck message with the requested or 911 default context information (if any). If all available context 912 information is transferred, the PMAG sets the Code value in the HAck 913 message to 6. If more context information is available, the PMAG 914 sets the Code value in the HAck to 5 and the NMAG MAY send new HI 915 message(s) to retrieve the rest of the available context information. 916 If none of the requested context information is available, the PMAG 917 returns the HAck message with Code value 131 without any context 918 information. 920 6.2. Mobility Options 922 6.2.1. Context Request Option 924 This option is sent in the HI message to request context information 925 on the MN. If a default set of context information is defined and 926 always sufficient, this option is not used. This option is more 927 useful to retrieve additional or dynamically selected context 928 information. 930 Context Request Option is typically used for the reactive (NAR- 931 initiated) fast handover mode to retrieve the context information 932 from the PMAG. When this option is included in the HI message, all 933 the requested context information SHOULD be included in the HAck 934 message in the corresponding mobility option(s) (e.g., HNP, LMAA or 935 MN LL-ID mobility options). 937 The default context information to request is the Home Network Prefix 938 Option. If the Mobile Node link-layer is available and used, the 939 Mobile Node Link-layer Identifier Option MUST also be requested. 941 0 1 2 3 942 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 943 +---------------+---------------+---------------+---------------+ 944 | Option-Type | Option-Length | Reserved | 945 +---------------+---------------+-------------------------------+ 946 | Req-type-1 | Req-length-1 | Req-type-2 | Req-length-2 | 947 +---------------------------------------------------------------+ 948 | Req-type-3 | Req-length-3 | Req-option-3 | 949 +---------------------------------------------------------------+ 950 | ... | 952 Option-Type TBD1 954 Option-Length The length in octets of this option, not including the 955 Option Type and Option Length fields. 957 Reserved This field is unused. It MUST be initialized to zero 958 by the sender and MUST be ignored by the receiver. 960 Req-type-n The type value for the n'th requested option. 962 Req-length-n The length of the n'th requested option excluding the 963 Req-type-n and Req-length-n fields. 965 Req-option-n The optional data to uniquely identify the requested 966 context for the n'th requested option. 968 In the case where there are only Req-type-n and Req-length-n fields, 969 the value of the Req-length-n is set to zero. If additional 970 information besides the Req-type-n is necessary to uniquely specify 971 the requested context, such information follows after the 972 Req-length-n. For example, when the requested contexts start with 973 the HNP Option (type=22), the MN Link-layer ID Option (type=25) and 974 the Vendor-Specific Option (type=19), the requested option format 975 looks as follows: 977 | ... | 978 +---------------+---------------+---------------+---------------+ 979 |Option-Type=CRO| Option-Length | Reserved | 980 +---------------+---------------+---------------+---------------+ 981 | Req-type-N=22 | Req-length-N=0| Req-type-N=25 | Req-length-N=0| 982 +---------------+---------------+-------------------------------+ 983 | Req-type-N=19 | Req-length-N=5| Vendor-ID | 984 +-------------------------------+---------------+---------------+ 985 | Vendor-ID | Sub-Type | | 986 +-----------------------------------------------+ | 987 | ... | 989 The first two options can uniquely identify the requested contexts 990 (i.e., the HNP and MN Link-layer ID) by the Req-type, so the Req- 991 length is set to zero; however, the subsequent Vendor-Specific Option 992 further needs the Vendor-ID and Sub-type to identify the requested 993 context, so these parameters follow and the Req-length is set to 5. 994 Note that the exact values in the Vendor-ID ans Sub-Type follow 995 [RFC5094]. 997 6.2.2. Local Mobility Anchor Address (LMAA) Option 999 This option is used to transfer the Local Mobility Anchor IPv6 1000 Address (LMAA) or its IPv4 Address (IPv4-LMAA), with which the MN is 1001 currently registered. The detailed definition of the LMAA is 1002 described in [RFC5213]. 1004 0 1 2 3 1005 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 1006 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1007 | Option-Type | Option-Length | Option-Code | Reserved | 1008 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1009 | Local Mobility Anchor Address ... | 1011 Option-Type TBD2 1013 Option-Length 18 or 6 1015 Option-Code 1017 0 Reserved 1019 1 IPv6 address of the LMA (LMAA) 1021 2 IPv4 address of the LMA (IPv4-LMAA) 1023 Reserved This field is unused. It MUST be initialized to zero 1024 by the sender and MUST be ignored by the receiver. 1026 Local Mobility Anchor Address 1027 If Option-Code is 1, the LMA IPv6 address (LMAA) is 1028 inserted. If Option-Code is 2, the LMA IPv4 address 1029 (IPv4-LMA) is inserted. 1031 6.2.3. Mobile Node Link-local Address Interface Identifier (MN LLA-IID) 1032 Option 1034 This option is used to transfer the interface identifier of the MN's 1035 IPv6 Link-local Address that is used in the P-AN. In deployments 1036 where the interface identifier is assigned by the network, or it is 1037 known to the network, this option is used to transfer this identifier 1038 from the PMAG to NMAG. 1040 0 1 2 3 1041 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 1042 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1043 | Option-Type | Option-Length | Reserved | 1044 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1045 | | 1046 + Interface Identifier + 1047 | | 1048 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1050 Option-Type TBD3 1052 Option-Length 10 1054 Reserved This field is unused. It MUST be initialized to zero 1055 by the sender and MUST be ignored by the receiver. 1057 Interface Identifier 1058 The Interface Identifier value used for the MN's IPv6 1059 Link-local address in the P-AN. 1061 6.2.4. Home Network Prefix Option 1063 This option is used to transfer the home network prefix that is 1064 assigned to the MN in the P-AN. The Home Network Prefix Option 1065 defined in [RFC5213] is used for this. 1067 6.2.5. Link-local Address Option 1069 This option is used to transfer the link-local address of the PMAG 1070 (PMAG). The Link-local Address Option defined in [RFC5213] is used 1071 for this. 1073 6.2.6. GRE Key Option 1075 This option is used to transfer the GRE Key for the MN's data flow 1076 over the bi-directional tunnel between the PMAG and NMAG. The 1077 message format of this option follows the GRE Key Option defined in 1078 [GREKEY]. The GRE Key value uniquely identifies each flow and the 1079 sender of this option expects to receive packets of the flow from the 1080 peer AR with this value. 1082 6.2.7. IPv4 Address Option 1084 As described in Section 4.3, if the MN runs in IPv4-only mode or 1085 dual-stack mode, it requires IPv4 home address (IPv4-MN-HoA). This 1086 option is used to transfer the IPv4 home address if assigned on the 1087 previous link. The format of this option follows the IPv4 Home 1088 Address Request Option defined in [IPv4PMIPv6]. 1090 6.2.8. Vendor-Specific Mobility Option 1092 This option is used to transfer any other information defined in this 1093 document. The format and used values of this option follow the 1094 Vendor-Specific Mobility Option defined in [RFC5094]. 1096 7. Security Considerations 1098 Security issues for this document follow those for PMIPv6 [RFC5213] 1099 and FMIPv6 [RFC5568]. In PMIPv6, the MAG and LMA are assumed to 1100 share security associations. In FMIPv6, the access routers (i.e., 1101 the PMAG and NMAG in this document) are assumed to share security 1102 associations. 1104 The Handover Initiate (HI) and Handover Acknowledge (HAck) messages 1105 exchanged between the PMAG and NMAG MUST be protected using end-to- 1106 end security association(s) offering integrity and data origin 1107 authentication. The PMAG and the NMAG MUST implement IPsec [RFC4301] 1108 for protecting the HI and HAck messages. IPsec Encapsulating 1109 Security Payload (ESP) [RFC4303] in transport mode with mandatory 1110 integrity protection SHOULD be used for protecting the signaling 1111 messages. Confidentiality protection SHOULD be used if sensitive 1112 context related to the mobile node is transferred. 1114 IPsec ESP [RFC4303] in tunnel mode SHOULD be used to protect the MN's 1115 packets at the time of forwarding if the link between the PMAG and 1116 NMAG exposes the MN's packets to more threats than if they had 1117 followed their normal routed path. 1119 8. IANA Considerations 1121 This document defines new flags and status codes in the HI and HAck 1122 messages as well as three new mobility options. The Type values for 1123 these mobility options are assigned from the same numbering space as 1124 allocated for the other mobility options defined in [RFC3775]. 1126 Mobility Options 1127 Value Description Reference 1128 ----- ------------------------------------- ------------- 1129 TBD1 Context Request Option Section 6.2.1 1130 TBD2 Local Mobility Anchor Address Option Section 6.2.2 1131 TBD3 Mobile Node Link-local Address 1132 Interface Identifier Option Section 6.2.3 1134 Handover Initiate Flags 1135 Flag Value Description Reference 1136 ---- ----- ------------------------------- ------------- 1137 P 0x20 Proxy flag Section 6.1.1 1138 F 0x10 Forwarding flag Section 6.1.1 1140 Handover Acknowledge Flags 1141 Flag Value Description Reference 1142 ---- ----- ------------------------------- ------------- 1143 P 0x40 Proxy flag Section 6.1.2 1144 F 0x20 Forwarding flag Section 6.1.2 1146 Handover Initiate Status Codes 1147 Code Description Reference 1148 ---- -------------------------------------- ------------- 1149 2 Indicate the completion of forwarding Section 6.1.1 1150 3 All available context transferred Section 6.1.1 1152 Handover Acknowledge Status Codes 1153 Code Description Reference 1154 ---- -------------------------------------- ------------- 1155 0 Handover Accepted or Successful Section 6.1.2 1156 5 Context Transfer Accepted or Successful Section 6.1.2 1157 6 All available Context Transferred Section 6.1.2 1158 131 Requested Context Not Available Section 6.1.2 1159 132 Forwarding Not Available Section 6.1.2 1161 9. Acknowledgments 1163 The authors would like to specially thank Vijay Devarapalli and Sri 1164 Gundavelli for their thorough reviews of this document. 1166 The authors would also like to thank Charlie Perkins, Desire Oulai, 1167 Ahmad Muhanna, Giaretta Gerardo, Domagoj Premec, Marco Liebsch, Fan 1168 Zhao, Julien Laganier and Pierrick Seite for their passionate 1169 discussions in the working group mailing list. 1171 10. References 1173 10.1. Normative References 1175 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 1176 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 1178 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1179 Requirement Levels", BCP 14, RFC 2119, March 1997. 1181 [RFC5568] Koodli, R., "Mobile IPv6 Fast Handovers", RFC 5568, 1182 July 2009. 1184 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 1185 in IPv6", RFC 3775, June 2004. 1187 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1188 Internet Protocol", RFC 4301, December 2005. 1190 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 1191 RFC 4303, December 2005. 1193 [RFC5094] Devarapalli, V., Patel, A., and K. Leung, "Mobile IPv6 1194 Vendor Specific Option", RFC 5094, December 2007. 1196 [IPv4PMIPv6] 1197 Wakikawa, R., Ed. and S. Gundavelli, "IPv4 Support for 1198 Proxy Mobile IPv6", 1199 draft-ietf-netlmm-pmip6-ipv4-support-17.txt, 1200 September 2009. 1202 [GREKEY] Muhanna, A., Ed., "GRE Key Option for Proxy Mobile IPv6", 1203 draft-ietf-netlmm-grekey-option-09.txt, May 2009. 1205 10.2. Informative References 1207 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 1208 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 1209 September 2007. 1211 [RFC4988] Koodli, R. and C. Perkins, "Mobile IPv4 Fast Handovers", 1212 RFC 4988, October 2007. 1214 Appendix A. Applicable Use Cases 1216 A.1. PMIPv6 Handoff Indication 1218 PMIPv6 [RFC5213] defines the Handoff Indicator Option and describes 1219 the type of the handoff and the values to set to the option. This 1220 document proposes one approach to determining the handoff type by the 1221 NMAG when the handoff of the MN is executed. 1223 According to [RFC5213], the following handoff types are defined: 1225 0) Reserved 1227 1) Attachment over a new interface 1229 2) Handoff between two different interfaces of the mobile node 1231 3) Handoff between mobile access gateways for the same interface 1233 4) Handoff state unknown 1235 5) Handoff state not changed (Re-registration) 1237 Assuming that there is a valid MN Link-layer Identifier (MN LL-ID), 1238 the following solution can be considered. When the NMAG receives the 1239 MN LL-ID from the PMAG in the MN LL-ID option via the HI or HAck 1240 message, the NMAG compares it with the new MN LL-ID that is obtained 1241 from the MN in the N-AN. If these two MN LL-IDs are the same, the 1242 handoff type falls into 3) and the Handoff Indicator value is set to 1243 3. If these two MN LL-IDs are different, the handoff is likely to be 1244 2) since the HI/HAck message exchange implies that this is a handoff 1245 not a multi-homing, therefore the Handoff Indicator value can be set 1246 to 2. If there is no HI/HAck exchange performed prior to the network 1247 attachment of the MN in the N-AN, the NMAG may infer that this is a 1248 multi-homing case and set the Handoff Indicator value to 1. In the 1249 case of re-registration, the MAG, to which the MN is attached, can 1250 determine if the handoff state is not changed, so the MAG can set the 1251 HI value to 5 without any additional information. If none of them 1252 can be assumed or there is no valid MN LL-ID available, the NMAG may 1253 set the value to 4. 1255 A.2. Local Routing 1257 Section 6.10.3 in [RFC5213] describes that if EnableMAGLocalRouting 1258 flag is set, when two mobile nodes are attached to one MAG, the 1259 traffic between them may be locally routed. If one mobile node moves 1260 from this MAG (PMAG) to another MAG (NMAG) and if the PMAG does not 1261 detect the MN's detachment, it will continue to forward packets 1262 locally forever. This situation is more likely to happen in the 1263 reactive fast handover with WLAN access, which does not have the 1264 capability to detect the detachment of the MN in a timely manner. 1265 PFMIPv6 can be applied to handle this case. When the MN attaches to 1266 the NMAG, the NMAG sends the HI message to the PMAG with the 'F' flag 1267 set, which makes the PMAG realize the detachment of the MN and 1268 establish the inter-MAG tunnel. The PMAG immediately stops the local 1269 routing and sends the packets for the MN to the NMAG via that tunnel, 1270 which are then delivered to the MN on the new link. 1272 Appendix B. Change Log 1274 Changes at -00 1276 * Added separate sections for MH and ICMP. 1278 * Clarified usage of HNP and IPv4-MN-HoA throughout the document. 1280 * Added IANA Considerations. 1282 * Added section on Other Considerations, including operation of 1283 uplink packets when using link-layer addresses, multiple 1284 interface usage and transmission of RA to withdraw HNP in the 1285 event of failure of PMIP6 registration. 1287 * Revised Security Considerations. 1289 Changes from -00 to -01 1291 * Removed ICMPv6-based message format. 1293 * Clarified HI/HAck exchange in the predictive mode (step (e) in 1294 Figure 2). 1296 * Clarified information retrieval about the PMAG in the reactive 1297 mode. 1299 * Removed the extension to the GRE Key Option. 1301 * Clarified the handoff type considerations in Appendix A. 1303 * Home Network Prefix Option, Link-local Address Option and 1304 Vendor-Specific Mobility Option are added. 1306 Changes from -01 to -02 1308 * Aligned HI/HAck message formats with 1309 draft-ietf-mipshop-rfc5268bis-00.txt. 1311 * Revised Section 8 removing the request for the type assignment 1312 of HI/HAck Mobility Headers. 1314 Changes from -02 to -03 1316 * Updated HI/HAck message formats according to 1317 draft-ietf-mipshop-rfc5268bis-01.txt. 1319 * Cleaned up Figure 2 and Figure 3. 1321 * Moved PMIP domain boundary crossing situation in Section 4.1 to 1322 Appendix A.3. 1324 * Removed the alternative protocol operation with an unsolicited 1325 HAck from Section 4.1. 1327 * Modified Code values in the HAck message in order to avoid 1328 collision with those in draft-ietf-mipshop-rfc5268bis-01.txt. 1330 * Clarified the usage scenarios of Context Request Option. 1332 * Modified the description of Code values in the HAck message. 1334 * Changed the container for the IPv4-LMAA from IPv4 Address 1335 option to the LMAA option. 1337 * Made Confidentiality protection "SHOULD" for context transfer. 1339 Changes from -03 to -04 1341 * Added more explanations about MIPv6, FMIPv6 and PMIPv6 in 1342 Abstract. 1344 * Moved Figure 1 to Section 4. 1346 * More clearly indicated the FMIPv6 messages that are not 1347 applicable in the PMIPv6 context. 1349 * Mandated the support of IP Sec on the PMAG and NMAG in order to 1350 protect signaling and user packets and the context information. 1352 * Added a new section for the inter-AR tunneling operation 1353 (Section 4.2). 1355 * Added descriptions about the encapsulation type in Sections 4.1 1356 and 4.3. 1358 * Added a description about buffering requirements on the MAG in 1359 Section 4.1. 1361 * Added a description about the timing of L2 and L3 connection 1362 establishments in Section 4.1. 1364 * Added a new section for PMIPv6-related fast handover issues 1365 (Section 5) and a description about preferable behaviors of the 1366 MN and MAG to reduce packet loss. 1368 * Added Acknowledgments section (Section 9). 1370 * Added a new section for local routing in Appendix (A.2). 1372 Changes from -04 to -05 1374 * Fixed Figure 2 (step (i)). 1376 * Defined the Mobile Network Interface Identifier (MN-IID) 1377 mobility option in Section 6.2.4 (swapped with old Section 1378 6.2.5), and added it to IANA considerations (Section 8). 1380 * Changed from SHOULD to MUST regarding the inclusion of the 1381 MN-ID, MN-HNP, MN-IID and the LMAA options in the HI message 1382 (step (c) in Section 4.1). 1384 * The optional behavior of the NMAG that allows it to send uplink 1385 packets directly to the LMA before the PBU/PBA exchange was 1386 removed from section 4.2 (as out of scope). 1388 * In Section A.3, the description about the HA address assignment 1389 from the NAR to the MN was removed (as out of scope). 1391 Changes from -05 to -06 1393 * Added 'P' flag in the HI and Hack messages to distinguish them 1394 from those in FMIPv6. 1396 * Made editorial corrections in Section 2 (Introduction), Section 1397 3 (Terminology), Section 4 (Protocol Overview) and Section 4.2 1398 (Inter-AR Tunneling Operation). 1400 * Added a description on how forwarded packets should be handled 1401 in the access network at step (f) in Section 4.1. 1403 * Added all types of encapsulation methods that should be 1404 supported in Section 4.1. 1406 * Revised the Code values for the HI message in Section 6.1.1. 1408 * Revised the Code values for the HAck message in Section 6.1.2 1409 and added a description of its usage at step (d) of the 1410 reactive handover mode in Section 4.1. 1412 * Removed the definition of the IP Address Option in Section 1413 6.2.3 and moved to Section 6.2.7, which currently refers to the 1414 IPv4 Home Address Option defined by RFC5555. Revised the IANA 1415 Consideration section accordingly. 1417 * Removed the Option-Code from the Mobile Node Identifier (MN 1418 IID) Option. 1420 * Removed Appendix A.3 (Handling of PMIPv6/MIPv6 switching). 1422 Changes from -06 to -07 1424 * Added explanations about defining and setting the 'P' flag for 1425 the HI and Hack messages in Sections 4 and 4.1. 1427 * Corrected the references for the encapsulation types in Section 1428 4.1. 1430 * Modified the Code values for the HI message in Section 6.1.1 to 1431 avoid overlapping with those in 1432 draft-ietf-mipshop-rfc5268bis-01.txt. 1434 * Modified the reference for the IPv4 Address Option from RFC5555 1435 to [IPv4PMIPv6] in Section 6.2.7. 1437 Changes from -07 to -08 1439 * Corrected the reference for the TLV-header UDP encapsulation in 1440 Section 4.1. 1442 * Updated the version number of the reference document 1443 [IPv4PMIPv6] and the option name defined by that document in 1444 Section 6.2.7. 1446 Changes from -08 to -09 1448 * Added a paragraph at the beginning of Section 4 describing the 1449 assumption related to the lower layer signaling. 1451 * Added a new section on the manageability considerations in 1452 Section 5 describing the configurations on the network and the 1453 mobile node assumed in this document. 1455 * Modified the assumed configuration of the MAG regarding its 1456 link-layer address in Section 5 (Section 5.2 in version -09). 1458 * Specified the requested option to identify the target MN for 1459 the inter-AR tunneling in Section 6.1.1. 1461 * Specified the default context information in the Context 1462 Request Option in Section 6.2.1. 1464 Changes from -09 to -10 1466 * Revised the document based on the comments from TSV-DIR, SEC- 1467 DIR, OPS-DIR and GEN-ART. 1469 + Split the abstract section in half for readability. 1471 + Added the definition of Localized Mobility Anchor (LMA) in 1472 Section 3. 1474 + Added the purpose of this document at the beginning of 1475 Section 4 to make the paragraph more complete. 1477 + Revised the third paragraph of the Security Consideration 1478 section for more precise expression. 1480 + Moved the description about the requirement to set the 'P' 1481 flag in HI/HAck to Sections 6.1.1 and 6.1.2. Also, noted 1482 the 'P' flag setting below the message formats. 1484 + Described the both 'P' and 'F' flags as newly defined ones 1485 in Section 4. 1487 + Clarified the usage of the Context Request Option if a 1488 default set of context information is defined in Section 1489 6.2.1 (changed from "not mandatory" to "not used"). 1491 + Modified the identifier for the interface on the MN to the 1492 MN's link-layer ID (MN LL-ID). 1494 + Corrected the local routing operation of the PMAG in 1495 Appendix A.2. 1497 * Revised the descriptions about the encapsulation mechanism for 1498 the inter-MAG tunnel in Section 4.2 and other related parts for 1499 clarification. 1501 * Also listed the new flags and status codes for the HI/HAck 1502 messages in the IANA Considerations section. 1504 * Elaborated on the example use of the Context Request Option in 1505 Section 6.2.1. 1507 Changes from -10 to -11 1509 * Changed the term "MN Interface Identifier (MN-IID) option" to 1510 "MN Link-local Address Interface Identifier (MN LLA-IID) 1511 option" in Section 6.2.3. Its usage is valid only when the 1512 network assigns the interface identifier. 1514 * Revised the description of the neighbor cache entry in Section 1515 4.1 to include the MN LLA-IID. 1517 Authors' Addresses 1519 Hidetoshi Yokota 1520 KDDI Lab 1521 2-1-15 Ohara, Fujimino 1522 Saitama, 356-8502 1523 Japan 1525 Email: yokota@kddilabs.jp 1527 Kuntal Chowdhury 1528 Starent Networks 1529 30 International Place 1530 Tewksbury, MA 01876 1531 USA 1533 Email: kchowdhury@starentnetworks.com 1535 Rajeev Koodli 1536 Starent Networks 1537 30 International Place 1538 Tewksbury, MA 01876 1539 USA 1541 Email: rkoodli@starentnetworks.com 1543 Basavaraj Patil 1544 Nokia 1545 6000 Connection Drive 1546 Irving, TX 75039 1547 USA 1549 Email: basavaraj.patil@nokia.com 1551 Frank Xia 1552 Huawei USA 1553 1700 Alma Dr. Suite 500 1554 Plano, TX 75075 1555 USA 1557 Email: xiayangsong@huawei.com