idnits 2.17.1 draft-ietf-mipshop-pfmipv6-01.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 (December 19, 2008) is 5605 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 5268 (Obsoleted by RFC 5568) ** 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-02 == Outdated reference: A later version (-09) exists of draft-ietf-netlmm-grekey-option-01 Summary: 4 errors (**), 0 flaws (~~), 3 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: June 22, 2009 R. Koodli 6 Starent Networks 7 B. Patil 8 Nokia 9 F. Xia 10 Huawei USA 11 December 19, 2008 13 Fast Handovers for Proxy Mobile IPv6 14 draft-ietf-mipshop-pfmipv6-01.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 June 22, 2009. 39 Copyright Notice 41 Copyright (c) 2008 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 . . . . . . . . . . . . . . . . . 21 76 6.2.4. Home Network Prefix Option . . . . . . . . . . . . . . 22 77 6.2.5. Mobile Node Interface Identifier (MN IID) Option . . . 22 78 6.2.6. Link-local Address Option . . . . . . . . . . . . . . 22 79 6.2.7. GRE Key Option . . . . . . . . . . . . . . . . . . . . 22 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 [RFC5268]. 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][RFC5268][RFC3775] for terminology. 115 The following terms and abbreviations are additionally used in this 116 document. The reference network is illustrated in Figure 1. 118 Previous Access Network (P-AN): 119 The access network to which the MN is attached before handover. 121 New Access Network (N-AN): 122 The access network to which the MN is attached after handover. 124 Previous Mobile Access Gateway (PMAG): 125 The MAG that manages mobility related signaling for the MN 126 before handover. In this document, the MAG and the Access 127 Router (AR) are collocated. 129 New Mobile Access Gateway (NMAG): 130 The MAG that manages mobility related signaling for the MN after 131 handover. In this document, the MAG and the Access Router (AR) 132 are collocated. 134 HO-Initiate: 135 A generic signaling that indicates the handover of the MN sent 136 from the P-AN to the PMAG. While this signaling is dependent on 137 the access technology, it is assumed that HO-Initiate can carry 138 the information to identify the MN and to assist the PAR resolve 139 the NAR (e.g., the new access point or base station to which the 140 MN is moving). 142 +----------+ 143 | LMA | 144 | | 145 +----------+ 146 / \ 147 / \ 148 / \ 149 +........../..+ +..\..........+ 150 . +-------+-+ .______. +-+-------+ . 151 . | PAR |()_______)| NAR | . 152 . | (PMAG) | . . | (NMAG) | . 153 . +----+----+ . . +----+----+ . 154 . | . . | . 155 . ___|___ . . ___|___ . 156 . / \ . . / \ . 157 . ( P-AN ) . . ( N-AN ) . 158 . \_______/ . . \_______/ . 159 . | . . | . 160 . +----+ . . +----+ . 161 . | MN | ----------> | MN | . 162 . +----+ . . +----+ . 163 +.............+ +.............+ 165 Figure 1: Reference network for fast handover 167 4. Proxy-based FMIPv6 Protocol Overview 169 In order to improve the performance during handover (when operations 170 such as attachment to a new network and signaling between mobility 171 agents are involved), the PFMIPv6 protocol in this document specifies 172 a bi-directional tunnel between the Previous MAG (PMAG) and the New 173 MAG (NMAG). In order to enable the NMAG to send the Proxy Binding 174 Update (PBU), the Handover Initiate (HI) and Handover Acknowledge 175 (HAck) messages in [RFC5268] are used for context transfer, in which 176 parameters such as MN's NAI, Home Network Prefix (HNP), IPv4 Home 177 Address, are transferred from the PMAG. 179 In this document, the Previous Access Router (PAR) and New Access 180 Router (NAR) are interchangeable with the PMAG and NMAG, 181 respectively. 183 Since a MN is not directly involved with IP mobility protocol 184 operations, it follows that the MN is not directly involved with fast 185 handover procedures either. Hence, the messages involving the MN in 186 [RFC5268] are not used when PMIPv6 is in use. Such messages are the 187 Router Solicitation for Proxy Advertisement (RtSolPr), Proxy Router 188 Advertisement (PrRtAdv), Fast Binding Update (FBU), Fast Binding 189 Acknowledgment (FBack) and Unsolicited Neighbor Advertisement (UNA). 191 4.1. Protocol Operation 193 There are two modes of operation in FMIPv6 [RFC5268]. In the 194 predictive mode of fast handover, a bi-directional tunnel between the 195 PAR and NAR is established prior to the MN's attachment to the NAR. 196 In the reactive mode, this tunnel establishment takes place after the 197 MN attaches to the NAR. Since the MN is not involved in IP mobility 198 signaling in PMIPv6, the sequence of events illustrating the 199 predictive fast handover are shown in Figure 2. 201 PMAG NMAG 202 MN P-AN N-AN (PAR) (NAR) LMA 203 | | | | | | 204 | Report | | | | | 205 (a) |-(MN ID,-->| | | | | 206 | New AP ID)| | | | | 207 | | HO Initiate | | | 208 (b) | |--(MN ID, New AP ID)-->| | | 209 | | | | | | 210 | | | | HI | | 211 (c) | | | |-(MN ID, ->| | 212 | | | | MN IID, LMAA) | 213 | | | | | | 214 (d) | | | |<---HAck---| | 215 | | | | (MN ID) | | 216 | | | | | | 217 | | | |HI/HAck(optional) | 218 (e) | | | |<- - - - ->| | 219 (f) | | | |==DL data=>| | 220 | | | | | | 221 (g) ~~~ | | | | | 222 ~~~ | | | | | 223 | MN-AN connection | AN-MAG connection | | 224 (h) |<---establishment---->|<----establishment----->| | 225 | | | (substitute for UNA) | | 226 | | | | | | 227 (i) |<==================DL data=====================| | 228 | | | | | | 229 (j) |===================UL data====================>|# | 230 | | | #|<==========|# | 231 | | | #|===================>| 232 | | | |HI/HAck(optional) | 233 (k) | | | |<- - - - ->| | 234 / | | | | | | \ 235 |(l) | | | | |--PBU-->| | 236 | | | | | | | | 237 |(m) | | | | |<--PBA--| | 238 \ | | | | | | / 240 Figure 2: Predictive fast handover for PMIPv6 (PAR initiated) 242 The detailed descriptions are as follows: 244 (a) The MN detects that a handover is imminent and reports the 245 identifications of itself (MN ID) and the access point (New AP 246 ID) to which the MN is most likely to move. The MN ID could be 247 the NAI or a Link Layer Address (LLA), or any other suitable 248 identifier. This step is access technology specific. In some 249 cases, the P-AN will determine which AP ID the MN is moving to. 251 (b) The previous access network (P-AN), to which the MN is currently 252 attached, indicates the handover of the MN to the PAR (PMAG). 254 (c) The PAR sends the HI to the NAR. The HI message MUST include 255 the MN ID and SHOULD include the MN-HNP, the MN-IID and the 256 address of the LMA that is currently serving the MN. 258 (d) The NAR sends the HAck back to the PAR. 260 (e) The NAR may optionally request the PAR to buffer or forward 261 packets by setting U or F flags in the HI message, respectively. 262 This step may be combined with steps (c) and (d). 264 (f) If the F flag is set in the previous step, a bi-directional 265 tunnel is established between the PAR and NAR and packets 266 destined for the MN are forwarded from the PAR to the NAR over 267 this tunnel. After decapsulation, those packets may be buffered 268 at the NAR. If the connection between the N-AN and NAR has 269 already been established, those packet may be forwarded towards 270 the N-AN; this is access technology specific. 272 (g) The MN undergoes handover to the New Access Network (N-AN). 274 (h) The MN establishes a connection (e.g., radio channel) with the 275 N-AN, which in turn triggers the establishment of the connection 276 between the N-AN and NAR if it has not been established already 277 (access technology specific). This can be regarded as a 278 substitute for the UNA. 280 (i) The NAR starts to forward packets destined for the MN via the 281 N-AN. 283 (j) The uplink packets from the MN are sent to the NAR via the N-AN 284 and the NAR forwards them to the PAR. The PAR then sends the 285 packets to the LMA that is currently serving the MN. 287 (k) The PAR MAY send the HI message to indicate that the packet 288 forwarding is completed. 290 (l) The NAR (NMAG) sends the Proxy Binding Update (PBU) to the LMA, 291 whose address is provided in (c). Steps (l) and (m) are not 292 part of the fast handover procedure, but shown for reference. 294 (m) The LMA sends back the Proxy Binding Acknowledgment (PBA) to the 295 NAR (NMAG). From this time on, the packets to/from the MN go 296 through the NAR instead of the PAR. 298 According to Section 4 of [RFC5268], the PAR establishes a binding 299 between the PCoA and NCoA to forward packets for the MN to the NAR, 300 and the NAR creates a proxy NCE to receive those packets for the NCoA 301 before the MN arrives. In the case of PMIPv6, however, the only 302 address that is used by the MN is MN-HoA. Hence the PAR forwards 303 MN's packets to the NAR instead of the NCoA. FMIPv4 [RFC4988] 304 specifies forwarding when the MN uses HoA as its on-link address 305 rather than the care-of address. The usage in PMIPv6 is similar to 306 that in FMIPv4, where the address is used by the MN is based on Home 307 Network Prefix. Hence the PAR forwards MN's packets to the NAR 308 instead of the NCoA. The NAR then simply decapsulates those packets 309 and delivers them to the MN. Since the NAR obtains the LLA (MN IID) 310 and MN-HNP by the HI, it can create the NCE for the MN and deliver 311 packets to it even before the MN can perform Neighbor Discovery. For 312 the uplink packets from the MN after handover in (j), the NAR 313 forwards the packets to the PAR through the tunnel established in 314 step (f). The PAR then decapsulates and sends them to the LMA. 316 The timing of the context transfer and that of packet forwarding may 317 be different. Thus, a new flag 'F' and the Option Code values for it 318 in the HI message are defined to request forwarding. To request 319 buffering, 'U' flag has already been defined in [RFC5268]. If the 320 PAR receives the HI message with F flag set and the Option Code value 321 being 2, it starts forwarding packets for the MN. The HI message 322 with U flag set may be sent earlier if the timing of buffering is 323 different from that of forwarding. If packet forwarding is 324 completed, the PAR MAY send the HI message with F flag set and the 325 Option Code value being 3. By this message, the ARs on both ends can 326 tear down the forwarding tunnel synchronously. 328 The IP addresses in the headers of those user packets are summarized 329 below: 331 In (f), 333 Inner source address: IP address of the CN 335 Inner destination address: HNP or IPv4-MN-HoA 337 Outer source address: IP address of the PAR (PMAG) 338 Outer destination address: IP address of the NAR (NMAG) 340 In (i), 342 Source address: IP address of the CN 344 Destination address: HNP or IPv4-MN-HoA 346 In (j), 348 - from the MN to the NMAG, 350 Source address: HNP or IPv4-MN-HoA 352 Destination address: IP address of the CN 354 - from the NMAG to the PMAG, 356 Inner source address: HNP or IPv4-MN-HoA 358 Inner destination address: IP address of the CN 360 Outer source address: IP address of the NAR (NMAG) 362 Outer destination address: IP address of the PAR (PMAG) 364 - from the PMAG to the LMA, 366 Inner source address: HNP or IPv4-MN-HoA 368 Inner destination address: IP address of the CN 370 Outer source address: IP address of the PAR (PMAG) 372 Outer destination address: IP address of the LMA 374 If the network that the MN has moved to does not support PMIPv6 but 375 only MIPv6 (i.e. there exists a MIPv6 HA) and the MN supports MIPv6 376 at the same time, the MN and HA can exchange BU/BA instead of PBU/PBA 377 in steps (j) and (k). If this is the case, the LMA and HA will most 378 likely be collocated and the LMA (HA) address should be maintained in 379 the new network for communication continuity. Since the LMA (HA) 380 address is transferred to the NAR in step (c), the MN can retrieve it 381 at or after step (g) by e.g. the authentication or DHCP procedure 382 (not shown in the figure). 384 In the case of the reactive handover for PMIPv6, since the MN does 385 not send either the FBU or UNA, it would be more natural that the NAR 386 sends the HI to the PAR after the MN has moved to the new link. The 387 NAR then needs to obtain the information of the PAR beforehand. Such 388 information could be provided, for example, by the MN sending the 389 AP-ID on the old link and/or by the lower-layer procedures between 390 the P-AN and N-AN. The exact method is not specified in this 391 document. Figure 3 illustrates the reactive fast handover procedures 392 for PMIPv6, where the bi-directional tunnel establishment is 393 initiated by the NAR. 395 PMAG NMAG 396 MN P-AN N-AN (PAR) (NAR) LMA 397 | | | | | | 398 (a) ~~~ | | | | | 399 ~~~ | | | | | 400 | MN-AN connection | AN-MAG connection | | 401 (b) |<--establishment-->|<-------establishment------>| | 402 |(MN ID, Old AP ID) | (MN ID, Old AP ID) | | 403 | | |(substitute for UNA and FBU)| | 404 | | | | | | 405 | | | | HI | | 406 (c) | | | |<---(MN ID) ---| | 407 | | | | | | 408 | | | | HAck | | 409 (d) | | | |---(MN ID, --->| | 410 | | | | MN IID, LMAA) | | 411 | | | | | | 412 (e) | | | |===DL data====>|# | 413 |<====================DL data====================|# | 414 | | | | | | 415 (f) |=====================UL data===================>|# | 416 | | | #=|<==============|# | 417 | | | #=|=======================>| 418 (g) | | | |<---HI/HAck--->| | 419 | | | | | | 420 / | | | | | | \ 421 |(h) | | | | |--PBU-->| | 422 | | | | | | | | 423 |(i) | | | | |<--PBA--| | 424 \ | | | | | | / 426 Figure 3: Reactive fast handover for PMIPv6 (NAR initiated) 428 The detailed descriptions are as follows: 430 (a) The MN undergoes handover from the P-AN to the N-AN. The AP-ID 431 on the old link may be provided by the MN to help identify the 432 PMAG on the new link. 434 (b) The MN establishes a connection (e.g., radio channel) with the 435 N-AN, which triggers the establishment of the connection between 436 the N-AN and NAR. The MN ID is transferred to the NAR for the 437 subsequent procedures. The AP-ID on the old link may also be 438 provided by the MN to help identify the PMAG on the new link. 439 This can be regarded as a substitute for the UNA and FBU. 441 (c) The NAR sends the HI to the PAR. The HI message MUST include 442 the MN ID. The Context Request Option MAY be included to 443 request additional context information on the MN to the PAR. 445 (d) The PAR sends the HAck back to the NAR. The HAck message MUST 446 include the HNP and/or IPv4-MN-HoA that is corresponding to the 447 MN ID in the HI message and SHOULD include the MN-IID and the 448 LMA address that is currently serving the MN. The context 449 information requested by the NAR MUST be included. 451 (e) If F flag in the HI is set, a bi-directional tunnel is 452 established between the PAR and NAR and packets destined for the 453 MN are forwarded from the PAR to the NAR over this tunnel. 454 After decapsulation, those packets are delivered to the MN via 455 the N-AN. 457 (f) The uplink packets from the MN are sent to the NAR via the N-AN 458 and the NAR forwards them to the PAR. The PAR then sends the 459 packets to the LMA that is currently serving the MN. 461 (g) The PAR MAY send the HI message to indicate that the packet 462 forwarding is completed. 464 Steps (h)-(i) are the same as (l)-(m) in the predictive fast handover 465 procedures. 467 In step (c), The IP address of the PAR needs to be resolved by the 468 NAR to send the HI to the PAR. This information may come from the 469 N-AN or some database that the NAR can access. 471 Also, in step (c), the NAR could send an unsolicited HAck message to 472 the PAR, which then triggers the HI message from the PAR. By doing 473 so, the directions of HI/HAck messages are aligned with the 474 predictive (PAR-initiated) fast handover. Further study is needed if 475 this call flow is more appropriate than the current one. 477 4.2. IPv4 Support Considerations 479 The motivation and usage scenarios of IPv4 protocol support by PMIPv6 480 are described in [IPv4PMIPv6]. The scope of IPv4 support covers the 481 following two features: 483 o IPv4 Home Address Mobility Support, and 485 o IPv4 Transport Support. 487 As for IPv4 Home Address Mobility Support, the MN acquires IPv4 Home 488 Address (IPv4-MN-HoA) and in the case of handover, the PMAG needs to 489 transfer IPv4-MN-HoA to the NMAG, which is the inner destination 490 address of the packets forwarded on the downlink. In order to 491 support IPv4-MN-HoA, a new option called IPv4 Address Option is 492 defined in this document. In order to provide IPv4 Transport 493 Support, the NMAG needs to know the IPv4 address of the LMA (IPv4- 494 LMAA) to send PMIPv6 signaling messages to the LMA in the IPv4 495 transport network. The above IPv4 Address Option is defined so as to 496 be able to convey IPv4-LMAA. The details of this option are 497 described in [IPv4PMIPv6]. 499 5. Other Considerations 501 The protocol specified in this document enables the NMAG to obtain 502 parameters which would otherwise be available only by communicating 503 with the LMA. For instance, the HNP and/or IPv4-MN-HoA of a MN are 504 made available to the NMAG through context transfer. This allows the 505 NMAG to perform some procedures which may be beneficial. For 506 instance, the NMAG could send a Router Advertisement (RA) with the 507 HNP option to the MN as soon as it's link attachment is detected 508 (e.g., via receipt of a Router Solicitation message). Such an RA is 509 recommended, for example, in scenarios where the MN uses a new radio 510 interface while attaching to the NMAG; since the MN does not have 511 information regarding the new interface, it will not be able to 512 immediately send packets without first receiving an RA with HNP. 513 However, if the subsequent PMIPv6 binding registration for the HNP 514 fails for some reason, then the NMAG MUST withdraw the advertised HNP 515 by sending another RA with zero prefix lifetime for the HNP in 516 question. This operation is the same as that described in Section 517 6.12 of [RFC5213]. 519 The protocol specified in this document is applicable regardless of 520 whether link-layer addresses are used between a MN and its access 521 router. A MN should be able to continue sending packets on the 522 uplink even when it changes link. When link-layer addresses are 523 used, the MN performs Neighbor Unreachability Detection (NUD) 524 [RFC4861], after attaching to a new link, probing the reachability of 525 its default router. If the new router's interface is configured to 526 respond to queries sent to link-layer addresses than its own (e.g., 527 set to promiscuous mode), then it can respond to the NUD probe, 528 providing its link-layer address in the solicited Neighbor 529 Advertisement. While the MN is performing NUD, it can continue to 530 send uplink packets. 532 6. Message Formats 534 This document defines new Mobility Header messages for the extended 535 HI and Hack and new mobility options for conveying context 536 information. 538 6.1. Mobility Header 540 6.1.1. Handover Initiate (HI) 542 The MH Type value of the HI Mobility Header is TBD1. The format of 543 the Message Data field in the Mobility Header is as follows: 545 0 1 2 3 546 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 547 +---------------+-+-+-----------+ 548 | Code |U|F| Reserved | 549 +-------------------------------+---------------+-+-+-----------+ 550 | Reserved | Identifier | 551 +-------------------------------+-------------------------------+ 552 | | 553 . . 554 . Mobility options . 555 . . 556 | | 557 +---------------------------------------------------------------+ 559 IP Fields: 561 Source Address 563 The IP address of PMAG or NMAG 565 Destination Address 567 The IP address of the peer MAG 569 Message Data: 571 Code If F flag is not set, the Code MUST be set to zero. 572 Otherwise, the Code value has the following meaning: 574 0: Reserved 576 1: Forwarding is not requested 577 2: Request forwarding 579 3: Indicate the completion of forwarding 581 U flag Buffer flag. Same as [RFC5268]. 583 F flag Forwarding flag. Used to request to forward the packets 584 for the MN. 586 Reserved These fields are unused. They MUST be initialized to zero 587 by the sender and MUST be ignored by the receiver. 589 Identifier Same as [RFC5268]. 591 Mobility options: 593 This field contains one or more mobility options, whose encoding and 594 formats are defined in [RFC3775]. At least one mobility option MUST 595 uniquely identify the target MN (e.g., the Mobile Node Identifier 596 Option defined in RFC4283) and the transferred context MUST be for 597 one MN per message. In addition, the NAR can request necessary 598 mobility options by the Context Request Option defined in this 599 document. 601 Context Request Option 603 This option is used to request context information typically 604 by the NAR to the PAR in the NAR-initiated fast handover. 606 6.1.2. Handover Acknowledge (HAck) 608 The MH Type value of the HAck Mobility Header is TBD2. The format of 609 the Message Data field in the Mobility Header is as follows: 611 0 1 2 3 612 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 613 +---------------+---------------+ 614 | Code | Reserved | 615 +-------------------------------+---------------+---------------+ 616 | Reserved | Identifier | 617 +-------------------------------+-------------------------------+ 618 | | 619 . . 620 . Mobility options . 621 . . 622 | | 623 +---------------------------------------------------------------+ 625 IP Fields: 627 Source Address 629 Copied from the destination address of the 630 Handover Initiate message to which this message 631 is a response. 633 Destination Address 635 Copied from the source address of the Handover 636 Initiate message to which this message is a 637 response. 639 Message Data: 641 Code: 643 0: Handover Accepted 645 5: Context Transferred successfully, more context 646 available 648 6: Context Transferred successfully, no more 649 context available 651 128: Handover Not Accepted 653 129: Administratively prohibited 655 130: Insufficient resources 657 131: Requested Context Not Available 659 132: Forwarding Not Available 661 Reserved These fields are unused. They MUST be initialized to 662 zero by the sender and MUST be ignored by the receiver. 664 Identifier Copied from the corresponding field in the Handover 665 Initiate message to which this message is a response. 667 Mobility options: 669 This field contains one or more mobility options, whose encoding and 670 formats are defined in [RFC3775]. The mobility option that uniquely 671 identifies the target MN MUST be copied from the corresponding HI 672 message and the transferred context MUST be for one MN per message. 674 Requested option(s) All the context information requested by the 675 Context Request Option in the HI message MUST be present in 676 the HAck message. Otherwise, the Code value MUST be set to 677 131. 679 6.2. Mobility Options 681 6.2.1. Context Request Option 683 This option is sent in the HI message to request context information 684 on the MN. 686 0 1 2 3 687 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 688 +---------------+---------------+---------------+---------------+ 689 | Option-Type | Option-Length | Reserved | 690 +---------------+---------------+-------------------------------+ 691 | Req-type-1 | Req-length-1 | Req-type-2 | Req-length-2 | 692 +---------------------------------------------------------------+ 693 | ... | 695 Context Request Option is typically used for the reactive (NAR- 696 initiated) fast handover mode to retrieve the context information 697 from the PAR. When this option is included in the HI message, the 698 requested option(s) MUST be included in the HAck message. 700 Option-Type TBD3 702 Option-Length The length in octets of this option, not including the 703 Option Type and Option Length fields. 705 Reserved This field is unused. It MUST be initialized to zero 706 by the sender and MUST be ignored by the receiver. 708 Req-type-n The type value for the n'th requested option. 710 Req-length-n The length of the n'th requested option excluding the 711 Req-type-n and Req-length-n fields. 713 In the case where there are only Req-type-n and Req-length-n fields, 714 the value of the Req-length-n is set to zero. If additional 715 information besides the Req-type-n is necessary to uniquely specify 716 the requested context, such information follows after the 717 Req-length-n. For example, when the requested context is the Vendor- 718 Specific Option defined in Section 6.2.8, the requested option format 719 looks as follows: 721 | ... | 722 +---------------+---------------+-------------------------------+ 723 | Req-type-N=19 | Req-length-N=6| Vendor-ID | 724 +-------------------------------+-------------------------------+ 725 | Vendor-ID | Sub-Type | 726 +---------------------------------------------------------------+ 727 | ... | 729 6.2.2. Local Mobility Anchor Address (LMAA) Option 731 This option is used to transfer the Local Mobility Anchor Address 732 (LMAA), with which the MN is currently registered. The detailed 733 definition of the LMAA is described in [RFC5213]. 735 0 1 2 3 736 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 737 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 738 | Option-Type | Option-Length | Reserved | 739 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 740 | | 741 + + 742 | | 743 + Local Mobility Anchor Address + 744 | | 745 + + 746 | | 747 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 749 Option-Type TBD4 751 Option-Length 18 753 Reserved This field is unused. It MUST be initialized to zero 754 by the sender and MUST be ignored by the receiver. 756 Local Mobility Anchor Address 757 The LMA address, with which the MN is currently 758 registered. 760 6.2.3. IPv4 Address Option 762 As described in Section 4.2, if the MN is IPv4-only mode or dual- 763 stack mode, the MN requires IPv4 home address (IPv4-MN-HoA). The 764 IPv4 address of the LMA (IPv4-LMAA) is also needed to send PMIP 765 signaling messages when the ARs and LMA are in an IPv4 transport 766 network. This option has alignment requirement of 4n. 768 0 1 2 3 769 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 770 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 771 | Option-Type | Option-Length | Option-Code | Reserved | 772 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 773 | IPv4 Address | 774 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 776 Option-Type TBD5 778 Option-Length 6 780 Option-Code 782 0 IPv4-MN-HoA 784 1 IPv4-LMAA 786 Reserved This field is unused. It MUST be initialized to zero 787 by the sender and MUST be ignored by the receiver. 789 IPv4 Address IPv4 address specified in Option-Code 791 6.2.4. Home Network Prefix Option 793 This option is used to transfer the home network prefix that is 794 assigned to the MN in the P-AN. The format of this option follows 795 the Home Network Prefix Option defined in [RFC5213]. 797 6.2.5. Mobile Node Interface Identifier (MN IID) Option 799 This option is used to transfer the interface identifier of the MN 800 that is used in the P-AN. The format of this option follows the 801 Mobile Node Interface Identifier Option defined in [RFC5213]. 803 6.2.6. Link-local Address Option 805 This option is used to transfer the link-local address of the PAR 806 (PMAG). The format of this option follows the Link-local Address 807 Option defined in [RFC5213]. 809 6.2.7. GRE Key Option 811 This option is used to transfer the GRE Key for the MN's data flow 812 over the bi-directional tunnel between the PAR and NAR. The message 813 format of this option follows the GRE Key Option defined in [GREKEY]. 814 The GRE Key value uniquely identifies each flow and the sender of 815 this option expects to receive packets of the flow from the peer AR 816 with this value. 818 6.2.8. Vendor-Specific Mobility Option 820 This option is used to transfer any other information defined in this 821 document. The format of this option follows the Vendor-Specific 822 Mobility Option defined in [RFC5094]. The exact values in the Vendor 823 ID, Sub-Type and Data fields are outside the scope of this document. 825 7. Security Considerations 827 Security issues for this document follow those for PMIPv6[RFC5213] 828 and FMIPv6[RFC5268]. In PMIPv6, MAG and LMA are assumed to share 829 security association. In FMIPv6, the access routers (i.e., the PMAG 830 and NMAG in this document) are assumed to share security association. 831 No new security risks are identified. Support for integrity 832 protection using IPsec is required, but support for confidentiality 833 is not necessary. 835 8. IANA Considerations 837 This document defines two new Mobility Header types: the Handover 838 Initiate (HI) and the Handover Acknowledge (HAck), which need to be 839 assigned from the same space as the Mobility Header defined in 840 [RFC3775]. 842 Mobility Header 843 Value Description Reference 844 ----- ----------------------------- ------------- 845 TBD1 Handover Initiate Section 6.1.1 846 TBD2 Handover Acknowledge Section 6.1.2 848 This document defines two new mobility options, which are described 849 in Section 6.2. The Type value for these options are assigned from 850 the same numbering space as allocated for the other mobility options, 851 as defined in [RFC3775]. 853 Mobility Options 854 Value Description Reference 855 ----- ------------------------------------- ------------- 856 TBD3 Context Request Option Section 6.2.1 857 TBD4 Local Nobility Anchor Address Option Section 6.2.2 858 TBD5 IPv4 Address Option Section 6.2.3 860 9. References 862 9.1. Normative References 864 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 865 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 867 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 868 Requirement Levels", BCP 14, RFC 2119, March 1997. 870 [RFC5268] Koodli, R., Ed., "Mobile IPv6 Fast Handovers", RFC 5268, 871 June 2008. 873 [RFC3775] Johnson, D., "Mobility Support in IPv6", RFC 3775, 874 June 2004. 876 [RFC4988] Koodli, R. and C. Perkins, "Mobile IPv4 Fast Handovers", 877 RFC 4988, October 2007. 879 [RFC5094] Devarapalli, V., Patel, A., and K. Leung, "Mobile IPv6 880 Vendor Specific Option", RFC 5094, December 2007. 882 9.2. Informative References 884 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 885 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 886 September 2007. 888 [IPv4PMIPv6] 889 Wakikawa, R., Ed. and S. Gundavelli, "IPv4 Support for 890 Proxy Mobile IPv6", 891 draft-ietf-netlmm-pmip6-ipv4-support-02.txt, 892 November 2007. 894 [GREKEY] Muhanna, A., Ed., "GRE Key Option for Proxy Mobile IPv6", 895 draft-ietf-netlmm-grekey-option-01.txt , October 2008. 897 Appendix A. Handoff Type Considerations 899 PMIPv6 [RFC5213] defines the Handoff Indicator Option and describes 900 the type of the handoff and the values to set to the option. This 901 document proposes one approach to determining the handoff type by the 902 NMAG when the handoff of the MN is executed. 904 According to [RFC5213], the following handoff types are defined: 906 0) Reserved 908 1) Attachment over a new interface 910 2) Handoff between two different interfaces of the mobile node 912 3) Handoff between mobile access gateways for the same interface 914 4) Handoff state unknown 916 5) Handoff state not changed (Re-registration) 918 By using the MN Interface Identifier (MN IID) option, which is 919 defined in this document, the following solution can be considered. 920 When the NMAG receives the MN IID used in the P-AN from the PMAG via 921 the HI or HAck messages, the NMAG compares it with the new MN IID 922 that is obtained from the MN in the N-AN. If these two MN IIDs are 923 the same, the handover type falls into 3) and the Handoff Indicator 924 value is set to 3. If these two MN IIDs are different, the handover 925 is likely to be 2) since the HI/HAck message exchange implies that 926 this is a handover not a multi-homing, therefore the Handoff 927 Indicator value can be set to 2. If there is no HI/Hack exchange 928 performed prior to the network attachment of the MN in the new 929 network, the NMAG may infer that this is a multi-homing case and set 930 the Handoff Indicator value to 1. In the case of re-registration, 931 the MAG, to which the MN is attached, can determine if the handoff 932 state is not changed, so the MAG can set the HI value to 5 without 933 any additional information. If none of them can be assumed, the NMAG 934 may set the value to 4. 936 Appendix B. Change Log 938 Changes at -00 940 * Added separate sections for MH and ICMP. 942 * Clarified usage of HNP and IPv4-MN-HoA throughout the document. 944 * Added IANA Considerations. 946 * Added section on Other Considerations, including operation of 947 uplink packets when using link-layer addresses, multiple 948 interface usage and transmission of RA to withdraw HNP in the 949 event of failure of PMIP6 registration. 951 * Revised Security Considerations. 953 Changes from -00 to -01 955 * Removed ICMPv6-based message format. 957 * Clarified HI/HAck exchange in the predictive mode (step (e) in 958 Figure 2). 960 * Clarified information retrieval about the PMAG in the reactive 961 mode. 963 * Removed the extension to the GRE Key Option. 965 * Clarified the handoff type considerations in Appendix A. 967 * Home Network Prefix Option, Link-local Address Option and 968 Vendor-Specific Mobility Option are added. 970 Authors' Addresses 972 Hidetoshi Yokota 973 KDDI Lab 974 2-1-15 Ohara, Fujimino 975 Saitama, 356-8502 976 JP 978 Email: yokota@kddilabs.jp 980 Kuntal Chowdhury 981 Starent Networks 982 30 International Place 983 Tewksbury, MA 01876 984 US 986 Email: kchowdhury@starentnetworks.com 988 Rajeev Koodli 989 Starent Networks 990 30 International Place 991 Tewksbury, MA 01876 992 US 994 Email: rkoodli@starentnetworks.com 996 Basavaraj Patil 997 Nokia 998 6000 Connection Drive 999 Irving, TX 75039 1000 US 1002 Email: basavaraj.patil@nokia.com 1004 Frank Xia 1005 Huawei USA 1006 1700 Alma Dr. Suite 500 1007 Plano, TX 75075 1008 US 1010 Email: xiayangsong@huawei.com