idnits 2.17.1 draft-tsirtsis-logically-separate-lmaha-01.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 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 353. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 364. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 371. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 377. 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 Copyright Line does not match the current year -- 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 (October 20, 2008) is 5659 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 (-06) exists of draft-ietf-mip6-bootstrapping-integrated-dhc-05 == Outdated reference: A later version (-14) exists of draft-ietf-monami6-multiplecoa-06 == Outdated reference: A later version (-18) exists of draft-ietf-netlmm-proxymip6-11 -- Obsolete informational reference (is this intentional?): RFC 3775 (Obsoleted by RFC 6275) Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group G. Tsirtsis 3 Internet-Draft Qualcomm 4 Intended status: Standards Track S. Krishnan 5 Expires: September 26, 2008 Ericsson 6 October 20, 2008 8 Behavior of Collocated HA/LMA 9 draft-tsirtsis-logically-separate-lmaha-01.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on April 23, 2009. 36 Abstract 38 In discussions about PMIPv6-MIPv6 interactions in NETLMM WG, scenario 39 C describes the case of collocation of LMA and HA function. In this 40 case a PMIP network emulates the "home link" for MNs using MIPv6. 41 This document argues that even when LMA and HA functions are 42 Collocated they MUST be treated as logically separate entities. In 43 particular this draft argues that PMIP BCEs MUST NOT overwrite MIPv6 44 BCEs and vice versa. 46 Table of Contents 48 1. Requirements notation . . . . . . . . . . . . . . . . . . . . . 3 49 2. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 3 50 3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 4. The Case for Logically Separate LMA and HA . . . . . . . . . . 3 52 4.1. Logical Relationship Between Colocated LMA/HA . . . . . . . 3 53 4.1.1. BCE Overwritting is Wrong . . . . . . . . . . . . . . . 4 54 4.1.2. Shared State between LMA and HA . . . . . . . . . . . . 5 55 5. Detailed Bootstrapping and Handoff Considerations . . . . . . . 5 56 5.1. Bootstrapping on Emulated Home Link . . . . . . . . . . . . 5 57 5.2. Connecting to Foreign Link . . . . . . . . . . . . . . . . 6 58 5.3. Connecting Back to Emulated Home Link . . . . . . . . . . . 7 59 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 60 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 61 8. Informative References . . . . . . . . . . . . . . . . . . . . 7 62 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 63 Intellectual Property and Copyright Statements . . . . . . . . . . 9 65 1. Requirements notation 67 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 68 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 69 document are to be interpreted as described in [RFC2119]. 71 2. Acknowledgments 73 We would like to thank the authors of PMIPv6-MIPv6 interactions draft 74 [I-D.giaretta-netlmm-mip-interactions] for providing the basis for 75 this discussion. 77 3. Introduction 79 In PMIPv6-MIPv6 interactions draft 80 [I-D.giaretta-netlmm-mip-interactions], scenario C describes the case 81 of collocation of LMA and HA function. In this case a PMIP network 82 emulates the "home link" for MNs using MIPv6. This document argues 83 that even when LMA and HA functions are Collocated they MUST be 84 treated as logically separate entities. In particular this draft 85 argues that PMIP BCEs MUST NOT overwrite MIPv6 BCEs and vice versa. 87 4. The Case for Logically Separate LMA and HA 89 When a PMIPv6 [I-D.ietf-netlmm-proxymip6] local mobility agent is 90 collocated with a MIPv6 [RFC3775] home agent, the PMIPv6 network can 91 be configured to emulate the MIPv6 "home link" for a mobile node 92 using MIPv6. This configuration and its implications are discussed 93 below. 95 4.1. Logical Relationship Between Colocated LMA/HA 97 A PMIPv6 network comprising an LMA and multiple MAGs emulates a 98 single link. When a PMIPv6 LMA and a MIPv6 HA are Collocated, PMIPv6 99 is used to handle mobility between MAGs in the same PMIPv6 network 100 emulating the link, and MIPv6 is used to handle mobility between 101 different links (emulated or physical). 103 In that sense, logically, the PMIPv6 LMA operates at a lower layer 104 than the MIPv6 HA. This means that when a packet is received by the 105 LMA/HA, the destination address of the packet is first matched 106 against Binding Cache Entries (BCE) created by MIPv6 BUs. If there 107 are no MIPv6 BCEs for this destination address (i.e., the MN is 108 deregistered at MIPv6 level) then LMA BCEs are searched. 110 This simple way of thinking about logically separating the two 111 functions, ensures that MNs can move between PMIPv6 emulated links 112 and other links the same way the do between physical links and 113 without require any specific implementation of the combined LMA/HA. 115 Indeed, the two logical functions can be implemented as two different 116 but communicating processes or as a single integrated process. The 117 BCE tables of the LMA and the HA can also be combined in a single 118 table or they can be maintained as separate tables. This draft does 119 not impose, propose, or in any other way imply any specific 120 implementation. Instead, this draft describes the required external 121 behavior of such a combined LMA/HA implementation and argues against 122 PMIPv6 BCEs overwriting MIPv6 BCEs. 124 4.1.1. BCE Overwritting is Wrong 126 There is currently a school of thought in the NETLMM WG that wants 127 PMIPv6 PBUs to overwrite state created by PMIPv6 BUs and vice versa. 128 This school of thought comes from a fundamental assumptions that as 129 MNs move from one link to another, they only maintain ONE link at a 130 time. In other words the assumption is that during a handoff an MN 131 will disconnect from one link and connect to another. In that sense, 132 when a combined HA/LMA receives a MIPv6 BU over a foreign link, it 133 can overwrite any state created in the LMA for the same mobile (since 134 presumably the MN is no longer connected to the MAG). Based on the 135 same logic when an combined HA/LMA receives a PMIPv6 BU over a MAG on 136 the home link, it can overwrite any state created in the HA for the 137 same mobile (since presumably the MN is no longer connected to a 138 foreign link). 140 This logic breaks down if one considers MNs that are capable of 141 maintaining more than one link at the same time. Such capability is 142 common and can be utilised in many different way, while specifically 143 MIPv6 allows for the following behavior: 145 Directing traffic between foreign links: If an MN can maintain two 146 links at the same time, it can direct traffic to one or the other 147 link by simply sending a BU to its HA, registering the CoA 148 corresponding to one or the other link. 150 Directing traffic between home and foreign link: If one of the 151 links maintained is the home link, the MN can direct traffic to it 152 by sending a deregistration MIPv6 BU to the HA over the home link, 153 while it can also direct traffic to the foreign link by sending a 154 MIPv6 BU to the HA directing traffic to the CoA of the foreign 155 link. 157 Directing traffic between Multiple links: MEXT WG is also working 158 on [I-D.ietf-monami6-multiplecoa] and 159 [I-D.soliman-monami6-flow-binding] specifications allowing an MN 160 to register multiple links (multiple CoAs and the home link) to 161 its HA at the same time and even direct different flows to 162 different links. 164 It should be clear that none of this can be possible if every time 165 the MN connects to its home link, the corresponding PMIPv6 BCE 166 overwrites the HA BCEs for the same mobile or every time the MN sends 167 a BU to its HA over a foreign link, the MIPv6 BCE overwrites the LMA 168 BCE entry for the same MN. 170 4.1.2. Shared State between LMA and HA 172 If the HA is configured as a virtual home link HA (i.e., there is no 173 direct link between MN and HA), there are no need to share any 174 parameters between HA and LMA functions. The LMA and HA function, 175 however, need to share certain parameters in a Collocated 176 implementation if the PMIPv6 network is used as a home link, i.e., if 177 the PMIPv6 network emulates a direct connection between the MN and 178 the HA. The parameters that need to be shared in this case have to 179 do with the addresses assigned to the MN by the two entities. 180 Specifically: 182 When an LMA receives a PBU for a new MN, it MUST first check if 183 the MN is associated with the Collocated HA e.g. based on the 184 MN-ID. If the HA already has a home address associated with this 185 MN, then the LMA MUST allocate the same address over the PMIPv6 186 home link. 188 When an HA receives an IKEv2 bootstrapping request for a new MN, 189 it MUST first check if the MN is associated with the Collocated 190 LMA e.g. based on the MN-ID. If the LMA already has a prefix 191 associated with this MN, then the HA provide the MN with the same 192 HNP over the IKEv2 session. 194 5. Detailed Bootstrapping and Handoff Considerations 196 5.1. Bootstrapping on Emulated Home Link 198 When an MN connects to a MAG in a PMIPv6 network, it receives an RA 199 indicating a prefix that is topologically correct at the LMA and 200 unique to the MN. This prefix can be used by the MN to autoconfigure 201 one (or more) IPv6 address. This address continues to be valid as 202 the MN moves between MAGs in the same PMIPv6 network. This is so 203 since every time the MN moves to a new MAG, the MAG sends a PBU to 204 the LMA creating a PMIPv6 Binding Cache Entry (BCE), binding the MN's 205 prefix with a MAG's address. Any packet with a destination address 206 matching the MN's prefix, is directed to the LMA, which based on the 207 BCE table it tunnels the packet to the appropriate MAG which then 208 delivers it to the MN. 210 Assume now that the MN, equipped with an IPv6 address derived from a 211 prefix provided to it over the link emulated by the PMIPv6 network, 212 wants to bootstrap MIPv6. Also assume that the HA used by the MN is 213 the one Collocated with the LMA of the PMIPv6 network the MN is 214 connected to. This address is maybe discovered by Dynamic HA Address 215 Detection (DHAAD) as defined in [RFC3775] or by any of the 216 bootstrapping mechanisms [RFC5026] 217 [I-D.ietf-mip6-bootstrapping-integrated-dhc]. 219 The MN proceeds to establish a security association with it using 220 IKEv2. According to [RFC5026], as part of this procedure the HA can 221 provide the home network prefix (HNP) to the MN. The MN immediately 222 understands that it is attached to its MIPv6 home link since the 223 prefix advertised to it directly over the link (in an RA) matches the 224 HNP provided to it by the HA. In this case the MN does not need to 225 send a MIPv6 BU to the HA and the logical HA function does not get 226 initiated. 228 In other words, any packet sent to the MN's prefix is still 229 intercepted by the LMA and redirected to the appropriate MAG 230 (according to PMIPv6 BCE table) for delivery to the MN over the 231 emulated home link. 233 5.2. Connecting to Foreign Link 235 If the MN connects to an access router that is not part of the same 236 PMIPv6 network as before i.e., on a foreign link, it will receive an 237 RA with a different prefix (say a foreign prefix) and generates an IP 238 address on the foreign link. 240 Note that up to now nothing has changed at the Collocated LMA/HA. 241 All traffic is still redirected by the LMA to the registered MAG 242 according to the state in the PMIPv6 BCE table. For this to change 243 the MN needs to send a MIPv6 BU to the HA. The BU introduces an 244 entry to the MIPv6 BCE, binding the MN's prefix to the CoA. Any 245 packets now reaching the LMA/HA will now match the MIPv6 BCE and be 246 redirected to the CoA. 248 Note that the MIPv6 BCE created by the BU sent over the foreign link 249 MUST NOT overwrite the PMIPv6 BCE for the same MN. The PMIPv6 BCE 250 for this MN is removed only if and when the MN disconnects from the 251 MAG in the PMIPv6 domain and has nothing to do with the HA state. 253 Indeed, according to when a MAG an MN disconnects from a MAG, the MAG 254 is supposed to send a deregistration BU to the LMA removing the 255 corresponding BCE for that MN. 257 5.3. Connecting Back to Emulated Home Link 259 Now say that after the MN has disconnected to from the PMIPv6 MAG and 260 registered to the HA via a foreign link, the MN connects again to its 261 emulated home link via one of the MAGs in the PMIPv6 network. 263 The MAG the MN connects to, is supposed to send a PBU to the LMA. 264 Since the MN maintains a relationship with the HA, the LMA should 265 provide the same prefix as before i.e., the HNP. This means that 266 when the MN receives the RA from the MAG, which includes the a prefix 267 matching its HNP, it will detect that this emulated link is its home 268 link. 270 Note that the PBU sent by the MAG MUST NOT overwrite the MIPv6 BCE 271 pointing to the foreign link for this MN. This is because the MAG 272 can not possibly know whether the MN still maintains the foreign link 273 or not. Indeed, if the MN wants to receive its traffic over the home 274 link it will sent a deregistration MIPv6 BU to the HA and remove the 275 MIPv6 BCE. When that happens packets will again reach the LMA and be 276 redirected according to the PMIPv6 BCE to the appropriate MAG. 278 6. Security Considerations 280 This document does not introduce security issues 282 7. IANA Considerations 284 This document requires no action from IANA. 286 8. Informative References 288 [I-D.giaretta-netlmm-mip-interactions] 289 Giaretta, G., "Interactions between PMIPv6 and MIPv6: 290 scenarios and related issues", 291 draft-giaretta-netlmm-mip-interactions-02 (work in 292 progress), November 2007. 294 [I-D.ietf-mip6-bootstrapping-integrated-dhc] 295 Chowdhury, K. and A. Yegin, "MIP6-bootstrapping for the 296 Integrated Scenario", 297 draft-ietf-mip6-bootstrapping-integrated-dhc-05 (work in 298 progress), July 2007. 300 [I-D.ietf-monami6-multiplecoa] 301 Ernst, T., Nagami, K., and V. Devarapalli, "Multiple 302 Care-of Addresses Registration", 303 draft-ietf-monami6-multiplecoa-06 (work in progress), 304 February 2008. 306 [I-D.ietf-netlmm-proxymip6] 307 Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 308 and B. Patil, "Proxy Mobile IPv6", 309 draft-ietf-netlmm-proxymip6-11 (work in progress), 310 February 2008. 312 [I-D.soliman-monami6-flow-binding] 313 Soliman, H., Montavont, N., Fikouras, N., and K. 314 Kuladinithi, "Flow Bindings in Mobile IPv6 and Nemo Basic 315 Support", draft-soliman-monami6-flow-binding-05 (work in 316 progress), November 2007. 318 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 319 Requirement Levels", BCP 14, RFC 2119, March 1997. 321 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 322 in IPv6", RFC 3775, June 2004. 324 [RFC5026] Giaretta, G., Kempf, J., and V. Devarapalli, "Mobile IPv6 325 Bootstrapping in Split Scenario", RFC 5026, October 2007. 327 Authors' Addresses 329 George Tsirtsis 330 Qualcomm 332 Email: tsirtsis@googlemail.com 334 Suresh Krishnan 335 Ericsson 337 Email: suresh.krishnan@ericsson.com 339 Full Copyright Statement 341 Copyright (C) The IETF Trust (2008). 343 This document is subject to the rights, licenses and restrictions 344 contained in BCP 78, and except as set forth therein, the authors 345 retain all their rights. 347 This document and the information contained herein are provided on an 348 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 349 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 350 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 351 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 352 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 353 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 355 Intellectual Property 357 The IETF takes no position regarding the validity or scope of any 358 Intellectual Property Rights or other rights that might be claimed to 359 pertain to the implementation or use of the technology described in 360 this document or the extent to which any license under such rights 361 might or might not be available; nor does it represent that it has 362 made any independent effort to identify any such rights. Information 363 on the procedures with respect to rights in RFC documents can be 364 found in BCP 78 and BCP 79. 366 Copies of IPR disclosures made to the IETF Secretariat and any 367 assurances of licenses to be made available, or the result of an 368 attempt made to obtain a general license or permission for the use of 369 such proprietary rights by implementers or users of this 370 specification can be obtained from the IETF on-line IPR repository at 371 http://www.ietf.org/ipr. 373 The IETF invites any interested party to bring to its attention any 374 copyrights, patents or patent applications, or other proprietary 375 rights that may cover technology that may be required to implement 376 this standard. Please address the information to the IETF at 377 ietf-ipr@ietf.org.