idnits 2.17.1 draft-ietf-mipshop-pfmipv6-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC3775], [RFC5268bis], [RFC5213]), 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 lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 9, 2009) is 5405 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) ** Downref: Normative reference to an Experimental RFC: RFC 4988 == Outdated reference: A later version (-18) exists of draft-ietf-netlmm-pmip6-ipv4-support-13 Summary: 4 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: January 10, 2010 R. Koodli 6 Starent Networks 7 B. Patil 8 Nokia 9 F. Xia 10 Huawei USA 11 July 9, 2009 13 Fast Handovers for Proxy Mobile IPv6 14 draft-ietf-mipshop-pfmipv6-06.txt 16 Status of this Memo 18 This Internet-Draft is submitted to IETF in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on January 10, 2010. 39 Copyright Notice 41 Copyright (c) 2009 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents in effect on the date of 46 publication of this document (http://trustee.ietf.org/license-info). 47 Please review these documents carefully, as they describe your rights 48 and restrictions with respect to this document. 50 Abstract 52 Mobile IPv6 (MIPv6) [RFC3775] provides a mobile node with IP mobility 53 when it performs a handover from one access router to another and 54 fast handovers for Mobile IPv6 (FMIPv6) [RFC5268bis] are specified to 55 enhance the handover performance in terms of latency and packet loss. 56 While MIPv6 (and FMIPv6 as well) requires the participation of the 57 mobile node in the mobility-related signaling, Proxy Mobile IPv6 58 (PMIPv6) [RFC5213] provides IP mobility to mobile nodes that either 59 have or do not have MIPv6 functionality without such involvement. 60 Nevertheless, the basic performance of PMIPv6 in terms of handover 61 latency and packet loss is considered not any different from that of 62 MIPv6. When the fast handover is considered in such an environment, 63 several modifications are needed to FMIPv6 to adapt to the network- 64 based mobility management. This document specifies the usage of Fast 65 Mobile IPv6 (FMIPv6) when Proxy Mobile IPv6 is used as the mobility 66 management protocol. Necessary extensions are specified for FMIPv6 67 to support the scenario when the mobile node does not have IP 68 mobility functionality and hence is not involved with either MIPv6 or 69 FMIPv6 operations. 71 Table of Contents 73 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 4 74 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 75 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 76 4. Proxy-based FMIPv6 Protocol Overview . . . . . . . . . . . . . 7 77 4.1. Protocol Operation . . . . . . . . . . . . . . . . . . . . 8 78 4.2. Inter-AR Tunneling Operation . . . . . . . . . . . . . . . 14 79 4.3. IPv4 Support Considerations . . . . . . . . . . . . . . . 15 80 5. PMIPv6-related Fast Handover Issues . . . . . . . . . . . . . 16 81 6. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 17 82 6.1. Mobility Header . . . . . . . . . . . . . . . . . . . . . 17 83 6.1.1. Handover Initiate (HI) . . . . . . . . . . . . . . . . 17 84 6.1.2. Handover Acknowledge (HAck) . . . . . . . . . . . . . 18 85 6.2. Mobility Options . . . . . . . . . . . . . . . . . . . . . 20 86 6.2.1. Context Request Option . . . . . . . . . . . . . . . . 20 87 6.2.2. Local Mobility Anchor Address (LMAA) Option . . . . . 22 88 6.2.3. Mobile Node Interface Identifier (MN IID) Option . . . 22 89 6.2.4. Home Network Prefix Option . . . . . . . . . . . . . . 23 90 6.2.5. Link-local Address Option . . . . . . . . . . . . . . 23 91 6.2.6. GRE Key Option . . . . . . . . . . . . . . . . . . . . 23 92 6.2.7. IPv4 Address Option . . . . . . . . . . . . . . . . . 23 93 6.2.8. Vendor-Specific Mobility Option . . . . . . . . . . . 24 94 7. Security Considerations . . . . . . . . . . . . . . . . . . . 25 95 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 96 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27 97 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 98 10.1. Normative References . . . . . . . . . . . . . . . . . . . 28 99 10.2. Informative References . . . . . . . . . . . . . . . . . . 28 100 Appendix A. Applicable Use Cases . . . . . . . . . . . . . . . . 29 101 A.1. PMIPv6 Handoff Indication . . . . . . . . . . . . . . . . 29 102 A.2. Local Routing . . . . . . . . . . . . . . . . . . . . . . 29 103 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 31 104 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35 106 1. Requirements notation 108 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 109 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 110 document are to be interpreted as described in [RFC2119]. 112 2. Introduction 114 Proxy Mobile IPv6 [RFC5213] provides IP mobility to a mobile node 115 that does not possess Mobile IPv6 [RFC3775] mobile node 116 functionality. A proxy agent in the network performs the mobility 117 management signaling on behalf of the mobile node. This model 118 transparently provides mobility for mobile nodes within a PMIPv6 119 domain. Nevertheless, the basic performance of PMIPv6 in terms of 120 handover latency and packet loss is considered not any different from 121 that of Mobile IPv6. 123 Fast Handovers for Mobile IPv6 (FMIPv6) [RFC5268bis] describes the 124 protocol to reduce the handover latency for Mobile IPv6 by allowing a 125 mobile node to send packets as soon as it detects a new subnet link 126 and by delivering packets to the mobile node as soon as its 127 attachment is detected by the new access router. This document 128 describes necessary extensions to FMIPv6 to minimize handover delay 129 and packet loss as well as to transfer network-resident context for a 130 PMIPv6 handover. 132 3. Terminology 134 This document reuses terminology from [RFC5213], [RFC5268bis] and 135 [RFC3775]. The following terms and abbreviations are additionally 136 used in this document. 138 Access Network (AN): 139 A network composed of link-layer access devices such as access 140 points or base stations providing access to the Access Router 141 (AR) connected to it. 143 Previous Access Network (P-AN): 144 The access network to which the MN is attached before handover. 146 New Access Network (N-AN): 147 The access network to which the MN is attached after handover. 149 Previous Mobile Access Gateway (PMAG): 150 The MAG that manages mobility related signaling for the MN 151 before handover. In this document, the MAG and the Access 152 Router are collocated. 154 New Mobile Access Gateway (NMAG): 155 The MAG that manages mobility related signaling for the MN after 156 handover. In this document, the MAG and the Access Router (AR) 157 are collocated. 159 HO-Initiate: 160 A generic signaling message, sent from the P-AN to the PMAG that 161 indicates a MN handover. While this signaling is dependent on 162 the access technology, it is assumed that HO-Initiate can carry 163 the information to identify the MN and to assist the PMAG 164 resolve the NMAG and the new access point or the base station to 165 which the MN is moving to. The details of this message are 166 outside the scope of this document. 168 4. Proxy-based FMIPv6 Protocol Overview 170 In order to improve the performance during handover (when operations 171 such as attachment to a new network and signaling between mobility 172 agents are involved), the PFMIPv6 protocol in this document specifies 173 a bi-directional tunnel between the Previous MAG (PMAG) and the New 174 MAG (NMAG) to tunnel packets meant for the mobile node. In order to 175 enable the NMAG to send the Proxy Binding Update (PBU), the Handover 176 Initiate (HI) and Handover Acknowledge (HAck) messages in 177 [RFC5268bis] are used for context transfer, in which parameters such 178 as MN's NAI, Home Network Prefix (HNP), IPv4 Home Address, are 179 transferred from the PMAG. 181 In this document, the Previous Access Router (PAR) and New Access 182 Router (NAR) are interchangeable with the PMAG and NMAG, 183 respectively. The reference network is illustrated in Figure 1. 185 Since a MN is not directly involved with IP mobility protocol 186 operations, it follows that the MN is not directly involved with fast 187 handover procedures either. Hence, the messages involving the MN in 188 [RFC5268bis] are not used when PMIPv6 is in use. More specifically, 189 the Router Solicitation for Proxy Advertisement (RtSolPr), the Proxy 190 Router Advertisement (PrRtAdv), Fast Binding Update (FBU), Fast 191 Binding Acknowledgment (FBack) and the Unsolicited Neighbor 192 Advertisement (UNA) messages are not applicable in the PMIPv6 193 context. 195 +----------+ 196 | LMA | 197 | | 198 +----------+ 199 / \ 200 / \ 201 / \ 202 +........../..+ +..\..........+ 203 . +-------+-+ .______. +-+-------+ . 204 . | PAR |()_______)| NAR | . 205 . | (PMAG) | . . | (NMAG) | . 206 . +----+----+ . . +----+----+ . 207 . | . . | . 208 . ___|___ . . ___|___ . 209 . / \ . . / \ . 210 . ( P-AN ) . . ( N-AN ) . 211 . \_______/ . . \_______/ . 212 . | . . | . 213 . +----+ . . +----+ . 214 . | MN | ----------> | MN | . 215 . +----+ . . +----+ . 216 +.............+ +.............+ 218 Figure 1: Reference network for fast handover 220 4.1. Protocol Operation 222 There are two modes of operation in FMIPv6 [RFC5268bis]. In the 223 predictive mode of fast handover, a bi-directional tunnel between the 224 PAR and NAR is established prior to the MN's attachment to the NAR. 225 In the reactive mode, this tunnel establishment takes place after the 226 MN attaches to the NAR. In order to eliminate the packet loss during 227 a MN's handover (especially when the MN is detached from both links), 228 the downlink packets for the MN need to be buffered either at the PAR 229 (PMAG) or NAR (NMAG), depending on when the packet forwarding is 230 performed. It is hence required that all MAGs have the capability 231 and enough resources to buffer packets for the MNs accommodated by 232 them. Note that the protocol operation specified in the document is 233 transparent to the LMA, hence there is no new functional requirement 234 or change on the LMA. 236 Since the MN is not involved in IP mobility signaling in PMIPv6, the 237 sequence of events illustrating the predictive fast handover are 238 shown in Figure 2. 240 PMAG NMAG 241 MN P-AN N-AN (PAR) (NAR) LMA 242 | | | | | | 243 | Report | | | | | 244 (a) |-(MN ID,-->| | | | | 245 | New AP ID)| | | | | 246 | | HO Initiate | | | 247 (b) | |--(MN ID, New AP ID)-->| | | 248 | | | | | | 249 | | | | HI | | 250 (c) | | | |-(MN ID, ->| | 251 | | | | MN IID, LMAA) | 252 | | | | | | 253 (d) | | | |<---HAck---| | 254 | | | | (MN ID) | | 255 | | | | | | 256 | | | |HI/HAck(optional) | 257 (e) | | | |<- - - - ->| | 258 | | | #=|<===================| 259 (f) | | | #====DL data=>| | 260 | | | | | | 261 (g) ~~~ | | | | | 262 ~~~ | | | | | 263 | MN-AN connection | AN-MAG connection | | 264 (h) |<---establishment---->|<----establishment----->| | 265 | | | (substitute for UNA) | | 266 | | | | | | 267 (i) |<==================DL data=====================| | 268 | | | | | | 269 (j) |===================UL data====================>|=# | 270 | | | #=|<============# | 271 | | | #=====================>| 272 / | | | | | | \ 273 |(k) | | | | |--PBU-->| | 274 | | | | | | | | 275 |(l) | | | | |<--PBA--| | 276 \ | | | | | | / 278 Figure 2: Predictive fast handover for PMIPv6 (PAR initiated) 280 The detailed descriptions are as follows: 282 (a) The MN detects that a handover is imminent and reports the 283 identifications of itself (MN ID) and the access point (New AP 284 ID) to which the MN is most likely to move. The MN ID could be 285 the NAI or a Link Layer Address (LLA), or any other suitable 286 identifier. This step is access technology specific. In some 287 cases, the P-AN will determine which AP ID the MN is moving to. 289 (b) The previous access network (P-AN), to which the MN is currently 290 attached, indicates the handover of the MN to the PAR (PMAG). 291 Detailed definition and specification of this message are 292 outside the scope of this document. 294 (c) The PAR sends the HI to the NAR. The HI message MUST include 295 the MN ID, the MN-HNP, the MN-IID and the address of the LMA 296 that is currently serving the MN. 298 (d) The NAR sends the HAck back to the PAR. 300 (e) If it is preferred that the timing of buffering or forwarding 301 should be later than step (c), the NAR may optionally request 302 the PAR at a later and appropriate time to buffer or forward 303 packets by setting U flag [RFC5268bis] or F flag in the HI 304 message, respectively. 306 (f) If the F flag is set in the previous step, a bi-directional 307 tunnel is established between the PAR and NAR and packets 308 destined for the MN are forwarded from the PAR to the NAR over 309 this tunnel. After decapsulation, those packets may be buffered 310 at the NAR. If the connection between the N-AN and NAR has 311 already been established, those packets may be forwarded towards 312 the N-AN, which then becomes responsible for them (e.g., 313 buffering or delivering depending on the condition of the MN's 314 attachment); this is access technology specific. 316 (g) The MN undergoes handover to the New Access Network (N-AN). 318 (h) The MN establishes a physical link connection with the N-AN 319 (e.g., radio channel assignment), which in turn triggers the 320 establishment of a link-layer connection between the N-AN and 321 NAR if not yet established. An IP layer connection setup may be 322 performed at this time (e.g., PPP IPv6CP) or at a later time 323 (e.g., stateful or stateless auto address configuration). This 324 step can be a substitute for the UNA in [RFC5268bis], but since 325 they are all access technology specific, details are outside the 326 scope of this document. 328 (i) The NAR starts to forward packets destined for the MN via the 329 N-AN. 331 (j) The uplink packets from the MN are sent to the NAR via the N-AN 332 and the NAR forwards them to the PAR. The PAR then sends the 333 packets to the LMA that is currently serving the MN. 335 (k) The NAR (NMAG) sends the Proxy Binding Update (PBU) to the LMA, 336 whose address is provided in (c). Steps (k) and (l) are not 337 part of the fast handover procedure, but shown for reference. 339 (l) The LMA sends back the Proxy Binding Acknowledgment (PBA) to the 340 NAR (NMAG). From this time on, the packets to/from the MN go 341 through the NAR instead of the PAR. 343 According to Section 4 of [RFC5268bis], the PAR establishes a binding 344 between the PCoA and NCoA to forward packets for the MN to the NAR, 345 and the NAR creates a proxy NCE to receive those packets for the NCoA 346 before the MN arrives. In the case of PMIPv6, however, the only 347 address that is used by the MN is MN-HoA. Hence the PAR forwards 348 MN's packets to the NAR instead of the NCoA. FMIPv4 [RFC4988] 349 specifies forwarding when the MN uses HoA as its on-link address 350 rather than the care-of address. The usage in PMIPv6 is similar to 351 that in FMIPv4, where the address is used by the MN is based on Home 352 Network Prefix. Hence the PAR forwards MN's packets to the NAR 353 instead of the NCoA. The NAR then simply decapsulates those packets 354 and delivers them to the MN. Since the NAR obtains the LLA (MN IID) 355 and MN-HNP by the HI, it can create the NCE for the MN and deliver 356 packets to it even before the MN can perform Neighbor Discovery. For 357 the uplink packets from the MN after handover in (j), the NAR 358 forwards the packets to the PAR through the tunnel established in 359 step (f). The PAR then decapsulates and sends them to the LMA. 361 The timing of the context transfer and that of packet forwarding may 362 be different. Thus, a new flag 'F' and Option Code values for it in 363 the HI and HAck messages are defined to request forwarding. To 364 request buffering, 'U' flag has already been defined in [RFC5268bis]. 365 If the PAR receives the HI message with the F flag set, it starts 366 forwarding packets for the MN. The HI message with the U flag set 367 may be sent earlier if the timing of buffering is different from that 368 of forwarding. If packet forwarding is completed, the PAR MAY send 369 the HI message with the F flag set and the Option Code value being 1. 370 By this message, the ARs on both ends can tear down the forwarding 371 tunnel synchronously. 373 The IP addresses in the headers of those user packets are summarized 374 below: 376 In (f), 378 Inner source address: IP address of the CN 379 Inner destination address: HNP or IPv4-MN-HoA 381 Outer source address: IP address of the PAR (PMAG) 383 Outer destination address: IP address of the NAR (NMAG) 385 In (i), 387 Source address: IP address of the CN 389 Destination address: HNP or IPv4-MN-HoA 391 In (j), 393 - from the MN to the NMAG, 395 Source address: HNP or IPv4-MN-HoA 397 Destination address: IP address of the CN 399 - from the NMAG to the PMAG, 401 Inner source address: HNP or IPv4-MN-HoA 403 Inner destination address: IP address of the CN 405 Outer source address: IP address of the NAR (NMAG) 407 Outer destination address: IP address of the PAR (PMAG) 409 - from the PMAG to the LMA, 411 Inner source address: HNP or IPv4-MN-HoA 413 Inner destination address: IP address of the CN 415 Outer source address: IP address of the PAR (PMAG) 417 Outer destination address: IP address of the LMA 419 The encapsulation type for these user packets SHOULD follow that used 420 in the tunnel between the LMA and MAG (IPv6-in-IPv6, IPv6-in-IPv4, 421 IPv6-in-IPv4-UDP, IPv6-in-IPv4-UDP-TLV as specified in [RFC5213], GRE 422 as specified in [GREKEY] or any new method defined in the future). 424 In the case of the reactive handover for PMIPv6, since the MN does 425 not send either the FBU or UNA, it would be more natural that the NAR 426 sends the HI to the PAR after the MN has moved to the new link. The 427 NAR then needs to obtain the information of the PAR beforehand. Such 428 information could be provided, for example, by the MN sending the 429 AP-ID on the old link and/or by the lower-layer procedures between 430 the P-AN and N-AN. The exact method is not specified in this 431 document. Figure 3 illustrates the reactive fast handover procedures 432 for PMIPv6, where the bi-directional tunnel establishment is 433 initiated by the NAR. 435 PMAG NMAG 436 MN P-AN N-AN (PAR) (NAR) LMA 437 | | | | | | 438 (a) ~~~ | | | | | 439 ~~~ | | | | | 440 | MN-AN connection | AN-MAG connection | | 441 (b) |<--establishment-->|<-------establishment------>| | 442 |(MN ID, Old AP ID) | (MN ID, Old AP ID) | | 443 | | |(substitute for UNA and FBU)| | 444 | | | | | | 445 | | | | HI | | 446 (c) | | | |<---(MN ID) ---| | 447 | | | | | | 448 | | | | HAck | | 449 (d) | | | |---(MN ID, --->| | 450 | | | | MN IID, LMAA) | | 451 | | | | | | 452 (e) | | | #=|<=======================| 453 | | | #================>|=# | 454 |<====================DL data======================# | 455 | | | | | | 456 (f) |=====================UL data===================>|=# | 457 | | | #=|<================# | 458 | | | #=========================>| 459 | | | | | | 460 / | | | | | | \ 461 |(g) | | | | |--PBU-->| | 462 | | | | | | | | 463 |(h) | | | | |<--PBA--| | 464 \ | | | | | | / 466 Figure 3: Reactive fast handover for PMIPv6 (NAR initiated) 468 The detailed descriptions are as follows: 470 (a) The MN undergoes handover from the P-AN to the N-AN. The AP-ID 471 on the old link may be provided by the MN to help identify the 472 PMAG on the new link. 474 (b) The MN establishes a connection (e.g., radio channel) with the 475 N-AN, which triggers the establishment of the connection between 476 the N-AN and NAR. The MN ID is transferred to the NAR for the 477 subsequent procedures. The AP-ID on the old link may also be 478 provided by the MN to help identify the PMAG on the new link. 479 This can be regarded as a substitute for the UNA and FBU. 481 (c) The NAR sends the HI to the PAR. The HI message MUST include 482 the MN ID. The Context Request Option MAY be included to 483 request additional context information on the MN to the PAR. 485 (d) The PAR sends the HAck back to the NAR. The HAck message MUST 486 include the HNP and/or IPv4-MN-HoA that is corresponding to the 487 MN ID in the HI message and SHOULD include the MN-IID and the 488 LMA address that is currently serving the MN. The context 489 information requested by the NAR MUST be included. If the 490 requested context is not available for some reason, the PAR MUST 491 return the HAck with the Code value 131. If the F flag is set 492 in the HI at step (c) and forwarding is nevertheless not 493 executable for some reason, the PAR MUST return the HAck with 494 the Code value 132. 496 (e) If the F flag in the HI is set at step (c), a bi-directional 497 tunnel is established between the PAR and NAR and packets 498 destined for the MN are forwarded from the PAR to the NAR over 499 this tunnel. After decapsulation, those packets are delivered 500 to the MN via the N-AN. 502 (f) The uplink packets from the MN are sent to the NAR via the N-AN 503 and the NAR forwards them to the PAR. The PAR then sends the 504 packets to the LMA that is currently serving the MN. 506 Steps (g)-(h) are the same as (k)-(l) in the predictive fast handover 507 procedures. 509 In step (c), The IP address of the PAR needs to be resolved by the 510 NAR to send the HI to the PAR. This information may come from the 511 N-AN or some database that the NAR can access. 513 4.2. Inter-AR Tunneling Operation 515 When the PMAG (PAR) or NMAG (NAR), depending on the fast handover 516 mode, receives the HI message with the F flag set, it prepares to 517 send/receive the MN's packets to/from the other MAG and returns the 518 HAck message with the same sequence number. The necessary 519 information MUST be transferred in the HI message to distinguish MN's 520 packets for forwarding in advance or at this time. Such information 521 includes the HoA of the MN and/or GRE key(s). For the downlink 522 packets, the PMAG redirects MN's packets from the LMA towards the 523 NMAG and if the MN is ready to receive those packets or the N-AN can 524 handle them regardless of the state of the MN, the NAR should 525 immediately send them towards the N-AN; otherwise it should buffer 526 them until the MN is ready. For the uplink packets, the NMAG SHOULD 527 reverse-tunnel them from the MN towards the PMAG and the PMAG sends 528 them to the LMA. 530 When the PMAG or NMAG receives the HI message with the U flag set, it 531 prepares to buffer the MN's packets and returns the HAck message with 532 the same sequence number. It MUST be followed by another HI message 533 with the F flag set at an appropriate time to forward the buffered 534 packets. 536 If the MAG that received the HI message encounters an erroneous 537 situation (e.g., insufficient buffer space), it SHOULD immediately 538 send the HAck message with the cause of the error and cancel all 539 tunneling operation. 541 4.3. IPv4 Support Considerations 543 The motivation and usage scenarios of IPv4 protocol support by PMIPv6 544 are described in [IPv4PMIPv6]. The scope of IPv4 support covers the 545 following two features: 547 o IPv4 Home Address Mobility Support, and 549 o IPv4 Transport Support. 551 As for IPv4 Home Address Mobility Support, the MN acquires IPv4 Home 552 Address (IPv4-MN-HoA) and in the case of handover, the PMAG needs to 553 transfer IPv4-MN-HoA to the NMAG, which is the inner destination 554 address of the packets forwarded on the downlink. For this purpose, 555 a new option called IPv4 Address Option is defined in this document. 556 In order to provide IPv4 Transport Support, the NMAG needs to know 557 the IPv4 address of the LMA (IPv4-LMAA) to send PMIPv6 signaling 558 messages to the LMA in the IPv4 transport network. In this case, a 559 new option called LMA Address (LMAA) option is used so as to convey 560 IPv4-LMAA from the PMAG to NMAG. The supported encapsulation type 561 follows Section 6.10.2 in [RFC5213], that is, IPv4, IPv4-UDP and 562 IPv4-UDP-TLV. 564 5. PMIPv6-related Fast Handover Issues 566 The protocol specified in this document enables the NMAG to obtain 567 parameters which would otherwise be available only by communicating 568 with the LMA. For instance, the HNP and/or IPv4-MN-HoA of a MN are 569 made available to the NMAG through context transfer. This allows the 570 NMAG to perform some procedures that may be beneficial. For 571 instance, the NMAG could send a Router Advertisement (RA) with the 572 HNP option to the MN as soon as its link attachment is detected 573 (e.g., via receipt of a Router Solicitation message). Such an RA is 574 recommended, for example, in scenarios where the MN uses a new radio 575 interface while attaching to the NMAG; since the MN does not have 576 information regarding the new interface, it will not be able to 577 immediately send packets without first receiving an RA with HNP. 578 Especially, in the reactive fast handover, the NMAG gets to know the 579 HNP assigned to the MN on the previous link at step (d) in Figure 3. 580 In order to reduce the communication disruption time, the NMAG SHOULD 581 expect the MN to keep using the same HNP and to send uplink packets 582 before that step upon the MN's request. However, if the HAck from 583 the PMAG returns a different HNP or the subsequent PMIPv6 binding 584 registration for the HNP fails for some reason, then the NMAG MUST 585 withdraw the advertised HNP by sending another RA with zero prefix 586 lifetime for the HNP in question. This operation is the same as 587 described in Section 6.12 of [RFC5213]. 589 The protocol specified in this document is applicable regardless of 590 whether link-layer addresses are used between a MN and its access 591 router. A MN should be able to continue sending packets on the 592 uplink even when it changes link. When link-layer addresses are 593 used, the MN performs Neighbor Unreachability Detection (NUD) 594 [RFC4861], after attaching to a new link, probing the reachability of 595 its default router. If the new router's interface is configured to 596 respond to queries sent to link-layer addresses than its own (e.g., 597 set to promiscuous mode), then it can respond to the NUD probe, 598 providing its link-layer address in the solicited Neighbor 599 Advertisement. Implementations should allow the MN to continue to 600 send uplink packets while it is performing NUD. 602 6. Message Formats 604 This document defines new Mobility Header messages for the extended 605 HI and Hack and new mobility options for conveying context 606 information. 608 6.1. Mobility Header 610 6.1.1. Handover Initiate (HI) 612 This section defines extensions to the HI message in [RFC5268bis]. 613 The format of the Message Data field in the Mobility Header is as 614 follows: 616 0 1 2 3 617 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 618 +-------------------------------+ 619 | Sequence # | 620 +-+-+-+-+-------+---------------+-------------------------------+ 621 |S|U|P|F|Resv'd | Code | | 622 +-+-+-+-+-------+---------------+ | 623 | | 624 . . 625 . Mobility options . 626 . . 627 | | 628 +---------------------------------------------------------------+ 630 IP Fields: 632 Source Address 634 The IP address of PMAG or NMAG 636 Destination Address 638 The IP address of the peer MAG 640 Message Data: 642 Sequence # Same as [RFC5268bis]. 644 S flag Defined in [RFC5268bis] and MUST be set to zero in this 645 specification. 647 U flag Buffer flag. Same as [RFC5268bis]. 649 P flag Proxy flag. Used to distinguish the message from that 650 defined in [RFC5268bis] and to indicate that it follows 651 the specification in this document. 653 F flag Forwarding flag. Used to request to forward the packets 654 for the MN. 656 Reserved Same as [RFC5268bis]. 658 Code [RFC5268bis] defines this field and its values 0 and 1. 659 In this specification, with the P flag set, this field 660 can be set to zero by default or the following values: 662 1: Indicate the completion of forwarding 664 2: All available context transferred 666 Code value 2 is set when the transfer of all necessary 667 context information is completed with this message. This 668 Code value is used in both cases where the context 669 information is fragmented into several pieces and the 670 last fragment is contained in this message and where the 671 whole information is transferred in one piece. 673 Mobility options: 675 This field contains one or more mobility options, whose encoding and 676 formats are defined in [RFC3775]. At least one mobility option MUST 677 uniquely identify the target MN (e.g., the Mobile Node Identifier 678 Option defined in RFC4283) and the transferred context MUST be for 679 one MN per message. In addition, the NAR can request necessary 680 mobility options by the Context Request Option defined in this 681 document. 683 Context Request Option 685 This option MAY be present to request context information 686 typically by the NAR to the PAR in the NAR-initiated fast 687 handover. 689 6.1.2. Handover Acknowledge (HAck) 691 This section defines extensions to the HAck message in[RFC5268bis]. 692 The format of the Message Data field in the Mobility Header is as 693 follows: 695 0 1 2 3 696 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 697 +-------------------------------+ 698 | Sequence # | 699 +-+-+-+---------+---------------+-------------------------------+ 700 |U|P|F|Reserved | Code | | 701 +-+-+-+---------+---------------+ | 702 | | 703 . . 704 . Mobility options . 705 . . 706 | | 707 +---------------------------------------------------------------+ 709 IP Fields: 711 Source Address 713 Copied from the destination address of the 714 Handover Initiate message to which this message 715 is a response. 717 Destination Address 719 Copied from the source address of the Handover 720 Initiate message to which this message is a 721 response. 723 Message Data: 725 The usages of Sequence # and Reserved fields are exactly the same as 726 those in [RFC5268bis]. 728 U flag Same as defined in Section 6.1.1. 730 P flag Used to distinguish the message from that defined in 731 [RFC5268bis] and to indicate that it follows the 732 specification in this document. 734 F flag Same as defined in Section 6.1.1. 736 Code 737 Code values 0 through 4 and 128 through 130 are defined 738 in [RFC5268bis]. In this specification, the meaning of 739 Code value 0 is modified, 128 through 130 are reused, and 740 5, 6, 131 and 132 are newly defined. 742 0: Handover Accepted or Successful 744 5: Context Transfer Accepted or Successful 746 6: All available Context Transferred 748 128: Handover Not Accepted, reason unspecified 750 129: Administratively prohibited 752 130: Insufficient resources 754 131: Requested Context Not Available 756 132: Forwarding Not Available 758 Mobility options: 760 This field contains one or more mobility options, whose encoding and 761 formats are defined in [RFC3775]. The mobility option that uniquely 762 identifies the target MN MUST be copied from the corresponding HI 763 message and the transferred context MUST be for one MN per message. 765 Requested option(s) All the context information requested by the 766 Context Request Option in the HI message SHOULD be present 767 in the HAck message. The other cases are described below. 769 In the case of the PAR-initiated fast handover, when the PAR sends 770 the HI message to the NAR with the context information and the NAR 771 successfully receives it, the NAR returns the HAck message with Code 772 value 5. In the case of the NAR-initiated fast handover, when the 773 NAR sends the HI message to the PAR with or without Context Request 774 Option, the PAR returns the HAck message with the requested or 775 default context information (if any). If all available context 776 information is transferred, the PAR sets the Code value in the HAck 777 message to 6. If more context information is available, the PAR sets 778 the Code value in the HAck to 5 and the NAR MAY send new HI 779 message(s) to retrieve the rest of the available context information. 780 If none of the requested context information is available, the PAR 781 returns the HAck message with Code value 131 without any context 782 information. 784 6.2. Mobility Options 786 6.2.1. Context Request Option 788 This option is sent in the HI message to request context information 789 on the MN. If a default set of context information is defined and 790 always sufficient, this option is not mandatory. This option is more 791 useful to retrieve additional or dynamically selected context 792 information. 794 Context Request Option is typically used for the reactive (NAR- 795 initiated) fast handover mode to retrieve the context information 796 from the PAR. When this option is included in the HI message, all 797 the requested context information SHOULD be included in the HAck 798 message in the corresponding mobility option(s) (e.g., HNP, LMAA or 799 MN-IID mobility options). 801 0 1 2 3 802 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 803 +---------------+---------------+---------------+---------------+ 804 | Option-Type | Option-Length | Reserved | 805 +---------------+---------------+-------------------------------+ 806 | Req-type-1 | Req-length-1 | Req-type-2 | Req-length-2 | 807 +---------------------------------------------------------------+ 808 | ... | 810 Option-Type TBD1 812 Option-Length The length in octets of this option, not including the 813 Option Type and Option Length fields. 815 Reserved This field is unused. It MUST be initialized to zero 816 by the sender and MUST be ignored by the receiver. 818 Req-type-n The type value for the n'th requested option. 820 Req-length-n The length of the n'th requested option excluding the 821 Req-type-n and Req-length-n fields. 823 In the case where there are only Req-type-n and Req-length-n fields, 824 the value of the Req-length-n is set to zero. If additional 825 information besides the Req-type-n is necessary to uniquely specify 826 the requested context, such information follows after the 827 Req-length-n. For example, when the requested context is the Vendor- 828 Specific Option described in Section 6.2.8, the requested option 829 format looks as follows: 831 | ... | 832 +---------------+---------------+-------------------------------+ 833 | Req-type-N=19 | Req-length-N=5| Vendor-ID | 834 +-------------------------------+---------------+---------------+ 835 | Vendor-ID | Sub-Type | | 836 +-----------------------------------------------+ | 837 | ... | 839 The exact values in the Vendor-ID and Sub-Type are outside the scope 840 of this document. 842 6.2.2. Local Mobility Anchor Address (LMAA) Option 844 This option is used to transfer the Local Mobility Anchor IPv6 845 Address (LMAA) or its IPv4 Address (IPv4-LMAA), with which the MN is 846 currently registered. The detailed definition of the LMAA is 847 described in [RFC5213]. 849 0 1 2 3 850 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 851 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 852 | Option-Type | Option-Length | Option-Code | Reserved | 853 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 854 | Local Mobility Anchor Address ... | 856 Option-Type TBD2 858 Option-Length 18 or 6 860 Option-Code 862 0 Reserved 864 1 IPv6 address of the LMA (LMAA) 866 2 IPv4 address of the LMA (IPv4-LMAA) 868 Reserved This field is unused. It MUST be initialized to zero 869 by the sender and MUST be ignored by the receiver. 871 Local Mobility Anchor Address 872 If Option-Code is 1, the LMA IPv6 address (LMAA) is 873 inserted. If Option-Code is 2, the LMA IPv4 address 874 (IPv4-LMA) is inserted. 876 6.2.3. Mobile Node Interface Identifier (MN IID) Option 878 This option is used to transfer the interface identifier of the MN 879 that is used in the P-AN. 881 0 1 2 3 882 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 883 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 884 | Option-Type | Option-Length | Reserved | 885 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 886 | | 887 + Interface Identifier + 888 | | 889 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 891 Option-Type TBD3 893 Option-Length 10 895 Reserved This field is unused. It MUST be initialized to zero 896 by the sender and MUST be ignored by the receiver. 898 Interface Identifier 899 The Interface Identifier value of the MN that is used 900 in the P-AN. 902 6.2.4. Home Network Prefix Option 904 This option is used to transfer the home network prefix that is 905 assigned to the MN in the P-AN. The Home Network Prefix Option 906 defined in [RFC5213] is used for this. 908 6.2.5. Link-local Address Option 910 This option is used to transfer the link-local address of the PAR 911 (PMAG). The Link-local Address Option defined in [RFC5213] is used 912 for this. 914 6.2.6. GRE Key Option 916 This option is used to transfer the GRE Key for the MN's data flow 917 over the bi-directional tunnel between the PAR and NAR. The message 918 format of this option follows the GRE Key Option defined in [GREKEY]. 919 The GRE Key value uniquely identifies each flow and the sender of 920 this option expects to receive packets of the flow from the peer AR 921 with this value. 923 6.2.7. IPv4 Address Option 925 As described in Section 4.3, if the MN runs in IPv4-only mode or 926 dual-stack mode, it requires IPv4 home address (IPv4-MN-HoA). This 927 option is used to transfer the IPv4 home address if assigned on the 928 previous link. The format of this option follows the IPv4 Home 929 Address Option defined in [RFC5555]. 931 6.2.8. Vendor-Specific Mobility Option 933 This option is used to transfer any other information defined in this 934 document. The format of this option follows the Vendor-Specific 935 Mobility Option defined in [RFC5094]. The exact values in the Vendor 936 ID, Sub-Type and Data fields are outside the scope of this document. 938 7. Security Considerations 940 Security issues for this document follow those for PMIPv6 [RFC5213] 941 and FMIPv6 [RFC5268bis]. In PMIPv6, the MAG and LMA are assumed to 942 share security associations. In FMIPv6, the access routers (i.e., 943 the PMAG and NMAG in this document) are assumed to share security 944 associations. 946 The Handover Initiate (HI) and Handover Acknowledgement (HAck) 947 messages exchanged between the PMAG and NMAG MUST be protected using 948 end-to-end security association(s) offering integrity and data origin 949 authentication. The PMAG and the NMAG MUST implement IPsec [RFC4301] 950 for protecting the HI and HAck messages. IPsec Encapsulating 951 Security Payload (ESP) [RFC4303] in transport mode with mandatory 952 integrity protection SHOULD be used for protecting the signaling 953 messages. Confidentiality protection SHOULD be used if sensitive 954 context related to the mobile node is transferred. 956 IPsec ESP [RFC4303] in tunnel mode MAY be used to protect the MN's 957 packets at the time of forwarding if protection of data traffic is 958 required. 960 8. IANA Considerations 962 This document defines four new mobility options, which are described 963 in Section 6.2. The Type value for these options are assigned from 964 the same numbering space as allocated for the other mobility options, 965 as defined in [RFC3775]. 967 Mobility Options 968 Value Description Reference 969 ----- ------------------------------------- ------------- 970 TBD1 Context Request Option Section 6.2.1 971 TBD2 Local Nobility Anchor Address Option Section 6.2.2 972 TBD3 Mobile Node Interface Identifier Option Section 6.2.3 974 9. Acknowledgments 976 The authors would like to specially thank Vijay Devarapalli and Sri 977 Gundavelli for their thorough reviews of this document. 979 The authors would also like to thank Charlie Perkins, Desire Oulai, 980 Ahmad Muhanna, Giaretta Gerardo, Domagoj Premec, Marco Liebsch, Fan 981 Zhao, Julien Laganier and Pierrick Seite for their passionate 982 discussions in the working group mailing list. 984 10. References 986 10.1. Normative References 988 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 989 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 991 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 992 Requirement Levels", BCP 14, RFC 2119, March 1997. 994 [RFC5268bis] 995 Koodli, R., Ed., "Mobile IPv6 Fast Handovers", 996 draft-ietf-mipshop-rfc5268bis-01.txt, March 2009. 998 [RFC3775] Johnson, D., "Mobility Support in IPv6", RFC 3775, 999 June 2004. 1001 [RFC4988] Koodli, R. and C. Perkins, "Mobile IPv4 Fast Handovers", 1002 RFC 4988, October 2007. 1004 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1005 Internet Protocol", RFC 4301, December 2005. 1007 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 1008 RFC 4303, December 2005. 1010 [RFC5094] Devarapalli, V., Patel, A., and K. Leung, "Mobile IPv6 1011 Vendor Specific Option", RFC 5094, December 2007. 1013 [RFC5555] Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and 1014 Routers", RFC 5555, June 2009. 1016 10.2. Informative References 1018 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 1019 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 1020 September 2007. 1022 [IPv4PMIPv6] 1023 Wakikawa, R., Ed. and S. Gundavelli, "IPv4 Support for 1024 Proxy Mobile IPv6", 1025 draft-ietf-netlmm-pmip6-ipv4-support-13.txt, June 2009. 1027 [GREKEY] Muhanna, A., Ed., "GRE Key Option for Proxy Mobile IPv6", 1028 draft-ietf-netlmm-grekey-option-09.txt, May 2009. 1030 Appendix A. Applicable Use Cases 1032 A.1. PMIPv6 Handoff Indication 1034 PMIPv6 [RFC5213] defines the Handoff Indicator Option and describes 1035 the type of the handoff and the values to set to the option. This 1036 document proposes one approach to determining the handoff type by the 1037 NMAG when the handoff of the MN is executed. 1039 According to [RFC5213], the following handoff types are defined: 1041 0) Reserved 1043 1) Attachment over a new interface 1045 2) Handoff between two different interfaces of the mobile node 1047 3) Handoff between mobile access gateways for the same interface 1049 4) Handoff state unknown 1051 5) Handoff state not changed (Re-registration) 1053 By using the MN Interface Identifier (MN IID) option, which is 1054 defined in this document, the following solution can be considered. 1055 When the NMAG receives the MN IID used in the P-AN from the PMAG via 1056 the HI or HAck messages, the NMAG compares it with the new MN IID 1057 that is obtained from the MN in the N-AN. If these two MN IIDs are 1058 the same, the handover type falls into 3) and the Handoff Indicator 1059 value is set to 3. If these two MN IIDs are different, the handover 1060 is likely to be 2) since the HI/HAck message exchange implies that 1061 this is a handover not a multi-homing, therefore the Handoff 1062 Indicator value can be set to 2. If there is no HI/HAck exchange 1063 performed prior to the network attachment of the MN in the new 1064 network, the NMAG may infer that this is a multi-homing case and set 1065 the Handoff Indicator value to 1. In the case of re-registration, 1066 the MAG, to which the MN is attached, can determine if the handoff 1067 state is not changed, so the MAG can set the HI value to 5 without 1068 any additional information. If none of them can be assumed, the NMAG 1069 may set the value to 4. 1071 A.2. Local Routing 1073 Section 6.10.3 in [RFC5213] describes that if EnableMAGLocalRouting 1074 flag is set, when two mobile nodes are attached to one MAG, the 1075 traffic between them may be locally routed. If one mobile node moves 1076 from this MAG (PMAG) to another MAG (NMAG) and if the PMAG does not 1077 detect the MN's detachment, it will continue to forward packets 1078 locally forever. This situation is more likely to happen in the 1079 reactive fast handover with WLAN access, which does not have the 1080 capability to detect the detachment of the MN in a timely manner. 1081 PFMIPv6 can be applied to handle this case. When the MN attaches to 1082 the NMAG, it sends the HI message to the PMAG, which makes it realize 1083 the detachment of the MN. The PMAG immediately stops the local 1084 routing and sends the packets for the MN towards the LMA, which in 1085 turn forwards them to the NMAG over the PMIPv6 tunnel. 1087 Appendix B. Change Log 1089 Changes at -00 1091 * Added separate sections for MH and ICMP. 1093 * Clarified usage of HNP and IPv4-MN-HoA throughout the document. 1095 * Added IANA Considerations. 1097 * Added section on Other Considerations, including operation of 1098 uplink packets when using link-layer addresses, multiple 1099 interface usage and transmission of RA to withdraw HNP in the 1100 event of failure of PMIP6 registration. 1102 * Revised Security Considerations. 1104 Changes from -00 to -01 1106 * Removed ICMPv6-based message format. 1108 * Clarified HI/HAck exchange in the predictive mode (step (e) in 1109 Figure 2). 1111 * Clarified information retrieval about the PMAG in the reactive 1112 mode. 1114 * Removed the extension to the GRE Key Option. 1116 * Clarified the handoff type considerations in Appendix A. 1118 * Home Network Prefix Option, Link-local Address Option and 1119 Vendor-Specific Mobility Option are added. 1121 Changes from -01 to -02 1123 * Aligned HI/HAck message formats with [RFC5268bis] 1124 (draft-ietf-mipshop-rfc5268bis-00.txt). 1126 * Revised Section 8 removing the request for the type assignment 1127 of HI/HAck Mobility Headers. 1129 Changes from -02 to -03 1131 * Updated HI/HAck message formats according to 1132 draft-ietf-mipshop-rfc5268bis-01.txt. 1134 * Cleaned up Figure 2 and Figure 3. 1136 * Moved PMIP domain boundary crossing situation in Section 4.1 to 1137 Appendix A.3. 1139 * Removed the alternative protocol operation with an unsolicited 1140 HAck from Section 4.1. 1142 * Modified Code values in the HAck message in order to avoid 1143 collision with those in [RFC5268bis]. 1145 * Clarified the usage scenarios of Context Request Option. 1147 * Modified the description of Code values in the HAck message. 1149 * Changed the container for the IPv4-LMAA from IPv4 Address 1150 option to the LMAA option. 1152 * Made Confidentiality protection "SHOULD" for context transfer. 1154 Changes from -03 to -04 1156 * Added more explanations about MIPv6, FMIPv6 and PMIPv6 in 1157 Abstract. 1159 * Moved Figure 1 to Section 4. 1161 * More clearly indicated the FMIPv6 messages that are not 1162 applicable in the PMIPv6 context. 1164 * Mandated the support of IP Sec on the PMAG and NMAG in order to 1165 protect signaling and user packets and the context information. 1167 * Added a new section for the inter-AR tunneling operation 1168 (Section 4.2). 1170 * Added descriptions about the encapsulation type in Sections 4.1 1171 and 4.3. 1173 * Added a description about buffering requirements on the MAG in 1174 Section 4.1. 1176 * Added a description about the timing of L2 and L3 connection 1177 establishments in Section 4.1. 1179 * Added a new section for PMIPv6-related fast handover issues 1180 (Section 5) and a description about preferable behaviors of the 1181 MN and MAG to reduce packet loss. 1183 * Added Acknowledgments section (Section 9). 1185 * Added a new section for local routing in Appendix (A.2). 1187 Changes from -04 to -05 1189 * Fixed Figure 2 (step (i)). 1191 * Defined the Mobile Network Interface Identifier (MN-IID) 1192 mobility option in Section 6.2.4 (swapped with old Section 1193 6.2.5), and added it to IANA considerations (Section 8). 1195 * Changed from SHOULD to MUST regarding the inclusion of the 1196 MN-ID, MN-HNP, MN-IID and the LMAA options in the HI message 1197 (step (c) in Section 4.1). 1199 * The optional behavior of the NMAG that allows it to send uplink 1200 packets directly to the LMA before the PBU/PBA exchange was 1201 removed from section 4.2 (as out of scope). 1203 * In Section A.3, the description about the HA address assignment 1204 from the NAR to the MN was removed (as out of scope). 1206 Changes from -05 to -06 1208 * Added 'P' flag in the HI and Hack messages to distinguish them 1209 from those in FMIPv6. 1211 * Made editorial corrections in Section 2 (Introduction), Section 1212 3 (Terminology), Section 4 (Protocol Overview) and Section 4.2 1213 (Inter-AR Tunneling Operation). 1215 * Added a description on how forwarded packets should be handled 1216 in the access network at step (f) in Section 4.1. 1218 * Added all types of encapsulation methods that should be 1219 supported in Section 4.1. 1221 * Revised the Code values for the HI message in Section 6.1.1. 1223 * Revised the Code values for the HAck message in Section 6.1.2 1224 and added a description of its usage at step (d) of the 1225 reactive handover mode in Section 4.1. 1227 * Removed the definition of the IP Address Option in Section 1228 6.2.3 and moved to Section 6.2.7, which currently refers to the 1229 IPv4 Home Address Option defined by RFC5555. Revised the IANA 1230 Consideration section accordingly. 1232 * Removed the Option-Code from the Mobile Node Identifier (MN 1233 IID) Option. 1235 * Removed Appendix A.3 (Handling of PMIPv6/MIPv6 switching). 1237 Authors' Addresses 1239 Hidetoshi Yokota 1240 KDDI Lab 1241 2-1-15 Ohara, Fujimino 1242 Saitama, 356-8502 1243 JP 1245 Email: yokota@kddilabs.jp 1247 Kuntal Chowdhury 1248 Starent Networks 1249 30 International Place 1250 Tewksbury, MA 01876 1251 US 1253 Email: kchowdhury@starentnetworks.com 1255 Rajeev Koodli 1256 Starent Networks 1257 30 International Place 1258 Tewksbury, MA 01876 1259 US 1261 Email: rkoodli@starentnetworks.com 1263 Basavaraj Patil 1264 Nokia 1265 6000 Connection Drive 1266 Irving, TX 75039 1267 US 1269 Email: basavaraj.patil@nokia.com 1271 Frank Xia 1272 Huawei USA 1273 1700 Alma Dr. Suite 500 1274 Plano, TX 75075 1275 US 1277 Email: xiayangsong@huawei.com