idnits 2.17.1 draft-hui-ip-multiple-connections-ps-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.2b on line 19. -- Found old boilerplate from RFC 3978, Section 5.3 on line 33. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 391. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 368. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 375. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 381. -- The document has an RFC 3978 Section 5.2(b) Derivative Works Limitation clause. If this document is intended for submission to the IESG for publication, this constitutes an error. -- The document has an RFC 3978 Section 5.3 Publication Limitation clause. If this document is intended for submission to the IESG for publication, this constitutes an error. 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 : ---------------------------------------------------------------------------- ** There are 5 instances of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == In addition to RFC 3978, Section 5.2b boilerplate, a section with a similar start was also found: This document may not be modified, and derivative works of it may not be created, except to publish it as an RFC and to translate it into languages other than English, other than to extract section XX as-is for separate use. The document has an RFC 3978 Section 5.2(a) Derivative Works Limitation clause. == 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 (November 3, 2008) is 5650 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC1122' is defined on line 309, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 312, but no explicit reference was found in the text == Unused Reference: 'RFC3582' is defined on line 315, but no explicit reference was found in the text == Unused Reference: 'RFC3775' is defined on line 318, but no explicit reference was found in the text == Unused Reference: 'RFC4177' is defined on line 321, but no explicit reference was found in the text == Unused Reference: 'RFC4191' is defined on line 324, but no explicit reference was found in the text == Unused Reference: 'RFC5213' is defined on line 327, but no explicit reference was found in the text == Unused Reference: 'MONAMI6' is defined on line 332, but no explicit reference was found in the text == Unused Reference: 'NETLMM' is defined on line 337, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) Summary: 3 errors (**), 0 flaws (~~), 11 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Area M.Hui 2 Internet Draft H.Deng 3 Intended status: Informational China Mobile 4 Expires: May 3, 2009 November 3, 2008 6 Problem Statement and Requirement of Simple IP Multi-homing of the 7 Host 8 draft-hui-ip-multiple-connections-ps-01 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that 13 any applicable patent or other IPR claims of which he or she is 14 aware have been or will be disclosed, and any of which he or she 15 becomes aware will be disclosed, in accordance with Section 6 of 16 BCP 79. 18 This document may not be modified, and derivative works of it may not 19 be created. 21 This document may not be modified, and derivative works of it may not 22 be created, other than to extract section XX as-is for separate use. 24 This document may not be modified, and derivative works of it may not 25 be created, except to publish it as an RFC and to translate it into 26 languages other than English. 28 This document may not be modified, and derivative works of it may not 29 be created, except to publish it as an RFC and to translate it into 30 languages other than English, other than to extract section XX as-is 31 for separate use. 33 This document may only be posted in an Internet-Draft. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF), its areas, and its working groups. Note that 37 other groups may also distribute working documents as Internet-Drafts. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 The list of current Internet-Drafts can be accessed at 45 http://www.ietf.org/ietf/1id-abstracts.txt 46 The list of Internet-Draft Shadow Directories can be accessed at 47 http://www.ietf.org/shadow.html 49 This Internet-Draft will expire on April 3, 2009. 51 Copyright Notice 53 Copyright (C) The IETF Trust (2008). 55 Abstract 57 This document discusses current issues with simple IP multi-homing. 58 In order to have deep understanding of the issue, the document also 59 analyzes related works in IETF. In the end gives the requirements of 60 the simple IP multi-homing in concern of technical implements. Simple 61 IP multi-homing focuses on simultaneous multiple IP connections of 62 the host. 64 Table of Contents 66 1. Introduction................................................3 67 2. Problem statements of Simple IP Multi-homing.................4 68 2.1. Default Gateway.........................................4 69 2.2. Metric Rules...........................................4 70 2.3. Weak and Strong Host Model..............................5 71 3. Analysis of Related Work in IETF.............................6 72 3.1. Multi6.................................................6 73 3.2. Shim6..................................................6 74 3.3. Monami6................................................7 75 3.4. Netlmm.................................................7 76 4. Requirements for Simple IP Multi-homing......................9 77 5. Security Considerations.....................................10 78 6. IANA Considerations........................................11 79 7. References.................................................12 80 7.1. Normative References...................................12 81 7.2. Informative References.................................12 82 Author's Addresses............................................13 83 Intellectual Property Statement................................14 84 Disclaimer of Validity........................................14 86 1. Introduction 88 Simple IP Multi-homing means the host connects to more than one 89 physical network through different network interfaces, and assigns 90 different network flows to each interface, and ensure all the 91 interfaces can deliver the flow simultaneously. 93 Simple IP Multi-homing is a necessary part of daily life, i.e., you 94 have to connect to your company office network through VPN connection 95 by your Ethernet interface, at the same time you want to watch the 96 stock market, which is not allowed through office network. And you 97 have a GPRS card, so you would like to use ethernet and GPRS at the 98 same time. 100 Current the operating systems only allow one default network 101 connection. If there are multiple connections of the host, all the 102 flows will go to the default gateway based on RFC1122 description. 103 One default gateway guarantees the host always has one entry to the 104 network, but lead to the multiple connections be difficult. The most 105 convenient way to make the host work under several networks at the 106 same time is to add specific static route in the host route table, so 107 that certain flow can use the assigned interface while others use the 108 default one, but it is not easy for the ordinary users to handle it. 110 2. Problem statements of Simple IP Multi-homing 112 As description above, simple IP multi-homing can not work based on 113 the current specification. There are several reasons cause it invalid, 114 and this section analyzes them in detail. 116 2.1. Default Gateway 118 The Windows operating system in the host follows the default gateway 119 mechanism, which will choose the unify gateway among more than one 120 default routes ('0.0.0.0'), the detail is described in RFC1122. The 121 default gateway guarantees there always has a route to network when 122 the host can not find a specific route for a datagram in the route 123 table. 125 But when it comes to multi-homing, the default gateway also causes 126 all the flows go out through one interface, although there has more 127 than one network connections. Nowadays there are diverse networks 128 can be chosen by the user, and the terminal have the capability and 129 interfaces to connect to more than one networks at the same time. It 130 is possible and necessary for the user to require connecting to 131 different networks to ensure the best user experiences of different 132 services, but the default gateway mechanism only allows one 133 connection at once. Although you can connect your host to several 134 networks physically, and each network has already assigned a IP 135 address for your host interface, even you can see different default 136 routes in the route table, all the flow goes to the default gateway 137 chosen by the operation system other than different gateways actually. 139 2.2. Metric Rules 141 The default gateway is chosen based on the metric rule as RFC1122 142 description. The one have the lowest metric value becomes to the 143 default gateway among several connected gateways, and the interface 144 correspond to this gateway turns to be the default interface. 146 Current metric rules define the 100M bps Ethernet network card to be 147 20 and 10M bps to be 30. But it is not a strict definition, and the 148 user can change the metric value manually. The problem is not every 149 network card follow the metric rules, which represents the lower 150 metric value is, the faster route is, so that the operating system 151 can always choose the best performance route as the default one for 152 the IP flow. For example, CDMA data card set its metric value as 1, 153 although its speed is lower than 100M bps Ethernet network card. In 154 this situation, the operating system will choose the CDMA connection 155 as the default one, so the user is forced to use the slower 156 connection, which violates the aim of the metric rule. 158 2.3. Weak and Strong Host Model 160 There exists two different host model today, which are weak host 161 model and strong host model, described in RFC 1122. The weak host 162 model treats the destination and the source as a host rather than an 163 interface, so the default gateway mechanism chooses only one 164 connection as the default one. Reversely, the strong host model 165 divides the host to several separated hosts logically, what means the 166 flow can only use the specific interface. 168 The problem is current host operating system such as Windows 2000/XP 169 all apply weak host model on its network interface, so the host can 170 not differ the flow to different interfaces, only the default gateway 171 is applied. 173 3. Analysis of Related Work in IETF 175 Multi-homing is a wide topic contains different aspects, and there 176 are some work groups in IETF worked on a certain aspect of multi- 177 homing. 179 This section explains their work, and compares the covered field with 180 the simple IP multi-homing. In the end we will find the simple IP 181 multi-homing is still a problem which is not solved yet. 183 3.1. Multi6 185 Multi6 WG in IETF focuses on the multi-homed site, which has more 186 than one connection to the public internet with those connections 187 through either the same or different ISPs. The reasons to choose 188 site multi-homing are to improve fault tolerance, perform load 189 balancing, etc. 191 The Multi6 WG mainly focuses on site multi-homing solutions that tend 192 to minimize adverse impacts on the end-to-end routing system and 193 limit the number of prefixes that need to be advertised in the 194 Default-Free Zone (DFZ). The background is site multi-homing today 195 is done largely by having a site obtain a dedicated block of address 196 space and then advertising a route for its prefix through each of its 197 ISP connections. A site's ISPs in turn advertise the prefix to some 198 or all of their upstream connections and the route for the prefix may 199 propagate to all of the routers connected to the default-free zone. 200 As the number of sites multi-homing in this manner increase, the 201 number of routes propagated throughout the DFZ increases and overall 202 routing stability decreases because of the burden on convergence time. 204 Multi6 WG tries to solve this by defining a set of goals for IPv6 205 site multi-homing architecture, and analyzing the current limitations 206 and the approaches to the site multi-homing. What's need to notice 207 is that the working group is not chartered to make significant 208 changes to the nature of IP addresses or to inter-domain routing. 209 Obviously, the site multi-homing does not consider the host multiple 210 connection which is the key problem of this document. 212 3.2. Shim6 214 Shim6 is another WG in IETF aims at site multi-homing. Shim6 work is 215 based on the architecture developed by the Multi6 WG, and completes 216 the required protocol developments and the architecture and security 217 analysis of the required protocols. Different form Multi6, Shim6 218 focuses on surviving hosts on the multi-homing site from the changes 219 or for creating new associations, when one or more of the site's 220 address prefixes becomes unreachable. 222 Shim6 WG produces specifications for an IPv6-based site multi-homing 223 solution that inserts a new sub-layer (shim) into the IP stack of 224 end-system hosts. It enables hosts on multi-homed sites to use a set 225 of provider-assigned IP address prefixes and switch between them 226 without upsetting transport protocols or applications. But it can 227 not support connecting to all the ISPs simultaneously. 229 3.3. Monami6 231 The objective of the Monami6 WG is to produce a clear problem 232 statement and to produce standard track specifications to the 233 straight-forward problems associated with the simultaneous use of 234 multiple addresses for either mobile hosts using Mobile IPv6 or 235 mobile routers using NEMO Basic Support and their variants (FMIPv6, 236 HMIPv6,etc). 238 The WG does not define a tunnel selection mechanism, but document how 239 to use existing mechanisms based upon preferences or policies. They 240 explain the limitations for mobile hosts using multiple simultaneous 241 Care-of Addresses and Home Agent addresses using Mobile IPv6, whether 242 issues are specific to Mobile IPv6 or not. They also deliver a 243 protocol extension to Mobile IPv6 (RFC 3775) and NEMO Basic Support 244 (RFC 3963) to support the registration of multiple Care-of Addresses 245 at a given Home Agent address [Standard Track]. What's more, Monami6 246 WG makes a "Flow/binding policies exchange" solution for an exchange 247 of policies from the mobile host/router to the Home Agent and from 248 the Home Agent to the mobile host/router influencing the choice of 249 the Care-of Address and Home Agent address. 251 Monami6 focus the same field with simple IP multi-homing, which is 252 ensuring simultaneous use of multiple addresses for the host. The 253 difference is Monami6 puts this aim to under a certain condition, the 254 mobile host using MIP6, while the simple IP multi-homing focuses on 255 ordinary host using IPv4/6. 257 3.4. Netlmm 259 Netlmm WG studies Proxy Mobile IPv6 (PMIPv6) which supports multiple 260 interfaces binding, by maintaining multiple binding cache entries for 261 a given MN. The scenario concerned by PMIPv6 is each interfaces gets 262 different prefix form others, however, there are many other scenarios 263 associated with multiple interface attachment are not covered. The 264 specific scenario needs specific solutions which require some 265 enhancement/modification to the current PMIPv6 protocol, and the 266 simple IP multi-homing hasn't supported in the PMIPv6 environment as 267 well. 269 What's more, the multi-homing in PMIPv6 lacks flow filtering support. 270 The LMA must has filter rules to allocate certain flow to traverse 271 via a certain care-of address, but the mechanism in PMIPv6 is 272 currently not supported. 274 4. Requirements for Simple IP Multi-homing 276 Based on problem statements and related work analysis, the 277 requirements for simple IP multi-homing is concluded and listed as 278 follows: 280 1) The host with multiple network interfaces should be capable to 281 connect with different networks simultaneously. 283 2) The default gateway mechanism needs to be improved to support 284 several gateways working at the same time. 286 3) New metric mechanism must be defined to adapt to various network 287 cards nowadays. 289 4) The policies to assign different flows to the appropriate 290 interface are required, and how to apply the policies to the host 291 need to be considered as well. 293 5 Network side should be capable of distributing the IP flow 294 according to some parameters, such as IP address prefix, network type 295 and so on. 297 5. Security Considerations 299 This document doesn't propose any new protocol. 301 6. IANA Considerations 303 This document doesn't require any new number from IANA. 305 7. References 307 7.1. Normative References 309 [RFC1122] Braden, R., "Requirements for Internet Hosts-communication 310 Layers", STD 3, RFC 1122, October 1989. 312 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 313 Requirement Levels", BCP 14, RFC 2119, March 1997. 315 [RFC3582] Abley, J., Black, B., and V. Gill, "Goals for IPv6 Site- 316 Multihoming Architectures", RFC 3582, August 2003. 318 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 319 in IPv6", RFC 3775, June 2004. 321 [RFC4177] Huston, G., "Architectural Approaches to Multi-homing for 322 IPv6", RFC 4177, September 2005. 324 [RFC4191] R. Draves, D. Thaler, "Default Router Preferences and 325 More-Specific Routes", RFC 4191, November 2005. 327 [RFC5213] S. Gundavelli, Ed., K. Leung, ''Proxy Mobile IPv6'', RFC5213, 328 August 2008 330 7.2. Informative References 332 [MONAMI6] Ernst, T., "Motivations and Scenarios for Using Multiple 333 Interfaces and global Addresses", May 2008, . 337 [NETLMM] M. Jeyatharan, C. Ng, J. Hirano, "Multiple Interfaced 338 Mobile Nodes in NetlMM", June 2008, . 341 Author's Addresses 343 Min Hui 344 China Mobile 345 53A,Xibianmennei Ave., 346 Xuanwu District, 347 Beijing 100053 348 China 349 Email: huimin.cmcc@gmail.com 351 Hui Deng 352 China Mobile 353 53A,Xibianmennei Ave., 354 Xuanwu District, 355 Beijing 100053 356 China 357 Email: denghui02@gmail.com 359 Intellectual Property Statement 361 The IETF takes no position regarding the validity or scope of any 362 Intellectual Property Rights or other rights that might be claimed to 363 pertain to the implementation or use of the technology described in 364 this document or the extent to which any license under such rights 365 might or might not be available; nor does it represent that it has 366 made any independent effort to identify any such rights. Information 367 on the procedures with respect to rights in RFC documents can be 368 found in BCP 78 and BCP 79. 370 Copies of IPR disclosures made to the IETF Secretariat and any 371 assurances of licenses to be made available, or the result of an 372 attempt made to obtain a general license or permission for the use of 373 such proprietary rights by implementers or users of this 374 specification can be obtained from the IETF on-line IPR repository at 375 http://www.ietf.org/ipr. 377 The IETF invites any interested party to bring to its attention any 378 copyrights, patents or patent applications, or other proprietary 379 rights that may cover technology that may be required to implement 380 this standard. Please address the information to the IETF at 381 ietf-ipr@ietf.org. 383 Disclaimer of Validity 385 This document and the information contained herein are provided on an 386 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 387 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 388 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 389 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 390 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 391 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 393 Copyright Statement 395 Copyright (C) The IETF Trust (2008). 397 This document is subject to the rights, licenses and restrictions 398 contained in BCP 78, and except as set forth therein, the authors 399 retain all their rights.