idnits 2.17.1 draft-oulai-netlmm-mip-interaction-multiple-hnp-00.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 seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (January 12, 2009) is 5580 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) == Outdated reference: A later version (-10) exists of draft-ietf-mext-nemo-v4traversal-07 == Outdated reference: A later version (-14) exists of draft-ietf-monami6-multiplecoa-10 == Outdated reference: A later version (-07) exists of draft-ietf-netlmm-mip-interactions-01 ** Downref: Normative reference to an Informational draft: draft-ietf-netlmm-mip-interactions (ref. 'I-D.ietf-netlmm-mip-interactions') ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Netlmm Working Group D. Oulai 3 Internet-Draft S. Krishnan 4 Intended status: Standards Track Ericsson 5 Expires: July 16, 2009 January 12, 2009 7 Multiple Home Network Prefixes Considerations in Handover involving 8 Network and Client Based IP Mobility Protocols 9 draft-oulai-netlmm-mip-interaction-multiple-hnp-00.txt 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on July 16, 2009. 34 Copyright Notice 36 Copyright (c) 2009 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. 46 Abstract 48 Proxy Mobile IPv6 (PMIPv6) and Mobile IPv6 (MIPv6) are the base 49 protocols defined by IETF for network based and client based 50 mobility. This document analyzes PMIPv6 and two MIPv6 extensions, 51 DSMIP and NEMO, with regard to multiple Home Network Prefixes 52 handling during handover. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Conventions used in this document . . . . . . . . . . . . . . 4 58 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 4. Interaction between PMIP and client based protocols . . . . . 6 60 4.1. Scenario A . . . . . . . . . . . . . . . . . . . . . . . . 6 61 4.1.1. PMIP-DSMIP . . . . . . . . . . . . . . . . . . . . . . 6 62 4.1.2. PMIP-NEMO . . . . . . . . . . . . . . . . . . . . . . 6 63 4.2. Scenario C . . . . . . . . . . . . . . . . . . . . . . . . 6 64 4.2.1. PMIP-DSMIP . . . . . . . . . . . . . . . . . . . . . . 6 65 4.2.2. PMIP-NEMO . . . . . . . . . . . . . . . . . . . . . . 7 66 5. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 9 67 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 68 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 69 8. Normative References . . . . . . . . . . . . . . . . . . . . . 12 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 72 1. Introduction 74 MIPv6 is the IETF standard for client-based mobility [RFC3775] and 75 PMIPv6 is an extension of MIPv6 developed to offer network-based 76 mobility [RFC5213]. Those two protocols will be deployed on a wide 77 scale. On the other hand, DSMIP [I-D.ietf-mext-nemo-v4traversal] and 78 NEMO [RFC3963] are two major variants of MIPv6 used to support IPv4 79 mobility and mobile routers (MR). Therefore, standardizing 80 interactions between those protocols becomes mandatory. Three 81 scenarios have been presented in [I-D.ietf-netlmm-mip-interactions]. 83 * Scenario A: Two distinct PMIPv6 domains inside a single MIPv6 84 domain. 86 * Scenario B: A single domain where PMIPv6 and MIPv6 are supported. 88 * Scenario C: A collocated LMA/HA serving distinct PMIPv6 and MIPv6 89 domain. 91 In this document, the ability to manage the mobility of a MN with 92 more than one assigned HNPs for a mobility session is considered. 93 This allows reducing the Binding Cache size, the signaling load and 94 the security processing in some ways. PMIP allows multiple HNPs for 95 a single mobility session while MIPv6 does not. MIPv6 [RFC3775] 96 works with only one v6 HoA by MIPv6 session. Therefore, we will not 97 consider MIPv6 as managing multiples HNPs results on multiple MIPv6 98 sessions. DSMIP [I-D.ietf-mext-nemo-v4traversal] has the same 99 limitations as MIPv6 except that a MN can have several v4 HoAs from 100 different prefixes. On the contrary, NEMO [RFC3963] supports 101 multiple prefixes assignment. 103 Having multiple HNPs is interesting for example in the case where, 104 through a single LMA, a MN is connected to several service providers 105 which assign prefixes to the MN. In this situation, the mobility is 106 managed through a single mobility session. This features is also 107 interesting for Mobile Routers (MR). Here we consider DSMIP and NEMO 108 as they are MIPv6 extensions that support multiple HNPs assignment in 109 different ways. Moreover, PMIP is the only network based IP mobility 110 protocol. Therefore, in this document we describe handover between 111 PMIP and client based IP Mobility protocols (DSMIP and NEMO). 113 2. Conventions used in this document 115 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL","SHALL NOT", 116 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 117 document are to be interpreted as described in [RFC2119]. 119 3. Terminology 121 All the general mobility-related terms used in this document are to 122 be interpreted as defined in the Mobile IPv6 [RFC3775], Proxy Mobile 123 IPv6 [RFC5213], NEMO [RFC3963] and DSMIP 124 [I-D.ietf-mext-nemo-v4traversal] base specifications. 126 4. Interaction between PMIP and client based protocols 128 We now describe the interaction between PMIP, DSMIP and NEMO 129 protocols. First, note that we will not address scenario B mentioned 130 in [I-D.ietf-netlmm-mip-interactions] as it does not involve any 131 handover. Home Addresses in a PMIP domain are referred as P-HoA and 132 Home Addresses in the other protocol are simply labeled HoA. 134 4.1. Scenario A 136 In this scenario, PMIP is used for local mobility and the other 137 protocols for global mobility. We consider the case where Multiple 138 HNPs are assigned in the PMIP domain. 140 4.1.1. PMIP-DSMIP 142 Here, the MN can locally obtain several HNPs and forms P-HoAs based 143 on these HNPs. To register more than one P-HoA as CoAs with the 144 DSMIP HA, the MN must use Multiple CoA [I-D.ietf-monami6-multiplecoa] 145 specification (MCoA). After a handover in a new PMIP domain, the MN 146 can configure different P-HoAs and register them with the DSMIPv6 HA. 147 Note that some extensions to MCoA protocol are required to register 148 v4 P-HoA as CoA. 150 4.1.2. PMIP-NEMO 152 The same operations described in Section 4.1.1 apply here and the 153 MCoA specification can be modify to handle the assignment of a Mobile 154 Network Prefix (MNP) toward a specific CoA. 156 4.2. Scenario C 158 In this scenario, the LMA and the HA are collocated. Let's also 159 mentioned that there is no prefix sharing between MNs as stated in 160 [I-D.ietf-netlmm-mip-interactions]. Moreover, when in the PMIP 161 domain, it is recommended to create the SA for the DSMIP or NEMO 162 session in order to reduce the handover delay. 164 4.2.1. PMIP-DSMIP 166 4.2.1.1. Handover PMIP-DSMIP 168 We consider that the MN is assigned several HNPs in the PMIP domain. 169 Based on [I-D.ietf-mext-nemo-v4traversal] and [RFC5213] 170 specifications, the MN MUST choose one HNP and register it in the 171 DSMIPv6 domain, loosing connectivity through the other HNPs. We 172 suggest to label one HNP as the primary one in the PMIP domain. This 173 primary HNP will likely be chosen in for registration in the DSMIP 174 domain. The MN can also create one DSMIPv6 session for each assigned 175 HNP, which is not optimal. 177 As the whole prefix is reserved for a MN, a simple extension to 178 DSMIPv6 could be to allow several v6HoAs in the BCE but perform all 179 the signaling and security operations based on a single HoA labeled 180 as the primary HoA. Therefore, allowing multiple HoAs is equivalent 181 to allowing multiple HNPs. The MN is then able to send a single BU 182 and binds all the HNPs to a single CoAs. Modifying DSMIP in this way 183 should be straightforward as DSMIP already allows v6 and v4 HoAs in a 184 single binding and all the signaling and security operations are 185 based on the v6HoA. 187 4.2.1.2. Handover DSMIP-PMIP 189 Two sub-cases may happen here: 191 1. The MN runs one or more DSMIPv6 session with one HNP for each 192 session 193 After the handover, the PMIP domain assigns the HNPs used in the 194 DSMIPv6 domain and additional ones if required for a single PMIP 195 session. The HNP used in the MIPv6 domains are labeled as the 196 primary HNPs. The MN MUST maintain the MIPv6 SAs. 198 2. The MN uses one DSMIPv6 session with several HNPs 199 In this case, the prefix list used in the DSMIPv6 BCE is copied 200 to the PMIP BCE and all the HNPs are assigned to the MNs. The 201 primary HNP in the PMIP domain is also the primary one in the 202 DSMIPv6 domain. The MN MUST maintain the DSMIPv6 SA using the 203 primary v6HoA. 205 4.2.2. PMIP-NEMO 207 As the LMA and NEMO HA are collocated, the same sets of prefixes 208 advertised as HNPs in the PMIP domain can be used as MNPs in the NEMO 209 domain as those prefixes are reserved. When the MN is in the PMIP 210 domain, the SA with the NEMO HA should be created. 212 4.2.2.1. Handover PMIP-NEMO 214 As the MN (which became a MR in the NEMO domain) knows which prefixes 215 are advertised in the PMIP domain, after the handover, it inserts all 216 the PMIP HNPs as MNPs in the BU sent to the NEMO HA. A binding is 217 created towards the CoA for all those MNPs. The MR can also follow 218 the implicit mode where the HA will be responsible of retrieving all 219 the HNPs used int he PMIP domain and assigning them to the MN as 220 MNPs. if other means are used to assign the MNPs in the NEMO domain, 221 the MN or the HA should send the HNPs as hints during the signaling. 223 4.2.2.2. Handover NEMO-PMIP 225 When the LMA/HA receives the PBU for the MN, it checks the NEMO BCE 226 and assigns all the MNPs as HNPs to the MN. Therefore, the MR can 227 continue serving its MNPs, believing it is on the home network. 229 5. Recommendations 231 For scenario A, the best approach is to register all the P-HoAs 232 formed in the PMIP domain as CoAs at the HA. This is performed using 233 MCoA [I-D.ietf-monami6-multiplecoa] specification. For scenario C, 234 the interaction between PMIP and NEMO is the most elegant way of 235 providing multiple HNPs support. However, as NEMO is not expected to 236 be supported by most of the HAs, a slight modification of DSMIPv6 237 where multiple HNPs (or at least multiple v6HoAs) are supported 238 represents the best alternative. 240 6. Security Considerations 242 The issue brought here resides in the SA for the signaling message as 243 there are several HNPs and it is not scalable to have one SA for each 244 HoA or HNP. The MN in scenario C MUST be able to create the SA based 245 on one primary HoA. When receiving a signaling packet, the LMA/HA 246 MUST be able to identify the primary HoA or HNP in order to locate 247 the right SA for the host. 249 7. IANA Considerations 251 TBD 253 8. Normative References 255 [I-D.ietf-mext-nemo-v4traversal] 256 Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and 257 Routers (DSMIPv6)", draft-ietf-mext-nemo-v4traversal-07 258 (work in progress), December 2008. 260 [I-D.ietf-monami6-multiplecoa] 261 Wakikawa, R., Devarapalli, V., Ernst, T., and K. Nagami, 262 "Multiple Care-of Addresses Registration", 263 draft-ietf-monami6-multiplecoa-10 (work in progress), 264 November 2008. 266 [I-D.ietf-netlmm-mip-interactions] 267 Giaretta, G., "Interactions between PMIPv6 and MIPv6: 268 scenarios and related issues", 269 draft-ietf-netlmm-mip-interactions-01 (work in progress), 270 November 2008. 272 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 273 Requirement Levels", BCP 14, RFC 2119, March 1997. 275 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 276 in IPv6", RFC 3775, June 2004. 278 [RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. 279 Thubert, "Network Mobility (NEMO) Basic Support Protocol", 280 RFC 3963, January 2005. 282 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 283 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 285 Authors' Addresses 287 Desire Oulai 288 Ericsson 289 8400 Blvd Decarie 290 Town of Mount Royal, Quebec 291 Canada 293 Email: desire.oulai@ericsson.com 295 Suresh Krishnan 296 Ericsson 297 8400 Blvd Decarie 298 Town of Mount Royal, Quebec 299 Canada 301 Email: Suresh.Krishnan@ericsson.com