idnits 2.17.1 draft-bagnulo-shim6-mip-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 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 265. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 242. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 249. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 255. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. 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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 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 (July 11, 2005) is 6864 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) -- Possible downref: Normative reference to a draft: ref. '1' Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Bagnulo 3 Internet-Draft UC3M 4 Expires: January 12, 2006 E. Nordmark 5 Sun Microsystems 6 July 11, 2005 8 SHIM - MIPv6 Interaction 9 draft-bagnulo-shim6-mip-00 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 January 12, 2006. 36 Copyright Notice 38 Copyright (C) The Internet Society (2005). 40 Abstract 42 In this note, we explore the interaction between the SHIM protocol 43 and MIPv6 protocol, identifying potential benefits and difficulties. 44 The analysis will consider the two modes of operation of MIPv6: the 45 Bidirectional Tunnel (BT) mode where the communication is routed 46 through the Home Agent and the Route Optimization (RO) mode, where 47 the communication flows directly between the Correspondent node and 48 the mobile node. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Bidirectional Tunnel (BT) Mode . . . . . . . . . . . . . . . . 4 54 2.1 Communication between the MN and the CN . . . . . . . . . 4 55 3. RO mode . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 56 4. Security considerations . . . . . . . . . . . . . . . . . . . 7 57 5. Normative References . . . . . . . . . . . . . . . . . . . . . 7 58 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 7 59 Intellectual Property and Copyright Statements . . . . . . . . 8 61 1. Introduction 63 SHIM [1] is a host-based mechanism to provide site-multihoming 64 support. In this note, we explore the interaction between the SHIM 65 protocol and MIPv6 protocol, identifying potential benefits and 66 difficulties. 68 The analysis contained in this document considers the most general 69 case of shim and MIPv6 interaction, where the mobile node has both 70 multiple Care-of-Addresses as well as multiple Home Addresses. The 71 MN can have multiple addresses for any number of reasons. For 72 example, the MN can have multiple CoAs due to the MN having multiple 73 interfaces (connecting to different providers), or the MN visiting a 74 link which has multiple address prefixes due to the visited site 75 being multihomed. Also, the MN can have multiple HoAs for different 76 reasons, including having a home link which has multiple address 77 prefixes due to being in a multihomed site, to having multiple, 78 independent Home Agents that each provide it with a Home Address. 80 Without loss of generality the analysis uses a single IP address for 81 the correspondent node. 83 The analysis will consider the two modes of operation of MIPv6: the 84 Bidirectional Tunnel (BT) mode where the communication is routed 85 through the Home Agent and the Route Optimization (RO) mode, where 86 the communication flows directly between the Correspondent Node and 87 the Mobile Node. 89 2. Bidirectional Tunnel (BT) Mode 91 2.1 Communication between the MN and the CN 93 In this case, we have a MN with multiple CoAs (CoA1,..., CoAj) and 94 multiple HoAs (HoA1,..., HoAm) communicating with a Cn with address 95 IPCN. 97 We assume that the SHIM is layered above MIPv6. 99 In this scenario, suppose that an application located above the SHIM 100 layer, establishes a communication using one of the available HoAs, 101 e.g. HoAl and the address of the CN, IPCN, as ULIDs. Because the 102 SHIM is located above MIPv6, packets will be tunneled through the HA, 103 i.e. packets will be encapsulated with an additional header that will 104 contain IPHA and CoAj as addresses. 106 At some point during the lifetime of the communication, a SHIM 107 context is established. Such context will contain: 109 o HoAl and IPCN as ULIDs 111 o HoA1,..., HoAm, as locator set for the MN. (Optionally, the MN 112 could choose not to provide the CoAs to the CN in the shim6 113 signaling.) 115 o IPCN as locator set for the CN 117 We will next consider the response in case of an outage: 119 Suppose that an outage occurs and the communication path becomes 120 unavailable. If there is an outage affecting the path between the CN 121 and the MN, then the SHIM layer will detect it, and will retry with 122 an alternative locator. 124 When an alternative HoA is used as alternative locator, packets will 125 be tunneled through the HA associated with the new HoA, and will be 126 received through the CoA associated with the new HoA. In case that 127 there is at least one HA and one CoA that are not affected by the 128 outage, the communication will be preserved. In this case, the 129 communication will still flow in BT mode, but it will be routed 130 through an alternative tunnel associated with the new HoA. 132 If an alternative CoA is used as alternative locator, then the 133 communication will run directly between the MN and the CN in a kind 134 of SHIM based RO mode, recovering from the outage. However, in this 135 case, care must be taken because the alternative CoA may become 136 unavailable after movement. 138 3. RO mode 140 We assume that the SHIM is layered above MIPv6. 142 In this case, we have a MN with multiple CoAs (CoA1,..., CoAj) and 143 multiple HoAs (HoA1,..., HoAm) communicating with a CN with address 144 IPCN. 146 Suppose that a communication is established between the MN and the CN 147 using HoAl and IPCN. In addition, through MIPv6 protocol, a Binding 148 Cache Entry (BCE) is created in the CN associating the HoAl with one 149 of the CoAs, CoAp. So, packets associated with the communication are 150 flowing directly between the CN and the MN carrying CoAp and IPCN in 151 the source and destination address fields. 153 Later on, at some point in time, a SHIM context is established 154 between the MN and the CN. In this case the SHIM context established 155 contain the following information: 157 o ULIDs: HoAl and IPCN 159 o Locator set for MN: HoA1,...,HoAm, CoA1,..., CoAj. (Optionally, 160 the MN could choose not to provide the CoAs to the CN in the shim6 161 signaling.) 163 o IPCN as locator set for the CN 165 We will next analyze how this configuration reacts to different 166 failure modes: 168 o The path between IPCN and CoAp fails. The SHIM will detect the 169 outage and will try with alternative locators available for the 170 ULIDs of the session. If an alternative HoA is used by the SHIM 171 as alternative locator, when the SHIM passes the packet with an 172 alternative HoA to the MIP layer, the MIP layer will route through 173 the corresponding CoA available in the BCE associated with the new 174 HoA, possibly falling back to BT mode but potentially recovering 175 the failure. If an alternative CoA is used by the SHIM as 176 alternative locator, the MIP layer wonOt affect the packet 177 carrying the alternative CoA, and packets will be routed directly 178 between the MN and the CN, in a kind of SHIM-based RO mode. 180 o The path between the MN and the CN through the HA fails. While 181 data traffic is not routed through the HA, HoTI/HoT packets are 182 exchanged through the HA. If the path between the MN and the CN 183 through the Ha fails, then HoTI/HoT exchange will fail. A few 184 minutes later, the corresponding BCE will expire, and the 185 communication will fallback to the BT mode through the HA. 187 However, because we are considering the case where the path 188 through the HA is down, the communication will fail. At this 189 point, the SHIM will detect the outage and use an alternative 190 locator pair. Analogously to the previous case, the SHIM can try 191 with an alternative CoA or an alternative HoA as alternative 192 locators for the communication. In any case, similar 193 considerations to the ones described above apply and the 194 communications will be restored, whether in BT mode (alternative 195 HoA) or in a SHIM-based RO mode (alternative CoA used). 197 In any case, the presented setup seems to allow the preservation of 198 the established communication through different failure modes. It 199 should be noted, that if CoAs are included as alternative locators 200 for the SHIM, those will be short lived locators, and they may become 201 unavailable sooner than the HoAs. 203 4. Security considerations 205 TBD 207 5. Normative References 209 [1] Nordmark, E. and M. Bagnulo, "Multihoming L3 Shim Approach", 210 draft-ietf-shim6-l3shim-00 (work in progress), October 2004. 212 Authors' Addresses 214 Marcelo Bagnulo 215 Universidad Carlos III de Madrid 216 Av. Universidad 30 217 Leganes, Madrid 28911 218 SPAIN 220 Phone: 34 91 6249500 221 Email: marcelo@it.uc3m.es 222 URI: http://www.it.uc3m.es 224 Erik Normark 225 Sun Microsystems, Inc. 226 17 Network Circle 227 Mountain View, CA 228 USA 230 Phone: +1 650 786 2921 231 Email: erik.nordmark@sun.com 233 Intellectual Property Statement 235 The IETF takes no position regarding the validity or scope of any 236 Intellectual Property Rights or other rights that might be claimed to 237 pertain to the implementation or use of the technology described in 238 this document or the extent to which any license under such rights 239 might or might not be available; nor does it represent that it has 240 made any independent effort to identify any such rights. Information 241 on the procedures with respect to rights in RFC documents can be 242 found in BCP 78 and BCP 79. 244 Copies of IPR disclosures made to the IETF Secretariat and any 245 assurances of licenses to be made available, or the result of an 246 attempt made to obtain a general license or permission for the use of 247 such proprietary rights by implementers or users of this 248 specification can be obtained from the IETF on-line IPR repository at 249 http://www.ietf.org/ipr. 251 The IETF invites any interested party to bring to its attention any 252 copyrights, patents or patent applications, or other proprietary 253 rights that may cover technology that may be required to implement 254 this standard. Please address the information to the IETF at 255 ietf-ipr@ietf.org. 257 Disclaimer of Validity 259 This document and the information contained herein are provided on an 260 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 261 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 262 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 263 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 264 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 265 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 267 Copyright Statement 269 Copyright (C) The Internet Society (2005). This document is subject 270 to the rights, licenses and restrictions contained in BCP 78, and 271 except as set forth therein, the authors retain all their rights. 273 Acknowledgment 275 Funding for the RFC Editor function is currently provided by the 276 Internet Society.