idnits 2.17.1 draft-hui-ip-multiple-connections-ps-02.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 : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' 1. Introduction' ) ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 5. Security Considerations' ) ** 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.) (A line matching the expected section header was found, but with an unexpected indentation: ' 6. IANA Considerations' ) ** There are 6 instances of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors 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 (March 9, 2009) is 5527 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Missing reference section? 'RFC1122' on line 325 looks like a reference -- Missing reference section? 'RFC2119' on line 328 looks like a reference -- Missing reference section? 'RFC3582' on line 331 looks like a reference -- Missing reference section? 'RFC3775' on line 334 looks like a reference -- Missing reference section? 'RFC4177' on line 337 looks like a reference -- Missing reference section? 'RFC4191' on line 340 looks like a reference -- Missing reference section? 'RFC5213' on line 343 looks like a reference -- Missing reference section? 'MONAMI6' on line 348 looks like a reference -- Missing reference section? 'NETLMM' on line 353 looks like a reference Summary: 4 errors (**), 0 flaws (~~), 1 warning (==), 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: September 9, 2009 March 9, 2009 6 Problem Statement and Requirement of Simple IP Multi-homing of the 7 Host 8 draft-hui-ip-multiple-connections-ps-02 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html 30 This Internet-Draft will expire on August 27, 2009. 32 Copyright Notice 34 Copyright (c) 2009 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents 39 (http://trustee.ietf.org/license-info) in effect on the date of 40 publication of this document. Please review these documents 41 carefully, as they describe your rights and restrictions with respect 42 to this document. 44 Abstract 46 This document discusses current issues with simple IP multi-homing. 47 In order to have deep understanding of the issue, the document also 48 analyzes related works in IETF. In the end gives the requirements of 49 the simple IP multi-homing in concern of technical implements. Simple 50 IP multi-homing focuses on simultaneous multiple IP connections of 51 the host. 53 Table of Contents 55 1. Introduction................................................3 56 2. Problem statements of Simple IP Multi-homing.................4 57 2.1. Default Gateway.........................................4 58 2.2. Merging of parameters...................................4 59 2.3. Source address selection for IPv4.......................5 60 3. Analysis of Related Work in IETF.............................6 61 3.1. Multi6.................................................6 62 3.2. Shim6..................................................6 63 3.3. Monami6................................................7 64 3.4. Netlmm.................................................7 65 4. Requirements for Simple IP Multi-homing......................9 66 5. Security Considerations.....................................10 67 6. IANA Considerations........................................11 68 7. References.................................................12 69 7.1. Normative References...................................12 70 7.2. Informative References.................................12 71 Author's Addresses............................................13 72 Intellectual Property Statement.................... 73 Disclaimer of Validity............................ 75 1. Introduction 77 Simple IP Multi-homing means the host connects to more than one 78 physical network through different network interfaces, and assigns 79 different network flows to each interface, and ensure all the 80 interfaces can deliver the flow simultaneously. 82 Simple IP Multi-homing is a necessary part of daily life, i.e., you 83 have to connect to your company office network through VPN connection 84 by your Ethernet interface, at the same time you want to watch the 85 stock market, which is not allowed through office network. And you 86 have a GPRS card, so you would like to use ethernet and GPRS at the 87 same time. 89 Current the operating systems only allow one default network 90 connection. If there are multiple connections of the host, all the 91 flows will go to the default gateway based on RFC1122 description. 92 One default gateway guarantees the host always has one entry to the 93 network, but lead to the multiple connections be difficult. The most 94 convenient way to make the host work under several networks at the 95 same time is to add specific static route in the host route table, so 96 that certain flow can use the assigned interface while others use the 97 default one, but it is not easy for the ordinary users to handle it. 99 2. Problem statements of Simple IP Multi-homing 101 As description above, simple IP multi-homing can not work based on 102 the current specification. There are several reasons cause it invalid, 103 and this section analyzes them in detail. 105 2.1. Default Gateway 107 The Windows operating system in the host follows the default gateway 108 mechanism, which will choose the unify gateway among more than one 109 default routes ('0.0.0.0'), the detail is described in RFC1122. The 110 default gateway guarantees there always has a route to network when 111 the host can not find a specific route for a datagram in the route 112 table. 114 But when it comes to multi-homing, the default gateway also causes 115 all the flows go out through one interface, although there has more 116 than one network connections. Nowadays there are diverse networks 117 can be chosen by the user, and the terminal have the capability and 118 interfaces to connect to more than one networks at the same time. It 119 is possible and necessary for the user to require connecting to 120 different networks to ensure the best user experiences of different 121 services, but the default gateway mechanism only allows one 122 connection at once. Although you can connect your host to several 123 networks physically, and each network has already assigned a IP 124 address for your host interface, even you can see different default 125 routes in the route table, all the flow goes to the default gateway 126 chosen by the operation system other than different gateways actually. 128 2.2. Merging of parameters 130 In multiple interfaces host, each interface will get its own IP 131 parameters in the procedure of IP address allocation all other policy 132 deployment, such as DNS, metrics of routings, TOS. How to merge the 133 same type of parameters derived form multiple interfaces to act 134 harmoniously in the host is the problem presented in multiple 135 interfaces host. 137 2.2.1. DNS consideration 139 DNS will be configured to the interface manually or by DHCP procedure, 140 and multiple interfaces will obtain multiple DNS. The host will 141 reserve several DNS in this situation. Referring to different domain 142 names the host should query proper DNS so that the domain names can 143 be resolved. The problem is current DNS selection mechanism is lack 144 to choose a right one for specific visited domain name, so that we 145 need to merge multiple DNS to provide the host with the best 146 connectivity. 148 2.2.2. Metrics consideration 150 Metrics are used to measure the performance of routings, the lower 151 metric it owns, the higher priority it has. For example, the default 152 gateway is chosen based on the metric rule as RFC1122 description, 153 The one have the lowest metric value becomes to the default gateway 154 among several connected gateways, and the interface correspond to 155 this gateway turns to be the default interface. 157 Metric rules are different depending on the access technology and 158 routing protocol, if the multiple interfaces connect to multiple 159 access networks which have different measurements of metrics, the 160 metric will not reflect the routing performances correctly. For 161 example, current metric rules define the 100M bps Ethernet network 162 card to be 20 and 10M bps to be 30, but the CDMA data card set its 163 metric value as 1, although its speed is lower than 100M bps Ethernet 164 network card. The merging of metrics is necessary in multiple 165 interfaces condition. 167 2.2.3. TOS consideration 169 TOS can be a parameter of routing item to indicate which kind of IP 170 data is suitable to deliver by this routing. The multiple interfaces 171 will connect to multiple access networks, so that the preference of 172 TOS need to be merged to have a better performance of data delivery. 173 For example, the WiFi access could indicate itself has broader 174 bandwidth comparing with 2G access, and set the TOS as broad 175 bandwidth. When another interface connects the Ethernet, the TOS is 176 also set as broad bandwidth preferred. In this situation, it needs 177 some mechanism to merge and reorder the TOS getting form multiple 178 interfaces. 180 2.3. Source address selection for IPv4 182 For the host has more than one IP addresses which are obtained by 183 multiple interfaces, the source address selection is the key issue in 184 order to use multiple interfaces reasonably. The application needs to 185 select right source address so that the data will be delivered by the 186 corresponding interface. This mechanism is lack currently which needs 187 to be solved in multiple interfaces situation. 189 3. Analysis of Related Work in IETF 191 Multi-homing is a wide topic contains different aspects, and there 192 are some work groups in IETF worked on a certain aspect of multi- 193 homing. 195 This section explains their work, and compares the covered field with 196 the simple IP multi-homing. In the end we will find the simple IP 197 multi-homing is still a problem which is not solved yet. 199 3.1. Multi6 201 Multi6 WG in IETF focuses on the multi-homed site, which has more 202 than one connection to the public internet with those connections 203 through either the same or different ISPs. The reasons to choose 204 site multi-homing are to improve fault tolerance, perform load 205 balancing, etc. 207 The Multi6 WG mainly focuses on site multi-homing solutions that tend 208 to minimize adverse impacts on the end-to-end routing system and 209 limit the number of prefixes that need to be advertised in the 210 Default-Free Zone (DFZ). The background is site multi-homing today 211 is done largely by having a site obtain a dedicated block of address 212 space and then advertising a route for its prefix through each of its 213 ISP connections. A site's ISPs in turn advertise the prefix to some 214 or all of their upstream connections and the route for the prefix may 215 propagate to all of the routers connected to the default-free zone. 216 As the number of sites multi-homing in this manner increase, the 217 number of routes propagated throughout the DFZ increases and overall 218 routing stability decreases because of the burden on convergence time. 220 Multi6 WG tries to solve this by defining a set of goals for IPv6 221 site multi-homing architecture, and analyzing the current limitations 222 and the approaches to the site multi-homing. What's need to notice 223 is that the working group is not chartered to make significant 224 changes to the nature of IP addresses or to inter-domain routing. 225 Obviously, the site multi-homing does not consider the host multiple 226 connection which is the key problem of this document. 228 3.2. Shim6 230 Shim6 is another WG in IETF aims at site multi-homing. Shim6 work is 231 based on the architecture developed by the Multi6 WG, and completes 232 the required protocol developments and the architecture and security 233 analysis of the required protocols. Different form Multi6, Shim6 234 focuses on surviving hosts on the multi-homing site from the changes 235 or for creating new associations, when one or more of the site's 236 address prefixes becomes unreachable. 238 Shim6 WG produces specifications for an IPv6-based site multi-homing 239 solution that inserts a new sub-layer (shim) into the IP stack of 240 end-system hosts. It enables hosts on multi-homed sites to use a set 241 of provider-assigned IP address prefixes and switch between them 242 without upsetting transport protocols or applications. But it can 243 not support connecting to all the ISPs simultaneously. 245 3.3. Monami6 247 The objective of the Monami6 WG is to produce a clear problem 248 statement and to produce standard track specifications to the 249 straight-forward problems associated with the simultaneous use of 250 multiple addresses for either mobile hosts using Mobile IPv6 or 251 mobile routers using NEMO Basic Support and their variants (FMIPv6, 252 HMIPv6,etc). 254 The WG does not define a tunnel selection mechanism, but document how 255 to use existing mechanisms based upon preferences or policies. They 256 explain the limitations for mobile hosts using multiple simultaneous 257 Care-of Addresses and Home Agent addresses using Mobile IPv6, whether 258 issues are specific to Mobile IPv6 or not. They also deliver a 259 protocol extension to Mobile IPv6 (RFC 3775) and NEMO Basic Support 260 (RFC 3963) to support the registration of multiple Care-of Addresses 261 at a given Home Agent address [Standard Track]. What's more, Monami6 262 WG makes a "Flow/binding policies exchange" solution for an exchange 263 of policies from the mobile host/router to the Home Agent and from 264 the Home Agent to the mobile host/router influencing the choice of 265 the Care-of Address and Home Agent address. 267 Monami6 focus the same field with simple IP multi-homing, which is 268 ensuring simultaneous use of multiple addresses for the host. The 269 difference is Monami6 puts this aim to under a certain condition, the 270 mobile host using MIP6, while the simple IP multi-homing focuses on 271 ordinary host using IPv4/6. 273 3.4. Netlmm 275 Netlmm WG studies Proxy Mobile IPv6 (PMIPv6) which supports multiple 276 interfaces binding, by maintaining multiple binding cache entries for 277 a given MN. The scenario concerned by PMIPv6 is each interfaces gets 278 different prefix form others, however, there are many other scenarios 279 associated with multiple interface attachment are not covered. The 280 specific scenario needs specific solutions which require some 281 enhancement/modification to the current PMIPv6 protocol, and the 282 simple IP multi-homing hasn't supported in the PMIPv6 environment as 283 well. 285 What's more, the multi-homing in PMIPv6 lacks flow filtering support. 286 The LMA must has filter rules to allocate certain flow to traverse 287 via a certain care-of address, but the mechanism in PMIPv6 is 288 currently not supported. 290 4. Requirements for Simple IP Multi-homing 292 Based on problem statements and related work analysis, the 293 requirements for simple IP multi-homing is concluded and listed as 294 follows: 296 1) The host with multiple network interfaces should be capable to 297 connect with different networks simultaneously. 299 2) The default gateway mechanism needs to be improved to support 300 several gateways working at the same time. 302 3) New metric mechanism must be defined to adapt to various network 303 cards nowadays. 305 4) The policies to assign different flows to the appropriate 306 interface are required, and how to apply the policies to the host 307 need to be considered as well. 309 5 Network side should be capable of distributing the IP flow 310 according to some parameters, such as IP address prefix, network type 311 and so on. 313 5. Security Considerations 315 This document doesn't propose any new protocol. 317 6. IANA Considerations 319 This document doesn't require any new number from IANA. 321 7. References 323 7.1. Normative References 325 [RFC1122] Braden, R., "Requirements for Internet Hosts-communication 326 Layers", STD 3, RFC 1122, October 1989. 328 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 329 Requirement Levels", BCP 14, RFC 2119, March 1997. 331 [RFC3582] Abley, J., Black, B., and V. Gill, "Goals for IPv6 Site- 332 Multihoming Architectures", RFC 3582, August 2003. 334 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 335 in IPv6", RFC 3775, June 2004. 337 [RFC4177] Huston, G., "Architectural Approaches to Multi-homing for 338 IPv6", RFC 4177, September 2005. 340 [RFC4191] R. Draves, D. Thaler, "Default Router Preferences and 341 More-Specific Routes", RFC 4191, November 2005. 343 [RFC5213] S. Gundavelli, Ed., K. Leung, ''Proxy Mobile IPv6'', RFC5213, 344 August 2008 346 7.2. Informative References 348 [MONAMI6] Ernst, T., "Motivations and Scenarios for Using Multiple 349 Interfaces and global Addresses", May 2008, . 353 [NETLMM] M. Jeyatharan, C. Ng, J. Hirano, "Multiple Interfaced 354 Mobile Nodes in NetlMM", June 2008, . 357 Author's Addresses 359 Min Hui 360 China Mobile 361 53A,Xibianmennei Ave., 362 Xuanwu District, 363 Beijing 100053 364 China 365 Email: huimin.cmcc@gmail.com 367 Hui Deng 368 China Mobile 369 53A,Xibianmennei Ave., 370 Xuanwu District, 371 Beijing 100053 372 China 373 Email: denghui02@gmail.com