idnits 2.17.1 draft-ietf-mipshop-pfmipv6-00.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 1349. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1360. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1367. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1373. 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 Copyright Line does not match the current year == Line 864 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 (October 27, 2008) is 5658 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 Summary: 4 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: April 30, 2009 R. Koodli 6 Starent Networks 7 B. Patil 8 Nokia 9 F. Xia 10 Huawei USA 11 October 27, 2008 13 Fast Handovers for Proxy Mobile IPv6 14 draft-ietf-mipshop-pfmipv6-00.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 April 30, 2009. 41 Abstract 43 This document specifies the usage of Fast Mobile IPv6 (FMIPv6) when 44 Proxy Mobile IPv6 is used as the mobility management protocol. 45 Necessary extensions are specified for FMIPv6 to support the scenario 46 when the mobile node does not have IP mobility functionality and 47 hence is not involved with either MIPv6 or FMIPv6 operations. 49 Table of Contents 51 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 52 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 53 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 54 4. Proxy-based FMIPv6 Protocol Overview . . . . . . . . . . . . . 7 55 4.1. Protocol Operation . . . . . . . . . . . . . . . . . . . . 7 56 4.2. IPv4 Support Considerations . . . . . . . . . . . . . . . 13 57 5. Other Considerations . . . . . . . . . . . . . . . . . . . . . 15 58 6. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 16 59 6.1. Mobility Header . . . . . . . . . . . . . . . . . . . . . 16 60 6.1.1. Handover Initiate (HI) . . . . . . . . . . . . . . . . 16 61 6.1.2. Handover Acknowledge (HAck) . . . . . . . . . . . . . 17 62 6.2. Mobility options . . . . . . . . . . . . . . . . . . . . . 19 63 6.2.1. Context Request Option . . . . . . . . . . . . . . . . 19 64 6.2.2. Local Mobility Anchor Address (LMAA) Option . . . . . 20 65 6.2.3. IPv4 Address Option . . . . . . . . . . . . . . . . . 21 66 6.2.4. Mobile Node Interface Identifier (MN IID) Option . . . 21 67 6.2.5. GRE Key Option . . . . . . . . . . . . . . . . . . . . 22 68 7. ICMPv6-based HI/HAck messages . . . . . . . . . . . . . . . . 23 69 7.1. ICMPv6-baqsed Handover Initiate . . . . . . . . . . . . . 23 70 7.2. ICMPv6-based Handover Acknowledge . . . . . . . . . . . . 24 71 7.3. Context Request Option . . . . . . . . . . . . . . . . . . 26 72 7.4. GRE Key Option . . . . . . . . . . . . . . . . . . . . . . 27 73 7.5. Mobile Node Interface Identifier (MN IID) Option . . . . . 28 74 7.6. New option-code for the IP Address Option . . . . . . . . 28 75 7.7. IPv4 Address Option . . . . . . . . . . . . . . . . . . . 28 76 7.8. Vendor Specific Option . . . . . . . . . . . . . . . . . . 29 77 8. Security Considerations . . . . . . . . . . . . . . . . . . . 31 78 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 79 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33 80 10.1. Normative References . . . . . . . . . . . . . . . . . . . 33 81 10.2. Informative References . . . . . . . . . . . . . . . . . . 33 82 Appendix A. Handoff Type Considerations . . . . . . . . . . . . . 34 83 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 35 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36 85 Intellectual Property and Copyright Statements . . . . . . . . . . 37 87 1. Requirements notation 89 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 90 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 91 document are to be interpreted as described in [RFC2119]. 93 2. Introduction 95 Proxy Mobile IPv6 [RFC5213] provides IP mobility to a mobile node 96 that does not possess Mobile IPv6 [RFC3775] functionality. A proxy 97 agent in the network performs the mobility management signaling on 98 behalf of the mobile node. This model transparently provides 99 mobility for Mobile Nodes within a PMIPv6 domain. Nevertheless, the 100 basic performance of PMIPv6 in terms of handover latency and packet 101 loss is considered not any different from that of Mobile IPv6. 103 Fast Handovers for Mobile IPv6 is specified in [RFC5268]. This 104 document applies the same Fast Handovers protocol for Proxy Mobile 105 IPv6 (PFMIPv6), in order to provide handover delay, packet loss and 106 transfer of network-resident contexts. This document also specifies 107 necessary extensions to FMIPv6 for operation in a PMIPv6 domain. 109 3. Terminology 111 This document refers to [RFC5213][RFC5268][RFC3775] for terminology. 112 The following terms and abbreviations are additionally used in this 113 document. The reference network is illustrated in Figure 1. 115 Previous Access Network (P-AN): 116 The access network to which the MN is attached before handover. 118 New Access Network (N-AN): 119 The access network to which the MN is attached after handover. 121 Previous Mobile Access Gateway (PMAG): 122 The MAG that manages mobility related signaling for the MN 123 before handover. In this document, the MAG and the Access 124 Router (AR) are collocated. 126 New Mobile Access Gateway (NMAG): 127 The MAG that manages mobility related signaling for the MN after 128 handover. In this document, the MAG and the Access Router (AR) 129 are collocated. 131 HO-Initiate: 132 A generic signaling that indicates the handover of the MN sent 133 from the P-AN to the PMAG. While this signaling is dependent on 134 the access technology, it is assumed that HO-Initiate can carry 135 the information to identify the MN and to assist the PAR resolve 136 the NAR (e.g., the new access point or base station to which the 137 MN is moving). 139 +----------+ 140 | LMA | 141 | | 142 +----------+ 143 / \ 144 / \ 145 / \ 146 +........../..+ +..\..........+ 147 . +-------+-+ .______. +-+-------+ . 148 . | PAR |()_______)| NAR | . 149 . | (PMAG) | . . | (NMAG) | . 150 . +----+----+ . . +----+----+ . 151 . | . . | . 152 . ___|___ . . ___|___ . 153 . / \ . . / \ . 154 . ( P-AN ) . . ( N-AN ) . 155 . \_______/ . . \_______/ . 156 . | . . | . 157 . +----+ . . +----+ . 158 . | MN | ----------> | MN | . 159 . +----+ . . +----+ . 160 +.............+ +.............+ 162 Figure 1: Reference network for fast handover 164 4. Proxy-based FMIPv6 Protocol Overview 166 In order to improve the performance during handover (when operations 167 such as attachment to a new network and signaling between mobility 168 agents are involved), the PFMIPv6 protocol in this document specifies 169 a bi-directional tunnel between the Previous MAG (PMAG) and the New 170 MAG (NMAG). In order to enable the NMAG to send the Proxy Binding 171 Update (PBU), the Handover Initiate (HI) and Handover Acknowledge 172 (HAck) messages in [RFC5268] are used for context transfer, in which 173 parameters such as MN's NAI, Home Network Prefix (HNP), IPv4 Home 174 Address, are 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 a MN is not directly involved with IP mobility protocol 181 operations, it follows that the MN is not directly involved with fast 182 handover procedures either. Hence, the messages involving the MN in 183 [RFC5268] are not used when PMIPv6 is in use. Such messages are the 184 Router Solicitation for Proxy Advertisement (RtSolPr), Proxy Router 185 Advertisement (PrRtAdv), Fast Binding Update (FBU), Fast Binding 186 Acknowledgment (FBack) and Unsolicited Neighbor Advertisement (UNA). 188 4.1. Protocol Operation 190 There are two modes of operation in FMIPv6 [RFC5268]. In the 191 predictive mode of fast handover, a bi-directional tunnel between the 192 PAR and NAR is established prior to the MN's attachment to the NAR. 193 In the reactive mode, this tunnel establishment takes place after the 194 MN attaches to the NAR. Since the MN is not involved in IP mobility 195 signaling in PMIPv6, the sequence of events illustrating the 196 predictive fast handover are shown in Figure 2. 198 PMAG NMAG 199 MN P-AN N-AN (PAR) (NAR) LMA 200 | | | | | | 201 | Report | | | | | 202 (a) |-(MN ID,-->| | | | | 203 | New AP ID)| | | | | 204 | | HO Initiate | | | 205 (b) | |--(MN ID, New AP ID)-->| | | 206 | | | | | | 207 | | | | HI | | 208 (c) | | | |-(MN ID, ->| | 209 | | | MN-HoA,MN IID,LMA) | 210 | | | | | | 211 (d) | | | |<---HAck---| | 212 | | | | (MN ID) | | 213 | | | | | | 214 | | | | HI/HAck | | 215 (e) | | | |<--------->| | 216 (f) | | | |==DL data=>| | 217 | | | | | | 218 (g) ~~~ | | | | | 219 ~~~ | | | | | 220 | MN-AN connection | AN-MAG connection | | 221 (h) |<---establishment---->|<----establishment----->| | 222 | | | (substitute for UNA) | | 223 | | | | | | 224 (i) |<==================DL data=====================| | 225 | | | | | | 226 (j) |===================UL data====================>|# | 227 | | | #|<==========|# | 228 | | | #|===================>| 229 | | | |HI/HAck(optional) | 230 (k) | | | |<- - - - ->| | 231 / | | | | | | \ 232 |(l) | | | | |--PBU-->| | 233 | | | | | | | | 234 |(m) | | | | |<--PBA--| | 235 \ | | | | | | / 237 Figure 2: Predictive fast handover for PMIPv6 (PAR initiated) 239 The detailed descriptions are as follows: 241 (a) The MN detects that a handover is imminent and reports the 242 identifications of itself (MN ID) and the access point (New AP 243 ID) to which the MN is most likely to move. The MN ID could be 244 the NAI or a Link Layer Address (LLA), or any other suitable 245 identifier. This step is access technology specific. In some 246 cases, the P-AN will determine which AP ID the MN is moving to. 248 (b) The previous access network (P-AN), to which the MN is currently 249 attached, indicates the handover of the MN to the PAR (PMAG). 251 (c) The PAR sends the HI to the NAR. The HI message MUST include 252 the MN ID and SHOULD include the MN-HoA, the MN-HNP, the MN-IID 253 and the address of the LMA that is currently serving the MN. 255 (d) The NAR sends the HAck back to the PAR. 257 (e) The NAR requests the PAR to buffer or forward packets by setting 258 U or F flags in the HI message, respectively. 260 (f) If the F flag is set in the previous step, a bi-directional 261 tunnel is established between the PAR and NAR and packets 262 destined for the MN are forwarded from the PAR to the NAR over 263 this tunnel. After decapsulation, those packets may be buffered 264 at the NAR. If the connection between the N-AN and NAR has 265 already been established, those packet may be forwarded towards 266 the N-AN; this is access technology specific. 268 (g) The MN undergoes handover to the New Access Network (N-AN). 270 (h) The MN establishes a connection (e.g., radio channel) with the 271 N-AN, which in turn triggers the establishment of the connection 272 between the N-AN and NAR if it has not been established already 273 (access technology specific). This can be regarded as a 274 substitute for the UNA. 276 (i) The NAR starts to forward packets destined for the MN via the 277 N-AN. 279 (j) The uplink packets from the MN are sent to the NAR via the N-AN 280 and the NAR forwards them to the PAR. The PAR then sends the 281 packets to the LMA that is currently serving the MN. 283 (k) The PAR MAY send the HI message to indicate that the packet 284 forwarding is completed. 286 (l) The NAR (NMAG) sends the Proxy Binding Update (PBU) to the LMA, 287 whose address is provided in (c). Steps (l) and (m) are not 288 part of the fast handover procedure, but shown for reference. 290 (m) The LMA sends back the Proxy Binding Acknowledgment (PBA) to the 291 NAR (NMAG). From this time on, the packets to/from the MN go 292 through the NAR instead of the PAR. 294 According to Section 4 of [RFC5268], the PAR establishes a binding 295 between the PCoA and NCoA to forward packets for the MN to the NAR, 296 and the NAR creates a proxy NCE to receive those packets for the NCoA 297 before the MN arrives. In the case of PMIPv6, however, the only 298 address that is used by the MN is MN-HoA. Hence the PAR forwards 299 MN's packets to the NAR instead of the NCoA. FMIPv4 [RFC4988] 300 specifies forwarding when the MN uses HoA as its on-link address 301 rather than the care-of address. The usage in PMIPv6 is similar to 302 that in FMIPv4, where the address is used by the MN is based on Home 303 Network Prefix. Hence the PAR forwards MN's packets to the NAR 304 instead of the NCoA. The NAR then simply decapsulates those packets 305 and delivers them to the MN. Since the NAR obtains the LLA (MN IID) 306 and MN-HoA by the HI, it can create the NCE for the MN and deliver 307 packets to it even before the MN can perform Neighbor Discovery. For 308 the uplink packets from the MN after handover in (j), the NAR 309 forwards the packets to the PAR through the tunnel established in 310 step (f). The PAR then decapsulates and sends them to the LMA. 312 The timing of the context transfer and that of packet forwarding may 313 be different. Thus, a new flag 'F' and the Option Code values for it 314 in the HI message are defined to request forwarding. To request 315 buffering, 'U' flag has already been defined in [RFC5268]. If the 316 PAR receives the HI message with F flag set and the Option Code value 317 being 2, it starts forwarding packets for the MN. The HI message 318 with U flag set may be sent earlier if the timing of buffering is 319 different from that of forwarding. If packet forwarding is 320 completed, the PAR MAY send the HI message with F flag set and the 321 Option Code value being 3. By this message, the ARs on both ends can 322 tear down the forwarding tunnel synchronously. 324 The IP addresses in the headers of those user packets are summarized 325 below: 327 In (f), 329 Inner source address: IP address of the CN 331 Inner destination address: HNP or IPv4-HoA 333 Outer source address: IP address of the PAR (PMAG) 335 Outer destination address: IP address of the NAR (NMAG) 337 In (i), 338 Source address: IP address of the CN 340 Destination address: HNP or IPv4-HoA 342 In (j), 344 - from the MN to the NMAG, 346 Source address: HNP or IPv4-HoA 348 Destination address: IP address of the CN 350 - from the NMAG to the PMAG, 352 Inner source address: HNP or IPv4-HoA 354 Inner destination address: IP address of the CN 356 Outer source address: IP address of the NAR (NMAG) 358 Outer destination address: IP address of the PAR (PMAG) 360 - from the PMAG to the LMA, 362 Inner source address: HNP or IPv4-HoA 364 Inner destination address: IP address of the CN 366 Outer source address: IP address of the PAR (PMAG) 368 Outer destination address: IP address of the LMA 370 If the network that the MN has moved to does not support PMIPv6 but 371 only MIPv6 (i.e. there exists a MIPv6 HA) and the MN supports MIPv6 372 at the same time, the MN and HA can exchange BU/BA instead of PBU/PBA 373 in steps (j) and (k). If this is the case, the LMA and HA will most 374 likely be collocated and the LMA (HA) address should be maintained in 375 the new network for communication continuity. Since the LMA (HA) 376 address is transferred to the NAR in step (c), the MN can retrieve it 377 at or after step (g) by e.g. the authentication or DHCP procedure 378 (not shown in the figure). 380 In the case of the reactive handover for PMIPv6, since the MN does 381 not send either the FBU or UNA, it would be more natural that the NAR 382 sends the HI to the PAR after the MN has moved to the new network. 383 Figure 3 illustrates the reactive fast handover procedures for 384 PMIPv6, where the bi-directional tunnel establishment is initiated by 385 the NAR. 387 PMAG NMAG 388 MN P-AN N-AN (PAR) (NAR) LMA 389 | | | | | | 390 (a) ~~~ | | | | | 391 ~~~ | | | | | 392 | MN-AN connection | AN-MAG connection | | 393 (b) |<--establishment-->|<-------establishment------>| | 394 | (MN ID) | (MN ID) | | 395 | | |(substitute for UNA and FBU)| | 396 | | | | | | 397 | | | | HI | | 398 (c) | | | |<---(MN ID) ---| | 399 | | | | | | 400 | | | | HAck | | 401 (d) | | | |---(MN ID, --->| | 402 | | | MN-HoA,MN IID,LMA) | 403 | | | | | | 404 (e) | | | |===DL data====>|# | 405 |<====================DL data====================|# | 406 | | | | | | 407 (f) |=====================UL data===================>|# | 408 | | | #=|<==============|# | 409 | | | #=|=======================>| 410 (g) | | | |<---HI/HAck--->| | 411 | | | | | | 412 / | | | | | | \ 413 |(h) | | | | |--PBU-->| | 414 | | | | | | | | 415 |(i) | | | | |<--PBA--| | 416 \ | | | | | | / 418 Figure 3: Reactive fast handover for PMIPv6 (NAR initiated) 420 The detailed descriptions are as follows: 422 (a) The MN undergoes handover from the P-AN to the N-AN. 424 (b) The MN establishes a connection (e.g., radio channel) with the 425 N-AN, which triggers the establishment of the connection between 426 the N-AN and NAR. The MN ID is transferred to the NAR for the 427 subsequent procedures. This can be regarded as a substitute for 428 the UNA and FBU. 430 (c) The NAR sends the HI to the PAR. The HI message MUST include 431 the MN ID. The Context Request Option MAY be included to 432 request additional context information on the MN to the PAR. 434 (d) The PAR sends the HAck back to the NAR. The HAck message MUST 435 include the HNP and/or IPv4-HoA that is corresponding to the MN 436 ID in the HI message and SHOULD include the MN-IID and the LMA 437 address that is currently serving the MN. The context 438 information requested by the NAR MUST be included. 440 (e) If F flag in the HI is set, a bi-directional tunnel is 441 established between the PAR and NAR and packets destined for the 442 MN are forwarded from the PAR to the NAR over this tunnel. 443 After decapsulation, those packets are delivered to the MN via 444 the N-AN. 446 (f) The uplink packets from the MN are sent to the NAR via the N-AN 447 and the NAR forwards them to the PAR. The PAR then sends the 448 packets to the LMA that is currently serving the MN. 450 (g) The PAR MAY send the HI message to indicate that the packet 451 forwarding is completed. 453 Steps (h)-(i) are the same as (l)-(m) in the predictive fast handover 454 procedures. 456 In step (c), The IP address of the PAR needs to be resolved by the 457 NAR to send the HI to the PAR. This information may come from the 458 N-AN or some database that the NAR can access. 460 Also, in step (c), the NAR could send an unsolicited HAck message to 461 the PAR, which then triggers the HI message from the PAR. By doing 462 so, the directions of HI/HAck messages are aligned with the 463 predictive (PAR-initiated) fast handover. Further study is needed if 464 this call flow is more appropriate than the current one. 466 4.2. IPv4 Support Considerations 468 The motivation and usage scenarios of IPv4 protocol support by PMIPv6 469 are described in [IPv4PMIPv6]. The scope of IPv4 support covers the 470 following two features: 472 o IPv4 Home Address Mobility Support, and 474 o IPv4 Transport Support. 476 As for IPv4 Home Address Mobility Support, the MN acquires IPv4 Home 477 Address (IPv4-MN-HoA) and in the case of handover, the PMAG needs to 478 transfer IPv4-MH-HoA to the NMAG, which is the inner destination 479 address of the packets forwarded on the downlink. In order to 480 support IPv4-MN-HoA, a new option called IPv4 Address Option is 481 defined in this document. In order to provide IPv4 Transport 482 Support, the NMAG needs to know the IPv4 address of the LMA (IPv4- 483 LMAA) to send PMIPv6 signaling messages to the LMA in the IPv4 484 transport network. The above IPv4 Address Option is defined so as to 485 be able to convey IPv4-LMAA. The details of this option are 486 described in [IPv4PMIPv6]. 488 5. Other Considerations 490 The protocol specified in this document enables the NMAG to obtain 491 parameters which would otherwise be available only by communicating 492 with the LMA. For instance, the HNP and/or IPv4-HoA of a MN are made 493 available to the NMAG through context transfer. This allows the NMAG 494 to perform some procedures which may be beneficial. For instance, 495 the NMAG could send a Router Advertisement (RA) with the HNP option 496 to the MN as soon as it's link attachment is detected (e.g., via 497 receipt of a Router Solicitation message). Such an RA is 498 recommended, for example, in scenarios where the MN uses a new radio 499 interface while attaching to the NMAG; since the MN does not have 500 information regarding the new interface, it will not be able to 501 immediately send packets without first receiving an RA with HNP. 502 However, if the subsequent PMIPv6 binding registration for the HNP 503 fails for some reason, then the NMAG MUST withdraw the advertised HNP 504 by sending another RA with zero prefix lifetime for the HNP in 505 question. This operation is the same as that described in Section 506 6.12 of [RFC5213]. 508 The protocol specified in this document is applicable regardless of 509 whether link-layer addresses are used between a MN and its access 510 router. A MN should be able to continue sending packets on the 511 uplink even when it changes link. When link-layer addresses are 512 used, the MN performs Neighbor Unreachability Detection (NUD) 513 [RFC4861], after attaching to a new link, probing the reachability of 514 its default router. If the new router's interface is configured to 515 respond to queries sent to link-layer addresses than it's own (e.g., 516 set to promiscuous mode), then it can respond to the NUD probe, 517 providing its link-layer address in the solicited Neighbor 518 Advertisement. While the MN is performing NUD, it can continue to 519 send uplink packets. 521 6. Message Formats 523 This document defines new Mobility Header messages for the extended 524 HI and Hack and new mobility options for conveying context 525 information. 527 Editor's note: this document also defines ICMPv6-based HI/Hack in 528 Section 7. Whether either one or both of the types is/are 529 specified will be resolved in later versions. 531 6.1. Mobility Header 533 6.1.1. Handover Initiate (HI) 535 The MH Type value of the HI Mobility Header is TBD1. The format of 536 the Message Data field in the Mobility Header is as follows: 538 0 1 2 3 539 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 540 +---------------+-+-+-----------+ 541 | Code |U|F| Reserved | 542 +-------------------------------+---------------+-+-+-----------+ 543 | Reserved | Identifier | 544 +-------------------------------+-------------------------------+ 545 | | 546 . . 547 . Mobility options . 548 . . 549 | | 550 +---------------------------------------------------------------+ 552 IP Fields: 554 Source Address 556 The IP address of PMAG or NMAG 558 Destination Address 560 The IP address of the peer MAG 562 Message Data: 564 Code If F flag is not set, the Code MUST be set to zero. 565 Otherwise, the Code value has the following meaning: 567 0: Reserved 569 1: Forwarding is not requested 571 2: Request forwarding 573 3: Indicate the completion of forwarding 575 U flag Buffer flag. Same as [RFC5268]. 577 F flag Forwarding flag. Used to request to forward the packets 578 for the MN. 580 Reserved These fields are unused. They MUST be initialized to zero 581 by the sender and MUST be ignored by the receiver. 583 Identifier Same as [RFC5268]. 585 Mobility options: 587 This field contains one or more mobility options, whose encoding and 588 formats are defined in [RFC3775]. At least one mobility option MUST 589 uniquely identify the target MN (e.g., the Mobile Node Identifier 590 Option defined in RFC4283) and the transferred context MUST be for 591 one MN per message. In addition, the NAR can request necessary 592 mobility options by the Context Request Option defined in this 593 document. 595 Context Request Option 597 This option is used to request context information typically 598 by the NAR to the PAR in the NAR-initiated fast handover. 600 6.1.2. Handover Acknowledge (HAck) 602 The MH Type value of the HAck Mobility Header is TBD2. The format of 603 the Message Data field in the Mobility Header is as follows: 605 0 1 2 3 606 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 607 +---------------+---------------+ 608 | Code | Reserved | 609 +-------------------------------+---------------+---------------+ 610 | Reserved | Identifier | 611 +-------------------------------+-------------------------------+ 612 | | 613 . . 614 . Mobility options . 615 . . 616 | | 617 +---------------------------------------------------------------+ 619 IP Fields: 621 Source Address 623 Copied from the destination address of the 624 Handover Initiate message to which this message 625 is a response. 627 Destination Address 629 Copied from the source address of the Handover 630 Initiate message to which this message is a 631 response. 633 Message Data: 635 Code: 637 0: Handover Accepted 639 5: Context Transferred successfully, more context 640 available 642 6: Context Transferred successfully, no more 643 context available 645 128: Handover Not Accepted 647 129: Administratively prohibited 649 130: Insufficient resources 650 131: Requested Context Not Available 652 132: Forwarding Not Available 654 Reserved These fields are unused. They MUST be initialized to 655 zero by the sender and MUST be ignored by the receiver. 657 Identifier Copied from the corresponding field in the Handover 658 Initiate message to which this message is a response. 660 Mobility options: 662 This field contains one or more mobility options, whose encoding and 663 formats are defined in [RFC3775]. The mobility option that uniquely 664 identifies the target MN MUST be copied from the corresponding HI 665 message and the transferred context MUST be for one MN per message. 667 Requested option(s) All the context information requested by the 668 Context Request Option in the HI message MUST be present in 669 the HAck message. Otherwise, the Code value MUST be set to 670 131. 672 6.2. Mobility options 674 6.2.1. Context Request Option 676 This option is sent in the HI message to request context information 677 on the MN. 679 0 1 2 3 680 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 681 +---------------+---------------+---------------+---------------+ 682 | Option-Type | Option-Length | Reserved | 683 +---------------+---------------+-------------------------------+ 684 | Req-type-1 | Req-length-1 | Req-type-2 | Req-length-2 | 685 +---------------------------------------------------------------+ 686 | ... | 688 Context Request Option is typically used for the reactive (NAR- 689 initiated) fast handover mode to retrieve the context information 690 from the PAR. When this option is included in the HI message, the 691 requested option(s) MUST be included in the HAck message. 693 Option-Type TBD3 694 Option-Length The length in octets of this option, not including the 695 Option Type and Option Length fields. 697 Reserved This field is unused. It MUST be initialized to zero 698 by the sender and MUST be ignored by the receiver. 700 Req-type-n The type value for the n'th requested option. 702 Req-length-n The length of the n'th requested option excluding the 703 Req-type-n and Req-length-n fields. 705 In the case where there are only Req-type-n and Req-length-n fields, 706 the value of the Req-length-n is set to zero. If additional 707 information besides the Req-type-n is necessary to uniquely specify 708 the requested context, such information follows after the 709 Req-length-n. For example, when the requested context is the Vendor- 710 Specific Option defined in RFC5094, the requested option format looks 711 as follows: 713 | ... | 714 +---------------+---------------+-------------------------------+ 715 | Req-type-N=19 | Req-length-N=6| Vendor-ID | 716 +-------------------------------+-------------------------------+ 717 | Vendor-ID | Sub-Type | 718 +---------------------------------------------------------------+ 719 | ... | 721 6.2.2. Local Mobility Anchor Address (LMAA) Option 723 This option is used to transfer the Local Mobility Anchor Address 724 (LMAA), with which the MN is currently registered. The detailed 725 definition of the LMAA is described in [RFC5213]. 727 0 1 2 3 728 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 729 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 730 | Option-Type | Option-Length | Reserved | 731 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 732 | | 733 + + 734 | | 735 + Local Mobility Anchor Address + 736 | | 737 + + 738 | | 739 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 741 Option-Type TBD4 743 Option-Length 18 745 Reserved This field is unused. It MUST be initialized to zero 746 by the sender and MUST be ignored by the receiver. 748 Local Mobility Anchor Address 749 The LMA address, with which the MN is currently 750 registered. 752 6.2.3. IPv4 Address Option 754 As described in Section 4.2, if the MN is IPv4-only mode or dual- 755 stack mode, the MN requires IPv4 home address (IPv4-MN-HoA). The 756 IPv4 address of the LMA (IPv4-LMAA) is also needed to send PMIP 757 signaling messages when the ARs and LMA are in an IPv4 transport 758 network. This option has alignment requirement of 4n. 760 0 1 2 3 761 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 762 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 763 | Option-Type | Option-Length | Option-Code | Reserved | 764 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 765 | IPv4 Address | 766 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 768 Option-Type TBD5 770 Option-Length 6 772 Option-Code 774 0 IPv4-MN-HoA 776 1 IPv4-LMAA 778 Reserved This field is unused. It MUST be initialized to zero 779 by the sender and MUST be ignored by the receiver. 781 IPv4 Address IPv4 address specified in Option-Code 783 6.2.4. Mobile Node Interface Identifier (MN IID) Option 785 This option is used to transfer the interface identifier of the MN 786 that is used in the P-AN. The format of the interface identifier 787 follows the Mobile Node Interface Identifier Option defined in 788 [RFC5213]. 790 6.2.5. GRE Key Option 792 This document extends the GRE Key option defined in [grekey] to 793 specify the direction of the packets and the tunnel to which the GRE 794 key is assigned. This option has alignment requirement of 4n. 796 0 1 2 3 797 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 798 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 799 | Option-Type | Option-Length | Reserved | Tunnel-Type | 800 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 801 | GRE Key Identifier | 802 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 804 Option-Type See [grekey]. 806 Option-Length 6 808 Reserved This field is unused. It MUST be initialized to zero 809 by the sender and MUST be ignored by the receiver. 811 Tunnel-Type 813 1 GRE Key for UL packets over MAG-LMA tunnel 815 2 GRE Key for UL packets over MAG-MAG tunnel 817 3 GRE Key for DL packets over MAG-MAG tunnel 819 GRE Key Identifier See [grekey]. 821 7. ICMPv6-based HI/HAck messages 823 This document extends the HI and HAck defined in [RFC5268] to work 824 with PMIPv6 and further defines new options and option-codes for the 825 IP Address option to convey context information. 827 7.1. ICMPv6-baqsed Handover Initiate 829 0 1 2 3 830 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 831 +---------------+---------------+-------------------------------+ 832 | Type | Code | Checksum | 833 +---------------+-+-+-+-+-------+-------------------------------+ 834 | Subtype |S|U|P|F|Resv'd | Identifier | 835 +---------------+-+-+-+-+-------+-------------------------------+ 836 | Options ... 837 +------------------------- 839 IP Fields: 841 Source Address 843 The IP address of PAR or NAR 845 Destination Address 847 The IP address of the peer AR 849 All the other fields follow [RFC5268]. 851 ICMP Fields: 853 Code If P flag is not set, the Code value follows [RFC5268]. If 854 P flag is set but F flag is not set, the Code MUST be set 855 to zero. If both P flag and F flag are set, the Code value 856 has the following meaning: 858 0, 1: See [RFC5268]. 860 2: Request forwarding 862 3: Indicate the completion of forwarding 864 S flag not used when P flag is set and MUST be set to zero. 866 U flag Buffer flag. Same as [RFC5268]. 868 P flag Proxy flag. When set, PMIPv6 instead of MIPv6 is assumed 869 for the mobility management protocol. All the involved 870 nodes MUST perform based on this document for fast handover 871 procedures. 873 F flag Forwarding flag. Used to request to forward the packets 874 for the MN. 876 All the other fields follow [RFC5268]. 878 Valid options: 880 MN ID This identifier can be the link-layer address of the MN or 881 any other type of information that can uniquely identify 882 the MN. If the link-layer address is used as the MN ID, 883 the Link-Layer Address (LLA) option defined in [RFC5268] 884 MUST be used. 886 MN-HoA This information is stored in the IP Address option. 888 MN-IID This information is stored in the MN Interface Identifier 889 option. 891 Context Request Option Context Request Option This option is used to 892 request context information typically by the NAR to the PAR 893 in the NAR-initiated fast handover. 895 7.2. ICMPv6-based Handover Acknowledge 897 0 1 2 3 898 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 899 +---------------+---------------+--------------------------------+ 900 | Type | Code | Checksum | 901 +---------------+-+-------------+--------------------------------+ 902 | Subtype |P| Reserved | Identifier | 903 +---------------+-+-------------+--------------------------------+ 904 | Options ... 905 +------------------------ 907 IP Fields: 909 Source Address 911 Copied from the destination address of the 912 Handover Initiate message to which this message 913 is a response. 915 Destination Address 917 Copied from the source address of the Handover 918 Initiate message to which this message is a 919 response. 921 All the other fields follow [RFC5268]. 923 ICMP Fields: 925 Code: 927 0: Handover Accepted 929 5: Context Transferred successfully, more context 930 available 932 6: Context Transferred successfully, no more 933 context available 935 128: Handover Not Accepted 937 129: Administratively prohibited 939 130: Insufficient resources 941 131: No context available 943 132: Forwarding Not Available 945 P flag Proxy flag. When set, PMIPv6 instead of MIPv6 is assumed 946 for the mobility management protocol. All the involved 947 nodes MUST perform based on this document for fast handover 948 procedures. 950 Valid options: 952 MN ID Copied from the corresponding HI message. 954 MN-HoA Stored in the IP Address option so that the NAR can use 955 this address for the PBU. 957 MN-IID This information is stored in the MN Interface Identifier 958 option. 960 LMA Stored in the IP Address option so that the NAR can use 961 this address for the PBU. 963 Requested option(s) All the other context information requested by 964 the Context Request Option in the HI message. 966 7.3. Context Request Option 968 This option is sent in the HI message to request context information 969 on the MN. 971 0 1 2 3 972 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 973 +---------------+---------------+---------------+---------------+ 974 | Type | Length | Option-Code | Reserved | 975 +---------------+---------------+---------------+---------------+ 976 | Req-type-1 | Req-option-1 | Req-type-2 | Req-option-2 | 977 +-------------------------------+---------------+---------------+ 978 . ... . 979 . . 980 +---------------+---------------+-------------------------------+ 981 | Req-type-N | Req-option-N | Vendor/Org-ID | 982 +-------------------------------+-------------------------------+ 983 | Vendor/Org-ID | VS-Type | 984 +---------------------------------------------------------------+ 985 . ... . 986 . . 988 Context Request Option is typically used for the reactive (NAR- 989 initiated) fast handover mode to retrieve the context information 990 from the PAR. When this option is included in the HI message, the 991 requested option(s) MUST be included in the HAck message. 993 Type TBD6 995 Length Number of requested context(s)+1. 997 Option-Code 0 998 Reserved This field is unused. It MUST be initialized to zero 999 by the sender and MUST be ignored by the receiver. 1001 Req-type-n The Type value for the requested option. 1003 Req-option-n The Option-Code for the requested option. 1005 Vendor/Org-ID When the Vendor Specific Option is requested, the 3rd 1006 to 6th octets are used for the Vendor/Org-ID defined 1007 in Section 7.8. 1009 VS-Type When the Vendor Specific Option is requested, the 7th 1010 to 8th octets are used for the VS-Type defined in 1011 Section 7.8. 1013 7.4. GRE Key Option 1015 This option is used to transfer the GRE keys that identify GRE 1016 tunnels between the LMA and MAG and between MAGs. 1018 0 1 2 3 1019 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 1020 +---------------+---------------+---------------+---------------+ 1021 | Type | Length | Option-Code | Reserved | 1022 +---------------------------------------------------------------+ 1023 | GRE Key ID | 1024 +---------------------------------------------------------------+ 1026 Type TBD7 1028 Length 1 1030 Option-Code 1032 1 GRE Key for UL packets over MAG-LMA tunnel 1034 2 GRE Key for UL packets over MAG-MAG tunnel 1036 3 GRE Key for DL packets over MAG-MAG tunnel 1038 Reserved This field is unused. It MUST be initialized to zero 1039 by the sender and MUST be ignored by the receiver. 1041 GRE Key ID GRE Key value. 1043 7.5. Mobile Node Interface Identifier (MN IID) Option 1045 This option is used to transfer the interface identifier of the MN 1046 that is used in the P-AN. The format of the interface identifier 1047 follows the Mobile Node Interface Identifier Option defined in 1048 [RFC5213]. 1050 0 1 2 3 1051 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 1052 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1053 | Type | Length | Option-Code | MN IID-Length | 1054 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1055 | | 1056 + Interface Identifier + 1057 | | 1058 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1060 Type TBD8 1062 Length The size of this option is in 8 octets including the 1063 Type, Length and Option-Code. 1065 Option-Code 0 1067 MN IID-Length The length of the MN IID in octets 1069 Interface Identifier 1070 The Interface Identifier value of the MN that is used 1071 in the P-AN. 1073 7.6. New option-code for the IP Address Option 1075 To convey the MN-HoA and LMA in the HI or HAck message, new Option- 1076 Codes for the IP Address Option[RFC5268] are defined: 1078 Option-Code 1080 4 MN-HoA 1082 5 LMA 1084 7.7. IPv4 Address Option 1086 As described in Section 4.2, if the MN is IPv4-only mode or dual- 1087 stack mode, the MN requires IPv4 home address (IPv4-MN-HoA). The 1088 IPv4 address of the LMA (IPv4-LMAA) is also needed to send PMIP 1089 signaling messages when the ARs and LMA are in an IPv4 transport 1090 network. 1092 0 1 2 3 1093 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 1094 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1095 | Type | Length | Option-Code | Reserved | 1096 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1097 | IPv4 Address | 1098 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1100 Type TBD9 1102 Length 1 1104 Option-Code 1106 0 IPv4-MN-HoA 1108 1 IPv4-LMAA 1110 Reserved This field is unused. It MUST be initialized to zero 1111 by the sender and MUST be ignored by the receiver. 1113 IPv4 Address IPv4 address specified in Option-Code 1115 7.8. Vendor Specific Option 1117 This option is to send other information than defined in this 1118 document. Many of the context information can be vendor specific 1119 (access technology specific). This option is used for such 1120 information. 1122 0 1 2 3 1123 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 1124 +---------------+---------------+---------------+---------------+ 1125 | Type | Length | Option-Code | Reserved | 1126 +---------------------------------------------------------------+ 1127 | Vendor/Org-ID | 1128 +-------------------------------+-------------------------------+ 1129 | VS-Type | VS-Length | 1130 +---------------------------------------------------------------+ 1131 | VS-Value ... 1132 +------------------------------ 1134 Type TBD10 1136 Length The size of this option is in 8 octets including the 1137 Type, Length and Option-Code. 1139 Option-Code 0 1141 Reserved This field is unused. It MUST be initialized to zero 1142 by the sender and MUST be ignored by the receiver. 1144 Vendor/Org-ID The SMI Network Management Private Enterprise Code of 1145 the Vendor/Organization as defined by IANA. 1147 VS-Type The type of the Vendor-Specific information carried in 1148 this option. The type value is defined by the vendor 1149 or organization specified by Vendor/Org-ID. 1151 VS-Length The length of the Vendor-Specific information carried 1152 in this option. 1154 VS-Value The value of the Vendor-Specific information carried 1155 in this option. 1157 8. Security Considerations 1159 Security issues for this document follow those for PMIPv6[RFC5213] 1160 and FMIPv6[RFC5268]. In PMIPv6, MAG and LMA are assumed to share 1161 security association. In FMIPv6, the access routers (i.e., the PMAG 1162 and NMAG in this document) are assumed to share security association. 1163 No new security risks are identified. Support for integrity 1164 protection using IPsec is required, but support for confidentiality 1165 is not necessary. 1167 9. IANA Considerations 1169 This document defines two new Mobility Header types: the Handover 1170 Initiate (HI) and the Handover Acknowledge (HAck), which need to be 1171 assigned from the same space as the Mobility Header defined in 1172 [RFC3775]. 1174 Mobility Header 1175 Value Description Reference 1176 ----- ----------------------------- ------------- 1177 TBD1 Handover Initiate Section 6.1.1 1178 TBD2 Handover Acknowledge Section 6.1.2 1180 This document defines two new mobility options, which are described 1181 in Section 6.2. The Type value for these options are assigned from 1182 the same numbering space as allocated for the other mobility options, 1183 as defined in [RFC3775]. 1185 Mobility Options 1186 Value Description Reference 1187 ----- ------------------------------------- ------------- 1188 TBD3 Context Request Option Section 6.2.1 1189 TBD4 Local Nobility Anchor Address Option Section 6.2.2 1190 TBD5 IPv4 Address Option Section 6.2.3 1192 This document defines five new IPv6 Neighbor Discovery options, which 1193 are described in Section 7. The Type value for these options are 1194 assigned from the same space as the IPv6 Neighbor Discovery Options 1195 defined in RFC4861. 1197 Neighbor Discovery Options 1198 Value Description Reference 1199 ----- ----------------------------- ------------- 1200 TBD6 Context Request Option Section 7.3 1201 TBD7 GRE Key Option Section 7.4 1202 TBD8 MN IID Option Section 7.5 1203 TBD9 IPv4 Address Option Section 7.7 1204 TBD10 Vendor Specific Option Section 7.8 1206 10. References 1208 10.1. Normative References 1210 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 1211 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 1213 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1214 Requirement Levels", BCP 14, RFC 2119, March 1997. 1216 [RFC5268] Koodli, R., Ed., "Mobile IPv6 Fast Handovers", RFC 5268, 1217 June 2008. 1219 [RFC3775] Johnson, D., "Mobility Support in IPv6", RFC 3775, 1220 June 2004. 1222 [RFC4988] Koodli, R. and C. Perkins, "Mobile IPv4 Fast Handovers", 1223 RFC 4988, October 2007. 1225 10.2. Informative References 1227 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 1228 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 1229 September 2007. 1231 [IPv4PMIPv6] 1232 Wakikawa, R., Ed. and S. Gundavelli, "IPv4 Support for 1233 Proxy Mobile IPv6", 1234 draft-ietf-netlmm-pmip6-ipv4-support-02.txt, 1235 November 2007. 1237 [grekey] Muhanna, A., Ed., "GRE Key Option for Proxy Mobile IPv6", 1238 draft-ietf-netlmm-grekey-option-01.txt , October 2008. 1240 Appendix A. Handoff Type Considerations 1242 PMIPv6 [RFC5213] defines the Handoff Indicator Option and describes 1243 the type of the handoff and the values to set to the option. This 1244 document proposes one approach to determining the handoff type. 1246 According to [RFC5213], the following handoff types are defined: 1248 0) Reserved 1250 1) Attachment over a new interface 1252 2) Handoff between two different interfaces of the mobile node 1254 3) Handoff between mobile access gateways for the same interface 1256 4) Handoff state unknown 1258 5) Handoff state not changed (Re-registration) 1260 By using the MN Interface Identifier (MN IID) option, which is 1261 defined in this document, the following solution can be considered. 1262 When the NMAG receives the MN IID used in the P-AN from the PMAG via 1263 the HI or HAck messages, the NMAG compares it with the new MN IID 1264 that is obtained from the MN in the N-AN. If these two MN IIDs are 1265 the same, the handover type falls into 3) and the Handoff Indicator 1266 value is set to 3. If these two MN IIDs are different, the handover 1267 is likely to be 2) since the HI/HAck message exchange implies that 1268 this is a handover not a multi-homing, therefore the Handoff 1269 Indicator value can be set to 2. If there is no HI/Hack exchange 1270 performed prior to the network attachment of the MN in the new 1271 network, the NMAG may infer that this is a multi-homing case and set 1272 the Handoff Indicator value to 1. In the case of re-registration, 1273 the MAG, to which the MN is attached, can determine if the handoff 1274 state is not changed, so the MAG can set the HI value to 5 without 1275 any additional information. If none of them can be assumed, the NMAG 1276 may set the value to 4. 1278 Appendix B. Change Log 1280 o Added separate sections for MH and ICMP. 1282 o Clarified usage of HNP and IPv4-HoA throughout the document. 1284 o Added IANA Considerations. 1286 o Added section on Other Considerations, including operation of 1287 uplink packets when using link-layer addresses, multiple interface 1288 usage and transmission of RA to withdraw HNP in the event of 1289 failure of PMIP6 registration. 1291 o Revised Security Considerations. 1293 Authors' Addresses 1295 Hidetoshi Yokota 1296 KDDI Lab 1297 2-1-15 Ohara, Fujimino 1298 Saitama, 356-8502 1299 JP 1301 Email: yokota@kddilabs.jp 1303 Kuntal Chowdhury 1304 Starent Networks 1305 30 International Place 1306 Tewksbury, MA 01876 1307 US 1309 Email: kchowdhury@starentnetworks.com 1311 Rajeev Koodli 1312 Starent Networks 1313 30 International Place 1314 Tewksbury, MA 01876 1315 US 1317 Email: rkoodli@starentnetworks.com 1319 Basavaraj Patil 1320 Nokia 1321 6000 Connection Drive 1322 Irving, TX 75039 1323 US 1325 Email: basavaraj.patil@nokia.com 1327 Frank Xia 1328 Huawei USA 1329 1700 Alma Dr. Suite 500 1330 Plano, TX 75075 1331 US 1333 Email: xiayangsong@huawei.com 1335 Full Copyright Statement 1337 Copyright (C) The IETF Trust (2008). 1339 This document is subject to the rights, licenses and restrictions 1340 contained in BCP 78, and except as set forth therein, the authors 1341 retain all their rights. 1343 This document and the information contained herein are provided on an 1344 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1345 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1346 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1347 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1348 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1349 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1351 Intellectual Property 1353 The IETF takes no position regarding the validity or scope of any 1354 Intellectual Property Rights or other rights that might be claimed to 1355 pertain to the implementation or use of the technology described in 1356 this document or the extent to which any license under such rights 1357 might or might not be available; nor does it represent that it has 1358 made any independent effort to identify any such rights. Information 1359 on the procedures with respect to rights in RFC documents can be 1360 found in BCP 78 and BCP 79. 1362 Copies of IPR disclosures made to the IETF Secretariat and any 1363 assurances of licenses to be made available, or the result of an 1364 attempt made to obtain a general license or permission for the use of 1365 such proprietary rights by implementers or users of this 1366 specification can be obtained from the IETF on-line IPR repository at 1367 http://www.ietf.org/ipr. 1369 The IETF invites any interested party to bring to its attention any 1370 copyrights, patents or patent applications, or other proprietary 1371 rights that may cover technology that may be required to implement 1372 this standard. Please address the information to the IETF at 1373 ietf-ipr@ietf.org.