idnits 2.17.1 draft-ietf-mipshop-pfmipv6-02.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? -- It seems you're using the 'non-IETF stream' Licence Notice instead Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 18, 2009) is 5544 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) == Outdated reference: A later version (-01) exists of draft-ietf-mipshop-rfc5268bis-00 ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) ** Downref: Normative reference to an Experimental RFC: RFC 4988 == Outdated reference: A later version (-18) exists of draft-ietf-netlmm-pmip6-ipv4-support-09 == Outdated reference: A later version (-09) exists of draft-ietf-netlmm-grekey-option-03 Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 3 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: August 22, 2009 R. Koodli 6 Starent Networks 7 B. Patil 8 Nokia 9 F. Xia 10 Huawei USA 11 February 18, 2009 13 Fast Handovers for Proxy Mobile IPv6 14 draft-ietf-mipshop-pfmipv6-02.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 August 22, 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 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. 51 Abstract 53 This document specifies the usage of Fast Mobile IPv6 (FMIPv6) when 54 Proxy Mobile IPv6 is used as the mobility management protocol. 55 Necessary extensions are specified for FMIPv6 to support the scenario 56 when the mobile node does not have IP mobility functionality and 57 hence is not involved with either MIPv6 or FMIPv6 operations. 59 Table of Contents 61 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 4 62 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 63 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 64 4. Proxy-based FMIPv6 Protocol Overview . . . . . . . . . . . . . 8 65 4.1. Protocol Operation . . . . . . . . . . . . . . . . . . . . 8 66 4.2. IPv4 Support Considerations . . . . . . . . . . . . . . . 14 67 5. Other Considerations . . . . . . . . . . . . . . . . . . . . . 16 68 6. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 17 69 6.1. Mobility Header . . . . . . . . . . . . . . . . . . . . . 17 70 6.1.1. Handover Initiate (HI) . . . . . . . . . . . . . . . . 17 71 6.1.2. Handover Acknowledge (HAck) . . . . . . . . . . . . . 18 72 6.2. Mobility Options . . . . . . . . . . . . . . . . . . . . . 20 73 6.2.1. Context Request Option . . . . . . . . . . . . . . . . 20 74 6.2.2. Local Mobility Anchor Address (LMAA) Option . . . . . 21 75 6.2.3. IPv4 Address Option . . . . . . . . . . . . . . . . . 22 76 6.2.4. Home Network Prefix Option . . . . . . . . . . . . . . 22 77 6.2.5. Mobile Node Interface Identifier (MN IID) Option . . . 23 78 6.2.6. Link-local Address Option . . . . . . . . . . . . . . 23 79 6.2.7. GRE Key Option . . . . . . . . . . . . . . . . . . . . 23 80 6.2.8. Vendor-Specific Mobility Option . . . . . . . . . . . 23 81 7. Security Considerations . . . . . . . . . . . . . . . . . . . 24 82 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 83 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 84 9.1. Normative References . . . . . . . . . . . . . . . . . . . 26 85 9.2. Informative References . . . . . . . . . . . . . . . . . . 26 86 Appendix A. Handoff Type Considerations . . . . . . . . . . . . . 27 87 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 28 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 90 1. Requirements notation 92 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 93 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 94 document are to be interpreted as described in [RFC2119]. 96 2. Introduction 98 Proxy Mobile IPv6 [RFC5213] provides IP mobility to a mobile node 99 that does not possess Mobile IPv6 [RFC3775] functionality. A proxy 100 agent in the network performs the mobility management signaling on 101 behalf of the mobile node. This model transparently provides 102 mobility for Mobile Nodes within a PMIPv6 domain. Nevertheless, the 103 basic performance of PMIPv6 in terms of handover latency and packet 104 loss is considered not any different from that of Mobile IPv6. 106 Fast Handovers for Mobile IPv6 is specified in [RFC5268bis]. This 107 document applies the same Fast Handovers protocol for Proxy Mobile 108 IPv6 (PFMIPv6), in order to provide handover delay, packet loss and 109 transfer of network-resident contexts. This document also specifies 110 necessary extensions to FMIPv6 for operation in a PMIPv6 domain. 112 3. Terminology 114 This document refers to [RFC5213][RFC5268bis][RFC3775] for 115 terminology. The following terms and abbreviations are additionally 116 used in this document. The reference network is illustrated in 117 Figure 1. 119 Previous Access Network (P-AN): 120 The access network to which the MN is attached before handover. 122 New Access Network (N-AN): 123 The access network to which the MN is attached after handover. 125 Previous Mobile Access Gateway (PMAG): 126 The MAG that manages mobility related signaling for the MN 127 before handover. In this document, the MAG and the Access 128 Router (AR) are collocated. 130 New Mobile Access Gateway (NMAG): 131 The MAG that manages mobility related signaling for the MN after 132 handover. In this document, the MAG and the Access Router (AR) 133 are collocated. 135 HO-Initiate: 136 A generic signaling that indicates the handover of the MN sent 137 from the P-AN to the PMAG. While this signaling is dependent on 138 the access technology, it is assumed that HO-Initiate can carry 139 the information to identify the MN and to assist the PAR resolve 140 the NAR (e.g., the new access point or base station to which the 141 MN is moving). 143 +----------+ 144 | LMA | 145 | | 146 +----------+ 147 / \ 148 / \ 149 / \ 150 +........../..+ +..\..........+ 151 . +-------+-+ .______. +-+-------+ . 152 . | PAR |()_______)| NAR | . 153 . | (PMAG) | . . | (NMAG) | . 154 . +----+----+ . . +----+----+ . 155 . | . . | . 156 . ___|___ . . ___|___ . 157 . / \ . . / \ . 158 . ( P-AN ) . . ( N-AN ) . 159 . \_______/ . . \_______/ . 160 . | . . | . 161 . +----+ . . +----+ . 162 . | MN | ----------> | MN | . 163 . +----+ . . +----+ . 164 +.............+ +.............+ 166 Figure 1: Reference network for fast handover 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). In order to enable the NMAG to send the Proxy Binding 175 Update (PBU), the Handover Initiate (HI) and Handover Acknowledge 176 (HAck) messages in [RFC5268bis] are used for context transfer, in 177 which parameters such as MN's NAI, Home Network Prefix (HNP), IPv4 178 Home Address, are transferred from the PMAG. 180 In this document, the Previous Access Router (PAR) and New Access 181 Router (NAR) are interchangeable with the PMAG and NMAG, 182 respectively. 184 Since a MN is not directly involved with IP mobility protocol 185 operations, it follows that the MN is not directly involved with fast 186 handover procedures either. Hence, the messages involving the MN in 187 [RFC5268bis] are not used when PMIPv6 is in use. Such messages are 188 the Router Solicitation for Proxy Advertisement (RtSolPr), Proxy 189 Router Advertisement (PrRtAdv), Fast Binding Update (FBU), Fast 190 Binding Acknowledgment (FBack) and Unsolicited Neighbor Advertisement 191 (UNA). 193 4.1. Protocol Operation 195 There are two modes of operation in FMIPv6 [RFC5268bis]. In the 196 predictive mode of fast handover, a bi-directional tunnel between the 197 PAR and NAR is established prior to the MN's attachment to the NAR. 198 In the reactive mode, this tunnel establishment takes place after the 199 MN attaches to the NAR. Since the MN is not involved in IP mobility 200 signaling in PMIPv6, the sequence of events illustrating the 201 predictive fast handover are shown in Figure 2. 203 PMAG NMAG 204 MN P-AN N-AN (PAR) (NAR) LMA 205 | | | | | | 206 | Report | | | | | 207 (a) |-(MN ID,-->| | | | | 208 | New AP ID)| | | | | 209 | | HO Initiate | | | 210 (b) | |--(MN ID, New AP ID)-->| | | 211 | | | | | | 212 | | | | HI | | 213 (c) | | | |-(MN ID, ->| | 214 | | | | MN IID, LMAA) | 215 | | | | | | 216 (d) | | | |<---HAck---| | 217 | | | | (MN ID) | | 218 | | | | | | 219 | | | |HI/HAck(optional) | 220 (e) | | | |<- - - - ->| | 221 (f) | | | |==DL data=>| | 222 | | | | | | 223 (g) ~~~ | | | | | 224 ~~~ | | | | | 225 | MN-AN connection | AN-MAG connection | | 226 (h) |<---establishment---->|<----establishment----->| | 227 | | | (substitute for UNA) | | 228 | | | | | | 229 (i) |<==================DL data=====================| | 230 | | | | | | 231 (j) |===================UL data====================>|# | 232 | | | #|<==========|# | 233 | | | #|===================>| 234 | | | |HI/HAck(optional) | 235 (k) | | | |<- - - - ->| | 236 / | | | | | | \ 237 |(l) | | | | |--PBU-->| | 238 | | | | | | | | 239 |(m) | | | | |<--PBA--| | 240 \ | | | | | | / 242 Figure 2: Predictive fast handover for PMIPv6 (PAR initiated) 244 The detailed descriptions are as follows: 246 (a) The MN detects that a handover is imminent and reports the 247 identifications of itself (MN ID) and the access point (New AP 248 ID) to which the MN is most likely to move. The MN ID could be 249 the NAI or a Link Layer Address (LLA), or any other suitable 250 identifier. This step is access technology specific. In some 251 cases, the P-AN will determine which AP ID the MN is moving to. 253 (b) The previous access network (P-AN), to which the MN is currently 254 attached, indicates the handover of the MN to the PAR (PMAG). 256 (c) The PAR sends the HI to the NAR. The HI message MUST include 257 the MN ID and SHOULD include the MN-HNP, the MN-IID and the 258 address of the LMA that is currently serving the MN. 260 (d) The NAR sends the HAck back to the PAR. 262 (e) The NAR may optionally request the PAR to buffer or forward 263 packets by setting U or F flags in the HI message, respectively. 264 This step may be combined with steps (c) and (d). 266 (f) If the F flag is set in the previous step, a bi-directional 267 tunnel is established between the PAR and NAR and packets 268 destined for the MN are forwarded from the PAR to the NAR over 269 this tunnel. After decapsulation, those packets may be buffered 270 at the NAR. If the connection between the N-AN and NAR has 271 already been established, those packet may be forwarded towards 272 the N-AN; this is access technology specific. 274 (g) The MN undergoes handover to the New Access Network (N-AN). 276 (h) The MN establishes a connection (e.g., radio channel) with the 277 N-AN, which in turn triggers the establishment of the connection 278 between the N-AN and NAR if it has not been established already 279 (access technology specific). This can be regarded as a 280 substitute for the UNA. 282 (i) The NAR starts to forward packets destined for the MN via the 283 N-AN. 285 (j) The uplink packets from the MN are sent to the NAR via the N-AN 286 and the NAR forwards them to the PAR. The PAR then sends the 287 packets to the LMA that is currently serving the MN. 289 (k) The PAR MAY send the HI message to indicate that the packet 290 forwarding is completed. 292 (l) The NAR (NMAG) sends the Proxy Binding Update (PBU) to the LMA, 293 whose address is provided in (c). Steps (l) and (m) are not 294 part of the fast handover procedure, but shown for reference. 296 (m) The LMA sends back the Proxy Binding Acknowledgment (PBA) to the 297 NAR (NMAG). From this time on, the packets to/from the MN go 298 through the NAR instead of the PAR. 300 According to Section 4 of [RFC5268bis], the PAR establishes a binding 301 between the PCoA and NCoA to forward packets for the MN to the NAR, 302 and the NAR creates a proxy NCE to receive those packets for the NCoA 303 before the MN arrives. In the case of PMIPv6, however, the only 304 address that is used by the MN is MN-HoA. Hence the PAR forwards 305 MN's packets to the NAR instead of the NCoA. FMIPv4 [RFC4988] 306 specifies forwarding when the MN uses HoA as its on-link address 307 rather than the care-of address. The usage in PMIPv6 is similar to 308 that in FMIPv4, where the address is used by the MN is based on Home 309 Network Prefix. Hence the PAR forwards MN's packets to the NAR 310 instead of the NCoA. The NAR then simply decapsulates those packets 311 and delivers them to the MN. Since the NAR obtains the LLA (MN IID) 312 and MN-HNP by the HI, it can create the NCE for the MN and deliver 313 packets to it even before the MN can perform Neighbor Discovery. For 314 the uplink packets from the MN after handover in (j), the NAR 315 forwards the packets to the PAR through the tunnel established in 316 step (f). The PAR then decapsulates and sends them to the LMA. 318 The timing of the context transfer and that of packet forwarding may 319 be different. Thus, a new flag 'F' and the Option Code values for it 320 in the HI message are defined to request forwarding. To request 321 buffering, 'U' flag has already been defined in [RFC5268bis]. If the 322 PAR receives the HI message with F flag set and the Option Code value 323 being 2, it starts forwarding packets for the MN. The HI message 324 with U flag set may be sent earlier if the timing of buffering is 325 different from that of forwarding. If packet forwarding is 326 completed, the PAR MAY send the HI message with F flag set and the 327 Option Code value being 3. By this message, the ARs on both ends can 328 tear down the forwarding tunnel synchronously. 330 The IP addresses in the headers of those user packets are summarized 331 below: 333 In (f), 335 Inner source address: IP address of the CN 337 Inner destination address: HNP or IPv4-MN-HoA 339 Outer source address: IP address of the PAR (PMAG) 340 Outer destination address: IP address of the NAR (NMAG) 342 In (i), 344 Source address: IP address of the CN 346 Destination address: HNP or IPv4-MN-HoA 348 In (j), 350 - from the MN to the NMAG, 352 Source address: HNP or IPv4-MN-HoA 354 Destination address: IP address of the CN 356 - from the NMAG to the PMAG, 358 Inner source address: HNP or IPv4-MN-HoA 360 Inner destination address: IP address of the CN 362 Outer source address: IP address of the NAR (NMAG) 364 Outer destination address: IP address of the PAR (PMAG) 366 - from the PMAG to the LMA, 368 Inner source address: HNP or IPv4-MN-HoA 370 Inner destination address: IP address of the CN 372 Outer source address: IP address of the PAR (PMAG) 374 Outer destination address: IP address of the LMA 376 If the network that the MN has moved to does not support PMIPv6 but 377 only MIPv6 (i.e. there exists a MIPv6 HA) and the MN supports MIPv6 378 at the same time, the MN and HA can exchange BU/BA instead of PBU/PBA 379 in steps (j) and (k). If this is the case, the LMA and HA will most 380 likely be collocated and the LMA (HA) address should be maintained in 381 the new network for communication continuity. Since the LMA (HA) 382 address is transferred to the NAR in step (c), the MN can retrieve it 383 at or after step (g) by e.g. the authentication or DHCP procedure 384 (not shown in the figure). 386 In the case of the reactive handover for PMIPv6, since the MN does 387 not send either the FBU or UNA, it would be more natural that the NAR 388 sends the HI to the PAR after the MN has moved to the new link. The 389 NAR then needs to obtain the information of the PAR beforehand. Such 390 information could be provided, for example, by the MN sending the 391 AP-ID on the old link and/or by the lower-layer procedures between 392 the P-AN and N-AN. The exact method is not specified in this 393 document. Figure 3 illustrates the reactive fast handover procedures 394 for PMIPv6, where the bi-directional tunnel establishment is 395 initiated by the NAR. 397 PMAG NMAG 398 MN P-AN N-AN (PAR) (NAR) LMA 399 | | | | | | 400 (a) ~~~ | | | | | 401 ~~~ | | | | | 402 | MN-AN connection | AN-MAG connection | | 403 (b) |<--establishment-->|<-------establishment------>| | 404 |(MN ID, Old AP ID) | (MN ID, Old AP ID) | | 405 | | |(substitute for UNA and FBU)| | 406 | | | | | | 407 | | | | HI | | 408 (c) | | | |<---(MN ID) ---| | 409 | | | | | | 410 | | | | HAck | | 411 (d) | | | |---(MN ID, --->| | 412 | | | | MN IID, LMAA) | | 413 | | | | | | 414 (e) | | | |===DL data====>|# | 415 |<====================DL data====================|# | 416 | | | | | | 417 (f) |=====================UL data===================>|# | 418 | | | #=|<==============|# | 419 | | | #=|=======================>| 420 (g) | | | |<---HI/HAck--->| | 421 | | | | | | 422 / | | | | | | \ 423 |(h) | | | | |--PBU-->| | 424 | | | | | | | | 425 |(i) | | | | |<--PBA--| | 426 \ | | | | | | / 428 Figure 3: Reactive fast handover for PMIPv6 (NAR initiated) 430 The detailed descriptions are as follows: 432 (a) The MN undergoes handover from the P-AN to the N-AN. The AP-ID 433 on the old link may be provided by the MN to help identify the 434 PMAG on the new link. 436 (b) The MN establishes a connection (e.g., radio channel) with the 437 N-AN, which triggers the establishment of the connection between 438 the N-AN and NAR. The MN ID is transferred to the NAR for the 439 subsequent procedures. The AP-ID on the old link may also be 440 provided by the MN to help identify the PMAG on the new link. 441 This can be regarded as a substitute for the UNA and FBU. 443 (c) The NAR sends the HI to the PAR. The HI message MUST include 444 the MN ID. The Context Request Option MAY be included to 445 request additional context information on the MN to the PAR. 447 (d) The PAR sends the HAck back to the NAR. The HAck message MUST 448 include the HNP and/or IPv4-MN-HoA that is corresponding to the 449 MN ID in the HI message and SHOULD include the MN-IID and the 450 LMA address that is currently serving the MN. The context 451 information requested by the NAR MUST be included. 453 (e) If F flag in the HI is set, a bi-directional tunnel is 454 established between the PAR and NAR and packets destined for the 455 MN are forwarded from the PAR to the NAR over this tunnel. 456 After decapsulation, those packets are delivered to the MN via 457 the N-AN. 459 (f) The uplink packets from the MN are sent to the NAR via the N-AN 460 and the NAR forwards them to the PAR. The PAR then sends the 461 packets to the LMA that is currently serving the MN. 463 (g) The PAR MAY send the HI message to indicate that the packet 464 forwarding is completed. 466 Steps (h)-(i) are the same as (l)-(m) in the predictive fast handover 467 procedures. 469 In step (c), The IP address of the PAR needs to be resolved by the 470 NAR to send the HI to the PAR. This information may come from the 471 N-AN or some database that the NAR can access. 473 Also, in step (c), the NAR could send an unsolicited HAck message to 474 the PAR, which then triggers the HI message from the PAR. By doing 475 so, the directions of HI/HAck messages are aligned with the 476 predictive (PAR-initiated) fast handover. Further study is needed if 477 this call flow is more appropriate than the current one. 479 4.2. IPv4 Support Considerations 481 The motivation and usage scenarios of IPv4 protocol support by PMIPv6 482 are described in [IPv4PMIPv6]. The scope of IPv4 support covers the 483 following two features: 485 o IPv4 Home Address Mobility Support, and 487 o IPv4 Transport Support. 489 As for IPv4 Home Address Mobility Support, the MN acquires IPv4 Home 490 Address (IPv4-MN-HoA) and in the case of handover, the PMAG needs to 491 transfer IPv4-MN-HoA to the NMAG, which is the inner destination 492 address of the packets forwarded on the downlink. In order to 493 support IPv4-MN-HoA, a new option called IPv4 Address Option is 494 defined in this document. In order to provide IPv4 Transport 495 Support, the NMAG needs to know the IPv4 address of the LMA (IPv4- 496 LMAA) to send PMIPv6 signaling messages to the LMA in the IPv4 497 transport network. The above IPv4 Address Option is defined so as to 498 be able to convey IPv4-LMAA. The details of this option are 499 described in [IPv4PMIPv6]. 501 5. Other Considerations 503 The protocol specified in this document enables the NMAG to obtain 504 parameters which would otherwise be available only by communicating 505 with the LMA. For instance, the HNP and/or IPv4-MN-HoA of a MN are 506 made available to the NMAG through context transfer. This allows the 507 NMAG to perform some procedures which may be beneficial. For 508 instance, the NMAG could send a Router Advertisement (RA) with the 509 HNP option to the MN as soon as it's link attachment is detected 510 (e.g., via receipt of a Router Solicitation message). Such an RA is 511 recommended, for example, in scenarios where the MN uses a new radio 512 interface while attaching to the NMAG; since the MN does not have 513 information regarding the new interface, it will not be able to 514 immediately send packets without first receiving an RA with HNP. 515 However, if the subsequent PMIPv6 binding registration for the HNP 516 fails for some reason, then the NMAG MUST withdraw the advertised HNP 517 by sending another RA with zero prefix lifetime for the HNP in 518 question. This operation is the same as that described in Section 519 6.12 of [RFC5213]. 521 The protocol specified in this document is applicable regardless of 522 whether link-layer addresses are used between a MN and its access 523 router. A MN should be able to continue sending packets on the 524 uplink even when it changes link. When link-layer addresses are 525 used, the MN performs Neighbor Unreachability Detection (NUD) 526 [RFC4861], after attaching to a new link, probing the reachability of 527 its default router. If the new router's interface is configured to 528 respond to queries sent to link-layer addresses than its own (e.g., 529 set to promiscuous mode), then it can respond to the NUD probe, 530 providing its link-layer address in the solicited Neighbor 531 Advertisement. While the MN is performing NUD, it can continue to 532 send uplink packets. 534 6. Message Formats 536 This document defines new Mobility Header messages for the extended 537 HI and Hack and new mobility options for conveying context 538 information. 540 6.1. Mobility Header 542 6.1.1. Handover Initiate (HI) 544 This section defines extensions to the HI message in [RFC5268bis]. 545 The format of the Message Data field in the Mobility Header is as 546 follows: 548 0 1 2 3 549 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 550 +---------------+-+-+-----------+ 551 | Sequence # | 552 +-+-+-+-------------------------+---------------+-+-+-----------+ 553 |S|U|F| Reserved | Code | 554 +-+-+-+-----------------------------------------+---------------+ 555 | | 556 . . 557 . Mobility options . 558 . . 559 | | 560 +---------------------------------------------------------------+ 562 IP Fields: 564 Source Address 566 The IP address of PMAG or NMAG 568 Destination Address 570 The IP address of the peer MAG 572 Message Data: 574 Sequence # Same as [RFC5268bis]. 576 S flag Must be set to zero (defined in [RFC5268bis]). 578 U flag Buffer flag. Same as [RFC5268bis]. 580 F flag Forwarding flag. Used to request to forward the packets 581 for the MN. 583 Reserved These fields are unused. They MUST be initialized to 584 zero by the sender and MUST be ignored by the receiver. 586 Code If F flag is not set, the Code MUST be set to zero. 587 Otherwise, the Code value has the following meaning: 589 0: Reserved 591 1: Forwarding is not requested 593 2: Request forwarding 595 3: Indicate the completion of forwarding 597 Mobility options: 599 This field contains one or more mobility options, whose encoding and 600 formats are defined in [RFC3775]. At least one mobility option MUST 601 uniquely identify the target MN (e.g., the Mobile Node Identifier 602 Option defined in RFC4283) and the transferred context MUST be for 603 one MN per message. In addition, the NAR can request necessary 604 mobility options by the Context Request Option defined in this 605 document. 607 Context Request Option 609 This option is used to request context information typically 610 by the NAR to the PAR in the NAR-initiated fast handover. 612 6.1.2. Handover Acknowledge (HAck) 614 This section defines extensions to the HAck message in [RFC5268bis]. 615 The format of the Message Data field in the Mobility Header is as 616 follows: 618 0 1 2 3 619 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 620 +---------------+---------------+ 621 | Sequence # | 622 +-------------------------------+---------------+---------------+ 623 | Reserved | Code | 624 +-----------------------------------------------+---------------+ 625 | | 626 . . 627 . Mobility options . 628 . . 629 | | 630 +---------------------------------------------------------------+ 632 IP Fields: 634 Source Address 636 Copied from the destination address of the 637 Handover Initiate message to which this message 638 is a response. 640 Destination Address 642 Copied from the source address of the Handover 643 Initiate message to which this message is a 644 response. 646 Message Data: 648 Sequence # Same as [RFC5268bis]. 650 Reserved These fields are unused. They MUST be initialized to 651 zero by the sender and MUST be ignored by the receiver. 653 Code: 655 0: Handover Accepted 657 5: Context Transferred successfully, more context 658 available 660 6: Context Transferred successfully, no more 661 context available 662 128: Handover Not Accepted 664 129: Administratively prohibited 666 130: Insufficient resources 668 131: Requested Context Not Available 670 132: Forwarding Not Available 672 Mobility options: 674 This field contains one or more mobility options, whose encoding and 675 formats are defined in [RFC3775]. The mobility option that uniquely 676 identifies the target MN MUST be copied from the corresponding HI 677 message and the transferred context MUST be for one MN per message. 679 Requested option(s) All the context information requested by the 680 Context Request Option in the HI message MUST be present in 681 the HAck message. Otherwise, the Code value MUST be set to 682 131. 684 6.2. Mobility Options 686 6.2.1. Context Request Option 688 This option is sent in the HI message to request context information 689 on the MN. 691 0 1 2 3 692 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 693 +---------------+---------------+---------------+---------------+ 694 | Option-Type | Option-Length | Reserved | 695 +---------------+---------------+-------------------------------+ 696 | Req-type-1 | Req-length-1 | Req-type-2 | Req-length-2 | 697 +---------------------------------------------------------------+ 698 | ... | 700 Context Request Option is typically used for the reactive (NAR- 701 initiated) fast handover mode to retrieve the context information 702 from the PAR. When this option is included in the HI message, the 703 requested option(s) MUST be included in the HAck message. 705 Option-Type TBD1 706 Option-Length The length in octets of this option, not including the 707 Option Type and Option Length fields. 709 Reserved This field is unused. It MUST be initialized to zero 710 by the sender and MUST be ignored by the receiver. 712 Req-type-n The type value for the n'th requested option. 714 Req-length-n The length of the n'th requested option excluding the 715 Req-type-n and Req-length-n fields. 717 In the case where there are only Req-type-n and Req-length-n fields, 718 the value of the Req-length-n is set to zero. If additional 719 information besides the Req-type-n is necessary to uniquely specify 720 the requested context, such information follows after the 721 Req-length-n. For example, when the requested context is the Vendor- 722 Specific Option defined in Section 6.2.8, the requested option format 723 looks as follows: 725 | ... | 726 +---------------+---------------+-------------------------------+ 727 | Req-type-N=19 | Req-length-N=6| Vendor-ID | 728 +-------------------------------+-------------------------------+ 729 | Vendor-ID | Sub-Type | 730 +---------------------------------------------------------------+ 731 | ... | 733 6.2.2. Local Mobility Anchor Address (LMAA) Option 735 This option is used to transfer the Local Mobility Anchor Address 736 (LMAA), with which the MN is currently registered. The detailed 737 definition of the LMAA is described in [RFC5213]. 739 0 1 2 3 740 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 741 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 742 | Option-Type | Option-Length | Reserved | 743 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 744 | | 745 + + 746 | | 747 + Local Mobility Anchor Address + 748 | | 749 + + 750 | | 751 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 753 Option-Type TBD2 755 Option-Length 18 757 Reserved This field is unused. It MUST be initialized to zero 758 by the sender and MUST be ignored by the receiver. 760 Local Mobility Anchor Address 761 The LMA address, with which the MN is currently 762 registered. 764 6.2.3. IPv4 Address Option 766 As described in Section 4.2, if the MN is IPv4-only mode or dual- 767 stack mode, the MN requires IPv4 home address (IPv4-MN-HoA). The 768 IPv4 address of the LMA (IPv4-LMAA) is also needed to send PMIP 769 signaling messages when the ARs and LMA are in an IPv4 transport 770 network. This option has alignment requirement of 4n. 772 0 1 2 3 773 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 774 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 775 | Option-Type | Option-Length | Option-Code | Reserved | 776 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 777 | IPv4 Address | 778 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 780 Option-Type TBD3 782 Option-Length 6 784 Option-Code 786 0 IPv4-MN-HoA 788 1 IPv4-LMAA 790 Reserved This field is unused. It MUST be initialized to zero 791 by the sender and MUST be ignored by the receiver. 793 IPv4 Address IPv4 address specified in Option-Code 795 6.2.4. Home Network Prefix Option 797 This option is used to transfer the home network prefix that is 798 assigned to the MN in the P-AN. The format of this option follows 799 the Home Network Prefix Option defined in [RFC5213]. 801 6.2.5. Mobile Node Interface Identifier (MN IID) Option 803 This option is used to transfer the interface identifier of the MN 804 that is used in the P-AN. The format of this option follows the 805 Mobile Node Interface Identifier Option defined in [RFC5213]. 807 6.2.6. Link-local Address Option 809 This option is used to transfer the link-local address of the PAR 810 (PMAG). The format of this option follows the Link-local Address 811 Option defined in [RFC5213]. 813 6.2.7. GRE Key Option 815 This option is used to transfer the GRE Key for the MN's data flow 816 over the bi-directional tunnel between the PAR and NAR. The message 817 format of this option follows the GRE Key Option defined in [GREKEY]. 818 The GRE Key value uniquely identifies each flow and the sender of 819 this option expects to receive packets of the flow from the peer AR 820 with this value. 822 6.2.8. Vendor-Specific Mobility Option 824 This option is used to transfer any other information defined in this 825 document. The format of this option follows the Vendor-Specific 826 Mobility Option defined in [RFC5094]. The exact values in the Vendor 827 ID, Sub-Type and Data fields are outside the scope of this document. 829 7. Security Considerations 831 Security issues for this document follow those for PMIPv6[RFC5213] 832 and FMIPv6[RFC5268bis]. In PMIPv6, MAG and LMA are assumed to share 833 security association. In FMIPv6, the access routers (i.e., the PMAG 834 and NMAG in this document) are assumed to share security association. 835 No new security risks are identified. Support for integrity 836 protection using IPsec is required, but support for confidentiality 837 is not necessary. 839 8. IANA Considerations 841 This document defines two new mobility options, which are described 842 in Section 6.2. The Type value for these options are assigned from 843 the same numbering space as allocated for the other mobility options, 844 as defined in [RFC3775]. 846 Mobility Options 847 Value Description Reference 848 ----- ------------------------------------- ------------- 849 TBD1 Context Request Option Section 6.2.1 850 TBD2 Local Nobility Anchor Address Option Section 6.2.2 851 TBD3 IPv4 Address Option Section 6.2.3 853 9. References 855 9.1. Normative References 857 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 858 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 860 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 861 Requirement Levels", BCP 14, RFC 2119, March 1997. 863 [RFC5268bis] 864 Koodli, R., Ed., "Mobile IPv6 Fast Handovers", 865 draft-ietf-mipshop-rfc5268bis-00.txt, February 2009. 867 [RFC3775] Johnson, D., "Mobility Support in IPv6", RFC 3775, 868 June 2004. 870 [RFC4988] Koodli, R. and C. Perkins, "Mobile IPv4 Fast Handovers", 871 RFC 4988, October 2007. 873 [RFC5094] Devarapalli, V., Patel, A., and K. Leung, "Mobile IPv6 874 Vendor Specific Option", RFC 5094, December 2007. 876 9.2. Informative References 878 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 879 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 880 September 2007. 882 [IPv4PMIPv6] 883 Wakikawa, R., Ed. and S. Gundavelli, "IPv4 Support for 884 Proxy Mobile IPv6", 885 draft-ietf-netlmm-pmip6-ipv4-support-09.txt, 886 January 2009. 888 [GREKEY] Muhanna, A., Ed., "GRE Key Option for Proxy Mobile IPv6", 889 draft-ietf-netlmm-grekey-option-03.txt, January 2009. 891 Appendix A. Handoff Type Considerations 893 PMIPv6 [RFC5213] defines the Handoff Indicator Option and describes 894 the type of the handoff and the values to set to the option. This 895 document proposes one approach to determining the handoff type by the 896 NMAG when the handoff of the MN is executed. 898 According to [RFC5213], the following handoff types are defined: 900 0) Reserved 902 1) Attachment over a new interface 904 2) Handoff between two different interfaces of the mobile node 906 3) Handoff between mobile access gateways for the same interface 908 4) Handoff state unknown 910 5) Handoff state not changed (Re-registration) 912 By using the MN Interface Identifier (MN IID) option, which is 913 defined in this document, the following solution can be considered. 914 When the NMAG receives the MN IID used in the P-AN from the PMAG via 915 the HI or HAck messages, the NMAG compares it with the new MN IID 916 that is obtained from the MN in the N-AN. If these two MN IIDs are 917 the same, the handover type falls into 3) and the Handoff Indicator 918 value is set to 3. If these two MN IIDs are different, the handover 919 is likely to be 2) since the HI/HAck message exchange implies that 920 this is a handover not a multi-homing, therefore the Handoff 921 Indicator value can be set to 2. If there is no HI/Hack exchange 922 performed prior to the network attachment of the MN in the new 923 network, the NMAG may infer that this is a multi-homing case and set 924 the Handoff Indicator value to 1. In the case of re-registration, 925 the MAG, to which the MN is attached, can determine if the handoff 926 state is not changed, so the MAG can set the HI value to 5 without 927 any additional information. If none of them can be assumed, the NMAG 928 may set the value to 4. 930 Appendix B. Change Log 932 Changes at -00 934 * Added separate sections for MH and ICMP. 936 * Clarified usage of HNP and IPv4-MN-HoA throughout the document. 938 * Added IANA Considerations. 940 * Added section on Other Considerations, including operation of 941 uplink packets when using link-layer addresses, multiple 942 interface usage and transmission of RA to withdraw HNP in the 943 event of failure of PMIP6 registration. 945 * Revised Security Considerations. 947 Changes from -00 to -01 949 * Removed ICMPv6-based message format. 951 * Clarified HI/HAck exchange in the predictive mode (step (e) in 952 Figure 2). 954 * Clarified information retrieval about the PMAG in the reactive 955 mode. 957 * Removed the extension to the GRE Key Option. 959 * Clarified the handoff type considerations in Appendix A. 961 * Home Network Prefix Option, Link-local Address Option and 962 Vendor-Specific Mobility Option are added. 964 Changes from -01 to -02 966 * Aligned HI/HAck message formats with [RFC5268bis]. 968 * Revised Section 8 removing the request for the type assignment 969 of HI/HAck Mobility Headers. 971 Authors' Addresses 973 Hidetoshi Yokota 974 KDDI Lab 975 2-1-15 Ohara, Fujimino 976 Saitama, 356-8502 977 JP 979 Email: yokota@kddilabs.jp 981 Kuntal Chowdhury 982 Starent Networks 983 30 International Place 984 Tewksbury, MA 01876 985 US 987 Email: kchowdhury@starentnetworks.com 989 Rajeev Koodli 990 Starent Networks 991 30 International Place 992 Tewksbury, MA 01876 993 US 995 Email: rkoodli@starentnetworks.com 997 Basavaraj Patil 998 Nokia 999 6000 Connection Drive 1000 Irving, TX 75039 1001 US 1003 Email: basavaraj.patil@nokia.com 1005 Frank Xia 1006 Huawei USA 1007 1700 Alma Dr. Suite 500 1008 Plano, TX 75075 1009 US 1011 Email: xiayangsong@huawei.com