idnits 2.17.1 draft-ietf-mipshop-pfmipv6-12.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 (December 28, 2009) is 5232 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'AP ID' is mentioned on line 363, but not defined == Missing Reference: 'AR-Info' is mentioned on line 363, but not defined ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) == Outdated reference: A later version (-18) exists of draft-ietf-netlmm-pmip6-ipv4-support-17 ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) Summary: 4 errors (**), 0 flaws (~~), 4 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: July 1, 2010 R. Koodli 6 Starent Networks 7 B. Patil 8 Nokia 9 F. Xia 10 Huawei USA 11 December 28, 2009 13 Fast Handovers for Proxy Mobile IPv6 14 draft-ietf-mipshop-pfmipv6-12.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 July 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 . . . . . . . . . . . . . . . . . . . . . . . 31 118 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32 119 10.1. Normative References . . . . . . . . . . . . . . . . . . . 32 120 10.2. Informative References . . . . . . . . . . . . . . . . . . 32 121 Appendix A. Applicable Use Cases . . . . . . . . . . . . . . . . 33 122 A.1. PMIPv6 Handoff Indication . . . . . . . . . . . . . . . . 33 123 A.2. Local Routing . . . . . . . . . . . . . . . . . . . . . . 33 124 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 35 125 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 41 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 extends FMIPv6 for Proxy MIPv6 operation to minimize handover delay 150 and packet loss as well as to transfer network-resident context for a 151 PMIPv6 handover. [RFC5568] should be considered normative for this 152 document, except where this document specifies new or revised 153 functions and messages. 155 3. Terminology 157 This document reuses terminology from [RFC5213], [RFC5568] and 158 [RFC3775]. The following terms and abbreviations are additionally 159 used in this document. 161 Access Network (AN): 162 A network composed of link-layer access devices such as access 163 points or base stations providing access to an Access Router 164 (AR) connected to it. 166 Previous Access Network (P-AN): 167 The access network to which the Mobile Node (MN) is attached 168 before handover. 170 New Access Network (N-AN): 171 The access network to which the Mobile Node (MN) is attached 172 after handover. 174 Previous Mobile Access Gateway (PMAG): 175 The MAG that manages mobility related signaling for the mobile 176 node before handover. In this document, the MAG and the Access 177 Router are co-located. 179 New Mobile Access Gateway (NMAG): 180 The MAG that manages mobility related signaling for the mobile 181 node after handover. In this document, the MAG and the Access 182 Router (AR) are co-located. 184 Local Mobility Anchor (LMA) 185 The topological anchor point for the mobile node's home network 186 prefix(es) and the entity that manages the mobile node's binding 187 state. This specification does not alter any capability or 188 functionality defined in [RFC5213]. 190 Handover indication: 191 A generic signaling message, sent from the P-AN to the PMAG that 192 indicates a mobile node's handover. While this signaling is 193 dependent on the access technology, it is assumed that Handover 194 indication can carry the information to identify the mobile node 195 and to assist the PMAG to resolve the NMAG and the new access 196 point or base station to which the mobile node is moving to. 197 The details of this message are outside the scope of this 198 document. 200 4. Proxy-based FMIPv6 Protocol Overview 202 This specification describes fast handover protocols for the network- 203 based mobility management protocol called Proxy Mobile IP (PMIPv6) 204 [RFC5213]. The core functional entities defined in PMIPv6 are the 205 Local Mobility Anchor (LMA) and the Mobile Access Gateway (MAG). The 206 LMA is the topological anchor point for the mobile node's home 207 network prefix(es). The MAG acts as an access router (AR) for the 208 mobile node and performs the mobility management procedures on its 209 behalf. The MAG is responsible for detecting the mobile node's 210 movements to and from the access link and for initiating binding 211 registrations to the mobile node's local mobility anchor. If the 212 MAGs can be informed of the detachment and/or attachment of the 213 mobile node in a timely manner via e.g., the lower layer signaling, 214 it will become possible to optimize the handover procedure, which 215 involves establishing a connection on the new link and signaling 216 between mobility agents, compared to the baseline specification of 217 PMIPv6. 219 In order to further improve the performance during the handover, the 220 PFMIPv6 protocol in this document specifies a bi-directional tunnel 221 between the Previous MAG (PMAG) and the New MAG (NMAG) to tunnel 222 packets meant for the mobile node. In order to enable the NMAG to 223 send the Proxy Binding Update (PBU), the Handover Initiate (HI) and 224 Handover Acknowledge (HAck) messages in [RFC5568] are extended for 225 context transfer, in which parameters such as mobile node's Network 226 Access Identifier (NAI), Home Network Prefix (HNP), IPv4 Home 227 Address, are transferred from the PMAG. New flags 'P' and 'F' are 228 defined for the HI and HAck messages to distinguish from those in 229 [RFC5568] and to request packet forwarding, respectively. 231 In this document, the Previous Access Router (PAR) and New Access 232 Router (NAR) are interchangeable with the PMAG and NMAG, 233 respectively. The reference network is illustrated in Figure 1. The 234 access networks in the figure (i.e., P-AN and N-AN) are composed of 235 Access Points (APs) defined in [RFC5568], which are often referred to 236 as base stations in cellular networks. 238 Since a mobile node is not directly involved with IP mobility 239 protocol operations, it follows that the mobile node is not directly 240 involved with fast handover procedures either. Hence, the messages 241 involving the mobile node in [RFC5568] are not used when PMIPv6 is in 242 use. More specifically, the Router Solicitation for Proxy 243 Advertisement (RtSolPr), the Proxy Router Advertisement (PrRtAdv), 244 Fast Binding Update (FBU), Fast Binding Acknowledgment (FBack) and 245 the Unsolicited Neighbor Advertisement (UNA) messages are not 246 applicable in the PMIPv6 context. 248 +----------+ 249 | LMA | 250 | | 251 +----------+ 252 / \ 253 / \ 254 / \ 255 +........../..+ +..\..........+ 256 . +-------+-+ .______. +-+-------+ . 257 . | PMAG |()_______)| NMAG | . 258 . | (PAR) | . . | (NAR) | . 259 . +----+----+ . . +----+----+ . 260 . | . . | . 261 . ___|___ . . ___|___ . 262 . / \ . . / \ . 263 . ( P-AN ) . . ( N-AN ) . 264 . \_______/ . . \_______/ . 265 . | . . | . 266 . +----+ . . +----+ . 267 . | MN | ----------> | MN | . 268 . +----+ . . +----+ . 269 +.............+ +.............+ 271 Figure 1: Reference network for fast handover 273 4.1. Protocol Operation 275 There are two modes of operation in FMIPv6 [RFC5568]. In the 276 predictive mode of fast handover, a bi-directional tunnel between the 277 PMAG (PAR) and NMAG (NAR) is established prior to the mobile node's 278 attachment to the NMAG. In the reactive mode, this tunnel 279 establishment takes place after the mobile node attaches to the NMAG. 280 In order to alleviate the packet loss during a mobile node's handover 281 (especially when the mobile node is detached from both links), the 282 downlink packets for the mobile node need to be buffered either at 283 the PMAG or NMAG, depending on when the packet forwarding is 284 performed. It is hence required that all MAGs have the capability 285 and enough resources to buffer packets for the mobile nodes 286 accommodated by them. The buffer size to be prepared and the rate at 287 which buffered packets are drained are addressed in Section 5.4 of 288 [RFC5568]. Note that the protocol operation specified in the 289 document is transparent to the local mobility anchor (LMA), hence 290 there is no new functional requirement or change on the LMA. 292 Unlike MIPv6, the mobile node in the PMIPv6 domain is not involved 293 with IP mobility signaling; therefore, in order for the predictive 294 fast handover to work effectively, it is required that the mobile 295 node is capable of reporting lower-layer information to the AN at a 296 short enough interval, and the AN is capable of sending the Handover 297 indication to the PMAG at an appropriate timing. The sequence of 298 events for the predictive fast handover are illustrated in Figure 2. 300 PMAG NMAG 301 MN P-AN N-AN (PAR) (NAR) LMA 302 | | | | | | 303 (a) |--Report-->| | | | | 304 | | | | | | 305 | | Handover | | | 306 (b) | |------indication------>| | | 307 | | | | | | 308 | | | | | | 309 (c) | | | |----HI---->| | 310 | | | | | | 311 | | | | | | 312 (d) | | | |<---HAck---| | 313 | | | | | | 314 | | | | | | 315 | | | |HI/HAck(optional) | 316 (e) | | | |<- - - - ->| | 317 | | | #=|<===================| 318 (f) | | | #====DL data=>| | 319 | Handover | Handover | | | 320 (g) |<-command--|<------command---------| | | 321 ~~~ | | | | | 322 ~~~ | | | | | 323 | MN-AN connection | AN-MAG connection | | 324 (h) |<---establishment---->|<----establishment----->| | 325 | | | (substitute for UNA) | | 326 | | | | | | 327 (i) |<==================DL data=====================| | 328 | | | | | | 329 (j) |===================UL data====================>|=# | 330 | | | #=|<============# | 331 | | | #=====================>| 332 / | | | | | | \ 333 |(k) | | | | |--PBU-->| | 334 | | | | | | | | 335 |(l) | | | | |<--PBA--| | 336 | |<==================DL data=====================|<=======| | 337 | | | | | | | | 338 \ |===================UL data====================>|=======>| / 340 Figure 2: Predictive fast handover for PMIPv6 (PMAG initiated) 342 The detailed descriptions are as follows: 344 (a) The mobile node detects that a handover is imminent and reports 345 the identifier of itself (MN ID) and the New Access Point 346 Identifier (New AP ID) [RFC5568] to which the mobile node is 347 most likely to move. The MN ID could be the NAI, Link-layer 348 address, or any other suitable identifier, but the MAG SHOULD be 349 able to map any access specific identifier to the NAI as the MN 350 ID. In some cases, the previous access network (P-AN) will 351 determine the New AP ID for the mobile node. This step is 352 access technology specific and details are outside the scope of 353 this document. 355 (b) The previous access network, to which the mobile node is 356 currently attached, indicates the handover of the mobile node to 357 the previous mobile access gateway (PMAG), with the MN ID and 358 New AP ID. Detailed definition and specification of this 359 message are outside the scope of this document. 361 (c) The previous MAG derives the new mobile access gateway (NMAG) 362 from the New AP ID, which is a similar process to that of 363 constructing an [AP ID, AR-Info] tuple in [RFC5568]. The 364 previous MAG then sends the Handover Initiate (HI) message to 365 the new MAG. The HI message MUST have the P flag set and 366 include the MN ID, the HNP(s) and the address of the local 367 mobility anchor that is currently serving the mobile node. If 368 there is a valid (non-zero) MN Link-layer Identifier (MN LL-ID), 369 that information MUST also be included. With some link layers, 370 the MN Link-local Address IID (MN LLA-IID) can also be included 371 (see Section 6.2.3). 373 (d) The new MAG sends the Handover Acknowledge (HAck) message back 374 to the previous MAG with the P flag set. 376 (e) If it is preferred that the timing of buffering or forwarding 377 should be later than step (c), the new MAG may optionally 378 request the previous MAG at a later and appropriate time to 379 buffer or forward packets by setting U flag [RFC5568] or F flag 380 in the HI message, respectively. 382 (f) If the F flag is set in the previous step, a bi-directional 383 tunnel is established between the previous MAG and new MAG and 384 packets destined for the mobile node are forwarded from the 385 previous MAG to the new MAG over this tunnel. After 386 decapsulation, those packets may be buffered at the new MAG. If 387 the connection between the new access network and new MAG has 388 already been established, those packets may be forwarded towards 389 the new access network, which then becomes responsible for them 390 (e.g., buffering or delivering depending on the condition of the 391 mobile node's attachment); this is access technology specific. 393 (g) When handover is ready on the network side, the mobile node is 394 triggered to perform handover to the new access network. This 395 step is access technology specific and details are outside the 396 scope of this document. 398 (h) The mobile node establishes a physical link connection with the 399 new access network (e.g., radio channel assignment), which in 400 turn triggers the establishment of a link-layer connection 401 between the new access network and new MAG if not yet 402 established. An IP layer connection setup may be performed at 403 this time (e.g., PPP IPv6CP) or at a later time (e.g., stateful 404 or stateless auto address configuration). This step can be a 405 substitute for the Unsolicited Neighbor Advertisement (UNA) in 406 [RFC5568]. If the new MAG acquires a valid new MN LL-ID via the 407 new access network and a valid old MN LL-ID from the previous 408 MAG at step (c), these IDs SHOULD be compared to determine 409 whether the same interface is used before and after handover. 410 When the connection between the mobile node and new MAG is PPP 411 and the same interface is used for the handover, the new MAG 412 SHOULD confirm that the same interface identifier is used for 413 the mobile node's link-local address (this is transferred from 414 previous MAG using the MN LLA-IID option at step (c), and sent 415 to the mobile node during the Configure-Request/Ack exchange). 417 (i) The new MAG starts to forward packets destined for the mobile 418 node via the new access network. 420 (j) The uplink packets from the mobile node are sent to the new MAG 421 via the new access network and the new MAG forwards them to the 422 previous MAG. The previous MAG then sends the packets to the 423 local mobility anchor that is currently serving the mobile node. 425 (k) The new MAG sends the Proxy Binding Update (PBU) to the local 426 mobility anchor, whose address is provided in (c). Steps (k) 427 and (l) are not part of the fast handover procedure, but shown 428 for reference. 430 (l) The local mobility anchor sends back the Proxy Binding 431 Acknowledgment (PBA) to the new MAG. From this time on, the 432 packets to/from the mobile node go through the new MAG instead 433 of the previous MAG. 435 According to Section 4 of [RFC5568], the previous access router 436 establishes a binding between the Previous Care-of Address (PCoA) and 437 New Care-of Address (NCoA) to forward packets for the mobile node to 438 the new access router, and the new access router creates a proxy 439 neighbor cache entry to receive those packets for the NCoA before the 440 mobile node arrives. In the case of PMIPv6, however, the only 441 address that is used by the mobile node is MN-HoA (Mobile Node's Home 442 Address), so the PMAG forwards mobile node's packets to the NMAG 443 instead of the NCoA. The NMAG then simply decapsulates those packets 444 and delivers them to the mobile node. FMIPv4 [RFC4988] specifies 445 forwarding when the mobile node uses the home address as its on-link 446 address rather than the care-of address. The usage in PMIPv6 is 447 similar to that in FMIPv4, where the address(es) used by the mobile 448 node is/are based on its HNP(s). Since the NMAG can obtain the Link- 449 layer address (MN LL-ID) and HNP(s) via the HI message (also the 450 interface identifier of the mobile node's link-local address (MN 451 LLA-ID) if available), it can create a neighbor cache entry for the 452 Link-local Address and the routes for the whole HNP(s) even before 453 the mobile node performs Neighbor Discovery. For the uplink packets 454 from the mobile node after handover in (j), the NMAG forwards the 455 packets to the PMAG through the tunnel established in step (f). The 456 PMAG then decapsulates and sends them to the local mobility anchor. 458 The timing of the context transfer and that of packet forwarding may 459 be different. Thus, a new flag 'F' and Option Code values for it in 460 the HI and HAck messages are defined to request forwarding. To 461 request buffering, 'U' flag has already been defined in [RFC5568]. 462 If the PMAG receives the HI message with the F flag set, it starts 463 forwarding packets for the mobile node. The HI message with the U 464 flag set may be sent earlier if the timing of buffering is different 465 from that of forwarding. If packet forwarding is completed, the PMAG 466 MAY send the HI message with the F flag set and the Option Code value 467 being 2. By this message, the ARs on both ends can tear down the 468 forwarding tunnel synchronously. 470 The IP addresses in the headers of those user packets are summarized 471 below: 473 In Step (f), 475 Inner source address: IP address of the CN 477 Inner destination address: HNP or Mobile Node's IPv4 Home 478 Address (IPv4-MN-HoA) 480 Outer source address: IP address of the PMAG 482 Outer destination address: IP address of the NMAG 484 In Step (i), 485 Source address: IP address of the CN 487 Destination address: HNP or IPv4-MN-HoA 489 In Step (j), 491 - from the mobile node to the NMAG, 493 Source address: HNP or IPv4-MN-HoA 495 Destination address: IP address of the CN 497 - from the NMAG to the PMAG, 499 Inner source address: HNP or IPv4-MN-HoA 501 Inner destination address: IP address of the CN 503 Outer source address: IP address of the NMAG 505 Outer destination address: IP address of the PMAG 507 - from the PMAG to the LMA, 509 Inner source address: HNP or IPv4-MN-HoA 511 Inner destination address: IP address of the CN 513 Outer source address: IP address of the PMAG 515 Outer destination address: IP address of the LMA 517 In the case of the reactive handover for PMIPv6, since the mobile 518 node does not send either the FBU or UNA, it would be more natural 519 that the NMAG sends the HI to the PMAG after the mobile node has 520 moved to the new link. The NMAG then needs to obtain the information 521 of the PMAG beforehand. Such information could be provided, for 522 example, by the mobile node sending the AP-ID on the old link and/or 523 by the lower-layer procedures between the P-AN and N-AN. The exact 524 method is not specified in this document. Figure 3 illustrates the 525 reactive fast handover procedures for PMIPv6, where the bi- 526 directional tunnel establishment is initiated by the NMAG. 528 PMAG NMAG 529 MN P-AN N-AN (PAR) (NAR) LMA 530 | | | | | | 531 (a) ~~~ | | | | | 532 ~~~ | | | | | 533 | MN-AN connection | AN-MAG connection | | 534 (b) |<--establishment-->|<-------establishment------>| | 535 | | |(substitute for UNA and FBU)| | 536 | | | | | | 537 | | | | | | 538 (c) | | | |<-----HI-------| | 539 | | | | | | 540 | | | | | | 541 (d) | | | |-----HAck----->| | 542 | | | | | | 543 | | | | | | 544 (e) | | | #=|<=======================| 545 | | | #================>|=# | 546 |<====================DL data======================# | 547 | | | | | | 548 (f) |=====================UL data===================>|=# | 549 | | | #=|<================# | 550 | | | #=========================>| 551 | | | | | | 552 / | | | | | | \ 553 |(g) | | | | |--PBU-->| | 554 | | | | | | | | 555 |(h) | | | | |<--PBA--| | 556 | |<====================DL data====================|<=======| | 557 | | | | | | | | 558 \ |=====================UL data===================>|=======>| / 560 Figure 3: Reactive fast handover for PMIPv6 (NMAG initiated) 562 The detailed descriptions are as follows: 564 (a) The mobile node undergoes handover from the previous access 565 network to the new access network. 567 (b) The mobile node establishes a connection (e.g., radio channel) 568 with the new access network, which triggers the establishment of 569 the connection between the new access network and new MAG. The 570 MN ID is transferred to the new MAG at this step for the 571 subsequent procedures. The AP-ID on the old link (Old AP ID), 572 which will be provided by either the mobile node or the new 573 access network, is also transferred to the new MAG to help 574 identify the previous MAG on the new link. This can be regarded 575 as a substitute for the UNA and FBU. 577 (c) The new MAG sends the HI to the previous MAG. The HI message 578 MUST have the P flag set and include the MN ID. The Context 579 Request Option MAY be included to request additional context 580 information on the mobile node to the previous MAG. 582 (d) The previous MAG sends the HAck back to the new MAG with the P 583 flag set. The HAck message MUST include the HNP(s) and/or IPv4- 584 MN-HoA that is corresponding to the MN ID in the HI message and 585 SHOULD include the MN LL-ID, only if it is valid (non zero), and 586 the local mobility anchor address that is currently serving the 587 mobile node. The context information requested by the new MAG 588 MUST be included. If the requested context is not available for 589 some reason, the previous MAG MUST return the HAck with the Code 590 value 131. If the F flag is set in the HI at step (c) and 591 forwarding is nevertheless not executable for some reason, the 592 previous MAG MUST return the HAck with the Code value 132. 594 (e) If the F flag in the HI is set at step (c), a bi-directional 595 tunnel is established between the previous MAG and new MAG and 596 packets destined for the mobile node are forwarded from the 597 previous MAG to the new MAG over this tunnel. After 598 decapsulation, those packets are delivered to the mobile node 599 via the new access network. 601 (f) The uplink packets from the mobile node are sent to the new MAG 602 via the new access network and the new MAG forwards them to the 603 previous MAG. The previous MAG then sends the packets to the 604 local mobility anchor that is currently serving the mobile node. 606 Steps (g)-(h) are the same as (k)-(l) in the predictive fast handover 607 procedures. 609 In step (c), the IP address of the PMAG needs to be resolved by the 610 NMAG to send the HI to the PMAG. This information may come from the 611 N-AN or some database that the NMAG can access. 613 4.2. Inter-AR Tunneling Operation 615 When the PMAG (PAR) or NMAG (NAR), depending on the fast handover 616 mode, receives the HI message with the F flag set, it prepares to 617 send/receive the mobile node's packets to/from the other MAG and 618 returns the HAck message with the same sequence number. The both 619 MAGs SHOULD support the following encapsulation modes for the user 620 packets, which are also defined for the tunnel between the local 621 mobility anchor and MAG: 623 o IPv4-or-IPv6-over-IPv6 [IPv4PMIPv6] 624 o IPv4-or-IPv6-over-IPv4 [IPv4PMIPv6] 626 o IPv4-or-IPv6-over-IPv4-UDP [IPv4PMIPv6] 628 o TLV-header UDP tunneling [GREKEY] 630 o GRE tunneling with or without GRE key(s) [GREKEY] 632 The PMAG and the NMAG MUST use the same tunneling mechanism for the 633 data traffic tunneled between them. The encapsulation mode to be 634 employed SHOULD be configurable. This specification recommends the 635 following: 637 1. As the default behavior, the inter-MAG tunnel uses the same 638 encapsulation mechanism as that for the PMIPv6 tunnel between the 639 local mobility anchor and the MAGs. The PMAG and NMAG 640 automatically start using the same encapsulation mechanism 641 without a need for a special configuration on the MAGs or a 642 dynamic tunneling mechanism negotiation between them. 644 2. Configuration on the MAGs can override the default mechanism 645 specified in #1 above. The PMAG and NMAG MUST be configured with 646 the same mechanism and this configuration is most likely to be 647 uniform throughout the PMIPv6 domain. If the packets on the 648 PMIPv6 tunnel cannot be uniquely mapped on to the configured 649 inter-MAG tunnel, this scenario is not applicable and scenario #3 650 below SHOULD directly be applied. 652 3. An implicit or explicit tunnel negotiation mechanism between the 653 MAGs can override the default mechanism specified in #1 above. 654 The employed tunnel negotiation mechanism is outside the scope of 655 this document. 657 The necessary information MUST be transferred in the HI/HAck messages 658 to distinguish mobile node's packets for forwarding in advance or at 659 this time. Such information includes the HNP(s) (or IPv4-MN-HoA) 660 and/or GRE key(s). In the case of GRE tunneling with GRE keys being 661 used, for each mobility session, the NMAG selects the GRE key for the 662 downlink packets and the PMAG selects the GRE key for the uplink 663 packets. These GRE keys are exchanged between the PMAG and the NMAG 664 using the GRE Key option as described in [GREKEY], e.g., In the case 665 of the reactive mode as shown in Figure 3, the DL GRE key is 666 communicated in the HI message while the UL GRE key is sent in the 667 HAck message. For the downlink packets, the PMAG redirects mobile 668 node's packets from the local mobility anchor towards the NMAG and if 669 the mobile node is ready to receive those packets or the N-AN can 670 handle them regardless of the state of the mobile node, the NMAG 671 should immediately send them towards the N-AN; otherwise it should 672 buffer them until the mobile node is ready. For the uplink packets, 673 the NMAG SHOULD reverse-tunnel them from the mobile node towards the 674 PMAG and the PMAG sends them to the local mobility anchor. 676 When the PMAG or NMAG receives the HI message with the U flag set, it 677 prepares to buffer the mobile node's packets and returns the HAck 678 message with the same sequence number. It MUST be followed by 679 another HI message with the F flag set at an appropriate time to 680 forward the buffered packets. 682 If the MAG that received the HI message encounters an erroneous 683 situation (e.g., insufficient buffer space), it SHOULD immediately 684 send the HAck message with the cause of the error and cancel all 685 tunneling operation. 687 4.3. IPv4 Support Considerations 689 The motivation and usage scenarios of IPv4 protocol support by PMIPv6 690 are described in [IPv4PMIPv6]. The scope of IPv4 support covers the 691 following two features: 693 o IPv4 Home Address Mobility Support, and 695 o IPv4 Transport Support. 697 As for IPv4 Home Address Mobility Support, the mobile node acquires 698 IPv4 Home Address (IPv4-MN-HoA) and in the case of handover, the PMAG 699 needs to transfer IPv4-MN-HoA to the NMAG, which is the inner 700 destination address of the packets forwarded on the downlink. For 701 this purpose, IPv4 Address Option described in Section 6.2.7 is used. 702 In order to provide IPv4 Transport Support, the NMAG needs to know 703 the IPv4 address of the local mobility anchor (IPv4-LMAA) to send 704 PMIPv6 signaling messages to the local mobility anchor in the IPv4 705 transport network. For this purpose, a new option called LMA Address 706 (LMAA) Option is defined in Section 6.2.2 so as to convey IPv4-LMAA 707 from the PMAG to NMAG. 709 5. PMIPv6-related Fast Handover Issues 711 5.1. Manageability Considerations 713 This specification does not require any additional IP-level 714 functionality on the local mobility anchor and the mobile node 715 running in the PMIPv6 domain. A typical network interface that the 716 mobile node could be assumed to have is one with the cellular 717 network, where the network controls the movement of the mobile node. 718 Different types of interfaces could be involved such as different 719 generations (3G and 3.9G) or different radio access systems. This 720 specification supports a mobile node with the single radio mode, 721 where only one interface is active at any given time. The assigned 722 IP address is preserved whether the physical interface changes or not 723 and the mobile node can identify which interface should be used if 724 there are multiple ones. 726 5.2. Expedited Packet Transmission 728 The protocol specified in this document enables the NMAG to obtain 729 parameters which would otherwise be available only by communicating 730 with the local mobility anchor. For instance, the HNP(s) and/or 731 IPv4-MN-HoA of a mobile node are made available to the NMAG through 732 context transfer. This allows the NMAG to perform some procedures 733 that may be beneficial. The NMAG, for example, could send a Router 734 Advertisement (RA) with the HNP option to the mobile node as soon as 735 its link attachment is detected (e.g., via receipt of a Router 736 Solicitation message). Such an RA is recommended, for example, in 737 scenarios where the mobile node uses a new radio interface while 738 attaching to the NMAG; since the mobile node does not have 739 information regarding the new interface, it will not be able to 740 immediately send packets without first receiving an RA with HNP(s). 741 Especially, in the reactive fast handover, the NMAG gets to know the 742 HNP(s) assigned to the mobile node on the previous link at step (d) 743 in Figure 3. In order to reduce the communication disruption time, 744 the NMAG SHOULD expect the mobile node to keep using the same HNP and 745 to send uplink packets before that step upon the mobile node's 746 request. However, if the HAck from the PMAG returns a different HNP 747 or the subsequent PMIPv6 binding registration for the HNP fails for 748 some reason, then the NMAG MUST withdraw the advertised HNP by 749 sending another RA with zero prefix lifetime for the HNP in question. 750 This operation is the same as described in Section 6.12 of [RFC5213]. 752 The protocol specified in this document is applicable regardless of 753 whether link-layer addresses are used between a mobile node and its 754 access router. A mobile node should be able to continue sending 755 packets on the uplink even when it changes link. When link-layer 756 addresses are used, the mobile node performs Neighbor Unreachability 757 Detection (NUD) [RFC4861], after attaching to a new link, probing the 758 reachability of its default router. The new router should respond to 759 the NUD probe, providing its link-layer address in the solicited 760 Neighbor Advertisement, which is common in the PMIPv6 domain. 761 Implementations should allow the mobile node to continue to send 762 uplink packets while it is performing NUD. 764 6. Message Formats 766 This document defines new Mobility Header messages for the extended 767 HI and Hack and new mobility options for conveying context 768 information. 770 6.1. Mobility Header 772 6.1.1. Handover Initiate (HI) 774 This section defines extensions to the HI message in [RFC5568]. The 775 format of the Message Data field in the Mobility Header is as 776 follows: 778 0 1 2 3 779 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 780 +-------------------------------+ 781 | Sequence # | 782 +-+-+-+-+-------+---------------+-------------------------------+ 783 |S|U|P|F|Resv'd | Code | | 784 +-+-+-+-+-------+---------------+ | 785 | | 786 . . 787 . Mobility options . 788 . . 789 | | 790 +---------------------------------------------------------------+ 791 (Note:P=1) 793 IP Fields: 795 Source Address 797 The IP address of PMAG or NMAG 799 Destination Address 801 The IP address of the peer MAG 803 Message Data: 805 Sequence # Same as [RFC5568]. 807 S flag Defined in [RFC5568] and MUST be set to zero in this 808 specification. 810 U flag Buffer flag. Same as [RFC5568]. 812 P flag Proxy flag. Used to distinguish the message from that 813 defined in [RFC5568] and MUST be set in all new message 814 formats defined in this document when using this protocol 815 extension. 817 F flag Forwarding flag. Used to request to forward the packets 818 for the mobile node. 820 Reserved Same as [RFC5568]. 822 Code [RFC5568] defines this field and its values 0 and 1. In 823 this specification, with the P flag set, this field can 824 be set to zero by default or the following values: 826 2: Indicate the completion of forwarding 828 3: All available context transferred 830 Code value 3 is set when the transfer of all necessary 831 context information is completed with this message. This 832 Code value is used in both cases where the context 833 information is fragmented into several pieces and the 834 last fragment is contained in this message and where the 835 whole information is transferred in one piece. 837 Mobility options: 839 This field contains one or more mobility options, whose encoding and 840 formats are defined in [RFC3775]. 842 Required option 843 In order to uniquely identify the target mobile node, the 844 mobile node Identifier MUST be contained in the Mobile Node 845 Identifier Option. 847 The transferred context MUST be for one mobile node per message. In 848 addition, the NMAG can request necessary mobility options by the 849 Context Request Option defined in this document. 851 Context Request Option 853 This option MAY be present to request context information 854 typically by the NMAG to the PMAG in the NMAG-initiated fast 855 handover. 857 6.1.2. Handover Acknowledge (HAck) 859 This section defines extensions to the HAck message in[RFC5568]. The 860 format of the Message Data field in the Mobility Header is as 861 follows: 863 0 1 2 3 864 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 865 +-------------------------------+ 866 | Sequence # | 867 +-+-+-+---------+---------------+-------------------------------+ 868 |U|P|F|Reserved | Code | | 869 +-+-+-+---------+---------------+ | 870 | | 871 . . 872 . Mobility options . 873 . . 874 | | 875 +---------------------------------------------------------------+ 876 (Note:P=1) 878 IP Fields: 880 Source Address 882 Copied from the destination address of the 883 Handover Initiate message to which this message 884 is a response. 886 Destination Address 888 Copied from the source address of the Handover 889 Initiate message to which this message is a 890 response. 892 Message Data: 894 The usages of Sequence # and Reserved fields are exactly the same as 895 those in [RFC5568]. 897 U flag Same as defined in Section 6.1.1. 899 P flag Used to distinguish the message from that defined in 900 [RFC5568] and MUST be set in all new message formats 901 defined in this document when using this protocol 902 extension. 904 F flag Same as defined in Section 6.1.1. 906 Code 907 Code values 0 through 4 and 128 through 130 are defined 908 in [RFC5568]. In this specification, the meaning of Code 909 value 0 is modified, 128 through 130 are reused, and 5, 910 6, 131 and 132 are newly defined. 912 0: Handover Accepted or Successful 914 5: Context Transfer Accepted or Successful 916 6: All available Context Transferred 918 128: Handover Not Accepted, reason unspecified 920 129: Administratively prohibited 922 130: Insufficient resources 924 131: Requested Context Not Available 926 132: Forwarding Not Available 928 Mobility options: 930 This field contains one or more mobility options, whose encoding and 931 formats are defined in [RFC3775]. The mobility option that uniquely 932 identifies the target mobile node MUST be copied from the 933 corresponding HI message and the transferred context MUST be for one 934 mobile node per message. 936 Required option(s) All the context information requested by the 937 Context Request Option in the HI message SHOULD be present 938 in the HAck message. The other cases are described below. 940 In the case of the PMAG-initiated fast handover, when the PMAG sends 941 the HI message to the NMAG with the context information and the NMAG 942 successfully receives it, the NMAG returns the HAck message with Code 943 value 5. In the case of the NMAG-initiated fast handover, when the 944 NMAG sends the HI message to the PMAG with or without Context Request 945 Option, the PMAG returns the HAck message with the requested or 946 default context information (if any). If all available context 947 information is transferred, the PMAG sets the Code value in the HAck 948 message to 6. If more context information is available, the PMAG 949 sets the Code value in the HAck to 5 and the NMAG MAY send new HI 950 message(s) to retrieve the rest of the available context information. 951 If none of the requested context information is available, the PMAG 952 returns the HAck message with Code value 131 without any context 953 information. 955 6.2. Mobility Options 957 6.2.1. Context Request Option 959 This option is sent in the HI message to request context information 960 on the mobile node. If a default set of context information is 961 defined and always sufficient, this option is not used. This option 962 is more useful to retrieve additional or dynamically selected context 963 information. 965 Context Request Option is typically used for the reactive (NMAG- 966 initiated) fast handover mode to retrieve the context information 967 from the PMAG. When this option is included in the HI message, all 968 the requested context information SHOULD be included in the HAck 969 message in the corresponding mobility option(s) (e.g., HNP, LMAA or 970 MN LL-ID mobility options). 972 The default context information to request is the Home Network Prefix 973 Option. If the Mobile Node link-layer is available and used, the 974 Mobile Node Link-layer Identifier Option MUST also be requested. 976 0 1 2 3 977 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 978 +---------------+---------------+---------------+---------------+ 979 | Option-Type | Option-Length | Reserved | 980 +---------------+---------------+-------------------------------+ 981 | Req-type-1 | Req-length-1 | Req-type-2 | Req-length-2 | 982 +---------------------------------------------------------------+ 983 | Req-type-3 | Req-length-3 | Req-option-3 | 984 +---------------------------------------------------------------+ 985 | ... | 987 Option-Type TBD1 989 Option-Length The length in octets of this option, not including the 990 Option Type and Option Length fields. 992 Reserved This field is unused. It MUST be initialized to zero 993 by the sender and MUST be ignored by the receiver. 995 Req-type-n The type value for the n'th requested option. 997 Req-length-n The length of the n'th requested option excluding the 998 Req-type-n and Req-length-n fields. 1000 Req-option-n The optional data to uniquely identify the requested 1001 context for the n'th requested option. 1003 In the case where there are only Req-type-n and Req-length-n fields, 1004 the value of the Req-length-n is set to zero. If additional 1005 information besides the Req-type-n is necessary to uniquely specify 1006 the requested context, such information follows after the 1007 Req-length-n. For example, when the requested contexts start with 1008 the HNP Option (type=22), the MN Link-layer ID Option (type=25) and 1009 the Vendor-Specific Option (type=19), the required option format 1010 looks as follows: 1012 | ... | 1013 +---------------+---------------+---------------+---------------+ 1014 |Option-Type=CRO| Option-Length | Reserved | 1015 +---------------+---------------+---------------+---------------+ 1016 | Req-type-N=22 | Req-length-N=0| Req-type-N=25 | Req-length-N=0| 1017 +---------------+---------------+-------------------------------+ 1018 | Req-type-N=19 | Req-length-N=5| Vendor-ID | 1019 +-------------------------------+---------------+---------------+ 1020 | Vendor-ID | Sub-Type | | 1021 +-----------------------------------------------+ | 1022 | ... | 1024 The first two options can uniquely identify the requested contexts 1025 (i.e., the HNP and MN Link-layer ID) by the Req-type, so the Req- 1026 length is set to zero; however, the subsequent Vendor-Specific Option 1027 further needs the Vendor-ID and Sub-type to identify the requested 1028 context, so these parameters follow and the Req-length is set to 5. 1029 Note that the exact values in the Vendor-ID ans Sub-Type follow 1030 [RFC5094]. 1032 6.2.2. Local Mobility Anchor Address (LMAA) Option 1034 This option is used to transfer the Local Mobility Anchor IPv6 1035 Address (LMAA) or its IPv4 Address (IPv4-LMAA), with which the mobile 1036 node is currently registered. The detailed definition of the LMAA is 1037 described in [RFC5213]. 1039 0 1 2 3 1040 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 1041 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1042 | Option-Type | Option-Length | Option-Code | Reserved | 1043 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1044 | Local Mobility Anchor Address ... | 1046 Option-Type TBD2 1048 Option-Length 18 or 6 1050 Option-Code 1052 0 Reserved 1054 1 IPv6 address of the local mobility anchor (LMAA) 1056 2 IPv4 address of the local mobility anchor (IPv4- 1057 LMAA) 1059 Reserved This field is unused. It MUST be initialized to zero 1060 by the sender and MUST be ignored by the receiver. 1062 Local Mobility Anchor Address 1063 If Option-Code is 1, the LMA IPv6 address (LMAA) is 1064 inserted. If Option-Code is 2, the LMA IPv4 address 1065 (IPv4-LMA) is inserted. 1067 6.2.3. Mobile Node Link-local Address Interface Identifier (MN LLA-IID) 1068 Option 1070 This option is used to transfer the interface identifier of the 1071 mobile node's IPv6 Link-local Address that is used in the P-AN. In 1072 deployments where the interface identifier is assigned by the 1073 network, or it is known to the network, this option is used to 1074 transfer this identifier from the PMAG to NMAG. 1076 0 1 2 3 1077 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 1078 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1079 | Option-Type | Option-Length | Reserved | 1080 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1081 | | 1082 + Interface Identifier + 1083 | | 1084 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1086 Option-Type TBD3 1088 Option-Length 10 1090 Reserved This field is unused. It MUST be initialized to zero 1091 by the sender and MUST be ignored by the receiver. 1093 Interface Identifier 1094 The Interface Identifier value used for the mobile 1095 node's IPv6 Link-local address in the P-AN. 1097 6.2.4. Home Network Prefix Option 1099 This option is used to transfer the home network prefix that is 1100 assigned to the mobile node in the P-AN. The Home Network Prefix 1101 Option defined in [RFC5213] is used for this. 1103 6.2.5. Link-local Address Option 1105 This option is used to transfer the link-local address of the PMAG 1106 (PMAG). The Link-local Address Option defined in [RFC5213] is used 1107 for this. 1109 6.2.6. GRE Key Option 1111 This option is used to transfer the GRE Key for the mobile node's 1112 data flow over the bi-directional tunnel between the PMAG and NMAG. 1113 The message format of this option follows the GRE Key Option defined 1114 in [GREKEY]. The GRE Key value uniquely identifies each flow and the 1115 sender of this option expects to receive packets of the flow from the 1116 peer AR with this value. 1118 6.2.7. IPv4 Address Option 1120 As described in Section 4.3, if the mobile node runs in IPv4-only 1121 mode or dual-stack mode, it requires IPv4 home address (IPv4-MN-HoA). 1122 This option is used to transfer the IPv4 home address if assigned on 1123 the previous link. The format of this option follows the IPv4 Home 1124 Address Request Option defined in [IPv4PMIPv6]. 1126 6.2.8. Vendor-Specific Mobility Option 1128 This option is used to transfer any other information defined in this 1129 document. The format and used values of this option follow the 1130 Vendor-Specific Mobility Option defined in [RFC5094]. 1132 7. Security Considerations 1134 Security issues for this document follow those for PMIPv6 [RFC5213] 1135 and FMIPv6 [RFC5568]. In PMIPv6, the MAG and local mobility anchor 1136 are assumed to share security associations. In FMIPv6, the access 1137 routers (i.e., the PMAG and NMAG in this document) are assumed to 1138 share security associations. 1140 The Handover Initiate (HI) and Handover Acknowledge (HAck) messages 1141 exchanged between the PMAG and NMAG MUST be protected using end-to- 1142 end security association(s) offering integrity and data origin 1143 authentication. The PMAG and the NMAG MUST implement IPsec [RFC4301] 1144 for protecting the HI and HAck messages. IPsec Encapsulating 1145 Security Payload (ESP) [RFC4303] in transport mode with mandatory 1146 integrity protection SHOULD be used for protecting the signaling 1147 messages. Confidentiality protection SHOULD be used if sensitive 1148 context related to the mobile node is transferred. 1150 IPsec ESP [RFC4303] in tunnel mode SHOULD be used to protect the 1151 mobile node's packets at the time of forwarding if the link between 1152 the PMAG and NMAG exposes the mobile node's packets to more threats 1153 than if they had followed their normal routed path. 1155 8. IANA Considerations 1157 This document defines new flags and status codes in the HI and HAck 1158 messages as well as three new mobility options. The Type values for 1159 these mobility options are assigned from the same numbering space as 1160 allocated for the other mobility options defined in [RFC3775]. Those 1161 for the flags and status codes are assigned from the corresponding 1162 numbering space defined in [RFC5568] and requested to be created as 1163 new tables in the IANA registry (marked with asterisks). New values 1164 for these registries can be allocated by Standards Action or IESG 1165 approval [RFC5226]. 1167 Mobility Options 1168 Value Description Reference 1169 ----- ------------------------------------- ------------- 1170 TBD1 Context Request Option Section 6.2.1 1171 TBD2 Local Mobility Anchor Address Option Section 6.2.2 1172 TBD3 Mobile Node Link-local Address 1173 Interface Identifier Option Section 6.2.3 1175 Handover Initiate Flags (*) 1176 Registration Procedures: Standards Action or IESG Approval 1177 Flag Value Description Reference 1178 ---- ----- ----------------------------------- ------------- 1179 S 0x80 Assigned Address Configuration flag [RFC5568] 1180 U 0x40 Buffer flag [RFC5568] 1181 P 0x20 Proxy flag Section 6.1.1 1182 F 0x10 Forwarding flag Section 6.1.1 1184 Handover Acknowledge Flags (*) 1185 Registration Procedures: Standards Action or IESG Approval 1186 Flag Value Description Reference 1187 ---- ----- ------------------------------- ------------- 1188 U 0x80 Buffer flag Section 6.1.2 1189 P 0x40 Proxy flag Section 6.1.2 1190 F 0x20 Forwarding flag Section 6.1.2 1192 Handover Initiate Status Codes (*) 1193 Registration Procedures: Standards Action or IESG Approval 1194 Code Description Reference 1195 ---- -------------------------------------- ------------- 1196 0 FBU with the PCoA as source IP address [RFC5568] 1197 1 FBU whose source IP address is not PCoA [RFC5568] 1198 2 Indicate the completion of forwarding Section 6.1.1 1199 3 All available context transferred Section 6.1.1 1201 4-255 Unassigned 1203 Handover Acknowledge Status Codes (*) 1204 Registration Procedures: Standards Action or IESG Approval 1205 Code Description Reference 1206 ---- --------------------------------------- ------------- 1207 0 Handover Accepted or Successful Section 6.1.2 1208 (with NCoA valid) [RFC5568] 1209 1 Handover Accepted, NCoA not valid [RFC5568] 1210 2 Handover Accepted, NCoA assigned [RFC5568] 1211 3 Handover Accepted, use PCoA [RFC5568] 1212 4 Message sent unsolicited [RFC5568] 1213 5 Context Transfer Accepted or Successful Section 6.1.2 1214 6 All available Context Transferred Section 6.1.2 1215 7-127 Unassigned 1216 128 Handover Not Accepted, reason unspecified [RFC5568] 1217 129 Administratively prohibited [RFC5568] 1218 130 Insufficient resources [RFC5568] 1219 131 Requested Context Not Available Section 6.1.2 1220 132 Forwarding Not Available Section 6.1.2 1221 133-255 Unassigned 1223 9. Acknowledgments 1225 The authors would like to specially thank Vijay Devarapalli and Sri 1226 Gundavelli for their thorough reviews of this document. 1228 The authors would also like to thank Charlie Perkins, Desire Oulai, 1229 Ahmad Muhanna, Giaretta Gerardo, Domagoj Premec, Marco Liebsch, Fan 1230 Zhao, Julien Laganier and Pierrick Seite for their passionate 1231 discussions in the working group mailing list. 1233 10. References 1235 10.1. Normative References 1237 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 1238 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 1240 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1241 Requirement Levels", BCP 14, RFC 2119, March 1997. 1243 [RFC5568] Koodli, R., "Mobile IPv6 Fast Handovers", RFC 5568, 1244 July 2009. 1246 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 1247 in IPv6", RFC 3775, June 2004. 1249 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1250 Internet Protocol", RFC 4301, December 2005. 1252 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 1253 RFC 4303, December 2005. 1255 [RFC5094] Devarapalli, V., Patel, A., and K. Leung, "Mobile IPv6 1256 Vendor Specific Option", RFC 5094, December 2007. 1258 [IPv4PMIPv6] 1259 Wakikawa, R., Ed. and S. Gundavelli, "IPv4 Support for 1260 Proxy Mobile IPv6", 1261 draft-ietf-netlmm-pmip6-ipv4-support-17.txt, 1262 September 2009. 1264 [GREKEY] Muhanna, A., Ed., "GRE Key Option for Proxy Mobile IPv6", 1265 draft-ietf-netlmm-grekey-option-09.txt, May 2009. 1267 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1268 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1269 May 2008. 1271 10.2. Informative References 1273 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 1274 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 1275 September 2007. 1277 [RFC4988] Koodli, R. and C. Perkins, "Mobile IPv4 Fast Handovers", 1278 RFC 4988, October 2007. 1280 Appendix A. Applicable Use Cases 1282 A.1. PMIPv6 Handoff Indication 1284 PMIPv6 [RFC5213] defines the Handoff Indicator Option and describes 1285 the type of the handoff and the values to set to the option. This 1286 document proposes one approach to determining the handoff type by the 1287 NMAG when the handoff of the mobile node is executed. 1289 According to [RFC5213], the following handoff types are defined: 1291 0) Reserved 1293 1) Attachment over a new interface 1295 2) Handoff between two different interfaces of the mobile node 1297 3) Handoff between mobile access gateways for the same interface 1299 4) Handoff state unknown 1301 5) Handoff state not changed (Re-registration) 1303 Assuming that there is a valid MN Link-layer Identifier (MN LL-ID), 1304 the following solution can be considered. When the NMAG receives the 1305 MN LL-ID from the PMAG in the MN LL-ID option via the HI or HAck 1306 message, the NMAG compares it with the new MN LL-ID that is obtained 1307 from the mobile node in the N-AN. If these two MN LL-IDs are the 1308 same, the handoff type falls into 3) and the Handoff Indicator value 1309 is set to 3. If these two MN LL-IDs are different, the handoff is 1310 likely to be 2) since the HI/HAck message exchange implies that this 1311 is a handoff not a multi-homing, therefore the Handoff Indicator 1312 value can be set to 2. If there is no HI/HAck exchange performed 1313 prior to the network attachment of the mobile node in the N-AN, the 1314 NMAG may infer that this is a multi-homing case and set the Handoff 1315 Indicator value to 1. In the case of re-registration, the MAG, to 1316 which the mobile node is attached, can determine if the handoff state 1317 is not changed, so the MAG can set the HI value to 5 without any 1318 additional information. If none of them can be assumed or there is 1319 no valid MN LL-ID available, the NMAG may set the value to 4. 1321 A.2. Local Routing 1323 Section 6.10.3 in [RFC5213] describes that if EnableMAGLocalRouting 1324 flag is set, when two mobile nodes are attached to one MAG, the 1325 traffic between them may be locally routed. If one mobile node moves 1326 from this MAG (PMAG) to another MAG (NMAG) and if the PMAG does not 1327 detect the mobile node's detachment, it will continue to forward 1328 packets locally forever. This situation is more likely to happen in 1329 the reactive fast handover with WLAN access, which does not have the 1330 capability to detect the detachment of the mobile node in a timely 1331 manner. PFMIPv6 can be applied to handle this case. When the mobile 1332 node attaches to the NMAG, the NMAG sends the HI message to the PMAG 1333 with the 'F' flag set, which makes the PMAG realize the detachment of 1334 the mobile node and establish the inter-MAG tunnel. The PMAG 1335 immediately stops the local routing and sends the packets for the 1336 mobile node to the NMAG via that tunnel, which are then delivered to 1337 the mobile node on the new link. 1339 Appendix B. Change Log 1341 Changes at -00 1343 * Added separate sections for MH and ICMP. 1345 * Clarified usage of HNP and IPv4-MN-HoA throughout the document. 1347 * Added IANA Considerations. 1349 * Added section on Other Considerations, including operation of 1350 uplink packets when using link-layer addresses, multiple 1351 interface usage and transmission of RA to withdraw HNP in the 1352 event of failure of PMIP6 registration. 1354 * Revised Security Considerations. 1356 Changes from -00 to -01 1358 * Removed ICMPv6-based message format. 1360 * Clarified HI/HAck exchange in the predictive mode (step (e) in 1361 Figure 2). 1363 * Clarified information retrieval about the PMAG in the reactive 1364 mode. 1366 * Removed the extension to the GRE Key Option. 1368 * Clarified the handoff type considerations in Appendix A. 1370 * Home Network Prefix Option, Link-local Address Option and 1371 Vendor-Specific Mobility Option are added. 1373 Changes from -01 to -02 1375 * Aligned HI/HAck message formats with 1376 draft-ietf-mipshop-rfc5268bis-00.txt. 1378 * Revised Section 8 removing the request for the type assignment 1379 of HI/HAck Mobility Headers. 1381 Changes from -02 to -03 1383 * Updated HI/HAck message formats according to 1384 draft-ietf-mipshop-rfc5268bis-01.txt. 1386 * Cleaned up Figure 2 and Figure 3. 1388 * Moved PMIP domain boundary crossing situation in Section 4.1 to 1389 Appendix A.3. 1391 * Removed the alternative protocol operation with an unsolicited 1392 HAck from Section 4.1. 1394 * Modified Code values in the HAck message in order to avoid 1395 collision with those in draft-ietf-mipshop-rfc5268bis-01.txt. 1397 * Clarified the usage scenarios of Context Request Option. 1399 * Modified the description of Code values in the HAck message. 1401 * Changed the container for the IPv4-LMAA from IPv4 Address 1402 option to the LMAA option. 1404 * Made Confidentiality protection "SHOULD" for context transfer. 1406 Changes from -03 to -04 1408 * Added more explanations about MIPv6, FMIPv6 and PMIPv6 in 1409 Abstract. 1411 * Moved Figure 1 to Section 4. 1413 * More clearly indicated the FMIPv6 messages that are not 1414 applicable in the PMIPv6 context. 1416 * Mandated the support of IP Sec on the PMAG and NMAG in order to 1417 protect signaling and user packets and the context information. 1419 * Added a new section for the inter-AR tunneling operation 1420 (Section 4.2). 1422 * Added descriptions about the encapsulation type in Sections 4.1 1423 and 4.3. 1425 * Added a description about buffering requirements on the MAG in 1426 Section 4.1. 1428 * Added a description about the timing of L2 and L3 connection 1429 establishments in Section 4.1. 1431 * Added a new section for PMIPv6-related fast handover issues 1432 (Section 5) and a description about preferable behaviors of the 1433 mobile node and MAG to reduce packet loss. 1435 * Added Acknowledgments section (Section 9). 1437 * Added a new section for local routing in Appendix (A.2). 1439 Changes from -04 to -05 1441 * Fixed Figure 2 (step (i)). 1443 * Defined the Mobile Network Interface Identifier (MN-IID) 1444 mobility option in Section 6.2.4 (swapped with old Section 1445 6.2.5), and added it to IANA considerations (Section 8). 1447 * Changed from SHOULD to MUST regarding the inclusion of the 1448 MN-ID, MN-HNP, MN-IID and the LMAA options in the HI message 1449 (step (c) in Section 4.1). 1451 * The optional behavior of the NMAG that allows it to send uplink 1452 packets directly to the local mobility anchor before the PBU/ 1453 PBA exchange was removed from section 4.2 (as out of scope). 1455 * In Section A.3, the description about the HA address assignment 1456 from the NAR to the mobile node was removed (as out of scope). 1458 Changes from -05 to -06 1460 * Added 'P' flag in the HI and Hack messages to distinguish them 1461 from those in FMIPv6. 1463 * Made editorial corrections in Section 2 (Introduction), Section 1464 3 (Terminology), Section 4 (Protocol Overview) and Section 4.2 1465 (Inter-AR Tunneling Operation). 1467 * Added a description on how forwarded packets should be handled 1468 in the access network at step (f) in Section 4.1. 1470 * Added all types of encapsulation methods that should be 1471 supported in Section 4.1. 1473 * Revised the Code values for the HI message in Section 6.1.1. 1475 * Revised the Code values for the HAck message in Section 6.1.2 1476 and added a description of its usage at step (d) of the 1477 reactive handover mode in Section 4.1. 1479 * Removed the definition of the IP Address Option in Section 1480 6.2.3 and moved to Section 6.2.7, which currently refers to the 1481 IPv4 Home Address Option defined by RFC5555. Revised the IANA 1482 Consideration section accordingly. 1484 * Removed the Option-Code from the Mobile Node Identifier (MN 1485 IID) Option. 1487 * Removed Appendix A.3 (Handling of PMIPv6/MIPv6 switching). 1489 Changes from -06 to -07 1491 * Added explanations about defining and setting the 'P' flag for 1492 the HI and Hack messages in Sections 4 and 4.1. 1494 * Corrected the references for the encapsulation types in Section 1495 4.1. 1497 * Modified the Code values for the HI message in Section 6.1.1 to 1498 avoid overlapping with those in 1499 draft-ietf-mipshop-rfc5268bis-01.txt. 1501 * Modified the reference for the IPv4 Address Option from RFC5555 1502 to [IPv4PMIPv6] in Section 6.2.7. 1504 Changes from -07 to -08 1506 * Corrected the reference for the TLV-header UDP encapsulation in 1507 Section 4.1. 1509 * Updated the version number of the reference document 1510 [IPv4PMIPv6] and the option name defined by that document in 1511 Section 6.2.7. 1513 Changes from -08 to -09 1515 * Added a paragraph at the beginning of Section 4 describing the 1516 assumption related to the lower layer signaling. 1518 * Added a new section on the manageability considerations in 1519 Section 5 describing the configurations on the network and the 1520 mobile node assumed in this document. 1522 * Modified the assumed configuration of the MAG regarding its 1523 link-layer address in Section 5 (Section 5.2 in version -09). 1525 * Specified the requested option to identify the target MN for 1526 the inter-AR tunneling in Section 6.1.1. 1528 * Specified the default context information in the Context 1529 Request Option in Section 6.2.1. 1531 Changes from -09 to -10 1533 * Revised the document based on the comments from TSV-DIR, SEC- 1534 DIR, OPS-DIR and GEN-ART. 1536 + Split the abstract section in half for readability. 1538 + Added the definition of Localized Mobility Anchor (local 1539 mobility anchor) in Section 3. 1541 + Added the purpose of this document at the beginning of 1542 Section 4 to make the paragraph more complete. 1544 + Revised the third paragraph of the Security Consideration 1545 section for more precise expression. 1547 + Moved the description about the requirement to set the 'P' 1548 flag in HI/HAck to Sections 6.1.1 and 6.1.2. Also, noted 1549 the 'P' flag setting below the message formats. 1551 + Described the both 'P' and 'F' flags as newly defined ones 1552 in Section 4. 1554 + Clarified the usage of the Context Request Option if a 1555 default set of context information is defined in Section 1556 6.2.1 (changed from "not mandatory" to "not used"). 1558 + Modified the identifier for the interface on the MN to the 1559 MN's link-layer ID (MN LL-ID). 1561 + Corrected the local routing operation of the PMAG in 1562 Appendix A.2. 1564 * Revised the descriptions about the encapsulation mechanism for 1565 the inter-MAG tunnel in Section 4.2 and other related parts for 1566 clarification. 1568 * Also listed the new flags and status codes for the HI/HAck 1569 messages in the IANA Considerations section. 1571 * Elaborated on the example use of the Context Request Option in 1572 Section 6.2.1. 1574 Changes from -10 to -11 1576 * Changed the term "MN Interface Identifier (MN-IID) option" to 1577 "MN Link-local Address Interface Identifier (MN LLA-IID) 1578 option" in Section 6.2.3. Its usage is valid only when the 1579 network assigns the interface identifier. 1581 * Revised the description of the neighbor cache entry in Section 1582 4.1 to include the MN LLA-IID. 1584 Changes from -11 to -12 1586 * Changed the term "HO-Initiate" to "Handover indication". 1588 * Added the handover trigger from the PMAG to the mobile node 1589 ("Handover command") to clarify the timing of handover in 1590 Figure 2. 1592 * Revised IANA Considerations to include all values that are 1593 defined in RFC5568, but not in the IANA Registry yet. 1595 Authors' Addresses 1597 Hidetoshi Yokota 1598 KDDI Lab 1599 2-1-15 Ohara, Fujimino 1600 Saitama, 356-8502 1601 Japan 1603 Email: yokota@kddilabs.jp 1605 Kuntal Chowdhury 1606 Starent Networks 1607 30 International Place 1608 Tewksbury, MA 01876 1609 USA 1611 Email: kchowdhury@starentnetworks.com 1613 Rajeev Koodli 1614 Starent Networks 1615 30 International Place 1616 Tewksbury, MA 01876 1617 USA 1619 Email: rkoodli@starentnetworks.com 1621 Basavaraj Patil 1622 Nokia 1623 6000 Connection Drive 1624 Irving, TX 75039 1625 USA 1627 Email: basavaraj.patil@nokia.com 1629 Frank Xia 1630 Huawei USA 1631 1700 Alma Dr. Suite 500 1632 Plano, TX 75075 1633 USA 1635 Email: xiayangsong@huawei.com