idnits 2.17.1 draft-ietf-mipshop-pfmipv6-04.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 (May 1, 2009) is 5466 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-12 == Outdated reference: A later version (-09) exists of draft-ietf-netlmm-grekey-option-08 Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group H. Yokota 3 Internet-Draft KDDI Lab 4 Intended status: Standards Track K. Chowdhury 5 Expires: November 2, 2009 R. Koodli 6 Starent Networks 7 B. Patil 8 Nokia 9 F. Xia 10 Huawei USA 11 May 1, 2009 13 Fast Handovers for Proxy Mobile IPv6 14 draft-ietf-mipshop-pfmipv6-04.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 November 2, 2009. 39 Copyright Notice 41 Copyright (c) 2009 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents in effect on the date of 46 publication of this document (http://trustee.ietf.org/license-info). 47 Please review these documents carefully, as they describe your rights 48 and restrictions with respect to this document. 50 Abstract 52 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. IPv4 Address Option . . . . . . . . . . . . . . . . . 22 89 6.2.4. Home Network Prefix Option . . . . . . . . . . . . . . 23 90 6.2.5. Mobile Node Interface Identifier (MN IID) Option . . . 23 91 6.2.6. Link-local Address Option . . . . . . . . . . . . . . 23 92 6.2.7. GRE Key Option . . . . . . . . . . . . . . . . . . . . 23 93 6.2.8. Vendor-Specific Mobility Option . . . . . . . . . . . 23 94 7. Security Considerations . . . . . . . . . . . . . . . . . . . 24 95 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 96 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 26 97 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 98 10.1. Normative References . . . . . . . . . . . . . . . . . . . 27 99 10.2. Informative References . . . . . . . . . . . . . . . . . . 27 100 Appendix A. Applicable Use Cases . . . . . . . . . . . . . . . . 28 101 A.1. PMIPv6 Handoff Indication . . . . . . . . . . . . . . . . 28 102 A.2. Local Routing . . . . . . . . . . . . . . . . . . . . . . 28 103 A.3. Handling of PMIPv6/MIPv6 switching . . . . . . . . . . . . 29 104 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 30 105 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33 107 1. Requirements notation 109 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 110 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 111 document are to be interpreted as described in [RFC2119]. 113 2. Introduction 115 Proxy Mobile IPv6 [RFC5213] provides IP mobility to a mobile node 116 that does not possess Mobile IPv6 [RFC3775] mobile node 117 functionality. A proxy agent in the network performs the mobility 118 management signaling on behalf of the mobile node. This model 119 transparently provides mobility for mobile nodes within a PMIPv6 120 domain. Nevertheless, the basic performance of PMIPv6 in terms of 121 handover latency and packet loss is considered not any different from 122 that of Mobile IPv6. 124 Fast Handovers for Mobile IPv6 (FMIPv6) [RFC5268bis] describes the 125 protocol to reduce the handover latency for Mobile IPv6 by allowing a 126 mobile node to send packets as soon as it detects a new subnet link 127 and by delivering packets to the mobile node as soon as its 128 attachment is detected by the new access router. This document 129 describes necessary extensions to FMIPv6 for operations in the PMIPv6 130 domain in order to minimize handover delay and packet loss as well as 131 to transfer network-resident contexts. 133 3. Terminology 135 This document reuses terminology from [RFC5213], [RFC5268bis] and 136 [RFC3775]. The following terms and abbreviations are additionally 137 used in this document. 139 Access Network (AN): 140 A network composed of link-layer access devices such as access 141 points or base stations providing access to the Access Router 142 (AR) connected to it. 144 Previous Access Network (P-AN): 145 The access network to which the MN is attached before handover. 147 New Access Network (N-AN): 148 The access network to which the MN is attached after handover. 150 Previous Mobile Access Gateway (PMAG): 151 The MAG that manages mobility related signaling for the MN 152 before handover. In this document, the MAG and the Access 153 Router are collocated. 155 New Mobile Access Gateway (NMAG): 156 The MAG that manages mobility related signaling for the MN after 157 handover. In this document, the MAG and the Access Router (AR) 158 are collocated. 160 HO-Initiate: 161 A generic signaling message that indicates the handover of the 162 MN sent from the P-AN to the PMAG. While this signaling is 163 dependent on the access technology, it is assumed that HO- 164 Initiate can carry the information to identify the MN and to 165 assist the PAR resolve the NAR (e.g., the new access point or 166 base station to which the MN is moving). Definition of details 167 in the specification of this message is outside the scope of 168 this document. 170 4. Proxy-based FMIPv6 Protocol Overview 172 In order to improve the performance during handover (when operations 173 such as attachment to a new network and signaling between mobility 174 agents are involved), the PFMIPv6 protocol in this document specifies 175 a bi-directional tunnel between the Previous MAG (PMAG) and the New 176 MAG (NMAG). In order to enable the NMAG to send the Proxy Binding 177 Update (PBU), the Handover Initiate (HI) and Handover Acknowledge 178 (HAck) messages in [RFC5268bis] are used for context transfer, in 179 which parameters such as MN's NAI, Home Network Prefix (HNP), IPv4 180 Home Address, are transferred from the PMAG. 182 In this document, the Previous Access Router (PAR) and New Access 183 Router (NAR) are interchangeable with the PMAG and NMAG, 184 respectively. The reference network is illustrated in Figure 1. 186 Since a MN is not directly involved with IP mobility protocol 187 operations, it follows that the MN is not directly involved with fast 188 handover procedures either. Hence, the messages involving the MN in 189 [RFC5268bis] are not used when PMIPv6 is in use. The Router 190 Solicitation for Proxy Advertisement (RtSolPr) and Proxy Router 191 Advertisement (PrRtAdv) are exchanged between the MN and PAR for the 192 MN to formulate the New Care-of Address (NCoA) in advance. Fast 193 Binding Update (FBU) and Fast Binding Acknowledgment (FBack) are also 194 exchanged between these nodes to request the PAR to forward packets 195 to the NAR. The Unsolicited Neighbor Advertisement (UNA) is sent 196 from the MN to NAR to forward the packets to the MN. These messages 197 are not applicable in the PMIPv6 context. 199 +----------+ 200 | LMA | 201 | | 202 +----------+ 203 / \ 204 / \ 205 / \ 206 +........../..+ +..\..........+ 207 . +-------+-+ .______. +-+-------+ . 208 . | PAR |()_______)| NAR | . 209 . | (PMAG) | . . | (NMAG) | . 210 . +----+----+ . . +----+----+ . 211 . | . . | . 212 . ___|___ . . ___|___ . 213 . / \ . . / \ . 214 . ( P-AN ) . . ( N-AN ) . 215 . \_______/ . . \_______/ . 216 . | . . | . 217 . +----+ . . +----+ . 218 . | MN | ----------> | MN | . 219 . +----+ . . +----+ . 220 +.............+ +.............+ 222 Figure 1: Reference network for fast handover 224 4.1. Protocol Operation 226 There are two modes of operation in FMIPv6 [RFC5268bis]. In the 227 predictive mode of fast handover, a bi-directional tunnel between the 228 PAR and NAR is established prior to the MN's attachment to the NAR. 229 In the reactive mode, this tunnel establishment takes place after the 230 MN attaches to the NAR. In order eliminate the packet loss during 231 MN's handover (especially when the MN is detached from both links), 232 the downlink packets for the MN need to be buffered either at the PAR 233 (PMAG) or NAR (NMAG), depending on when the packet forwarding is 234 performed. It is hence required that all MAGs have the capability 235 and enough resources to buffer packets for the MNs accommodated by 236 them. Note that the protocol operation specified in the document is 237 transparent to the LMA, hence there is no new functional requirement 238 or change on the LMA. 240 Since the MN is not involved in IP mobility signaling in PMIPv6, the 241 sequence of events illustrating the predictive fast handover are 242 shown in Figure 2. 244 PMAG NMAG 245 MN P-AN N-AN (PAR) (NAR) LMA 246 | | | | | | 247 | Report | | | | | 248 (a) |-(MN ID,-->| | | | | 249 | New AP ID)| | | | | 250 | | HO Initiate | | | 251 (b) | |--(MN ID, New AP ID)-->| | | 252 | | | | | | 253 | | | | HI | | 254 (c) | | | |-(MN ID, ->| | 255 | | | | MN IID, LMAA) | 256 | | | | | | 257 (d) | | | |<---HAck---| | 258 | | | | (MN ID) | | 259 | | | | | | 260 | | | |HI/HAck(optional) | 261 (e) | | | |<- - - - ->| | 262 | | | #=|<===================| 263 (f) | | | #====DL data=>| | 264 | | | | | | 265 (g) ~~~ | | | | | 266 ~~~ | | | | | 267 | MN-AN connection | AN-MAG connection | | 268 (h) |<---establishment---->|<----establishment----->| | 269 | | | (substitute for UNA) | | 270 | | | | | | 271 (i) |<==================DL data=====================|<=======| 272 | | | | | | 273 (j) |===================UL data====================>|=# | 274 | | | #=|<============# | 275 | | | #=====================>| 276 / | | | | | | \ 277 |(k) | | | | |--PBU-->| | 278 | | | | | | | | 279 |(l) | | | | |<--PBA--| | 280 \ | | | | | | / 282 Figure 2: Predictive fast handover for PMIPv6 (PAR initiated) 284 The detailed descriptions are as follows: 286 (a) The MN detects that a handover is imminent and reports the 287 identifications of itself (MN ID) and the access point (New AP 288 ID) to which the MN is most likely to move. The MN ID could be 289 the NAI or a Link Layer Address (LLA), or any other suitable 290 identifier. This step is access technology specific. In some 291 cases, the P-AN will determine which AP ID the MN is moving to. 293 (b) The previous access network (P-AN), to which the MN is currently 294 attached, indicates the handover of the MN to the PAR (PMAG). 295 Detailed definition and specification of this message are 296 outside the scope of this document. 298 (c) The PAR sends the HI to the NAR. The HI message MUST include 299 the MN ID and SHOULD include the MN-HNP, the MN-IID and the 300 address of the LMA that is currently serving the MN. 302 (d) The NAR sends the HAck back to the PAR. 304 (e) If it is preferred that the timing of buffering or forwarding 305 should be later than step (c), the NAR may optionally request 306 the PAR at a later and appropriate time to buffer or forward 307 packets by setting U flag [RFC5268bis] or F flag in the HI 308 message, respectively. 310 (f) If the F flag is set in the previous step, a bi-directional 311 tunnel is established between the PAR and NAR and packets 312 destined for the MN are forwarded from the PAR to the NAR over 313 this tunnel. After decapsulation, those packets may be buffered 314 at the NAR. If the connection between the N-AN and NAR has 315 already been established, those packet may be forwarded towards 316 the N-AN; this is access technology specific. 318 (g) The MN undergoes handover to the New Access Network (N-AN). 320 (h) The MN establishes a physical link connection with the N-AN 321 (e.g., radio channel assignment), which in turn triggers the 322 establishment of a link-layer connection between the N-AN and 323 NAR if not yet established. An IP layer connection setup may be 324 performed at this time (e.g., PPP IPv6CP) or at a later time 325 (e.g., stateful or stateless auto address configuration). This 326 step can be a substitute for the UNA in [RFC5268bis], but since 327 they are all access technology specific, details are outside the 328 scope of this document. 330 (i) The NAR starts to forward packets destined for the MN via the 331 N-AN. 333 (j) The uplink packets from the MN are sent to the NAR via the N-AN 334 and the NAR forwards them to the PAR. The PAR then sends the 335 packets to the LMA that is currently serving the MN. 337 (k) The NAR (NMAG) sends the Proxy Binding Update (PBU) to the LMA, 338 whose address is provided in (c). Steps (k) and (l) are not 339 part of the fast handover procedure, but shown for reference. 341 (l) The LMA sends back the Proxy Binding Acknowledgment (PBA) to the 342 NAR (NMAG). From this time on, the packets to/from the MN go 343 through the NAR instead of the PAR. 345 According to Section 4 of [RFC5268bis], the PAR establishes a binding 346 between the PCoA and NCoA to forward packets for the MN to the NAR, 347 and the NAR creates a proxy NCE to receive those packets for the NCoA 348 before the MN arrives. In the case of PMIPv6, however, the only 349 address that is used by the MN is MN-HoA. Hence the PAR forwards 350 MN's packets to the NAR instead of the NCoA. FMIPv4 [RFC4988] 351 specifies forwarding when the MN uses HoA as its on-link address 352 rather than the care-of address. The usage in PMIPv6 is similar to 353 that in FMIPv4, where the address is used by the MN is based on Home 354 Network Prefix. Hence the PAR forwards MN's packets to the NAR 355 instead of the NCoA. The NAR then simply decapsulates those packets 356 and delivers them to the MN. Since the NAR obtains the LLA (MN IID) 357 and MN-HNP by the HI, it can create the NCE for the MN and deliver 358 packets to it even before the MN can perform Neighbor Discovery. For 359 the uplink packets from the MN after handover in (j), the NAR 360 forwards the packets to the PAR through the tunnel established in 361 step (f). The PAR then decapsulates and sends them to the LMA. 363 The timing of the context transfer and that of packet forwarding may 364 be different. Thus, a new flag 'F' and the Option Code values for it 365 in the HI message are defined to request forwarding. To request 366 buffering, 'U' flag has already been defined in [RFC5268bis]. If the 367 PAR receives the HI message with F flag set and the Option Code value 368 being 2, it starts forwarding packets for the MN. The HI message 369 with U flag set may be sent earlier if the timing of buffering is 370 different from that of forwarding. If packet forwarding is 371 completed, the PAR MAY send the HI message with F flag set and the 372 Option Code value being 3. By this message, the ARs on both ends can 373 tear down the forwarding tunnel synchronously. 375 The IP addresses in the headers of those user packets are summarized 376 below: 378 In (f), 380 Inner source address: IP address of the CN 382 Inner destination address: HNP or IPv4-MN-HoA 384 Outer source address: IP address of the PAR (PMAG) 385 Outer destination address: IP address of the NAR (NMAG) 387 In (i), 389 Source address: IP address of the CN 391 Destination address: HNP or IPv4-MN-HoA 393 In (j), 395 - from the MN to the NMAG, 397 Source address: HNP or IPv4-MN-HoA 399 Destination address: IP address of the CN 401 - from the NMAG to the PMAG, 403 Inner source address: HNP or IPv4-MN-HoA 405 Inner destination address: IP address of the CN 407 Outer source address: IP address of the NAR (NMAG) 409 Outer destination address: IP address of the PAR (PMAG) 411 - from the PMAG to the LMA, 413 Inner source address: HNP or IPv4-MN-HoA 415 Inner destination address: IP address of the CN 417 Outer source address: IP address of the PAR (PMAG) 419 Outer destination address: IP address of the LMA 421 The encapsulation type for these user packets SHOULD follow that used 422 in the tunnel between the LMA and MAG (e.g., IPv6-in-IPv6 [RFC5213] 423 or GRE [GREKEY]). 425 In the case of the reactive handover for PMIPv6, since the MN does 426 not send either the FBU or UNA, it would be more natural that the NAR 427 sends the HI to the PAR after the MN has moved to the new link. The 428 NAR then needs to obtain the information of the PAR beforehand. Such 429 information could be provided, for example, by the MN sending the 430 AP-ID on the old link and/or by the lower-layer procedures between 431 the P-AN and N-AN. The exact method is not specified in this 432 document. Figure 3 illustrates the reactive fast handover procedures 433 for PMIPv6, where the bi-directional tunnel establishment is 434 initiated by the NAR. 436 PMAG NMAG 437 MN P-AN N-AN (PAR) (NAR) LMA 438 | | | | | | 439 (a) ~~~ | | | | | 440 ~~~ | | | | | 441 | MN-AN connection | AN-MAG connection | | 442 (b) |<--establishment-->|<-------establishment------>| | 443 |(MN ID, Old AP ID) | (MN ID, Old AP ID) | | 444 | | |(substitute for UNA and FBU)| | 445 | | | | | | 446 | | | | HI | | 447 (c) | | | |<---(MN ID) ---| | 448 | | | | | | 449 | | | | HAck | | 450 (d) | | | |---(MN ID, --->| | 451 | | | | MN IID, LMAA) | | 452 | | | | | | 453 (e) | | | #=|<=======================| 454 | | | #================>|=# | 455 |<====================DL data======================# | 456 | | | | | | 457 (f) |=====================UL data===================>|=# | 458 | | | #=|<================# | 459 | | | #=========================>| 460 | | | | | | 461 / | | | | | | \ 462 |(g) | | | | |--PBU-->| | 463 | | | | | | | | 464 |(h) | | | | |<--PBA--| | 465 \ | | | | | | / 467 Figure 3: Reactive fast handover for PMIPv6 (NAR initiated) 469 The detailed descriptions are as follows: 471 (a) The MN undergoes handover from the P-AN to the N-AN. The AP-ID 472 on the old link may be provided by the MN to help identify the 473 PMAG on the new link. 475 (b) The MN establishes a connection (e.g., radio channel) with the 476 N-AN, which triggers the establishment of the connection between 477 the N-AN and NAR. The MN ID is transferred to the NAR for the 478 subsequent procedures. The AP-ID on the old link may also be 479 provided by the MN to help identify the PMAG on the new link. 480 This can be regarded as a substitute for the UNA and FBU. 482 (c) The NAR sends the HI to the PAR. The HI message MUST include 483 the MN ID. The Context Request Option MAY be included to 484 request additional context information on the MN to the PAR. 486 (d) The PAR sends the HAck back to the NAR. The HAck message MUST 487 include the HNP and/or IPv4-MN-HoA that is corresponding to the 488 MN ID in the HI message and SHOULD include the MN-IID and the 489 LMA address that is currently serving the MN. The context 490 information requested by the NAR MUST be included. 492 (e) If F flag in the HI is set, a bi-directional tunnel is 493 established between the PAR and NAR and packets destined for the 494 MN are forwarded from the PAR to the NAR over this tunnel. 495 After decapsulation, those packets are delivered to the MN via 496 the N-AN. 498 (f) The uplink packets from the MN are sent to the NAR via the N-AN 499 and the NAR forwards them to the PAR. The PAR then sends the 500 packets to the LMA that is currently serving the MN. 502 Steps (g)-(h) are the same as (k)-(l) in the predictive fast handover 503 procedures. 505 In step (c), The IP address of the PAR needs to be resolved by the 506 NAR to send the HI to the PAR. This information may come from the 507 N-AN or some database that the NAR can access. 509 4.2. Inter-AR Tunneling Operation 511 When the PMAG (PAR) or NMAG (NAR), depending on the fast handover 512 mode, receives the HI message with the F flag set, it prepares to 513 send/receive the MN's packets to/from the other MAG and returns the 514 HAck message with the same sequence number. The necessary 515 information MUST be transferred in the HI message to distinguish MN's 516 packets for forwarding in advance or at this time. Such information 517 includes the HoA of the MN and/or GRE key(s). For the downlink 518 packets, the PMAG redirects MN's packets from the LMA towards the 519 NMAG and if the MN is ready to receive those packets or the N-AN can 520 handle them regardless of the state of the MN, the NAR should 521 immediately send them towards the N-AN; otherwise it should buffer 522 them until the MN is ready. For the uplink packets, the NMAG SHOULD 523 redirect them from the MN towards the PMAG and the PMAG sends them to 524 the LMA. Depending on the implementation, the NMAG MAY send them 525 directly to the LMA. 527 When the PMAG or NMAG receives the HI message with the U flag set, it 528 prepares to buffer the MN's packets and returns the HAck message with 529 the same sequence number. It MUST be followed by another HI message 530 with the F flag set at an appropriate time to forward the buffered 531 packets. 533 If the MAG that received the HI message encounters an erroneous 534 situation (e.g., insufficient buffer space), it SHOULD immediately 535 send the HAck message with the cause of the error and cancel all 536 tunneling operation. 538 4.3. IPv4 Support Considerations 540 The motivation and usage scenarios of IPv4 protocol support by PMIPv6 541 are described in [IPv4PMIPv6]. The scope of IPv4 support covers the 542 following two features: 544 o IPv4 Home Address Mobility Support, and 546 o IPv4 Transport Support. 548 As for IPv4 Home Address Mobility Support, the MN acquires IPv4 Home 549 Address (IPv4-MN-HoA) and in the case of handover, the PMAG needs to 550 transfer IPv4-MN-HoA to the NMAG, which is the inner destination 551 address of the packets forwarded on the downlink. For this purpose, 552 a new option called IPv4 Address Option is defined in this document. 553 In order to provide IPv4 Transport Support, the NMAG needs to know 554 the IPv4 address of the LMA (IPv4-LMAA) to send PMIPv6 signaling 555 messages to the LMA in the IPv4 transport network. In this case, a 556 new option called LMA Address (LMAA) option is used so as to convey 557 IPv4-LMAA from the PMAG to NMAG. The supported encapsulation type 558 follows Section 6.10.2 in [RFC5213], that is, IPv4, IPv4-UDP and 559 IPv4-UDP-TLV. 561 5. PMIPv6-related Fast Handover Issues 563 The protocol specified in this document enables the NMAG to obtain 564 parameters which would otherwise be available only by communicating 565 with the LMA. For instance, the HNP and/or IPv4-MN-HoA of a MN are 566 made available to the NMAG through context transfer. This allows the 567 NMAG to perform some procedures that may be beneficial. For 568 instance, the NMAG could send a Router Advertisement (RA) with the 569 HNP option to the MN as soon as it's link attachment is detected 570 (e.g., via receipt of a Router Solicitation message). Such an RA is 571 recommended, for example, in scenarios where the MN uses a new radio 572 interface while attaching to the NMAG; since the MN does not have 573 information regarding the new interface, it will not be able to 574 immediately send packets without first receiving an RA with HNP. 575 Especially, in the reactive fast handover, the NMAG gets to know the 576 HNP assigned to the MN on the previous link at step (d) in Figure 3. 577 In order to reduce the communication disruption time, the NMAG SHOULD 578 accept the MN to keep using the same HNP and to send uplink packets 579 before that step upon MN's request. However, if the HAck from the 580 PMAG returns a different HNP or the subsequent PMIPv6 binding 581 registration for the HNP fails for some reason, then the NMAG MUST 582 withdraw the advertised HNP by sending another RA with zero prefix 583 lifetime for the HNP in question. This operation is the same as 584 described in Section 6.12 of [RFC5213]. 586 The protocol specified in this document is applicable regardless of 587 whether link-layer addresses are used between a MN and its access 588 router. A MN should be able to continue sending packets on the 589 uplink even when it changes link. When link-layer addresses are 590 used, the MN performs Neighbor Unreachability Detection (NUD) 591 [RFC4861], after attaching to a new link, probing the reachability of 592 its default router. If the new router's interface is configured to 593 respond to queries sent to link-layer addresses than its own (e.g., 594 set to promiscuous mode), then it can respond to the NUD probe, 595 providing its link-layer address in the solicited Neighbor 596 Advertisement. Implementations should allow the MN to continue to 597 send uplink packets while it is performing NUD. 599 6. Message Formats 601 This document defines new Mobility Header messages for the extended 602 HI and Hack and new mobility options for conveying context 603 information. 605 6.1. Mobility Header 607 6.1.1. Handover Initiate (HI) 609 This section defines extensions to the HI message in [RFC5268bis]. 610 The format of the Message Data field in the Mobility Header is as 611 follows: 613 0 1 2 3 614 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 615 +-------------------------------+ 616 | Sequence # | 617 +-+-+-+---------+---------------+-------------------------------+ 618 |S|U|F|Reserved | Code | | 619 +-+-+-+---------+---------------+ | 620 | | 621 . . 622 . Mobility options . 623 . . 624 | | 625 +---------------------------------------------------------------+ 627 IP Fields: 629 Source Address 631 The IP address of PMAG or NMAG 633 Destination Address 635 The IP address of the peer MAG 637 Message Data: 639 Sequence # Same as [RFC5268bis]. 641 S flag Defined in [RFC5268bis] and MUST be set to zero in this 642 specification. 644 U flag Buffer flag. Same as [RFC5268bis]. 646 F flag Forwarding flag. Used to request to forward the packets 647 for the MN. 649 Reserved Same as [RFC5268bis]. 651 Code [RFC5268bis] defines this field and its values 0 and 1. 652 In this specification, if F flag is not set, this field 653 MUST be set to zero. Otherwise, it has the following 654 meaning: 656 2: Forwarding is not requested 658 3: Request forwarding 660 4: Indicate the completion of forwarding 662 Mobility options: 664 This field contains one or more mobility options, whose encoding and 665 formats are defined in [RFC3775]. At least one mobility option MUST 666 uniquely identify the target MN (e.g., the Mobile Node Identifier 667 Option defined in RFC4283) and the transferred context MUST be for 668 one MN per message. In addition, the NAR can request necessary 669 mobility options by the Context Request Option defined in this 670 document. 672 Context Request Option 674 This option MAY be present to request context information 675 typically by the NAR to the PAR in the NAR-initiated fast 676 handover. 678 6.1.2. Handover Acknowledge (HAck) 680 This section defines extensions to the HAck message in[RFC5268bis]. 681 The format of the Message Data field in the Mobility Header is as 682 follows: 684 0 1 2 3 685 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 686 +-------------------------------+ 687 | Sequence # | 688 +-+-+-----------+---------------+-------------------------------+ 689 |U|F| Reserved | Code | | 690 +-+-+-----------+---------------+ | 691 | | 692 . . 693 . Mobility options . 694 . . 695 | | 696 +---------------------------------------------------------------+ 698 IP Fields: 700 Source Address 702 Copied from the destination address of the 703 Handover Initiate message to which this message 704 is a response. 706 Destination Address 708 Copied from the source address of the Handover 709 Initiate message to which this message is a 710 response. 712 Message Data: 714 The usages of Sequence # and Reserved fields are exactly the same as 715 those in [RFC5268bis]. 717 U, F flags Same as defined in Section 6.1.1. 719 Code 720 Code values 0 through 4 and 128 through 130 are defined 721 in [RFC5268bis]. In this specification, the meaning of 722 Code value 0 is modified, 128 through 130 are reused, and 723 5, 6, 131 and 132 are newly defined. 725 0: Handover Accepted 727 5: Context Transfer Successful or Accepted 728 6: All available Context Transferred 730 128: Handover Not Accepted, reason unspecified 732 129: Administratively prohibited 734 130: Insufficient resources 736 131: Requested Context Not Available 738 132: Forwarding Not Available 740 Mobility options: 742 This field contains one or more mobility options, whose encoding and 743 formats are defined in [RFC3775]. The mobility option that uniquely 744 identifies the target MN MUST be copied from the corresponding HI 745 message and the transferred context MUST be for one MN per message. 747 Requested option(s) All the context information requested by the 748 Context Request Option in the HI message SHOULD be present 749 in the HAck message. The other cases are described below. 751 In the case of the PAR-initiated fast handover, when the PAR sends 752 the HI message to the NAR with the context information and the NAR 753 successfully receives it, the NAR returns the HAck message with Code 754 value 5. In the case of the NAR-initiated fast handover, when the 755 NAR sends the HI message to the PAR with or without Context Request 756 Option, the PAR returns the HAck message with the requested or 757 default context information (if any). If all available context 758 information is transferred, the PAR sets the Code value in the HAck 759 message to 6. If more context information is available, the PAR sets 760 the Code value in the HAck to 5 and the NAR MAY send new HI 761 message(s) to retrieve the rest of the available context information. 762 If none of the requested context information is available, the PAR 763 returns the HAck message with Code value 131 without any context 764 information. 766 6.2. Mobility Options 768 6.2.1. Context Request Option 770 This option is sent in the HI message to request context information 771 on the MN. If a default set of context information is defined and 772 always sufficient, this option is not mandatory. This option is more 773 useful to retrieve additional or dynamically selected context 774 information. 776 Context Request Option is typically used for the reactive (NAR- 777 initiated) fast handover mode to retrieve the context information 778 from the PAR. When this option is included in the HI message, all 779 the requested context information SHOULD be included in the HAck 780 message in the corresponding mobility option(s) (e.g., HNP, LMAA or 781 MN-IID mobility options). 783 0 1 2 3 784 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 785 +---------------+---------------+---------------+---------------+ 786 | Option-Type | Option-Length | Reserved | 787 +---------------+---------------+-------------------------------+ 788 | Req-type-1 | Req-length-1 | Req-type-2 | Req-length-2 | 789 +---------------------------------------------------------------+ 790 | ... | 792 Option-Type TBD1 794 Option-Length The length in octets of this option, not including the 795 Option Type and Option Length fields. 797 Reserved This field is unused. It MUST be initialized to zero 798 by the sender and MUST be ignored by the receiver. 800 Req-type-n The type value for the n'th requested option. 802 Req-length-n The length of the n'th requested option excluding the 803 Req-type-n and Req-length-n fields. 805 In the case where there are only Req-type-n and Req-length-n fields, 806 the value of the Req-length-n is set to zero. If additional 807 information besides the Req-type-n is necessary to uniquely specify 808 the requested context, such information follows after the 809 Req-length-n. For example, when the requested context is the Vendor- 810 Specific Option described in Section 6.2.8, the requested option 811 format looks as follows: 813 | ... | 814 +---------------+---------------+-------------------------------+ 815 | Req-type-N=19 | Req-length-N=5| Vendor-ID | 816 +-------------------------------+---------------+---------------+ 817 | Vendor-ID | Sub-Type | | 818 +-----------------------------------------------+ | 819 | ... | 821 The exact values in the Vendor-ID and Sub-Type are outside the scope 822 of this document. 824 6.2.2. Local Mobility Anchor Address (LMAA) Option 826 This option is used to transfer the Local Mobility Anchor IPv6 827 Address (LMAA) or its IPv4 Address (IPv4-LMAA), with which the MN is 828 currently registered. The detailed definition of the LMAA is 829 described in [RFC5213]. 831 0 1 2 3 832 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 833 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 834 | Option-Type | Option-Length | Option-Code | Reserved | 835 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 836 | Local Mobility Anchor Address ... | 838 Option-Type TBD2 840 Option-Length 18 or 6 842 Option-Code 844 0 Reserved 846 1 IPv6 address of the LMA (LMAA) 848 2 IPv4 address of the LMA (IPv4-LMAA) 850 Reserved This field is unused. It MUST be initialized to zero 851 by the sender and MUST be ignored by the receiver. 853 Local Mobility Anchor Address 854 If Option-Code is 1, the LMA IPv6 address (LMAA) is 855 inserted. If Option-Code is 2, the LMA IPv4 address 856 (IPv4-LMA) is inserted. 858 6.2.3. IPv4 Address Option 860 As described in Section 4.3, if the MN is IPv4-only mode or dual- 861 stack mode, the MN requires IPv4 home address (IPv4-MN-HoA). This 862 option has alignment requirement of 4n. 864 0 1 2 3 865 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 866 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 867 | Option-Type | Option-Length | Option-Code | Reserved | 868 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 869 | IPv4 Address | 870 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 872 Option-Type TBD3 874 Option-Length 6 876 Option-Code 878 0 Reserved 880 1 IPv4-MN-HoA 882 Reserved This field is unused. It MUST be initialized to zero 883 by the sender and MUST be ignored by the receiver. 885 IPv4 Address IPv4 address specified in Option-Code 887 6.2.4. Home Network Prefix Option 889 This option is used to transfer the home network prefix that is 890 assigned to the MN in the P-AN. The Home Network Prefix Option 891 defined in [RFC5213] is used for this. 893 6.2.5. Mobile Node Interface Identifier (MN IID) Option 895 This option is used to transfer the interface identifier of the MN 896 that is used in the P-AN. The Mobile Node Interface Identifier 897 Option defined in [RFC5213] is used for this. 899 6.2.6. Link-local Address Option 901 This option is used to transfer the link-local address of the PAR 902 (PMAG). The Link-local Address Option defined in [RFC5213] is used 903 for this. 905 6.2.7. GRE Key Option 907 This option is used to transfer the GRE Key for the MN's data flow 908 over the bi-directional tunnel between the PAR and NAR. The message 909 format of this option follows the GRE Key Option defined in [GREKEY]. 910 The GRE Key value uniquely identifies each flow and the sender of 911 this option expects to receive packets of the flow from the peer AR 912 with this value. 914 6.2.8. Vendor-Specific Mobility Option 916 This option is used to transfer any other information defined in this 917 document. The format of this option follows the Vendor-Specific 918 Mobility Option defined in [RFC5094]. The exact values in the Vendor 919 ID, Sub-Type and Data fields are outside the scope of this document. 921 7. Security Considerations 923 Security issues for this document follow those for PMIPv6 [RFC5213] 924 and FMIPv6 [RFC5268bis]. In PMIPv6, the MAG and LMA are assumed to 925 share security associations. In FMIPv6, the access routers (i.e., 926 the PMAG and NMAG in this document) are assumed to share security 927 associations. 929 The Handover Initiate (HI) and Handover Acknowledgement (HAck) 930 messages exchanged between the PMAG and NMAG MUST be protected using 931 end-to-end security association(s) offering integrity and data origin 932 authentication. The PMAG and the NMAG MUST implement IPsec [RFC4301] 933 for protecting the HI and HAck messages. IPsec Encapsulating 934 Security Payload (ESP) [RFC4303] in transport mode with mandatory 935 integrity protection SHOULD be used for protecting the signaling 936 messages. Confidentiality protection SHOULD be used if sensitive 937 context related to the mobile node is transferred. 939 IPsec ESP [RFC4303] in tunnel mode MAY be used to protect the MN's 940 packets at the time of forwarding if protection of data traffic is 941 required. 943 8. IANA Considerations 945 This document defines two new mobility options, which are described 946 in Section 6.2. The Type value for these options are assigned from 947 the same numbering space as allocated for the other mobility options, 948 as defined in [RFC3775]. 950 Mobility Options 951 Value Description Reference 952 ----- ------------------------------------- ------------- 953 TBD1 Context Request Option Section 6.2.1 954 TBD2 Local Nobility Anchor Address Option Section 6.2.2 955 TBD3 IPv4 Address Option Section 6.2.3 957 9. Acknowledgments 959 The authors would like to specially thank Vijay Devarapalli and Sri 960 Gundavelli for their thorough reviews of this document. 962 The authors would also like to thank Charlie Perkins, Desire Oulai, 963 Ahmad Muhanna, Giaretta Gerardo, Domagoj Premec, Marco Liebsch, Fan 964 Zhao, David Cypher, Julien Laganier and Pierrick Seite for their 965 passionate discussions in the working group mailing list. 967 10. References 969 10.1. Normative References 971 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 972 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 974 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 975 Requirement Levels", BCP 14, RFC 2119, March 1997. 977 [RFC5268bis] 978 Koodli, R., Ed., "Mobile IPv6 Fast Handovers", 979 draft-ietf-mipshop-rfc5268bis-01.txt, March 2009. 981 [RFC3775] Johnson, D., "Mobility Support in IPv6", RFC 3775, 982 June 2004. 984 [RFC4988] Koodli, R. and C. Perkins, "Mobile IPv4 Fast Handovers", 985 RFC 4988, October 2007. 987 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 988 Internet Protocol", RFC 4301, December 2005. 990 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 991 RFC 4303, December 2005. 993 [RFC5094] Devarapalli, V., Patel, A., and K. Leung, "Mobile IPv6 994 Vendor Specific Option", RFC 5094, December 2007. 996 10.2. Informative References 998 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 999 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 1000 September 2007. 1002 [IPv4PMIPv6] 1003 Wakikawa, R., Ed. and S. Gundavelli, "IPv4 Support for 1004 Proxy Mobile IPv6", 1005 draft-ietf-netlmm-pmip6-ipv4-support-12.txt, April 2009. 1007 [GREKEY] Muhanna, A., Ed., "GRE Key Option for Proxy Mobile IPv6", 1008 draft-ietf-netlmm-grekey-option-08.txt, April 2009. 1010 Appendix A. Applicable Use Cases 1012 A.1. PMIPv6 Handoff Indication 1014 PMIPv6 [RFC5213] defines the Handoff Indicator Option and describes 1015 the type of the handoff and the values to set to the option. This 1016 document proposes one approach to determining the handoff type by the 1017 NMAG when the handoff of the MN is executed. 1019 According to [RFC5213], the following handoff types are defined: 1021 0) Reserved 1023 1) Attachment over a new interface 1025 2) Handoff between two different interfaces of the mobile node 1027 3) Handoff between mobile access gateways for the same interface 1029 4) Handoff state unknown 1031 5) Handoff state not changed (Re-registration) 1033 By using the MN Interface Identifier (MN IID) option, which is 1034 defined in this document, the following solution can be considered. 1035 When the NMAG receives the MN IID used in the P-AN from the PMAG via 1036 the HI or HAck messages, the NMAG compares it with the new MN IID 1037 that is obtained from the MN in the N-AN. If these two MN IIDs are 1038 the same, the handover type falls into 3) and the Handoff Indicator 1039 value is set to 3. If these two MN IIDs are different, the handover 1040 is likely to be 2) since the HI/HAck message exchange implies that 1041 this is a handover not a multi-homing, therefore the Handoff 1042 Indicator value can be set to 2. If there is no HI/Hack exchange 1043 performed prior to the network attachment of the MN in the new 1044 network, the NMAG may infer that this is a multi-homing case and set 1045 the Handoff Indicator value to 1. In the case of re-registration, 1046 the MAG, to which the MN is attached, can determine if the handoff 1047 state is not changed, so the MAG can set the HI value to 5 without 1048 any additional information. If none of them can be assumed, the NMAG 1049 may set the value to 4. 1051 A.2. Local Routing 1053 Section 6.10.3 in [RFC5213] describes that if EnableMAGLocalRouting 1054 flag is set, when two mobile nodes are attached to one MAG, the 1055 traffic between them may be locally routed. If one mobile node moves 1056 from this MAG (PMAG) to another MAG (NMAG) and if the PMAG does not 1057 detect the MN's detachment, it will continue to forward packets 1058 locally forever. This situation is more likely to happen in the 1059 reactive fast handover with WLAN access, which does not have the 1060 capability to detect the detachment of the MN in a timely manner. 1061 PFMIPv6 can be applied to handle this case. When the MN attaches to 1062 the NMAG, it sends the HI message to the PMAG, which makes it realize 1063 the detachment of the MN. The PMAG immediately stops the local 1064 routing and sends the packets for the MN towards the LMA, which in 1065 turn forwards them to the NMAG over the PMIPv6 tunnel. 1067 A.3. Handling of PMIPv6/MIPv6 switching 1069 If the network that the MN has moved to does not support PMIPv6 but 1070 only MIPv6 (i.e. there exists a MIPv6 HA) and the MN supports MIPv6 1071 at the same time, the MN and HA can exchange BU/BA instead of PBU/PBA 1072 (e.g., at steps (k) and (l) in Figure 2). If this is the case, the 1073 LMA and HA will most likely be collocated and the LMA (HA) address 1074 should be maintained in the new network for communication continuity. 1075 Since the LMA (HA) address is transferred to the NAR in the HI/HAck 1076 exchange, the MN can retrieve it at or after the handover by way of, 1077 e.g., the authentication or DHCP procedure. 1079 Appendix B. Change Log 1081 Changes at -00 1083 * Added separate sections for MH and ICMP. 1085 * Clarified usage of HNP and IPv4-MN-HoA throughout the document. 1087 * Added IANA Considerations. 1089 * Added section on Other Considerations, including operation of 1090 uplink packets when using link-layer addresses, multiple 1091 interface usage and transmission of RA to withdraw HNP in the 1092 event of failure of PMIP6 registration. 1094 * Revised Security Considerations. 1096 Changes from -00 to -01 1098 * Removed ICMPv6-based message format. 1100 * Clarified HI/HAck exchange in the predictive mode (step (e) in 1101 Figure 2). 1103 * Clarified information retrieval about the PMAG in the reactive 1104 mode. 1106 * Removed the extension to the GRE Key Option. 1108 * Clarified the handoff type considerations in Appendix A. 1110 * Home Network Prefix Option, Link-local Address Option and 1111 Vendor-Specific Mobility Option are added. 1113 Changes from -01 to -02 1115 * Aligned HI/HAck message formats with [RFC5268bis] 1116 (draft-ietf-mipshop-rfc5268bis-00.txt). 1118 * Revised Section 8 removing the request for the type assignment 1119 of HI/HAck Mobility Headers. 1121 Changes from -02 to -03 1123 * Updated HI/HAck message formats according to 1124 draft-ietf-mipshop-rfc5268bis-01.txt. 1126 * Cleaned up Figure 2 and Figure 3. 1128 * Moved PMIP domain boundary crossing situation in Section 4.1 to 1129 Appendix A.3. 1131 * Removed the alternative protocol operation with an unsolicited 1132 HAck from Section 4.1. 1134 * Modified Code values in the HAck message in order to avoid 1135 collision with those in [RFC5268bis]. 1137 * Clarified the usage scenarios of Context Request Option. 1139 * Modified the description of Code values in the HAck message. 1141 * Changed the container for the IPv4-LMAA from IPv4 Address 1142 option to the LMAA option. 1144 * Made Confidentiality protection "SHOULD" for context transfer. 1146 Changes from -03 to -04 1148 * Added more explanations about MIPv6, FMIPv6 and PMIPv6 in 1149 Abstract. 1151 * Moved Figure 1 to Section 4. 1153 * More clearly Indicated the FMIPv6 messages that are not 1154 applicable In the PMIPv6 context. 1156 * Mandated the support of IP Sec on the PMAG and NMAG in order to 1157 protect signaling and user packets and the context information. 1159 * Added a new section for the inter-AR tunneling operation 1160 (Section 4.2). 1162 * Added descriptions about the encapsulation type in Sections 4.1 1163 and 4.3. 1165 * Added a description about buffering requirements on the MAG in 1166 Section 4.1. 1168 * Added a description about the timing of L2 and L3 connection 1169 establishments in Section 4.1. 1171 * Added a new section for PMIPv6-related fast handover issues 1172 (Section 5) and a description about preferable behaviors of the 1173 MN and MAG to reduce packet loss. 1175 * Added Acknowledgments section (Section 9). 1177 * Added a new section for local routing in Appendix (A.2). 1179 Authors' Addresses 1181 Hidetoshi Yokota 1182 KDDI Lab 1183 2-1-15 Ohara, Fujimino 1184 Saitama, 356-8502 1185 JP 1187 Email: yokota@kddilabs.jp 1189 Kuntal Chowdhury 1190 Starent Networks 1191 30 International Place 1192 Tewksbury, MA 01876 1193 US 1195 Email: kchowdhury@starentnetworks.com 1197 Rajeev Koodli 1198 Starent Networks 1199 30 International Place 1200 Tewksbury, MA 01876 1201 US 1203 Email: rkoodli@starentnetworks.com 1205 Basavaraj Patil 1206 Nokia 1207 6000 Connection Drive 1208 Irving, TX 75039 1209 US 1211 Email: basavaraj.patil@nokia.com 1213 Frank Xia 1214 Huawei USA 1215 1700 Alma Dr. Suite 500 1216 Plano, TX 75075 1217 US 1219 Email: xiayangsong@huawei.com