idnits 2.17.1 draft-ietf-mipshop-fmip-ptp-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 14, 2012) is 4149 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 346, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group F. Xia 3 Internet-Draft B. Sarikaya 4 Intended status: Informational Huawei USA 5 Expires: June 17, 2013 December 14, 2012 7 Prefix Management for Mobile IPv6 Fast Handover on Point-to-Point Links 8 draft-ietf-mipshop-fmip-ptp-05 10 Abstract 12 Mobile IPv6 Fast Handovers specification currently does not 13 explicitly define prefix management over point-to-point links when a 14 mobile node uses a prefix to formulate a new care-of-address. In 15 this document a mechanism is developed for a previous access router 16 to request unique prefixes from a new access router, and in turn, the 17 previous access router advertises the prefixes to the mobile node for 18 a new care-of-address configuration. Extensions to Mobile IPv6 Fast 19 Handovers specification are also specified in this document. 21 Status of this Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on June 17, 2013. 38 Copyright Notice 40 Copyright (c) 2012 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . . 4 58 4. Prefix Management on Point-to-Point Links . . . . . . . . . . . 5 59 4.1. Predictive mode . . . . . . . . . . . . . . . . . . . . . . 5 60 4.2. Reactive Mode . . . . . . . . . . . . . . . . . . . . . . . 6 61 5. HI and Hack Extensions . . . . . . . . . . . . . . . . . . . . 7 62 5.1. HI Extension . . . . . . . . . . . . . . . . . . . . . . . 7 63 5.2. HAck Extension . . . . . . . . . . . . . . . . . . . . . . 7 64 5.3. Dedicated Prefix Option . . . . . . . . . . . . . . . . . . 7 65 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 66 7. IANA considerations . . . . . . . . . . . . . . . . . . . . . . 9 67 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 68 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 69 9.1. Normative References . . . . . . . . . . . . . . . . . . . 9 70 9.2. Informative references . . . . . . . . . . . . . . . . . . 9 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 73 1. Introduction 75 Mobile IPv6 Fast Handovers (FMIPv6) [RFC5568] aims at reducing the 76 handover latency by reducing the time to configure a new care-of 77 address (NCoA) for a mobile node(MN). In FMIPv6, the MN formulates a 78 prospective NCoA when it is still present on a link of a previous 79 access router (PAR). 81 [RFC4968] provides different IPv6 link models that are suitable for 82 IEEE802.16 based networks and provides analysis of various 83 considerations for each link model and the applicability of each link 84 model under different deployment scenarios. [RFC5121] specifies the 85 addressing and operation of IPv6 over the IPv6 specific part of the 86 packet convergence sublayer of IEEE Std 802.16e [802.16e], and point- 87 to-point link model is recommended. Also, 3GPP and 3GPP2 have 88 adopted the point-to-point link model based on the recommendations in 89 [RFC3314]. 91 In this document, we first explain the problems associated with 92 FMIPv6 on point-to-point links followed by a detailed description of 93 prefix management for FMIPv6 operation on point-to-point links. 95 In Section 3 we describe why the point-to-point link address 96 formation procedures are needed in FMIPv6, in Section 4 we define a 97 procedure that a new access router (NAR) can use to dynamically 98 assign unique prefixes in point-to-point links and in Section 5 we 99 define necessary messages/options for the operation in Section 4. 101 2. Terminology 103 The terminology in this document is based on the definitions in 104 [RFC5568], in addition to the ones specified in this section. 106 point-to-point link model: In this model, a set of layer 2 transport 107 connections between a MN and an access router (AR) are treated as 108 a single link. Each link is allocated a separate, unique prefix 109 or a set of unique prefixes by the AR. Please refer to [RFC4968] 110 for details. 112 shared link model: In this model, one or more prefixes are shared by 113 mobile nodes for constructing their global IPv6 addresses. Please 114 refer to [RFC4968] for details. 116 dedicated prefix: In point-to-point link model, a unique prefix used 117 by a MN for formulating a NCoA while the MN is still on a PAR's 118 link. 120 3. Problem Statement 122 The following are operations relating to prefix management as per 123 [RFC5568]: 125 o Movement detection. The protocol enables a MN to quickly detect 126 that it has moved to a new subnet by providing the new access 127 point and the associated subnet prefix information when the MN is 128 still connected to its current subnet. For instance, the MN may 129 discover available access points using link-layer specific 130 mechanisms (i.e., a "scan" in WLAN) and then request subnet 131 information corresponding to one or more of those discovered 132 access points. The MN sends a Router Solicitation for Proxy 133 Advertisement (RtSolPr) to its access router to resolve one or 134 more Access Point Identifiers (AP-ID)to subnet-specific 135 information. In response, the access router sends a Proxy Router 136 Advertisement (PrRtAdv) message containing one or more [AP-ID, AR- 137 Info] tuples, which the MN can use in readily detecting movement: 138 when attachment to an access point with AP-ID takes place, the MN 139 knows the corresponding new router's coordinates including its 140 prefix, IP address, and L2 address. In this document, there is no 141 changes to the movement detection procedure specified in 142 [RFC5568]. 144 o NCoA configuration. AR-Info contains the access router's L2 and 145 IP addresses, and the prefix valid on the interface to which the 146 Access Point (identified by AP-ID) is attached. With the prefix 147 provided in the PrRtAdv message, the MN formulates a prospective 148 NCoA. 150 In the shared link mode, the PAR only needs to figure out what IPv6 151 prefix is advertised by the NAR. In most cases, there would only be 152 a small set of adjacent NARs and the PAR would be able to obtain this 153 information easily. In the point-to-point link mode, the NAR has 154 access to a pool of IPv6 prefixes and these prefixes are assigned 155 dynamically to each mobile node's point-to-point link. Therefore it 156 becomes difficult for the PAR to figure out which IPv6 prefix is 157 going to be assigned to a particular mobile node when point-to-point 158 link mode is used. 160 For the mobile node to configure an NCoA, the PAR sends a Proxy 161 Router Advertisement to the mobile node. This requires that for 162 point-to-point links, the PAR must first contact the NAR to for the 163 dedicated prefix and then advertise the prefix to the mobile node. 164 This is an extension to [RFC5568] to support point-to-point links. 166 4. Prefix Management on Point-to-Point Links 168 Upon the indication of handover from the PAR to the NAR, the PAR uses 169 Handover Initiate (HI)/ Handover Acknowledge (HAck) message exchange 170 to get a dedicated prefix from the NAR. The PAR then sends this 171 prefix in the PrRtAdv message to the MN as described in [RFC5568]. 172 In the PrRtAdv message, A-bit and L-bit must be turned on. The MN 173 thus uses this prefix for movement detection and NCoA configuration 174 as per [RFC5568]. 176 4.1. Predictive mode 178 New FMIPv6 message exchange is introduced for the PAR to ask for MN's 179 dedicated prefix as shown in Figure 1. The MN sends an RtSolPr 180 message to the PAR to resolve one or more Access Point Identifiers to 181 subnet-specific information. The PAR in turn requests dedicated 182 prefixes from the NAR through modified HI/HAck message exchange 183 described in Section 5. With the information provided in the PrRtAdv 184 message, the MN formulates a prospective NCoA and sends an FBU 185 message to the PAR. The following operation is exactly the same as 186 these specified in [RFC5568]. 188 Lifetime in Dedicated Prefix Option Section 5.3 is used to prevent 189 prefix depletion because of erroneous movement in which the mobile 190 node receives a dedicated prefix prior to a handover that it is 191 moving to a new access point but it either moves to a different one 192 or it aborts movement altogether. Not until timeout of the prefix 193 does the NAR release it. 195 MN PAR NAR 196 | | | 197 | | | 198 |------RtSolPr------->| | 199 | | HI(Prefix Request) | 200 | |----------------------->| 201 | | | 202 | | | 203 | | HAck(Prefix Response) | 204 | |<-----------------------| 205 |<-----PrRtAdv--------| | 206 | | |No FBU 207 | | |Release 208 | | |Prefix 209 |------FBU----------->|--------HI------------->| 210 | |<------HAck-------------| 211 | <--FBack---|--FBack---> | 212 disconnect forward | 213 | packets===================>| 214 | | | 215 | | | 216 connect | | 217 | | | 218 |--------- UNA ------------------------------->| 219 |<=================================== deliver packets 220 | | 222 Figure 1: Prefix Signaling 224 In some wireless networks, the handover control may reside in the 225 network even though the decision to undergo handover may be mutually 226 agreed between the MN and the network. In such a case, the PAR can 227 send an unsolicited PrRtAdv containing the link-layer address, IP 228 address, and dedicated prefix of the mobile node when the network 229 decides that a handover is imminent. In this network-initiated 230 handover scenario, there isn't explicit RtSolPr to trigger PAR to 231 request a prefix and implementation specific trigger must be used by 232 PAR to send HI message for prefix request. 234 4.2. Reactive Mode 236 In the reactive mode, there are two cases. 238 o In the first case, the MN receives the PrRtAdv message while still 239 attached to the PAR. The MN is then able to formulate NCoA before 240 attaching to the NAR. The MN and the NAR operate as per the 241 procedures defined in [RFC5568]. 243 o In the second case, the MN does not receive a PrRtAdv before 244 attaching to the NAR. The MN can configure its IP address using 245 stateless or stateful address configuration. In the former case, 246 the NAR should send un-solicited RA to expedite MN's address 247 configuration. Once NCoA formulation is finished, the MN operates 248 according to [RFC5568]. 250 In both cases, the MN formulates NCoA from the dedicated prefix. 251 Since the MN has already handed over to the NAR, this prefix is 252 retained. 254 5. HI and Hack Extensions 256 5.1. HI Extension 258 The Handover Initiate (HI),defined in [RFC5568], is a Mobility Header 259 message sent by one Access Router to another to initiate the process 260 of a MN's handover. 262 In [RFC5568], the PAR uses a Code value of 0 when it processes an FBU 263 with PCoA as source IP address, while uses a Code value of 1 when it 264 processes an FBU whose source IP address is not PCoA. A Code value 265 is used for the dedicated prefix request. Dedicated Prefix Option 266 defined in Section 5.3 may be included as a hint for a requested 267 preference. The NAR may allocate a dedicated prefix based on the 268 prefix preference in the option. If the option is not included, the 269 NAR allocates a prefix according to it's discretion. 271 5.2. HAck Extension 273 Handover Acknowledgment message defined in [RFC5568] is a Mobility 274 Header message that must be sent as a reply to the Handover Initiate 275 message. In this document, HAck is extended as follows to respond to 276 a dedicated prefix request: 277 o One new Code value is defined. Here, a Code value is used for 278 dedicated prefix response. 279 o Dedicated Prefix Option defined in Section 5.3 must be included 280 for prefix delegation. 282 5.3. Dedicated Prefix Option 284 This option is of the form shown in Figure 2. 286 0 1 2 3 287 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 288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 289 | Type | Length | Prefix Length | Reserved | 290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 291 | Lifetime | 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 | | 294 + + 295 | | 296 + Prefix + 297 | | 298 + + 299 | | 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 Figure 2: Dedicated Prefix Option 304 Type The type of the option 306 Length The length of the option in units of 8 octets. 308 Reserved 309 must be set to zero by the sender and ignored by the 310 receiver. 312 Prefix Length 313 8-bit unsigned integer. The number of leading bits 314 in the Prefix that are valid. The value ranges from 0 315 to 128. 317 Lifetime 32-bit unsigned integer. The length of time in seconds 318 (relative to the time the packet is sent). A value of 319 all one bits (0xffffffff) represents infinity. 321 Prefix An IP address or a prefix of an IP address. A MN uses it 322 to formulate a NCoA. 324 6. Security Considerations 326 Prefix management for FMIPv6 operation on point-to-point links uses 327 two messages (HI/Hack) for prefix request and response. These 328 messages are secured using FMIPv6 security mechanisms and hence do 329 not introduce any new security threats and the security provided by 330 FMIPv6 applies completely. 332 7. IANA considerations 334 None. 336 8. Acknowledgements 338 The authors would like to thank Heejin Jang, Daniel Park, Vijay 339 Devarapalli, Rajeev Koodli, Subir Das, Spencer Dawkins, and Dirk Von- 340 Hugo for valuable comments. 342 9. References 344 9.1. Normative References 346 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 347 Requirement Levels", BCP 14, RFC 2119, March 1997. 349 [RFC5568] Koodli, R., "Mobile IPv6 Fast Handovers", RFC 5568, 350 July 2009. 352 [RFC5121] Patil, B., Xia, F., Sarikaya, B., Choi, JH., and S. 353 Madanapalli, "Transmission of IPv6 via the IPv6 354 Convergence Sublayer over IEEE 802.16 Networks", RFC 5121, 355 February 2008. 357 9.2. Informative references 359 [802.16e] Institute of Electrical and Electronics Engineer, 360 "Amendment for Physical and Medium Access Control Layers 361 for Combined Fixed and Mobile Operation in Licensed 362 Bands", IEEE 802.16e/D12. 364 [RFC3314] Wasserman, M., "Recommendations for IPv6 in Third 365 Generation Partnership Project (3GPP) Standards", 366 RFC 3314, September 2002. 368 [RFC4968] Madanapalli, S., "Analysis of IPv6 Link Models for 802.16 369 Based Networks", RFC 4968, August 2007. 371 Authors' Addresses 373 Frank Xia 374 Huawei USA 375 5340 Legacy Dr. Building 3 376 Plano, TX 75024 378 Phone: +1 972-509-5599 379 Email: xiayangsong@huawei.com 381 Behcet Sarikaya 382 Huawei USA 383 5340 Legacy Dr. Building 3 384 Plano, TX 75024 386 Phone: +1 972-509-5599 387 Email: sarikaya@ieee.org