idnits 2.17.1 draft-yokota-mipshop-pfmipv6-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 21. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1033. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1044. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1051. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1057. 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 document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Line 570 has weird spacing: '... S flag not...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 14, 2008) is 5757 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 (ref. '3') (Obsoleted by RFC 5568) ** Obsolete normative reference: RFC 3775 (ref. '4') (Obsoleted by RFC 6275) ** Downref: Normative reference to an Experimental RFC: RFC 4988 (ref. '5') == Outdated reference: A later version (-18) exists of draft-ietf-netlmm-pmip6-ipv4-support-02 Summary: 5 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group H. Yokota 3 Internet-Draft KDDI Lab 4 Intended status: Standards Track K. Chowdhury 5 Expires: January 15, 2009 R. Koodli 6 Starent Networks 7 B. Patil 8 Nokia 9 F. Xia 10 Huawei USA 11 July 14, 2008 13 Fast Handovers for PMIPv6 14 draft-yokota-mipshop-pfmipv6-03.txt 16 Status of this Memo 18 By submitting this Internet-Draft, each author represents that any 19 applicable patent or other IPR claims of which he or she is aware 20 have been or will be disclosed, and any of which he or she becomes 21 aware will be disclosed, in accordance with Section 6 of BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt. 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 This Internet-Draft will expire on January 15, 2009. 41 Copyright Notice 43 Copyright (C) The IETF Trust (2008). 45 Abstract 47 This document specifies the usage of FMIPv6 when Proxy Mobile IPv6 is 48 applied for the mobility management protocol. Necessary amendments 49 are shown for FMIPv6 to work under the condition that the mobile node 50 does not have IP mobility functionality and it is not involved with 51 either MIPv6 or FMIPv6 operations. 53 Table of Contents 55 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 56 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 58 4. Proxy-based FMIPv6 Protocol Overview . . . . . . . . . . . . . 7 59 4.1. Protocol Operation . . . . . . . . . . . . . . . . . . . . 7 60 4.2. Handoff Type Considerations . . . . . . . . . . . . . . . 13 61 4.3. IPv4 Support Considerations . . . . . . . . . . . . . . . 14 62 5. Message Format . . . . . . . . . . . . . . . . . . . . . . . . 15 63 5.1. Handover Initiate (HI) . . . . . . . . . . . . . . . . . . 15 64 5.2. Handover Acknowledge (HAck) . . . . . . . . . . . . . . . 16 65 5.3. Context Request Option . . . . . . . . . . . . . . . . . . 18 66 5.4. Tunnel-ID Option . . . . . . . . . . . . . . . . . . . . . 19 67 5.5. Mobile Node Interface Identifier (MN IID) Option . . . . . 19 68 5.6. New option-code for the IP Address Option . . . . . . . . 20 69 5.7. IPv4 Address Option . . . . . . . . . . . . . . . . . . . 20 70 5.8. Vendor Specific Option . . . . . . . . . . . . . . . . . . 21 71 6. Mobility Header-based HI/HAck messages . . . . . . . . . . . . 23 72 6.1. Handover Initiate (HI) Mobility Header . . . . . . . . . . 23 73 6.2. Handover Acknowledge (HAck) Mobility Header . . . . . . . 23 74 7. IPv4 Transport Support . . . . . . . . . . . . . . . . . . . . 24 75 7.1. Handover Initiate (HI) . . . . . . . . . . . . . . . . . . 24 76 7.2. Handover Acknowledge (HAck) . . . . . . . . . . . . . . . 24 77 8. Security Considerations . . . . . . . . . . . . . . . . . . . 26 78 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 79 9.1. Normative References . . . . . . . . . . . . . . . . . . . 27 80 9.2. Informative References . . . . . . . . . . . . . . . . . . 27 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28 82 Intellectual Property and Copyright Statements . . . . . . . . . . 29 84 1. Requirements notation 86 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 87 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 88 document are to be interpreted as described in [1]. 90 2. Introduction 92 Proxy Mobile IPv6 [2] provides IP mobility to a mobile node that does 93 not have Mobile IPv6 [4] functionality. The proxy agent in the 94 network performs the signaling and does the mobility management on 95 behalf of the mobile node. Although the signaling between the mobile 96 node and the network can be saved, the basic performance for handover 97 such as handover latency is considered to be not different from that 98 of Mobile IPv6. 100 To improve handover latency due to Mobile IPv6 procedures, fast 101 handovers for MIPv6 is specified in FMIPv6[3]. By applying the 102 FMIPv6 solution to Proxy MIPv6 as well, it is expected that the 103 handover latency due to Proxy MIPv6 procedures will be improved as 104 much. However, Mobile IPv6 and Proxy MIPv6 are intrinsically 105 different in the sense that the mobile node is not involved with IP 106 mobility and hence does not directly handle the care-of address. 107 Hence, there are some issues in directly applying the original 108 specifications of FMIPv6 to Proxy MIPv6. This document identifies 109 those differences and specifies amendments to apply FMIPv6 solution 110 principles to Proxy MIPv6. 112 3. Terminology 114 This document refers to [2][3][4] for terminology. The following 115 terms and abbreviations are additionally used in this document. The 116 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. 133 HO-Initiate: 134 A generic signaling that indicates the handover of the MN sent 135 from the P-AN to the PMAG. While this signaling is dependent on 136 the access technology, it is assumed that HO-Initiate can carry 137 the information to specify the MN and to help the PAR resolve 138 the NAR (e.g. the new access point or base station to which the 139 MN is moving to). 141 +----------+ 142 | LMA | 143 | | 144 +----------+ 145 / \ 146 / \ 147 / \ 148 +........../..+ +..\..........+ 149 . +-------+-+ .______. +-+-------+ . 150 . | PAR |()_______)| NAR | . 151 . | (PMAG) | . . | (NMAG) | . 152 . +----+----+ . . +----+----+ . 153 . | . . | . 154 . ___|___ . . ___|___ . 155 . / \ . . / \ . 156 . ( P-AN ) . . ( N-AN ) . 157 . \_______/ . . \_______/ . 158 . | . . | . 159 . +----+ . . +----+ . 160 . | MN | ----------> | MN | . 161 . +----+ . . +----+ . 162 +.............+ +.............+ 164 Figure 1: Reference network for fast handover 166 4. Proxy-based FMIPv6 Protocol Overview 168 To reduce the handover latency due to signaling between the MAGs 169 (Mobile Access Gateways) and the LMA (Local Mobility Anchor), FMIPv6 170 in this document specifies a bi-directional tunnel between the 171 Previous MAG (PMAG) and the New MAG (NMAG). To expedite sending the 172 Proxy Binding Update (PBU) by the NMAG, FMIPv6 protocol is also used 173 for context transfer, whereby the necessary information for sending 174 the PBU is transferred from the PMAG. 176 In this document, the Previous Access Router (PAR) and New Access 177 Router (NAR) are interchangeable with the PMAG and NMAG, 178 respectively. 180 Since the MN is not directly involved with IP mobility, it is natural 181 to think that the MN is not directly involved with fast handover 182 procedures, either at least from the IP layer perspective. 183 Therefore, among the messages for fast handovers defined in [3], 184 those that are initiated by and targeted to the MN are not used when 185 PMIPv6 is in use. Such messages are the Router Solicitation for 186 Proxy Advertisement (RtSolPr), Proxy Router Advertisement (PrRtAdv), 187 Fast Binding Update (FBU), Fast Binding Acknowledgment (FBack) and 188 Unsolicited Neighbor Advertisement (UNA). 190 4.1. Protocol Operation 192 FMIPv6 [3] specifies two types of fast handovers; the predictive fast 193 handover and the reactive fast handover. In the predictive fast 194 handover, the MN sends the FBU to the PAR before handover, which then 195 triggers to establish a bi-directional tunnel between the PAR and NAR 196 to transfer packets for the MN. On the other hand, in the reactive 197 fast handover, the FBU is sent by the MN to the NAR after it has 198 moved to the new network, which is then transferred to the PAR to 199 trigger to send the Handover Initiate (HI) towards the NAR. Based on 200 the above observations, the fast handover procedures for PMIPv6 need 201 to work without the involvement of the MN. Figure 2 illustrates the 202 predictive fast handover procedures for PMIPv6, where the bi- 203 directional tunnel establishment is initiated by the PAR. 205 PMAG NMAG 206 MN P-AN N-AN (PAR) (NAR) LMA 207 | | | | | | 208 | Report | | | | | 209 (a) |-(MN ID,-->| | | | | 210 | New AP ID)| | | | | 211 | | HO Initiate | | | 212 (b) | |--(MN ID, New AP ID)-->| | | 213 | | | | | | 214 | | | | HI | | 215 (c) | | | |-(MN ID, ->| | 216 | | | MN-HoA,MN IID,LMA) | 217 | | | | | | 218 (d) | | | |<---HAck---| | 219 | | | | (MN ID) | | 220 | | | | | | 221 | | | | HI/HAck | | 222 (e) | | | |<--------->| | 223 (f) | | | |==DL data=>| | 224 | | | | | | 225 (g) ~~~ | | | | | 226 ~~~ | | | | | 227 | MN-AN connection | AN-MAG connection | | 228 (h) |<---establishment---->|<----establishment----->| | 229 | | | (substitute for UNA) | | 230 | | | | | | 231 (i) |<==================DL data=====================| | 232 | | | | | | 233 (j) |===================UL data====================>|# | 234 | | | #|<==========|# | 235 | | | #|===================>| 236 | | | | HI/HAck | | 237 (k) | | | |<--------->| | 238 / | | | | | | \ 239 |(l) | | | | |--PBU-->| | 240 | | | | | | | | 241 |(m) | | | | |<--PBA--| | 242 \ | | | | | | / 244 Figure 2: Predictive fast handover for PMIPv6 (PAR initiated) 246 The detailed descriptions are as follows: 248 (a) The MN detects that a handover is imminent and reports the 249 identifications of itself (MN ID) and the access point (New AP 250 ID) to which the MN is most likely to move. These IDs can be 251 Link-Layer Addresses (LLAs) or any other types of IDs. This 252 step is access technology specific. In some cases, the P-AN 253 will figure out which AP ID the MN is moving to. 255 (b) The previous access network (P-AN), to which the MN is currently 256 attached, indicates the handover of the MN to the PAR (PMAG). 258 (c) The PAR sends the HI to the NAR. The HI message MUST include 259 the MN ID and SHOULD include the MN-HoA, the MN-IID and the 260 address of the LMA that is currently serving the MN. 262 (d) The NAR sends back the Hack to the PAR. 264 (e) The NAR requests the PAR to buffer or forward packets by setting 265 U or F flags in the HI message, respectively. 267 (f) If F flag is set in the HI at the previous step, a bi- 268 directional tunnel is established between the PAR and NAR and 269 packets destined for the MN are forwarded from the PAR to the 270 NAR over this tunnel. After detunneling, those packets may be 271 buffered at the NAR. If the connection between the N-AN and NAR 272 has already been established, those packet may reach the N-AN 273 (access technology specific). 275 (g) The MN hands over to the New Access Network (N-AN). 277 (h) The MN establishes a connection (e.g. radio channel) with the 278 N-AN, which in turn triggers the establishment of the connection 279 between the N-AN and NAR if it has not been established, yet 280 (access technology specific). This can be regarded as a 281 substitute for the UNA. 283 (i) The NAR starts to transfer packets destined for the MN via the 284 N-AN. 286 (j) The uplink packets from the MN are sent to the NAR via the N-AN 287 and the NAR forwards them to the PAR. The PAR then sends the 288 packets to the LMA that is currently serving the MN. 290 (k) The PAR MAY send the HI message to indicate that the packet 291 forwarding is completed. 293 (l) The NAR (NMAG) sends the Proxy Binding Update (PBU) to the LMA, 294 whose address can be obtained in (c). Steps (l) and (m) are not 295 part of the fast handover procedure, but shown for reference. 297 (m) The LMA sends back the Proxy Binding Acknowledgment (PBA) to the 298 NAR (NMAG). From this time on, the packets to/from the MN go 299 through the NAR instead of the PAR. 301 According to Section 4 of [3], the PAR establishes a binding between 302 the PCoA and NCoA to forward packets for the MN to the NAR, and the 303 NAR creates a proxy NCE to receive those packets for the NCoA before 304 the MN arrives. In the case of PMIPv6, however, the only address 305 that is used by the MN is MN-HoA, so the PAR transfers the packets 306 for the MN to the NAR instead of the NCoA. The NAR then simply 307 detunnels (decapsulates) those packets and delivers them to the MN. 308 If the NAR obtains the LLA (=MN ID) and MN-HoA by the HI, it can 309 create the NCE for the MN and deliver packets to it before the MN 310 performs the ND. For the uplink packets from the MN after handover 311 in (j), the NAR forwards the packets to the PAR through the tunnel 312 established in step (f). The PAR then decapsulates and sends them to 313 the LMA. 315 The timing of the context transfer and that of packet forwarding may 316 be different. Thus, a new flag 'F' and the Option Code values for it 317 in the HI message are defined to request forwarding. To request 318 buffering, 'U' flag has already been defined in [3]. If the PAR 319 receives the HI message with F flag set and the Option Code value 320 being 2, it starts forwarding packets for the MN. The HI message 321 with U flag set may be sent earlier if the timing of buffering is 322 different from that of forwarding. If packet forwarding is 323 completed, the PAR MAY send the HI message with F flag set and the 324 Option Code value being 3. By this message, the ARs on both ends can 325 tear down the forwarding tunnel synchronously. 327 The IP addresses in the headers of those user packets are summarized 328 below: 330 In (f), 332 Inner source address: IP address of the CN 334 Inner destination address: MN-HoA 336 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: MN-HoA 346 In (j), 348 - from the MN to the NMAG, 349 Source address: MN-HoA 351 Destination address: IP address of the CN 353 - from the NMAG to the PMAG, 355 Inner source address: MN-HoA 357 Inner destination address: IP address of the CN 359 Outer source address: IP address of the NAR (NMAG) 361 Outer destination address: IP address of the PAR (PMAG) 363 - from the PMAG to the LMA, 365 Inner source address: MN-HoA 367 Inner destination address: IP address of the CN 369 Outer source address: IP address of the PAR (PMAG) 371 Outer destination address: IP address of the LMA 373 If the network that the MN has moved in does not support PMIPv6 but 374 only MIPv6 (i.e. there exists a MIPv6 HA) and the MN supports MIPv6 375 at the same time, the MN and HA can exchange BU/BA instead of PBU/PBA 376 in steps (j) and (k). If this is the case, the LMA and HA will most 377 likely be collocated and the LMA (HA) address should be maintained in 378 the new network for communication continuity. Since the LMA (HA) 379 address is transferred to the NAR in step (c), the MN can retrieve it 380 at or after step (g) by e.g. the authentication or DHCP procedure 381 (not shown in the figure). 383 In the case of the reactive handover for PMIPv6, since the MN does 384 not send either the FBU or UNA, it would be more natural that the NAR 385 sends the HI to the PAR after the MN has moved to the new network. 386 Figure 3 illustrates the reactive fast handover procedures for 387 PMIPv6, where the bi-directional tunnel establishment is initiated by 388 the NAR. 390 PMAG NMAG 391 MN P-AN N-AN (PAR) (NAR) LMA 392 | | | | | | 393 (a) ~~~ | | | | | 394 ~~~ | | | | | 395 | MN-AN connection | AN-MAG connection | | 396 (b) |<--establishment-->|<-------establishment------>| | 397 | (MN ID) | (MN ID) | | 398 | | |(substitute for UNA and FBU)| | 399 | | | | | | 400 | | | | HI | | 401 (c) | | | |<---(MN ID) ---| | 402 | | | | | | 403 | | | | HAck | | 404 (d) | | | |---(MN ID, --->| | 405 | | | MN-HoA,MN IID,LMA) | 406 | | | | | | 407 (e) | | | |===DL data====>|# | 408 |<====================DL data====================|# | 409 | | | | | | 410 (f) |=====================UL data===================>|# | 411 | | | #=|<==============|# | 412 | | | #=|=======================>| 413 (g) | | | |<---HI/HAck--->| | 414 | | | | | | 415 / | | | | | | \ 416 |(h) | | | | |--PBU-->| | 417 | | | | | | | | 418 |(i) | | | | |<--PBA--| | 419 \ | | | | | | / 421 Figure 3: Reactive fast handover for PMIPv6 (NAR initiated) 423 The detailed descriptions are as follows: 425 (a) The MN hands over from the P-AN to the N-AN. 427 (b) The MN establishes a connection (e.g. radio channel) with the 428 N-AN, which triggers the establishment of the connection between 429 the N-AN and NAR. The MN ID is transferred to the NAR for the 430 subsequent procedures. This can be regarded as a substitute for 431 the UNA and FBU. 433 (c) The NAR sends the HI to the PAR. The HI message MUST include 434 the MN ID. The Context Request Option MAY be included to 435 request additional context information on the MN to the PAR. 437 (d) The PAR sends back the HAck to the NAR. The HAck message MUST 438 include the MN-HoA that is corresponding to the MN ID in the HI 439 message and SHOULD include the MN-IID and the LMA address that 440 is currently serving the MN. The context information requested 441 by the NAR MUST be included. 443 (e) If F flag in the HI is set, a bi-directional tunnel is 444 established between the PAR and NAR and packets destined for the 445 MN are transferred from the PAR to the NAR over this tunnel. 446 After detunneling, those packets are delivered to the MN via the 447 N-AN. 449 (f) The uplink packets from the MN are sent to the NAR via the N-AN 450 and the NAR forwards them to the PAR. The PAR then sends the 451 packets to the LMA that is currently serving the MN. 453 (g) The PAR MAY send the HI message to indicate that the packet 454 forwarding is completed. 456 Steps (h)-(i) are the same as (l)-(m) in the predictive fast handover 457 procedures. 459 In step (c), The IP address of the PAR needs to be resolved by the 460 NAR to send the HI to the PAR. This information may come from the 461 N-AN or some database that the NAR can access. 463 Also, in step (c), the NAR could send an unsolicited HAck message to 464 the PAR, which then triggers the HI message from the PAR. By doing 465 so, the directions of HI/HAck messages are aligned with the 466 predictive (PAR-initiated) fast handover. Further study is needed if 467 this call flow is more appropriate than the current one. 469 4.2. Handoff Type Considerations 471 PMIPv6 [2] defines the Handoff Indicator Option and describes the 472 type of the handoff and the values to set to the option. This 473 document proposes one approach to determining the handoff type. 475 According to [2], the following handoff types are defined: 477 0) Reserved 479 1) Attachment over a new interface 480 2) Handoff between two different interfaces of the mobile node 482 3) Handoff between mobile access gateways for the same interface 484 4) Handoff state unknown 486 5) Handoff state not changed (Re-registration) 488 By using the MN Interface Identification (MN IID) option, which is 489 defined in this document, the following solution can be considered. 490 When the NMAG receives the MN IID used in the P-AN from the PMAG via 491 the HI or HAck messages, the NMAG compares it with the new MN IID 492 that is obtained from the MN in the N-AN. If these two MN IIDs are 493 the same, the handover type falls into 3) and the Handoff Indicator 494 value is set to 3. If these two MN IIDs are different, the handover 495 is likely to be 2) since the HI/HAck message exchange implies that 496 this is a handover not a multi-homing, therefore the Handoff 497 Indicator value can be set to 2. If there is no HI/Hack exchange 498 performed prior to the network attachment of the MN in the new 499 network, the NMAG may infer that this is a multi-homing case and set 500 the Handoff Indicator value to 1. In the case of re-registration, 501 the MAG, to which the MN is attached, can determine if the handoff 502 state is not changed, so the MAG can set the HI value to 5 without 503 any additional information. If none of them can be assumed, the NMAG 504 may set the value to 4. 506 4.3. IPv4 Support Considerations 508 The motivation and usage scenarios of IPv4 protocol support by PMIPv6 509 are described in [6]. The scope of IPv4 support covers the following 510 two features: 512 o IPv4 Home Address Mobility Support, and 514 o IPv4 Transport Support. 516 As for IPv4 Home Address Mobility Support, the MN acquires IPv4 Home 517 Address (IPv4-MN-HoA) and in the case of handover, the PMAG needs to 518 transfer IPv4-MH-HoA to the NMAG, which is the inner destination 519 address of the downlink forwarded packets. To this end, a new option 520 called IPv4 Address Option is defined in this document. As for IPv4 521 Transport Support, the NMAG needs to know the IPv4 address of the LMA 522 (IPv4-LMAA) to send PMIPv6 signaling messages to the LMA in the IPv4 523 transport network. The above IPv4 Address Option is defined so as to 524 be able to convey IPv4-LMAA. The details of this option are 525 described in Section 5.7. 527 5. Message Format 529 This document extends the HI and HAck to work with PMIPv6 and further 530 defines new options and option-codes for the IP Address option to 531 convey context information. 533 5.1. Handover Initiate (HI) 535 0 1 2 3 536 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 537 +---------------+---------------+-------------------------------+ 538 | Type | Code | Checksum | 539 +---------------+-+-+-+-+-------+-------------------------------+ 540 | Subtype |S|U|P|F|Resv'd | Identifier | 541 +---------------+-+-+-+-+-------+-------------------------------+ 542 | Options ... 543 +------------------------- 545 IP Fields: 547 Source Address 549 The IP address of PAR or NAR 551 Destination Address 553 The IP address of the peer AR 555 All the other fields follow [3]. 557 ICMP Fields: 559 Code If P flag is not set, the Code value follows [3]. If P 560 flag is set but F flag is not set, the Code MUST be set to 561 zero. If both P flag and F flag are set, the Code value 562 has the following meaning: 564 0, 1: See [3]. 566 2: Request forwarding 568 3: Indicate the completion of forwarding 570 S flag not used when P flag is set and MUST be set to zero. 572 U flag Buffer flag. Same as [3]. 574 P flag Proxy flag. When set, PMIPv6 instead of MIPv6 is assumed 575 for the mobility management protocol. All the involved 576 nodes MUST perform based on this document for fast handover 577 procedures. 579 F flag Forwarding flag. Used to request to forward the packets 580 for the MN. 582 All the other fields follow [3]. 584 Valid options: 586 MN ID This identifier can be the link-layer address of the MN or 587 any other type of information that can uniquely identify 588 the MN. If the link-layer address is used as the MN ID, 589 the Link-Layer Address (LLA) option defined in [3] MUST be 590 used. 592 MN-HoA This information is stored in the IP Address option. 594 MN-IID This information is stored in the MN Interface Identifier 595 option. 597 Context Request Option Context Request Option This option is used to 598 request context information typically by the NAR to the PAR 599 in the NAR-initiated fast handover. 601 5.2. Handover Acknowledge (HAck) 603 0 1 2 3 604 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 605 +---------------+---------------+--------------------------------+ 606 | Type | Code | Checksum | 607 +---------------+-+-------------+--------------------------------+ 608 | Subtype |P| Reserved | Identifier | 609 +---------------+-+-------------+--------------------------------+ 610 | Options ... 611 +------------------------ 613 IP Fields: 615 Source Address 617 Copied from the destination address of the 618 Handover Initiate message to which this message 619 is a response. 621 Destination Address 623 Copied from the source address of the Handover 624 Initiate message to which this message is a 625 response. 627 All the other fields follow [3]. 629 ICMP Fields: 631 Code: 633 0: Handover Accepted 635 5: Context Transferred successfully, more context 636 available 638 6: Context Transferred successfully, no more 639 context available 641 128: Handover Not Accepted 643 129: Administratively prohibited 645 130: Insufficient resources 647 131: No context available 649 132: Forwarding Not Available 651 P flag Proxy flag. When set, PMIPv6 instead of MIPv6 is assumed 652 for the mobility management protocol. All the involved 653 nodes MUST perform based on this document for fast handover 654 procedures. 656 Valid options: 658 MN ID Copied from the corresponding HI message. 660 MN-HoA Stored in the IP Address option so that the NAR can use 661 this address for the PBU. 663 MN-IID This information is stored in the MN Interface Identifier 664 option. 666 LMA Stored in the IP Address option so that the NAR can use 667 this address for the PBU. 669 Requested option(s) All the other context information requested by 670 the Context Request Option in the HI message. 672 5.3. Context Request Option 674 This option is sent in the HI message to request context information 675 on the MN. 677 0 1 2 3 678 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 679 +---------------+---------------+---------------+---------------+ 680 | Type | Length | Option-Code | Reserved | 681 +---------------------------------------------------------------+ 682 | Reserved | 683 +---------------+---------------+-------------------------------+ 684 | Req-type-1 | Req-option-1 | Padding | 685 +---------------------------------------------------------------+ 686 | Padding | 687 +---------------------------------------------------------------+ 688 | ... | 689 +---------------+---------------+-------------------------------+ 690 | Req-type-N | Req-option-N | Vendor/Org-ID | 691 +-------------------------------+-------------------------------+ 692 | Vendor/Org-ID | VS-Type | 693 +---------------------------------------------------------------+ 694 | ... | 696 Context Request Option is typically used for the reactive (NAR- 697 initiated) fast handover mode to retrieve the context information 698 from the PAR. When this option is included in the HI message, the 699 requested option(s) MUST be included in the HAck message. 701 Type TBD 703 Length Number of requested context(s)+1. 705 Option-Code 0 707 Req-type-n The Type value for the requested option. 709 Req-option-n The Option-Code for the requested option. 711 Padding 6 octets of padding are added if the requested type is 712 not the Vendor-Specific Option. MUST be set to zero. 714 Vendor/Org-ID When the Vendor Specific Option is requested, the 3rd 715 to 6th octets are used for the Vendor/Org-ID defined 716 in Section 5.8. 718 VS-Type When the Vendor Specific Option is requested, the 7th 719 to 8th octets are used for the VS-Type defined in 720 Section 5.8. 722 5.4. Tunnel-ID Option 724 This option is used to transfer additional information that 725 associates the MN with the tunnel used by the MN. The exact format 726 of the Tunnel-ID is outside the scope of this document. 728 0 1 2 3 729 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 730 +---------------+---------------+---------------+---------------+ 731 | Type | Length | Option-Code | TID-Length | 732 +---------------------------------------------------------------+ 733 | Tunnel-ID ... 734 +------------------------------ 736 Type TBD 738 Length The size of this option is in 8 octets including the 739 Type, Length and Option-Code. 741 Option-Code 0 743 TID-Length The length of the Tunnel-ID in octets 745 Tunnel-ID The Tunnel-ID value. 747 5.5. Mobile Node Interface Identifier (MN IID) Option 749 This option is used to transfer the interface identifier of the MN 750 that is used in the P-AN. The format of the interface identifier 751 follows the Mobile Node Interface Identifier Option defined in [2]. 753 0 1 2 3 754 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 755 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 756 | Type | Length | Option-Code | MN IID-Length | 757 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 758 | | 759 + Interface Identifier + 760 | | 761 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 763 Type TBD 765 Length The size of this option is in 8 octets including the 766 Type, Length and Option-Code. 768 Option-Code 0 770 MN IID-Length The length of the MN IID in octets 772 Interface Identifier 773 The Interface Identifier value of the MN that is used 774 in the P-AN. 776 5.6. New option-code for the IP Address Option 778 To convey the MN-HoA and LMA in the HI or HAck message, new Option- 779 Codes for the IP Address Option[3] are defined: 781 Option-Code 783 4 MN-HoA 785 5 LMA 787 5.7. IPv4 Address Option 789 As described in Section 4.3, if the MN is IPv4-only mode or dual- 790 stack mode, the MN requires IPv4 home address (IPv4-MN-HoA). The 791 IPv4 address of the LMA (IPv4-LMAA) is also needed to send PMIP 792 signaling messages when the ARs and LMA are in an IPv4 transport 793 network. 795 0 1 2 3 796 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 797 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 798 | Type | Length | Option-Code | Reserved | 799 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 800 | IPv4 Address | 801 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 803 Type TBD 805 Length 1 807 Option-Code 809 0 IPv4-MN-HoA 811 1 IPv4-LMAA 813 IPv4 Address IPv4 address specified in Option-Code 815 5.8. Vendor Specific Option 817 This option is to send other information than defined in this 818 document. Many of the context information can be vendor specific 819 (access technology specific). This option is used for such 820 information. 822 0 1 2 3 823 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 824 +---------------+---------------+---------------+---------------+ 825 | Type | Length | Option-Code | Reserved | 826 +---------------------------------------------------------------+ 827 | Vendor/Org-ID | 828 +-------------------------------+-------------------------------+ 829 | VS-Type | VS-Length | 830 +---------------------------------------------------------------+ 831 | VS-Value ... 832 +------------------------------ 834 Type TBD 836 Length The size of this option is in 8 octets including the 837 Type, Length and Option-Code. 839 Option-Code 0 841 Vendor/Org-ID The SMI Network Management Private Enterprise Code of 842 the Vendor/Organization as defined by IANA. 844 VS-Type The type of the Vendor-Specific information carried in 845 this option. The type value is defined by the vendor 846 or organization specified by Vendor/Org-ID. 848 VS-Length The length of the Vendor-Specific information carried 849 in this option. 851 VS-Value The value of the Vendor-Specific information carried 852 in this option. 854 6. Mobility Header-based HI/HAck messages 856 If ICMPv6 is not allowed between the PAR and NAR for security reason 857 (e.g. blocked by the firewall), the HI and HAck messages MAY be 858 exchanged in the form of the Mobility Header [4]. Which type of HI/ 859 HAck message is used MUST be preconfigured both in the PAR and NAR. 861 6.1. Handover Initiate (HI) Mobility Header 863 The MH Type value of the HI Mobility Header is TBD1. The format of 864 the Message Data field in the Mobility Header is as follows: 866 0 1 2 3 867 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 868 +---------------+---------------+ 869 | Type | Code | 870 +---------------+-+-+-+-+-------+---------------+---------------+ 871 | Subtype |S|U|P|F| Resv'd| Identifier | 872 +---------------+-+-+-+-+-------+-------------------------------+ 873 | Options ... 874 +------------------------ 876 The usages of all the above fields are the same as those in the 877 original HI message. 879 6.2. Handover Acknowledge (HAck) Mobility Header 881 The MH Type value of the HAck Mobility Header is TBD2. The format of 882 the Message Data field in the Mobility Header is as follows: 884 0 1 2 3 885 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 886 +---------------+---------------+ 887 | Type | Code | 888 +---------------+-+-------------+---------------+---------------+ 889 | Subtype |P| Reserved | Identifier | 890 +---------------+-+-------------+-------------------------------+ 891 | Options ... 892 +------------------------ 894 The usages of all the above fields are the same as those in the 895 original HAck message. 897 7. IPv4 Transport Support 899 If the connection between the PAR and NAR only supports IPv4, then 900 the HI/HAck messages MAY be transferred by ICMPv4. Which version of 901 ICMP is used MUST be preconfigured in both the PAR and NAR. 903 7.1. Handover Initiate (HI) 905 The message format is the same as in Section 5.1. 907 IP fields: 909 Source address: the IPv4 address of PAR or NAR 911 Destination address: the IPv4 address of the peer AR 913 Time-to-Live: At least 1. See Section 5.5 in [5] 915 ICMP fields: 917 Same as in Section 5.1 except for the following: 919 Type: 41. See Section 5.5 in [5] 921 Checksum: See Section 5.5 in [5] 923 Subtype: assigned by IANA 925 7.2. Handover Acknowledge (HAck) 927 The message format is the same as in Section 5.2. 929 IP fields: 931 Source address: See Section 5.2 933 Destination address: See Section 5.2 935 Time-to-Live: At least 1. See Section 5.6 in [5] 937 ICMP fields: 939 Same as in Section 5.2 except for the following: 941 Type: 41. See Section 5.6 in [5] 942 Checksum: See Section 5.6 in [5] 944 Subtype: assigned by IANA 946 8. Security Considerations 948 Security issues for this document follow those for PMIPv6[2] and 949 FMIPv6[3]. In this document, it is assumed that the PAR (PMAG), NAR 950 (NMAG) and LMA have trust relationship with each other and the 951 connection between any pair is securely protected. 953 9. References 955 9.1. Normative References 957 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 958 Levels", BCP 14, RFC 2119, March 1997. 960 [2] Gundave, S., Ed., "Proxy Mobile IPv6", 961 draft-ietf-netlmm-proxymip6-18.txt, May 2008. 963 [3] Koodli, R., Ed., "Mobile IPv6 Fast Handovers", RFC 5268, 964 June 2008. 966 [4] Johnson, D., "Mobility Support in IPv6", RFC 3775, June 2004. 968 [5] Koodli, R. and C. Perkins, "Mobile IPv4 Fast Handovers", 969 RFC 4988, October 2007. 971 9.2. Informative References 973 [6] Wakikawa, R., Ed. and S. Gundavelli, "IPv4 Support for Proxy 974 Mobile IPv6", draft-ietf-netlmm-pmip6-ipv4-support-02.txt, 975 November 2007. 977 Authors' Addresses 979 Hidetoshi Yokota 980 KDDI Lab 981 2-1-15 Ohara, Fujimino 982 Saitama, 356-8502 983 JP 985 Email: yokota@kddilabs.jp 987 Kuntal Chowdhury 988 Starent Networks 989 30 International Place 990 Tewksbury, MA 01876 991 US 993 Email: kchowdhury@starentnetworks.com 995 Rajeev Koodli 996 Starent Networks 997 30 International Place 998 Tewksbury, MA 01876 999 US 1001 Email: rkoodli@starentnetworks.com 1003 Basavaraj Patil 1004 Nokia 1005 6000 Connection Drive 1006 Irving, TX 75039 1007 US 1009 Email: basavaraj.patil@nokia.com 1011 Frank Xia 1012 Huawei USA 1013 1700 Alma Dr. Suite 500 1014 Plano, TX 75075 1015 US 1017 Email: xiayangsong@huawei.com 1019 Full Copyright Statement 1021 Copyright (C) The IETF Trust (2008). 1023 This document is subject to the rights, licenses and restrictions 1024 contained in BCP 78, and except as set forth therein, the authors 1025 retain all their rights. 1027 This document and the information contained herein are provided on an 1028 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1029 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1030 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1031 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1032 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1033 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1035 Intellectual Property 1037 The IETF takes no position regarding the validity or scope of any 1038 Intellectual Property Rights or other rights that might be claimed to 1039 pertain to the implementation or use of the technology described in 1040 this document or the extent to which any license under such rights 1041 might or might not be available; nor does it represent that it has 1042 made any independent effort to identify any such rights. Information 1043 on the procedures with respect to rights in RFC documents can be 1044 found in BCP 78 and BCP 79. 1046 Copies of IPR disclosures made to the IETF Secretariat and any 1047 assurances of licenses to be made available, or the result of an 1048 attempt made to obtain a general license or permission for the use of 1049 such proprietary rights by implementers or users of this 1050 specification can be obtained from the IETF on-line IPR repository at 1051 http://www.ietf.org/ipr. 1053 The IETF invites any interested party to bring to its attention any 1054 copyrights, patents or patent applications, or other proprietary 1055 rights that may cover technology that may be required to implement 1056 this standard. Please address the information to the IETF at 1057 ietf-ipr@ietf.org. 1059 Acknowledgment 1061 Funding for the RFC Editor function is provided by the IETF 1062 Administrative Support Activity (IASA).