idnits 2.17.1 draft-xia-mipshop-fmip-ptp-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 5, 2009) is 5377 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 2 comments (--). 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: February 6, 2010 August 5, 2009 7 Prefix Management for Mobile IPv6 Fast Handover on Point-to-Point Links 8 draft-xia-mipshop-fmip-ptp-04 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. This document may contain material 14 from IETF Documents or IETF Contributions published or made publicly 15 available before November 10, 2008. The person(s) controlling the 16 copyright in some of this material may not have granted the IETF 17 Trust the right to allow modifications of such material outside the 18 IETF Standards Process. Without obtaining an adequate license from 19 the person(s) controlling the copyright in such materials, this 20 document may not be modified outside the IETF Standards Process, and 21 derivative works of it may not be created outside the IETF Standards 22 Process, except to format it for publication as an RFC or to 23 translate it into languages other than English. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as Internet- 28 Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt. 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html. 41 This Internet-Draft will expire on February 6, 2010. 43 Copyright Notice 45 Copyright (c) 2009 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents in effect on the date of 50 publication of this document (http://trustee.ietf.org/license-info). 51 Please review these documents carefully, as they describe your rights 52 and restrictions with respect to this document. 54 Abstract 56 Mobile IPv6 Fast Handovers specification currently does not 57 explicitly define prefix management over point-to-point links when a 58 mobile node uses a prefix to formulate a new care-of-address. In 59 this document a mechanism is developed for a previous access router 60 to request unique prefixes from a new access router, and in turn, the 61 previous access router advertises the prefixes to the mobile node for 62 a new care-of-address configuration. Extensions to Mobile IPv6 Fast 63 Handovers specification are also specified in this document. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5 70 4. Prefix Management on Point-to-Point Links . . . . . . . . . . 6 71 4.1. Predictive mode . . . . . . . . . . . . . . . . . . . . . 6 72 4.2. Reactive Mode . . . . . . . . . . . . . . . . . . . . . . 7 73 5. HI and Hack Extensions . . . . . . . . . . . . . . . . . . . . 8 74 5.1. HI Extension . . . . . . . . . . . . . . . . . . . . . . . 8 75 5.2. HAck Extension . . . . . . . . . . . . . . . . . . . . . . 8 76 5.3. Dedicated Prefix Option . . . . . . . . . . . . . . . . . 8 77 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 78 7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 10 79 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 80 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 81 9.1. Normative References . . . . . . . . . . . . . . . . . . . 10 82 9.2. Informative references . . . . . . . . . . . . . . . . . . 10 83 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 12 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 86 1. Introduction 88 Mobile IPv6 Fast Handovers (FMIPv6) [RFC5568] aims at reducing the 89 handover latency by reducing the time to configure a new care-of 90 address (NCoA) for a mobile node(MN). In FMIPv6, the MN formulates a 91 prospective NCoA when it is still present on a link of a previous 92 access router (PAR). 94 [RFC4968] provides different IPv6 link models that are suitable for 95 IEEE802.16 based networks and provides analysis of various 96 considerations for each link model and the applicability of each link 97 model under different deployment scenarios. [RFC5121] specifies the 98 addressing and operation of IPv6 over the IPv6 specific part of the 99 packet convergence sublayer of IEEE Std 802.16e [802.16e], and point- 100 to-point link model is recommended. Also, 3GPP and 3GPP2 have 101 adopted the point-to-point link model based on the recommendations in 102 [RFC3314]. 104 In this document, we first explain the problems associated with 105 FMIPv6 on point-to-point links followed by a detailed description of 106 prefix management for FMIPv6 operation on point-to-point links. 108 In Section 3 we describe why the point-to-point link address 109 formation procedures are needed in FMIPv6, in Section 4 we define a 110 procedure that a new access router (NAR) can use to dynamically 111 assign unique prefixes in point-to-point links and in Section 5 we 112 define necessary messages/options for the operation in Section 4. 114 2. Terminology 116 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 117 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 118 document are to be interpreted as described in [RFC2119]. 120 The terminology in this document is based on the definitions in 121 [RFC5568], in addition to the ones specified in this section. 123 point-to-point link model: In this model, a set of layer 2 transport 124 connections between a MN and an access router (AR) are treated as 125 a single link. Each link is allocated a separate, unique prefix 126 or a set of unique prefixes by the AR. Please refer to [RFC4968] 127 for details. 129 shared link model: In this model, one or more prefixes are shared by 130 mobile nodes for constructing their global IPv6 addresses. Please 131 refer to [RFC4968] for details. 133 dedicated prefix: In point-to-point link model, a unique prefix used 134 by a MN for formulating a NCoA while the MN is still on a PAR's 135 link. 137 3. Problem Statement 139 The following are operations relating to prefix management as per 140 [RFC5568]: 142 o Movement detection. The protocol enables a MN to quickly detect 143 that it has moved to a new subnet by providing the new access 144 point and the associated subnet prefix information when the MN is 145 still connected to its current subnet. For instance, the MN may 146 discover available access points using link-layer specific 147 mechanisms (i.e., a "scan" in WLAN) and then request subnet 148 information corresponding to one or more of those discovered 149 access points. The MN sends a Router Solicitation for Proxy 150 Advertisement (RtSolPr) to its access router to resolve one or 151 more Access Point Identifiers (AP-ID)to subnet-specific 152 information. In response, the access router sends a Proxy Router 153 Advertisement (PrRtAdv) message containing one or more [AP-ID, AR- 154 Info] tuples, which the MN can use in readily detecting movement: 155 when attachment to an access point with AP-ID takes place, the MN 156 knows the corresponding new router's coordinates including its 157 prefix, IP address, and L2 address. 159 o NCoA configuration. AR-Info contains the access router's L2 and 160 IP addresses, and the prefix valid on the interface to which the 161 Access Point (identified by AP-ID) is attached. With the prefix 162 provided in the PrRtAdv message, the MN formulates a prospective 163 NCoA. 165 In shared link model, the prefixes are manually configured in the 166 previous access router. This is not a problem because there is only 167 a small number of adjacent access routers, and the prefix is shared 168 by many mobile nodes. However, it becomes a big problem when trying 169 to configure prefixes manually in point-to-point link model. In this 170 model, each MN has one or more dedicated prefixes, that is, different 171 MNs have different prefixes. The prefixes could be allocated 172 dynamically. When a MN attaches to an AR, the AR should allocate one 173 or more dedicated prefixes for it; when the MN detaches from the AR, 174 the MN's prefixes are released, and can be reused by other MNs. The 175 number of unique prefixes in this operation can be huge. 177 NCoA formulation in point-to-point links requires a PAR to 178 dynamically request a dedicated prefix from a NAR, and then advertise 179 it to the MN using a Proxy Router Advertisement (PrRtAdv) message. 180 [RFC5568] does not specify such dependencies. 182 4. Prefix Management on Point-to-Point Links 184 Upon the indication of handover from the PAR to the NAR, the PAR uses 185 Handover Initiate (HI)/ Handover Acknowledge (HAck) message exchange 186 to get a dedicated prefix from the NAR. The PAR then sends this 187 prefix in the PrRtAdv message to the MN as described in [RFC5568]. 188 In the PrRtAdv message, A-bit and L-bit MUST be turned on. The MN 189 thus uses this prefix for movement detection and NCoA configuration 190 as per [RFC5568]. 192 4.1. Predictive mode 194 New FMIPv6 message exchange is introduced for the PAR to ask for MN's 195 dedicated prefix as shown in Figure 1. In [RFC5568], HI is assumed 196 to be sent after the Fast Binding Update (FBU) for handover 197 indication. Here, modified HI/Hack messages are used for prefix 198 request/response. Details are described in Section 5. 200 The NAR MAY use DHCPv6 prefix delegation to request/ release prefixes 201 from a DHCPv6 server. The DHCPv6 messages are triggered by the HI 202 for prefix request. The NAR MAY also use AAA prefix delegation to 203 request/ release prefixes for this MN from an AAA server. The 204 mechanisms for the NAR to acquire the prefixes are outside the scope 205 of this document. 207 Lifetime in Dedicated Prefix Option in Figure 1 is used to prevent 208 prefix depletion because of erroneous movement in which the mobile 209 node receives a dedicated prefix prior to a handover that it is 210 moving to a new access point but it either moves to a different one 211 or it aborts movement altogether. Not until timeout of the prefix 212 does the NAR release it. 214 MN PAR NAR DHCP/AAA 215 | | | Server 216 | | | | 217 |------RtSolPr------->| | | 218 | | HI(Prefix Request) | | 219 | |----------------------->|Prefix | 220 | | |-Request->| 221 | | |<-Reply---| 222 | | HAck(Prefix Response) | | 223 | |<-----------------------| | 224 |<-----PrRtAdv--------| | | 225 | | |No FBU | 226 | | |Release | 227 | | |Prefix | 228 |------FBU----------->|--------HI------------->| | 229 | |<------HAck-------------| | 230 | <--FBack---|--FBack---> | | 231 disconnect forward | | 232 | packets===================>| | 233 | | | | 234 | | | | 235 connect | | | 236 | | | | 237 |--------- UNA ------------------------------->| | 238 |<=================================== deliver packets | 239 | | | 241 Figure 1: Prefix Signaling 243 In some wireless networks, the handover control may reside in the 244 network even though the decision to undergo handover may be mutually 245 agreed between the MN and the network. In such a case, the PAR can 246 send an unsolicited PrRtAdv containing the link-layer address, IP 247 address, and dedicated prefix of the mobile node when the network 248 decides that a handover is imminent. In this network-initiated 249 handover scenario, there isn't explicit RtSolPr to trigger PAR to 250 request a prefix and implementation specific trigger MUST be used by 251 PAR to send HI message for prefix request. 253 4.2. Reactive Mode 255 In the reactive mode, there are two cases. A MN receives PrRtAdv 256 message or otherwise. 258 o The MN receives PrRtAdv message and formulates NCoA before 259 attaching to the NAR. The MN and the NAR operate in line with the 260 procedure defined in [RFC5568]. 262 o The MN can't formulate NCoA before attaching to the NAR. IP 263 connectivity should be established first. The MN can configure 264 its IP address using stateless address configuration, or using 265 stateful address configuration. In the former case, the NAR 266 SHOULD send un-solicited RA to expedite MN's address 267 configuration. Once NCoA formulation is finished, the MN operates 268 according to [RFC5568]. 270 In both cases, the MN formulates NCoA from the dedicated prefix. 271 Since the MN has already handed over to the NAR, this prefix is 272 retained. 274 5. HI and Hack Extensions 276 5.1. HI Extension 278 The Handover Initiate (HI),defined in [RFC5568], is a Mobility Header 279 message sent by one Access Router to another to initiate the process 280 of a MN's handover. 282 In [RFC5568], the PAR uses a Code value of 0 when it processes an FBU 283 with PCoA as source IP address, while uses a Code value of 1 when it 284 processes an FBU whose source IP address is not PCoA. A new Code 285 value of TBD1 (to be assigned by IANA) is used for the dedicated 286 prefix request. Dedicated Prefix Option defined in Section 5.3 MAY 287 be included as a hint for a requested preference. The NAR MAY 288 allocate a dedicated prefix based on the prefix preference in the 289 option. If the option is not included, the NAR allocates a prefix 290 according to it's discretion. 292 5.2. HAck Extension 294 Handover Acknowledgment message defined in [RFC5568] is a Mobility 295 Header message that MUST be sent as a reply to the Handover Initiate 296 message. In this document, HAck is extended as follows to respond to 297 a dedicated prefix request: 298 o One new Code value is defined. Here, a Code value of TBD2 (to be 299 assigned by IANA) is used for dedicated prefix response. 300 o Dedicated Prefix Option defined in Section 5.3 MUST be included 301 for prefix delegation. 303 5.3. Dedicated Prefix Option 305 This option is of the form shown in Figure 2. 307 0 1 2 3 308 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 309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 310 | Type | Length | Option-Code | Prefix Length | 311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 312 | Lifetime | 313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 314 | | 315 + + 316 | | 317 + Prefix + 318 | | 319 + + 320 | | 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 323 Figure 2: Dedicated Prefix Option 325 Type To be assigned by IANA 327 Length The length of the option in units of 8 octets. 329 Prefix Length 330 8-bit unsigned integer. The number of leading bits 331 in the Prefix that are valid. The value ranges from 0 332 to 128. 334 Option-Code 335 1 Dedicated Prefix 337 Lifetime 32-bit unsigned integer. The length of time in seconds 338 (relative to the time the packet is sent). A value of 339 all one bits (0xffffffff) represents infinity. 341 Prefix An IP address or a prefix of an IP address. A MN uses it 342 to formulate a NCoA. 344 6. Security Considerations 346 Prefix management for FMIPv6 operation on point-to-point links uses 347 two messages (HI/Hack) for prefix request and response. These 348 messages are secured using FMIPv6 security mechanisms and hence do 349 not introduce any new security threats and the security provided by 350 FMIPv6 applies completely. 352 7. IANA considerations 354 This document extends existing HI/HAck messages, new HI Code (TBD1) 355 and HAck Code (TBD2) values need to be assigned by IANA. 357 The document also defines one new Mobility Option which needs type 358 assignment from the Mobility Options Type registry at 359 http://www.iana.org/assignments/mobility-parameters: 361 1. Dedicated Prefix Option described in Section 5.3. 363 8. Acknowledgements 365 The authors would like to thank Heejin Jang, Daniel Park, Vijay 366 Devarapalli, Rajeev Koodli, Subir Das, and Spencer Dawkins for 367 valuable comments. 369 9. References 371 9.1. Normative References 373 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 374 Requirement Levels", BCP 14, RFC 2119, March 1997. 376 [RFC5568] Koodli, R., "Mobile IPv6 Fast Handovers", RFC 5568, 377 July 2009. 379 [RFC5121] Patil, B., Xia, F., Sarikaya, B., Choi, JH., and S. 380 Madanapalli, "Transmission of IPv6 via the IPv6 381 Convergence Sublayer over IEEE 802.16 Networks", RFC 5121, 382 February 2008. 384 9.2. Informative references 386 [802.16e] Institute of Electrical and Electronics Engineer, 387 "Amendment for Physical and Medium Access Control Layers 388 for Combined Fixed and Mobile Operation in Licensed 389 Bands", IEEE 802.16e/D12. 391 [RFC3314] Wasserman, M., "Recommendations for IPv6 in Third 392 Generation Partnership Project (3GPP) Standards", 393 RFC 3314, September 2002. 395 [RFC4968] Madanapalli, S., "Analysis of IPv6 Link Models for 802.16 396 Based Networks", RFC 4968, August 2007. 398 Appendix A. Change Log 400 o v03 Dedicated Prefix Option made compatible with [RFC5568]. 402 Authors' Addresses 404 Frank Xia 405 Huawei USA 406 1700 Alma Dr. Suite 500 407 Plano, TX 75075 409 Phone: +1 972-509-5599 410 Email: xiayangsong@huawei.com 412 Behcet Sarikaya 413 Huawei USA 414 1700 Alma Dr. Suite 500 415 Plano, TX 75075 417 Phone: +1 972-509-5599 418 Email: sarikaya@ieee.org