idnits 2.17.1 draft-krishnan-netext-intertech-ps-02.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 doesn't use any RFC 2119 keywords, yet has text resembling RFC 2119 boilerplate text. -- The document date (July 12, 2009) is 5402 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Netext BOF S. Krishnan 3 Internet-Draft Ericsson 4 Intended status: Informational H. Yokota 5 Expires: January 13, 2010 KDDI Lab 6 T. Melia 7 Alcatel-Lucent 8 C. Bernardos 9 UC3M 10 July 12, 2009 12 Issues with network based inter-technology handovers 13 draft-krishnan-netext-intertech-ps-02 15 Status of this Memo 17 This Internet-Draft is submitted to IETF in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on January 13, 2010. 38 Copyright Notice 40 Copyright (c) 2009 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 in effect on the date of 45 publication of this document (http://trustee.ietf.org/license-info). 46 Please review these documents carefully, as they describe your rights 47 and restrictions with respect to this document. 49 Abstract 51 Proxy Mobile IPv6 (PMIPv6) is a network based mobility management 52 protocol that enables IP mobility for a host without requiring its 53 participation in any mobility-related signaling. While the PMIPv6 54 protocol itself supports handover across interfaces and between 55 access types, there are several issues with effectively performing 56 inter-technology handovers with network based mobility protocols. 57 This document aims to enumerate some known issues with such 58 handovers. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 1.1. Conventions used in this document . . . . . . . . . . . . . 3 64 2. Issues occuring in the MN . . . . . . . . . . . . . . . . . . . 3 65 2.1. Formation of interface identifier for SLAAC . . . . . . . . 3 66 2.2. Use of DHCP for address configuration . . . . . . . . . . . 3 67 2.3. Usage of the same address on multiple interfaces . . . . . 3 68 2.4. Limitations of interfaces . . . . . . . . . . . . . . . . . 4 69 2.5. Interface between MN and MAG . . . . . . . . . . . . . . . 4 70 3. Issues occuring in the network . . . . . . . . . . . . . . . . 4 71 3.1. Access selection . . . . . . . . . . . . . . . . . . . . . 5 72 3.2. Handover vs. multi-homing . . . . . . . . . . . . . . . . . 5 73 3.3. Predictive handovers . . . . . . . . . . . . . . . . . . . 5 74 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 75 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 76 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 77 6.1. Normative References . . . . . . . . . . . . . . . . . . . 6 78 6.2. Informative References . . . . . . . . . . . . . . . . . . 6 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 81 1. Introduction 83 Proxy Mobile IPv6 (PMIPv6) [RFC5213] is a network based mobility 84 management protocol enables IP mobility for a host without requiring 85 its participation in any mobility-related signaling. While the 86 PMIPv6 protocol itself supports handover across interfaces and 87 between access types, there are several issues with effectively 88 performing inter-technology handovers with network based mobility 89 protocols. This document aims to enumerate some known issues with 90 such handovers. On a high level these can be classified into those 91 issues occurring on the MN and those issues occurring in the network. 93 1.1. Conventions used in this document 95 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL","SHALL NOT", 96 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 97 document are to be interpreted as described in [RFC2119]. 99 2. Issues occuring in the MN 101 2.1. Formation of interface identifier for SLAAC 103 The IPv6 address of the MN is composed of two parts, the prefix and 104 the interface identifier. Even if the network correctly identified 105 the handover and allocated the same prefix on the new interface, the 106 MN might come up with a different interface identifier on the new 107 interface than it was using on the old interface. This is usually in 108 several link-layer technologies because the interface identifier is 109 formed based on a unique identifier of the link-layer interface. 110 E.g. the modified EUI-64 based interface identifiers based on the MAC 111 address of the link-layer interface. If this is the case, the 112 resulting address on the new interface is different than the address 113 the MN was using prior to the handover and hence the applications 114 bound to the earlier IPv6 address will lose connectivity. 116 2.2. Use of DHCP for address configuration 118 If the MN uses DHCP to configure the IP address and as long as it 119 complies to recommendations highlighted in RFC 5213 the issue raised 120 in the previous section does not apply. 122 2.3. Usage of the same address on multiple interfaces 124 Several MN operating system implementations do not allow the 125 configuration of the same address on multiple interfaces. Even on 126 those that do, the resulting behavior is usually not predictable. 127 e.g. after a handover all the traffic might still be directed to the 128 old interface (hence getting dropped) because the default route was 129 pointing towards that interface. 131 2.4. Limitations of interfaces 133 Certain types of point-to-point interfaces are tightly bound to the 134 underlying interface and could be torn down even if there is another 135 viable interface that can carry the traffic. For instance, some 136 operating system dynamically creates a PPP interface with an IP 137 address assigned to it when its connection is established and all 138 transport sessions over that connection are maintained only while 139 that PPP interface exists. This implies that the address should not 140 be bound directly to an interface that can go down during handovers 141 but something a bit more stable. 143 2.5. Interface between MN and MAG 145 The PMIPv6 protocol needs to receive the right information fro the MN 146 to form the PBU message for the LMA. In particular the MN should 147 indicate to the access network if the interface attachment 148 corresponds to an initial attachment or to an handover. This 149 information is contained in the Handover Indicator option in the PBU 150 message. Conveying this information from the MN to the MAG implies 151 discussing mobile node involvement in the mobility procedure. 153 The MN to MAG interface can be based upon L2 signalling or L3 154 signalling. 156 If L2 signalling is used it is necessary that each wireless access 157 technology connected to the PMIPv6 domain supports transferring of 158 such information (e.g. HI). Although no changes to the IP stack 159 would be required, the main drawback is that each L2 technology will 160 need to implement their own mechanisms. 162 If L3 signalling is used the MN can then include such info in IP 163 based signalling being technology agnostic. Major drawback is the 164 modification of the IP stack. 166 In any case to support inter-technology the MN needs to send the 167 information required to fill the PBU message. Withount this support, 168 it might be hard to implement inter-hechnology handovers. 170 3. Issues occuring in the network 171 3.1. Access selection 173 The network nodes may not always be aware of the complete set of 174 access technologies available to the MN. This is especially true if 175 the multiple accesses are administered by different entities. Only 176 the MN is guaranteed to have this information. The network may also 177 not know about the characteristics that the MN desires from the 178 selected access technology. Because of these reasons it is almost 179 impossible for the network to perform access selection without some 180 amount of co-operation from the MN. 182 3.2. Handover vs. multi-homing 184 The network nodes may not always be aware of the intent of the MN 185 when it attaches to a new attachment point. The MN may be performing 186 a handover, or may wish to be simultaneously connected. The access 187 router at the new attachment point is unable to distinguish between 188 these cases, but needs to communicate this information to the 189 mobility anchor. The mobility anchor point needs this information to 190 determine whether to handover an existing mobility session or to 191 create a new one. 193 3.3. Predictive handovers 195 An MN that is capable of being attached to multiple accesses can 196 perform a predictive handover attaching to the target access even 197 before detaching from the previous access. This is done in order to 198 reduce the handover latency and to reduce packet loss. Most of the 199 time, the intent of the MN is to continue using the previous access 200 until it explicitly signals to the network to start using the new 201 access. The target access router cannot determine if this is the 202 case and may end up prematurely moving the MNs binding over to the 203 new access even while the MN is sending outgoing packets onto the old 204 access. 206 4. Security Considerations 208 This document discusses issues with inter-technology handovers with 209 network based mobility protocols, and does not raise any new security 210 issues. 212 5. IANA Considerations 214 This document does not require any IANA action. 216 6. References 218 6.1. Normative References 220 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 221 Requirement Levels", BCP 14, RFC 2119, March 1997. 223 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 224 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 226 6.2. Informative References 228 Authors' Addresses 230 Suresh Krishnan 231 Ericsson 232 8400 Blvd Decarie 233 Town of Mount Royal, Quebec 234 Canada 236 Email: suresh.krishnan@ericsson.com 238 Hidetoshi Yokota 239 KDDI Lab 241 Email: yokota@kddilabs.jp 243 Telemaco Melia 244 Alcatel-Lucent 245 Route de Villejust 246 Nozay 91620 247 France 249 Email: telemaco.melia@alcatel-lucent.com 250 Carlos J. Bernardos 251 Universidad Carlos III de Madrid 252 Av. Universidad, 30 253 Leganes, Madrid 28911 254 Spain 256 Phone: +34 91624 6236 257 Email: cjbc@it.uc3m.es 258 URI: http://www.it.uc3m.es/cjbc/