idnits 2.17.1 draft-sarikaya-netlmm-itho-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 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 369. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 380. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 387. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 393. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard 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 327 has weird spacing: '...d Fixed and M...' == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- 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 (June 3, 2008) is 5806 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) == Unused Reference: 'RFC2629' is defined on line 271, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2629 (Obsoleted by RFC 7749) ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) == Outdated reference: A later version (-03) exists of draft-yokota-mipshop-pfmipv6-02 ** Downref: Normative reference to an Informational draft: draft-ietf-netlmm-mn-ar-if (ref. 'I-D.ietf-netlmm-mn-ar-if') == Outdated reference: A later version (-01) exists of draft-premec-netlmm-intertech-handover-00 ** Downref: Normative reference to an Informational draft: draft-premec-netlmm-intertech-handover (ref. 'I-D.premec-netlmm-intertech-handover') == Outdated reference: A later version (-09) exists of draft-irtf-mobopts-mpa-framework-02 ** Downref: Normative reference to an Informational draft: draft-irtf-mobopts-mpa-framework (ref. 'I-D.irtf-mobopts-mpa-framework') -- Possible downref: Normative reference to a draft: ref. 'I-D.soliman-netlmm-harmful' == Outdated reference: A later version (-14) exists of draft-ietf-monami6-multiplecoa-08 == Outdated reference: A later version (-11) exists of draft-ietf-mext-flow-binding-00 == Outdated reference: A later version (-18) exists of draft-ietf-netlmm-pmip6-ipv4-support-03 Summary: 6 errors (**), 0 flaws (~~), 11 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Sarikaya 3 Internet-Draft F. Xia 4 Expires: December 5, 2008 Huawei USA 5 June 3, 2008 7 Proxy Mobile IPv6 Inter-Technology Handover Issue 8 draft-sarikaya-netlmm-itho-00 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on December 5, 2008. 35 Abstract 37 Proxy Mobile IPv6 (PMIPv6) is a mobile node agnostic mobility 38 management protocol, that is, a mobile node does not take part in any 39 mobility signaling. In inter-technology handovers, mobile node input 40 is required in moving IP sessions from one interface to the other. 41 This document discusses the impact of the mobile node involvement 42 during inter-technology handover. 44 Table of Contents 46 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 47 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 48 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4 49 4. Proposed Solutions . . . . . . . . . . . . . . . . . . . . . . 4 50 5. Multi-homing Issues . . . . . . . . . . . . . . . . . . . . . 6 51 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 52 7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 7 53 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 54 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 55 9.1. Normative References . . . . . . . . . . . . . . . . . . . 7 56 9.2. Informative references . . . . . . . . . . . . . . . . . . 8 57 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 58 Intellectual Property and Copyright Statements . . . . . . . . . . 10 60 1. Introduction 62 Proxy Mobile IPv6 [I-D.ietf-netlmm-proxymip6] supports multi-homing 63 and therefore enables inter-technology handovers. Prefixes assigned 64 to the mobile node (MN) on one interface can be transferred to the 65 other interface thus achieving session continuity is only possible if 66 the new Mobile Access Gateway (MAG) sets the handoff indicator (HI) 67 parameter in the Proxy Binding Update (PBU) correctly. So far two 68 approaches have been proposed in order to help MAG set the parameter 69 correctly: MAG gets the link layer support during handover and MN 70 directly signals its willingness to move its sessions to the new 71 interface. However there are concerns that MN signaling which is 72 needed for MAG to do this contradicts PMIPv6 design principle of no 73 MN involvement. 75 Link layer support proposals include using the same interface 76 identifier in [I-D.ietf-netlmm-mn-ar-if] and handover extensions to 77 PMIPv6, e.g. using Fast Mobile IPv6 in [I-D.yokota-mipshop-pfmipv6]. 79 [I-D.premec-netlmm-intertech-handover] proposes a solution for MN 80 signaling to enable session continuity in inter-technology handovers. 82 [I-D.soliman-netlmm-harmful] states that the use of one technology 83 over the other is a policy decision and MN should make such a 84 decision. Since PMIPv6 singles out any MN involvement, PMIPv6 can 85 not help MN to use the different technologies properly. 87 Issues related to supporting IPv4 88 [I-D.ietf-netlmm-pmip6-ipv4-support] during inter-technology handover 89 are discussed in [I-D.premec-netlmm-intertech-handover]. 91 2. Terminology 93 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 94 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 95 document are to be interpreted as described in [RFC2119]. 97 The terminology in this document is based on the definitions in 98 [I-D.ietf-netlmm-proxymip6], in addition to the ones specified in 99 this section: 101 Single-Radio MN: Consider MN with two interfaces. These interfaces 102 are implemented in such a way that MN can keep one radio module on 103 at a given time. 105 Dual/multiple-Radio MN: Consider MN with two interfaces. These 106 interfaces are implemented in such a way that both radio modules 107 can receive and transmit simultaneously. 108 Inter-technology handover: Sometimes called vertical handover. A 109 multi-homed MN communicates with one interface at any time to 110 conserve power. Each interface can support different access 111 technology. Inter-technology handover occurs when MN moves out of 112 coverage of one technology and moves into the coverage area of 113 another technology which will result in switching of the 114 communicating interface on MN [I-D.irtf-mobopts-mpa-framework]. 116 3. Problem Statement 118 When MN does an inter-technology handover, the new MAG sends a Proxy 119 Binding Update (PBU) message to the local mobility anchor (LMA) to 120 register the new care-of address. In the PBU, MAG sets the access 121 technology type (ATT) and handoff indicator (HI) values. If ATT is 122 different from the one stored in the existing binding cache entry for 123 this MN and if HI is set to 2 (Handoff between two different 124 interfaces of the mobile node), LMA concludes that an inter- 125 technology handover happened and assigns the same home network 126 prefix(es) to MN which enables IP session continuity. 128 Setting the access technology type correctly might prove easier for 129 MAGs that are connected to a single technology. Currently this could 130 be the most popular case. However with the advent of fixed mobile 131 convergence this is likely to change. MAGs in the future are 132 expected to serve more than one access technologies. 134 Setting the handoff indicator correctly is also not so easy. Most 135 MAGs would tend to set HI to 1 (Attachment over a new interface) 136 which would result in LMA setting new prefix(es) to MN. 138 4. Proposed Solutions 140 There are two categories of solutions: link layer input and MN input. 142 One of the link layer based solutions suggests using the same 143 interface identifier, i.e. MAC address on the new interface. 144 Previous MAG (PMAG) can then send MN's interface identifier to the 145 new MAG using context transfer. Also the access technology type 146 could be sent by the previous MAG. This together with the access 147 technology type being different enables the new MAG to conclude that 148 MN is capable and has intention to move its IP sessions to the new 149 interface. NMAG then sets the parameters correctly enabling IP 150 session continuity [I-D.ietf-netlmm-mn-ar-if]. 152 Using the same interface identifier on a different interface means 153 changing the MAC address of that interface. MAC addresses in some 154 technologies like WiMAX [802.16e] are tied to certificates and thus 155 can not be changed. 157 In [I-D.yokota-mipshop-pfmipv6], the new MAG (NMAG) can receive MN 158 interface identification (IID) information and based on the values 159 received NMAG sets correctly the handoff indicator parameter. Fast 160 Mobile IPv6 allows MAGs to receive link layer data about the MN 161 during handoff from the access nodes (AN) such as base stations. 162 NMAG receives MN IID on the new interface. 163 [I-D.yokota-mipshop-pfmipv6] defines context transfer from PMAG to 164 NMAG which includes MN IID of the previous interface. This value is 165 compared with IID value received of the new interface and set HI 166 value to 2 if the two values are different. 168 The values could be different but MN may be connecting simultaneously 169 to another network. This case is detected by NMAG if there was no 170 context transfer because no handoff happened. In this case NMAG sets 171 HI to 1. This scenario is valid for a dual-radio MN. 173 This link layer input based solution does not require any changes on 174 the link layer addresses. However an additional handover protocol 175 needs to be used in order for MAGs to receive the link layer data for 176 MNs during handover. The use of a different handover protocol could 177 invalidate the solution. 179 MN input based solution is proposed in 180 [I-D.premec-netlmm-intertech-handover]. Router solicitation (RS) 181 message is modified to include two bits, C flag which is set by MN to 182 indicate that MN is capable of performing itw own mobility management 183 and P flag which is set by MN to indicate that MN is willing to move 184 its IP sessions accross interfaces. 186 MAG first waits until it receives an RS message from MN and then 187 sends an initial PBU message. If P flag is set in RS, MAG will set 188 HI to 2. This will result in LMA assigning the same prefix(es) to MN 189 which are returned in PBA. MAG will advertise the same prefix(es) in 190 its router advertisement message to MN. MN will move its IP sessions 191 to the new interface. 193 MN input-based solution is better than link layer input based 194 solutions because MAG knows what MN wants and acts accordingly. 195 However the requirement for MN input defeats the purpose of PMIPv6 196 which is a mobility solution that does not involve MN in any mobility 197 signaling. Also the solution is based on a single bit input from MN. 198 As discussed later in Section 5 such a simple input is hardly enough 199 for MN to convey its needs in case of multi-homing. 201 5. Multi-homing Issues 203 Multiple/dual radio MNs require simultaneous operations of radios 204 which is more complex than single-radio operation. When the radio 205 frequencies are close to each other single-radio could be the only 206 mode of operation due to the interference. However in other cases 207 multiple/dual mode of operation increases MN's capabilities to 208 communicate. 210 For single-radio MNs or when the coverage of two radios is not 211 overlapping the inter-technology handover is simpler to handle. It 212 is clear that IP sessions need to be moved to the new interface. 214 [I-D.soliman-netlmm-harmful] points out several deficiences of netlmm 215 (in this document called PMIPv6) in case of multiple/dual radio 216 operation. 218 If the networks are operated by different companies, i.e. inter- 219 domain handover and both networks support PMIPv6 then in case of 220 inter-technology handover the current network will try to keep IP 221 sessions rather than moving them to the next network. In case of 222 link layer input solutions discussed in Section 4 PMAG can simply 223 refuse to context transfer the required interface identifier and 224 access technology type information to NMAG. Only MN input can enable 225 NMAG to move IP sessions to the new interface. 227 For multiple/dual radio MNs, inter-technology handover brings the 228 possibility of partially moving IP sessions to each interface even in 229 intra-domain handover where the networks are operated by the same 230 company. MN should be able to use different links for different 231 applications depending on link quality/capabilities. Recent work, 232 e.g. [I-D.ietf-monami6-multiplecoa] and [I-D.ietf-mext-flow-binding] 233 shows how this can be done. The main component of these solutions is 234 that MN input is required which is singled out in PMIPv6. 236 For multiple/dual radio MNs, in inter-technology handover the use of 237 one interface or the other becomes a policy decision. Leaving this 238 decision to MN is the right thing to do because MN knows the 239 applications that it wants to run and MN can best decide which link 240 layer is best to run each application. Using PMIPv6, such a 241 possibility would totally disappear. 243 PMIPv6 protocol operation will not encounter any difficulties if MN 244 has a single interface or if MN is single-radio and the coverage of 245 different radios is not overlapping. For multiple/dual mode MNs it 246 is better to use host mobility protocols [RFC3775] in order to fully 247 utilize its interface capabilities to run the applications and manage 248 the flows by itself. Using PMIPv6 even if MN input is allowed, the 249 amount of data that can be passed to MAG will be very limited. 251 6. Security Considerations 253 This document is informational and does not define any new messages. 254 PMIPv6 security procedures apply. 256 7. IANA considerations 258 None. 260 8. Acknowledgements 262 TBD. 264 9. References 266 9.1. Normative References 268 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 269 Requirement Levels", BCP 14, RFC 2119, March 1997. 271 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 272 June 1999. 274 [I-D.ietf-netlmm-proxymip6] 275 Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 276 and B. Patil, "Proxy Mobile IPv6", 277 draft-ietf-netlmm-proxymip6-18 (work in progress), 278 May 2008. 280 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 281 in IPv6", RFC 3775, June 2004. 283 [I-D.yokota-mipshop-pfmipv6] 284 Yokota, H., Chowdhury, K., Koodli, R., Patil, B., and F. 285 Xia, "Fast Handovers for PMIPv6", 286 draft-yokota-mipshop-pfmipv6-02 (work in progress), 287 February 2008. 289 [I-D.ietf-netlmm-mn-ar-if] 290 Laganier, J., Narayanan, S., and P. McCann, "Interface 291 between a Proxy MIPv6 Mobility Access Gateway and a Mobile 292 Node", draft-ietf-netlmm-mn-ar-if-03 (work in progress), 293 February 2008. 295 [I-D.premec-netlmm-intertech-handover] 296 Premec, D. and T. Savolainen, "Inter-technology handover 297 in netlmm domain", 298 draft-premec-netlmm-intertech-handover-00 (work in 299 progress), April 2008. 301 [I-D.irtf-mobopts-mpa-framework] 302 Dutta, A., Fajardo, V., Ohba, Y., Taniuchi, K., and H. 303 Schulzrinne, "A Framework of Media-Independent Pre- 304 Authentication (MPA) for Inter- domain Handover 305 Optimization", draft-irtf-mobopts-mpa-framework-02 (work 306 in progress), February 2008. 308 [I-D.soliman-netlmm-harmful] 309 Soliman, H., "Network-based mobility considered harmful", 310 draft-soliman-netlmm-harmful-00 (work in progress), 311 May 2006. 313 [I-D.ietf-monami6-multiplecoa] 314 Wakikawa, R., Devarapalli, V., Ernst, T., and K. Nagami, 315 "Multiple Care-of Addresses Registration", 316 draft-ietf-monami6-multiplecoa-08 (work in progress), 317 May 2008. 319 [I-D.ietf-mext-flow-binding] 320 Soliman, H., Montavont, N., Fikouras, N., and K. 321 Kuladinithi, "Flow Bindings in Mobile IPv6 and Nemo Basic 322 Support", draft-ietf-mext-flow-binding-00 (work in 323 progress), May 2008. 325 [802.16e] Institute of Electrical and Electronics Engineer, 326 "Amendment for Physical and Medium Access Control Layers 327 for Combined Fixed and Mobile Operation in Licensed 328 Bands", IEEE 802.16e/D12. 330 9.2. Informative references 332 [I-D.ietf-netlmm-pmip6-ipv4-support] 333 Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy 334 Mobile IPv6", draft-ietf-netlmm-pmip6-ipv4-support-03 335 (work in progress), May 2008. 337 Authors' Addresses 339 Behcet Sarikaya 340 Huawei USA 341 1700 Alma Dr. Suite 500 342 Plano, TX 75075 344 Phone: +1 972-509-5599 345 Email: sarikaya@ieee.org 347 Frank Xia 348 Huawei USA 349 1700 Alma Dr. Suite 500 350 Plano, TX 75075 352 Phone: +1 972-509-5599 353 Email: xiayangsong@huawei.com 355 Full Copyright Statement 357 Copyright (C) The IETF Trust (2008). 359 This document is subject to the rights, licenses and restrictions 360 contained in BCP 78, and except as set forth therein, the authors 361 retain all their rights. 363 This document and the information contained herein are provided on an 364 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 365 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 366 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 367 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 368 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 369 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 371 Intellectual Property 373 The IETF takes no position regarding the validity or scope of any 374 Intellectual Property Rights or other rights that might be claimed to 375 pertain to the implementation or use of the technology described in 376 this document or the extent to which any license under such rights 377 might or might not be available; nor does it represent that it has 378 made any independent effort to identify any such rights. Information 379 on the procedures with respect to rights in RFC documents can be 380 found in BCP 78 and BCP 79. 382 Copies of IPR disclosures made to the IETF Secretariat and any 383 assurances of licenses to be made available, or the result of an 384 attempt made to obtain a general license or permission for the use of 385 such proprietary rights by implementers or users of this 386 specification can be obtained from the IETF on-line IPR repository at 387 http://www.ietf.org/ipr. 389 The IETF invites any interested party to bring to its attention any 390 copyrights, patents or patent applications, or other proprietary 391 rights that may cover technology that may be required to implement 392 this standard. Please address the information to the IETF at 393 ietf-ipr@ietf.org.