idnits 2.17.1 draft-mrw-mif-current-practices-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 date (March 9, 2009) is 5526 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-01) exists of draft-blanchet-mif-problem-statement-00 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force M. Wasserman, Ed. 3 Internet-Draft Sandstorm Enterprises 4 Intended status: Informational March 9, 2009 5 Expires: September 10, 2009 7 Current Practices for Multiple Interface Hosts 8 draft-mrw-mif-current-practices-01 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- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on September 10, 2009. 33 Copyright Notice 35 Copyright (c) 2009 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents in effect on the date of 40 publication of this document (http://trustee.ietf.org/license-info). 41 Please review these documents carefully, as they describe your rights 42 and restrictions with respect to this document. 44 Abstract 46 An increasing number of hosts are operating in multiple-interface 47 environments, where different network interfaces are providing 48 unequal levels of service or connectivity. This document describes 49 how some common operating systems cope with the related challenges. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Current practices of some operating systems . . . . . . . . . 3 55 2.1. Nokia S60 3rd Edition, Feature Pack 2 . . . . . . . . . . 3 56 2.2. Microsoft Windows Mobile 2003 Second Edition . . . . . . . 5 57 2.3. BlackBerry . . . . . . . . . . . . . . . . . . . . . . . . 6 58 2.4. Google Android . . . . . . . . . . . . . . . . . . . . . . 6 59 2.5. Arena Connection Manager . . . . . . . . . . . . . . . . . 7 60 2.6. Microsoft Windows . . . . . . . . . . . . . . . . . . . . 7 61 2.7. Linux and BSD-based Operating Systems . . . . . . . . . . 7 62 2.8. Apple Mac OS X . . . . . . . . . . . . . . . . . . . . . . 8 63 3. Common solutions . . . . . . . . . . . . . . . . . . . . . . . 9 64 3.1. Centralized connection management . . . . . . . . . . . . 9 65 3.2. Per application connection settings . . . . . . . . . . . 9 66 4. Common problems . . . . . . . . . . . . . . . . . . . . . . . 9 67 4.1. Selection of an interface providing access to a 68 destination . . . . . . . . . . . . . . . . . . . . . . . 10 69 4.2. Prioritization of interfaces for the same destination . . 10 70 4.3. Enablers for application multihoming . . . . . . . . . . . 10 71 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 72 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 73 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 74 8. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 11 75 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 11 76 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 77 10.1. Normative References . . . . . . . . . . . . . . . . . . . 12 78 10.2. Informative References . . . . . . . . . . . . . . . . . . 12 79 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13 81 1. Introduction 83 Multiple-interface hosts face several challenges not faced by single- 84 interface hosts, some of which are described in 85 [I-D.blanchet-mif-problem-statement]. 87 This document collects and analyzes publicly-available information 88 about the multiple-interface solutions implemented in some widely 89 used operating systems, including: Nokia S60 [S60], Microsoft Windows 90 Mobile [WINDOWSMOBILE], Blackberry [BLACKBERRY], Google Android 91 [ANDROID], Apple Mac OS X, Linux and BSD-based operating systems. 93 In section 3, common solutions implemented in different operating 94 systems are identified and generalized. 96 NOTE: Further input on the behaviour of these or other operating 97 systems (including newer versons) is very welcome. 99 2. Current practices of some operating systems 101 The following sections briefly describe the current multiple- 102 interface host implementations on some widely-used operating systems. 103 Please refer to the References section for pointers to original 104 documentation on most of these systems, including further details. 106 2.1. Nokia S60 3rd Edition, Feature Pack 2 108 Cellular devices typically run a variety of applications in parallel, 109 each with different requirements for IP connectivity. A typical 110 scenario is shown in figure 1, where a cellular device is utilizing 111 WLAN access for web browsing and GPRS access for transferring 112 multimedia messages (MMS). Another typical scenario would be a real- 113 time VoIP session over one network interface in parallel with best 114 effort web browsing on another network interface. Yet another 115 typical scenario would be global Internet access through one network 116 interface and local (e.g. corporate VPN) network access through 117 another. 119 Web server MMS Gateway 120 | | 121 -+--Internet---- ----Operator network--+- 122 | | 123 +-------+ +-------+ 124 |WLAN AP| | GGSN | 125 +-------+ +-------+ 126 | +--------+ | 127 +--------|Cellular|--------+ 128 |device | 129 +--------+ 131 A cellular device with two network interfaces 133 Figure 1 135 Different network access technologies require different settings. 136 For example, WLAN requires Service Set Identifier (SSID) and the GPRS 137 network requires the Access Point Name (APN) of the Gateway GPRS 138 Support Node (GGSN), among other parameters. It is common that 139 different accesses lead to different destination networks (e.g. to 140 "Internet", "Intranet", cellular network services, etc.). 142 S60 uses the concept of an Internet Access Point (IAP) [S60] that 143 contains all information required for opening a network connection 144 using a specific access technology. A device may have several IAPs 145 configured for different network technologies and settings (multiple 146 WLAN SSIDs, GPRS APNs, dial-up numbers, and so forth). There may 147 also be 'virtual' IAPs that define parameters needed for tunnel 148 establishment (e.g. for VPN). 150 For each application, a correct IAP needs to be selected at the point 151 when the application requires network connectivity. This is 152 essential, as the wrong IAP may not be able to support the 153 application or reach the desired destination. For example, MMS 154 application must use the correct IAP in order to reach the MMS 155 Gateway, which typically is not accessible from the public Internet. 156 As another example, an application might need to use the IAP 157 associated with its corporate VPN in order to reach internal 158 corporate servers. Binding applications to IAPs avoids several 159 problems, such as choosing the correct DNS server in the presence of 160 split DNS (as an application will use the DNS server list from its 161 bound IAP), and overlapping private IPv4 address spaces used for 162 different interfaces (as each application will use the default routes 163 from its bound IAP). 165 If multiple applications utilize the same IAP, the underlying network 166 connection can typically be shared. This is often the case when 167 multiple Internet-using applications are running in parallel. 169 The IAP for an application can be selected in multiple ways: 171 o Statically: e.g. from a configuration interface, via client 172 provisioning/device management system, or at build-time. 174 o Manually by the user: e.g. each time an application starts the 175 user may be asked to select the IAP to use. This may be needed, 176 for example, if a user sometimes wishes to access his corporate 177 intranet and other times would prefer to access the Internet 178 directly. 180 o Automatically by the system: after the destination network has 181 been selected statically or dynamically. 183 The static approach is fine for certain applications, like MMS, for 184 which configuration can be provisioned by the network operator and 185 does not change often. Manual selection works, but may be seen as 186 troublesome by the user. An automatic selection mechanism needs to 187 have some way of knowing which destination network the user, or an 188 application, is trying access. 190 S60 3rd Edition, Feature Pack 2, introduces a concept of Service 191 Network Access Points (SNAPs) that group together IAPs that lead to 192 the same destination. This enables static or manual selection of the 193 destination network for an application and leaves the problem of 194 selecting the best of the available IAPs within a SNAP to the 195 operating system. 197 When SNAPs are used, it it possibly for the operating system to 198 notify applications when a preferred IAP, leading to the same 199 destination, becomes available (for example, when a user comes within 200 range of his home WLAN access point), or when the currently used IAP 201 is no longer available and applications have to reconnect via another 202 IAP (for example, when a user goes out of range of his home WLAN and 203 must move to the cellular network). 205 Please see the source documentation for more details and screenshots: 206 [S60]. 208 2.2. Microsoft Windows Mobile 2003 Second Edition 210 A Connection Manager architecture is described in [WINDOWSMOBILE]. 211 This architecture centralizes and automates network connection 212 establishment and management, and makes it possible to automatically 213 select a connection, to dial-in automatically or by user initiation, 214 and to optimize connection and shared resource usage. Connection 215 Manager periodically re-evaluates the validity of the connection 216 selection. The Connection Manager uses various attributes such as 217 cost, security, bandwidth, error rate, and latency in its decision 218 making. 220 The Connection Manager selects the best possible connection for the 221 application based on the destination network the application wishes 222 to reach. The selection is made between available physical and 223 virtual connections (e.g. VPN, GPRS, WLAN, and wired Ethernet) that 224 are known to provide connectivity to the destination network, and the 225 selection is based on the costs associated with each connection. 226 Different applications are bundled to use the same network connection 227 when possible, but in conflict situations when a connection cannot be 228 shared, higher priority applications take precedence, and the lower 229 priority applications lose connectivity until the conflict situation 230 clears. 232 During operation, Connection Manager opens new connections as needed, 233 and also disconnects unused or idle connections. 235 To optimize resource use, such as battery power and bandwidth, 236 Connection Manager enables applications to synchronize network 237 connection usage by allowing applications to register their 238 requirements for periodic connectivity. An application is notified 239 when a suitable connection becomes available for its use. 241 2.3. BlackBerry 243 In BlackBerry devices [BLACKBERRY] Java applications can use one of 244 two wireless gateways to proxy the connection to the Internet or to a 245 corporate network. The application can be designed to always use the 246 default Internet gateway, or to use a more preferred enterprise 247 gateway when available. The intent is to hide connectivity issues 248 from users. 250 DISCUSS: How does the Blackberry decide when a WLAN interface, a 251 cellular interface or some other physical interface is used? 253 2.4. Google Android 255 The Android reference documentation describes the android.net package 256 [ANDROID] and the ConnectivityManager class that applications can use 257 to request a route to a specified destination address via a specified 258 network interface (Mobile or Wifi). Applications also ask Connection 259 Manager for permission to start using a network feature. The 260 Connectivity Manager monitors changes in network connectivity and 261 attempts to failover to another network if connectivity to an active 262 network is lost. When there are changes in network connectivity, 263 applications are notified. Applications are also able to ask for 264 information about all network interfaces, including their 265 availability, type and other information. 267 DISCUSS: Are applications bound to use one network type at a time, or 268 can one application use multiple network features in parallel? 270 2.5. Arena Connection Manager 272 The Arena Connection Manager is described in 273 [I-D.zhang-mif-connection-manager-arena] and 274 [I-D.yang-mif-connection-manager-impl-req]. 276 2.6. Microsoft Windows 278 The multi-interface functionality currently implemented in Microsoft 279 Windows operation systems is described in 280 [I-D.montenegro-mif-multihoming]. 282 Question: Is it possible to specify specific operating systems/ 283 versions to which this applies? 285 2.7. Linux and BSD-based Operating Systems 287 Most BSD and Linux distributions rely on their DHCP client to handle 288 the configuration of interface-specific information (such as an IP 289 address and netmask), and a set of system-wide configuration 290 information, (such a DNS server list, an NTP server list and default 291 routes). Users of these operating systems have the choice of using 292 any DHCP client available for their platform, with an operating 293 system default. This section discusses the behavior of several DHCP 294 clients that may be used with Linux and BSD distributions. 296 The Internet Systems Consortium (ISC) DHCP Client [ISCDHCP] and its 297 derivative for OpenBSD [OPENBSDDHCLIENT] can be configured with 298 specific instructions for each interface. However, each time new 299 configuration data is received by the host from a DHCP server, 300 regardless of which interface it is received on, the DHCP client 301 rewrites the global configuration data, such as the default routes 302 and the DNS server list (in /etc/resolv.conf) with the most recent 303 information received. Therefore, the last configured interface 304 always become the primary one. The ISC DHCPv6 client behaves 305 similarly. 307 The Phystech dhcpcd client [PHYSTECHDHCPC] behaves similarly to the 308 ISC client. It replaces the DNS server list in /etc/resolv.conf and 309 the default routes each time new DHCP information is received on any 310 interface. However, the -R flag can be used to instruct the client 311 to not replace the DNS servers in /etc/resolv.conf. However, this 312 flag is a global flag for the DHCP server, and is therefore 313 applicable to all interfaces. When dhcpd is called with the -R flag, 314 the DNS servers are never replaced. 316 The pump client [PUMP] also behaves similarly to the ISC client. It 317 replaces the DNS servers in /etc/resolv.conf and the default routes 318 each time new DHCP information is received on any interface. 319 However, the nodns and nogateway options can be specified on a per 320 interface basis, enabling the user to define which interface should 321 be used to obtain the global configuration information. 323 The udhcp client [UDHCP] is often used in embedded platforms based on 324 busybox. The udhcp client behaves similarly to the ISC client. It 325 rewrites default routes and the DNS server list each time new DHCP 326 information is received. 328 Redhat-based distributions, such as Redhat, Centos and Fedora have a 329 per-interface configuration option (PEERDNS) that indicates that the 330 DNS server list should not be updated based on configuration received 331 on that interface. 333 The most configurable DHCP clients can be set to define a primary 334 interface to use only that interface for the global configuration 335 data. However, this is limited, since a mobile host might not always 336 have the same set of interfaces available. Connection managers may 337 help in this situation. 339 Some distributions also have a connection manager. However, most 340 connection managers serve as a GUI to the DHCP client, therefore not 341 changing the functionality described above . TODO: Verify all 342 connection managers. 344 TODO: DHCPv6 clients 346 2.8. Apple Mac OS X 348 This section is based on testing Mac OS X (version 10.5.6). 350 When using multiple interfaces on Mac OS X, global configuration data 351 such as default routes and the DNS server list are taken from the 352 DHCP data received on the primary interface. Therefore, the order in 353 which the interfaces receive their configuration data is not 354 relevant. For example, if the primary interface receives its 355 configuration data first, then the second interface receives its 356 configuration data, the interface-specific information for the second 357 interface will be configured, but the global configuration 358 information such as the DNS server list and default routes is not 359 overwritten. 361 3. Common solutions 363 Essentially all operating systems use the same types of information 364 to make decisions about multiple-interface operation: user input, 365 operator/administrator provided information, and what has been 366 statically configured or hard-coded. It is possible to design clever 367 ways for tackling the problems related to multi-homing from the set 368 of dynamically available information, vendor specific policies and 369 design decisions. However, limitations on available information also 370 set limits on what different operating systems can theoretically 371 achieve. 373 This section describes what common solution approaches the analyzed 374 operating systems are known to utilize. 376 3.1. Centralized connection management 378 It seems to be common practice to have a centralized connection 379 manager entity, which does the network interface selection based on 380 application input. The information used by the connection manager 381 may be programmed into an application, learned from the users, or 382 provisioned. 384 Routing tables are not typically used for network interface 385 selection, as the criteria for network selection is not strictly IP- 386 based but is also dependent on other properties of the interface 387 (cost, type, etc.). Furthermore, multiple overlapping private IPv4 388 address spaces are often exposed to a multiple-interface host, making 389 it difficult to make interface selection decisions based on prefix 390 matching. 392 3.2. Per application connection settings 394 As each application has its particular connectivity needs, 395 applications are able to request what kind of connectivity they need. 397 4. Common problems 399 The current solutions are limited by the information available. This 400 section discusses what types of information IETF-designed protocols 401 could provide to allow implementations to improve functionality in 402 multi-inteface scenarios. 404 Please also see MIF problem statement document 405 [I-D.blanchet-mif-problem-statement]. 407 DISCUSS: is this section 4 required in this document, or should we 408 fully leave the problem descriptions to problem statement, or have 409 here some general problems, and in problem-statement more detailed 410 problems? 412 4.1. Selection of an interface providing access to a destination 414 As different network interfaces may provide connectivity to different 415 destination networks, a host needs to be able to choose a correct 416 network interface (or a set of interfaces, if the application can use 417 multiple interfaces in parallel) to allow the application or IP flow 418 to reach the intended destination. 420 4.2. Prioritization of interfaces for the same destination 422 As several interfaces may lead to the same destination network, a 423 host has to choose which one to use. It may be that if one network 424 has connectivity limitations, such as firewalls or NATs, and the 425 other network does not, it may be preferable to use the interface to 426 the less restricted network. This is not always the case, e.g. if 427 access to the restricted network is faster or cheaper, it might be 428 desirable to use that interface, if it can support the application 429 and reach the desired destination. Could the network somehow 430 indicate what limitations it is imposing, or could there be new 431 technologies that would help to determine the connectivity properties 432 of a network? 434 Improved source/destination address selection (underway in the 6man 435 address selection design team), more specific routes (RFC4191), or 436 other (TBD) technologies may be helpful in this area. 438 4.3. Enablers for application multihoming 440 When applications are bound to use single network interface at a 441 time, they are unable to benefit from technologies developed for 442 multihoming purposes. Therefore technologies that help to free 443 applications from being bound into a single network interface would 444 be useful. Essentially this means advanced ways to ensure that 445 applications use the right network interface, and that applications 446 do not accidentally use interfaces that will not support the 447 application or provide connetivity to the destination. Can 448 improvements be designed for IPv4 in spite of overlapping private 449 IPv4 address spaces, or only for IPv6? 451 5. Acknowledgements 453 Authors of the document would like to thank following people for 454 their input and feedback: Hui Deng, Jari Arkko. 456 This document was prepared using xml2rfc template and related web- 457 tool. 459 6. IANA Considerations 461 This memo includes no request to IANA. 463 7. Security Considerations 465 This draft describes current multiple-interface host implementations 466 on some common operating systems without any focus on security 467 considerations. 469 8. Change Log 471 The following changes were made between versions -00 and -01: 473 o Number of authors passed five, so moved to Contributors section. 475 o Added information on Microsoft Windows. 477 o Added information on Arena Connection Manager. 479 9. Contributors 481 The following people contributed most of the information found in 482 this document: 484 o Marc Blanchet, Viagenie 486 o Hua Chen, Leadcoretech, Ltd. 488 o Shunan Fan, Huawei Technology 490 o Gabriel Montenegro, Microsoft Corporation 492 o Teemu Savolainen, Nokia 493 o Shyam Seshadri, Microsoft Corporation 495 o Tao Sun, China Mobile 497 o Dave Thaler, Microsoft Corporation 499 o Jian Yang, Huawei Technology 501 o Yan Zhang, Leadcoretech Ltd. 503 10. References 505 10.1. Normative References 507 [I-D.blanchet-mif-problem-statement] 508 Blanchet, M., "Multiple Interfaces Problem Statement", 509 draft-blanchet-mif-problem-statement-00 (work in 510 progress), December 2008. 512 10.2. Informative References 514 [ANDROID] Google Inc., "Android developers: package android.net", 515 2009, . 518 [BLACKBERRY] 519 Research In Motion Limited, "BlackBerry Java Development 520 Environment - Fundamentals Guide: Wireless gateways", 521 2009, . 524 [I-D.montenegro-mif-multihoming] 525 Montenegro, G., Thaler, D., and S. Seshadri, "Multiple 526 Interfaces on Windows", 527 draft-montenegro-mif-multihoming-00 (work in progress), 528 March 2009. 530 [I-D.yang-mif-connection-manager-impl-req] 531 Yang, J., Sun, T., and S. Fan, "Multi-interface Connection 532 Manager Implementation and Requirements", 533 draft-yang-mif-connection-manager-impl-req-00 (work in 534 progress), March 2009. 536 [I-D.zhang-mif-connection-manager-arena] 537 Zhang, Y., Sun, T., and H. Chen, "Multi-interface Network 538 Connection Manager in Arena Platform", 539 draft-zhang-mif-connection-manager-arena-00 (work in 540 progress), February 2009. 542 [ISCDHCP] Internet Software Consortium, "ISC DHCP", 2009, 543 . 545 [OPENBSDDHCLIENT] 546 OpenBSD, "OpenBSD dhclient", 2009, 547 . 549 [PHYSTECHDHCPC] 550 Phystech, "dhcpcd", 2009, 551 . 553 [PUMP] RedHat, "PUMP", 2009, . 555 [S60] Nokia Corporation, "S60 Platform: IP Bearer Management", 556 2007, . 560 [UDHCP] Busybox, "uDHCP", 2009, . 563 [WINDOWSMOBILE] 564 Microsoft Corporation, "SDK Documentation for Windows 565 Mobile-Based Smartphones: Connection Manager", 2005, 566 . 568 Author's Address 570 Margaret Wasserman (editor) 571 Sandstorm Enterprises 572 14 Summer Street 573 Malden, MA 02148 574 USA 576 Phone: +1 781 333 3200 577 Email: mrw@lilacglade.org 578 URI: http://www.sandstorm.net