idnits 2.17.1 draft-mrw-mif-current-practices-00.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 4, 2009) is 5532 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 T. Savolainen 5 Expires: September 5, 2009 Nokia 6 M. Blanchet 7 Viagenie 8 March 4, 2009 10 Current Practices for Multiple Interface Hosts 11 draft-mrw-mif-current-practices-00 13 Status of this Memo 15 This Internet-Draft is submitted to IETF in full conformance with the 16 provisions of BCP 78 and 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 September 5, 2009. 36 Copyright Notice 38 Copyright (c) 2009 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents in effect on the date of 43 publication of this document (http://trustee.ietf.org/license-info). 44 Please review these documents carefully, as they describe your rights 45 and restrictions with respect to this document. 47 Abstract 49 An increasing number of hosts are operating in multiple-interface 50 environments, where different network interfaces are providing 51 unequal levels of service or connectivity. This document describes 52 how some common operating systems cope with the related challenges. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Current practices of some operating systems . . . . . . . . . 3 58 2.1. Nokia S60 3rd Edition, Feature Pack 2 . . . . . . . . . . 3 59 2.2. Microsoft Windows Mobile 2003 Second Edition . . . . . . . 5 60 2.3. BlackBerry . . . . . . . . . . . . . . . . . . . . . . . . 6 61 2.4. Google Android . . . . . . . . . . . . . . . . . . . . . . 6 62 2.5. Linux and BSD-based Operating Systems . . . . . . . . . . 7 63 2.6. Apple Mac OS X . . . . . . . . . . . . . . . . . . . . . . 8 64 3. Common solutions . . . . . . . . . . . . . . . . . . . . . . . 8 65 3.1. Centralized connection management . . . . . . . . . . . . 9 66 3.2. Per application connection settings . . . . . . . . . . . 9 67 4. Common problems . . . . . . . . . . . . . . . . . . . . . . . 9 68 4.1. Selection of an interface providing access to a 69 destination . . . . . . . . . . . . . . . . . . . . . . . 9 70 4.2. Prioritization of interfaces for the same destination . . 10 71 4.3. Enablers for application multihoming . . . . . . . . . . . 10 72 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 73 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 74 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 75 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 76 8.1. Normative References . . . . . . . . . . . . . . . . . . . 11 77 8.2. Informative References . . . . . . . . . . . . . . . . . . 11 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 80 1. Introduction 82 Multiple-interface hosts face several challenges not faced by single- 83 interface hosts, some of which are described in 84 [I-D.blanchet-mif-problem-statement]. 86 This document collects and analyzes publicly-available information 87 about the multiple-interface solutions implemented in some widely 88 used operating systems, including: Nokia S60 [S60], Microsoft Windows 89 Mobile [WINDOWSMOBILE], Blackberry [BLACKBERRY], Google Android 90 [ANDROID], Apple Mac OS X, Linux and BSD-based operating systems. 92 In section 3, common solutions implemented in different operating 93 systems are identified and generalized. 95 NOTE: Further input on the behaviour of these or other operating 96 systems (including newer versons) is very welcome. 98 2. Current practices of some operating systems 100 The following sections briefly describe the current multiple- 101 interface host implementations on some widely-used operating systems. 102 Please refer to the References section for pointers to original 103 documentation on most of these systems, including further details. 105 2.1. Nokia S60 3rd Edition, Feature Pack 2 107 Cellular devices typically run a variety of applications in parallel, 108 each with different requirements for IP connectivity. A typical 109 scenario is shown in figure 1, where a cellular device is utilizing 110 WLAN access for web browsing and GPRS access for transferring 111 multimedia messages (MMS). Another typical scenario would be a real- 112 time VoIP session over one network interface in parallel with best 113 effort web browsing on another network interface. Yet another 114 typical scenario would be global Internet access through one network 115 interface and local (e.g. corporate VPN) network access through 116 another. 118 Web server MMS Gateway 119 | | 120 -+--Internet---- ----Operator network--+- 121 | | 122 +-------+ +-------+ 123 |WLAN AP| | GGSN | 124 +-------+ +-------+ 125 | +--------+ | 126 +--------|Cellular|--------+ 127 |device | 128 +--------+ 130 A cellular device with two network interfaces 132 Figure 1 134 Different network access technologies require different settings. 135 For example, WLAN requires Service Set Identifier (SSID) and the GPRS 136 network requires the Access Point Name (APN) of the Gateway GPRS 137 Support Node (GGSN), among other parameters. It is common that 138 different accesses lead to different destination networks (e.g. to 139 "Internet", "Intranet", cellular network services, etc.). 141 S60 uses the concept of an Internet Access Point (IAP) [S60] that 142 contains all information required for opening a network connection 143 using a specific access technology. A device may have several IAPs 144 configured for different network technologies and settings (multiple 145 WLAN SSIDs, GPRS APNs, dial-up numbers, and so forth). There may 146 also be 'virtual' IAPs that define parameters needed for tunnel 147 establishment (e.g. for VPN). 149 For each application, a correct IAP needs to be selected at the point 150 when the application requires network connectivity. This is 151 essential, as the wrong IAP may not be able to support the 152 application or reach the desired destination. For example, MMS 153 application must use the correct IAP in order to reach the MMS 154 Gateway, which typically is not accessible from the public Internet. 155 As another example, an application might need to use the IAP 156 associated with its corporate VPN in order to reach internal 157 corporate servers. Binding applications to IAPs avoids several 158 problems, such as choosing the correct DNS server in the presence of 159 split DNS (as an application will use the DNS server list from its 160 bound IAP), and overlapping private IPv4 address spaces used for 161 different interfaces (as each application will use the default routes 162 from its bound IAP). 164 If multiple applications utilize the same IAP, the underlying network 165 connection can typically be shared. This is often the case when 166 multiple Internet-using applications are running in parallel. 168 The IAP for an application can be selected in multiple ways: 170 o Statically: e.g. from a configuration interface, via client 171 provisioning/device management system, or at build-time. 173 o Manually by the user: e.g. each time an application starts the 174 user may be asked to select the IAP to use. This may be needed, 175 for example, if a user sometimes wishes to access his corporate 176 intranet and other times would prefer to access the Internet 177 directly. 179 o Automatically by the system: after the destination network has 180 been selected statically or dynamically. 182 The static approach is fine for certain applications, like MMS, for 183 which configuration can be provisioned by the network operator and 184 does not change often. Manual selection works, but may be seen as 185 troublesome by the user. An automatic selection mechanism needs to 186 have some way of knowing which destination network the user, or an 187 application, is trying access. 189 S60 3rd Edition, Feature Pack 2, introduces a concept of Service 190 Network Access Points (SNAPs) that group together IAPs that lead to 191 the same destination. This enables static or manual selection of the 192 destination network for an application and leaves the problem of 193 selecting the best of the available IAPs within a SNAP to the 194 operating system. 196 When SNAPs are used, it it possibly for the operating system to 197 notify applications when a preferred IAP, leading to the same 198 destination, becomes available (for example, when a user comes within 199 range of his home WLAN access point), or when the currently used IAP 200 is no longer available and applications have to reconnect via another 201 IAP (for example, when a user goes out of range of his home WLAN and 202 must move to the cellular network). 204 Please see the source documentation for more details and screenshots: 205 [S60]. 207 2.2. Microsoft Windows Mobile 2003 Second Edition 209 A Connection Manager architecture is described in [WINDOWSMOBILE]. 210 This architecture centralizes and automates network connection 211 establishment and management, and makes it possible to automatically 212 select a connection, to dial-in automatically or by user initiation, 213 and to optimize connection and shared resource usage. Connection 214 Manager periodically re-evaluates the validity of the connection 215 selection. The Connection Manager uses various attributes such as 216 cost, security, bandwidth, error rate, and latency in its decision 217 making. 219 The Connection Manager selects the best possible connection for the 220 application based on the destination network the application wishes 221 to reach. The selection is made between available physical and 222 virtual connections (e.g. VPN, GPRS, WLAN, and wired Ethernet) that 223 are known to provide connectivity to the destination network, and the 224 selection is based on the costs associated with each connection. 225 Different applications are bundled to use the same network connection 226 when possible, but in conflict situations when a connection cannot be 227 shared, higher priority applications take precedence, and the lower 228 priority applications lose connectivity until the conflict situation 229 clears. 231 During operation, Connection Manager opens new connections as needed, 232 and also disconnects unused or idle connections. 234 To optimize resource use, such as battery power and bandwidth, 235 Connection Manager enables applications to synchronize network 236 connection usage by allowing applications to register their 237 requirements for periodic connectivity. An application is notified 238 when a suitable connection becomes available for its use. 240 2.3. BlackBerry 242 In BlackBerry devices [BLACKBERRY] Java applications can use one of 243 two wireless gateways to proxy the connection to the Internet or to a 244 corporate network. The application can be designed to always use the 245 default Internet gateway, or to use a more preferred enterprise 246 gateway when available. The intent is to hide connectivity issues 247 from users. 249 DISCUSS: How does the Blackberry decide when a WLAN interface, a 250 cellular interface or some other physical interface is used? 252 2.4. Google Android 254 The Android reference documentation describes the android.net package 255 [ANDROID] and the ConnectivityManager class that applications can use 256 to request a route to a specified destination address via a specified 257 network interface (Mobile or Wifi). Applications also ask Connection 258 Manager for permission to start using a network feature. The 259 Connectivity Manager monitors changes in network connectivity and 260 attempts to failover to another network if connectivity to an active 261 network is lost. When there are changes in network connectivity, 262 applications are notified. Applications are also able to ask for 263 information about all network interfaces, including their 264 availability, type and other information. 266 DISCUSS: Are applications bound to use one network type at a time, or 267 can one application use multiple network features in parallel? 269 2.5. Linux and BSD-based Operating Systems 271 Most BSD and Linux distributions rely on their DHCP client to handle 272 the configuration of interface-specific information (such as an IP 273 address and netmask), and a set of system-wide configuration 274 information, (such a DNS server list, an NTP server list and default 275 routes). Users of these operating systems have the choice of using 276 any DHCP client available for their platform, with an operating 277 system default. This section discusses the behavior of several DHCP 278 clients that may be used with Linux and BSD distributions. 280 The Internet Systems Consortium (ISC) DHCP Client [ISCDHCP] and its 281 derivative for OpenBSD [OPENBSDDHCLIENT] can be configured with 282 specific instructions for each interface. However, each time new 283 configuration data is received by the host from a DHCP server, 284 regardless of which interface it is received on, the DHCP client 285 rewrites the global configuration data, such as the default routes 286 and the DNS server list (in /etc/resolv.conf) with the most recent 287 information received. Therefore, the last configured interface 288 always become the primary one. The ISC DHCPv6 client behaves 289 similarly. 291 The Phystech dhcpcd client [PHYSTECHDHCPC] behaves similarly to the 292 ISC client. It replaces the DNS server list in /etc/resolv.conf and 293 the default routes each time new DHCP information is received on any 294 interface. However, the -R flag can be used to instruct the client 295 to not replace the DNS servers in /etc/resolv.conf. However, this 296 flag is a global flag for the DHCP server, and is therefore 297 applicable to all interfaces. When dhcpd is called with the -R flag, 298 the DNS servers are never replaced. 300 The pump client [PUMP] also behaves similarly to the ISC client. It 301 replaces the DNS servers in /etc/resolv.conf and the default routes 302 each time new DHCP information is received on any interface. 303 However, the nodns and nogateway options can be specified on a per 304 interface basis, enabling the user to define which interface should 305 be used to obtain the global configuration information. 307 The udhcp client [UDHCP] is often used in embedded platforms based on 308 busybox. The udhcp client behaves similarly to the ISC client. It 309 rewrites default routes and the DNS server list each time new DHCP 310 information is received. 312 Redhat-based distributions, such as Redhat, Centos and Fedora have a 313 per-interface configuration option (PEERDNS) that indicates that the 314 DNS server list should not be updated based on configuration received 315 on that interface. 317 The most configurable DHCP clients can be set to define a primary 318 interface to use only that interface for the global configuration 319 data. However, this is limited, since a mobile host might not always 320 have the same set of interfaces available. Connection managers may 321 help in this situation. 323 Some distributions also have a connection manager. However, most 324 connection managers serve as a GUI to the DHCP client, therefore not 325 changing the functionality described above . TODO: Verify all 326 connection managers. 328 TODO: DHCPv6 clients 330 2.6. Apple Mac OS X 332 This section is based on testing Mac OS X (version 10.5.6). 334 When using multiple interfaces on Mac OS X, global configuration data 335 such as default routes and the DNS server list are taken from the 336 DHCP data received on the primary interface. Therefore, the order in 337 which the interfaces receive their configuration data is not 338 relevant. For example, if the primary interface receives its 339 configuration data first, then the second interface receives its 340 configuration data, the interface-specific information for the second 341 interface will be configured, but the global configuration 342 information such as the DNS server list and default routes is not 343 overwritten. 345 3. Common solutions 347 Essentially all operating systems use the same types of information 348 to make decisions about multiple-interface operation: user input, 349 operator/administrator provided information, and what has been 350 statically configured or hard-coded. It is possible to design clever 351 ways for tackling the problems related to multi-homing from the set 352 of dynamically available information, vendor specific policies and 353 design decisions. However, limitations on available information also 354 set limits on what different operating systems can theoretically 355 achieve. 357 This section describes what common solution approaches the analyzed 358 operating systems are known to utilize. 360 3.1. Centralized connection management 362 It seems to be common practice to have a centralized connection 363 manager entity, which does the network interface selection based on 364 application input. The information used by the connection manager 365 may be programmed into an application, learned from the users, or 366 provisioned. 368 Routing tables are not typically used for network interface 369 selection, as the criteria for network selection is not strictly IP- 370 based but is also dependent on other properties of the interface 371 (cost, type, etc.). Furthermore, multiple overlapping private IPv4 372 address spaces are often exposed to a multiple-interface host, making 373 it difficult to make interface selection decisions based on prefix 374 matching. 376 3.2. Per application connection settings 378 As each application has its particular connectivity needs, 379 applications are able to request what kind of connectivity they need. 381 4. Common problems 383 The current solutions are limited by the information available. This 384 section discusses what types of information IETF-designed protocols 385 could provide to allow implementations to improve functionality in 386 multi-inteface scenarios. 388 Please also see MIF problem statement document 389 [I-D.blanchet-mif-problem-statement]. 391 DISCUSS: is this section 4 required in this document, or should we 392 fully leave the problem descriptions to problem statement, or have 393 here some general problems, and in problem-statement more detailed 394 problems? 396 4.1. Selection of an interface providing access to a destination 398 As different network interfaces may provide connectivity to different 399 destination networks, a host needs to be able to choose a correct 400 network interface (or a set of interfaces, if the application can use 401 multiple interfaces in parallel) to allow the application or IP flow 402 to reach the intended destination. 404 4.2. Prioritization of interfaces for the same destination 406 As several interfaces may lead to the same destination network, a 407 host has to choose which one to use. It may be that if one network 408 has connectivity limitations, such as firewalls or NATs, and the 409 other network does not, it may be preferable to use the interface to 410 the less restricted network. This is not always the case, e.g. if 411 access to the restricted network is faster or cheaper, it might be 412 desirable to use that interface, if it can support the application 413 and reach the desired destination. Could the network somehow 414 indicate what limitations it is imposing, or could there be new 415 technologies that would help to determine the connectivity properties 416 of a network? 418 Improved source/destination address selection (underway in the 6man 419 address selection design team), more specific routes (RFC4191), or 420 other (TBD) technologies may be helpful in this area. 422 4.3. Enablers for application multihoming 424 When applications are bound to use single network interface at a 425 time, they are unable to benefit from technologies developed for 426 multihoming purposes. Therefore technologies that help to free 427 applications from being bound into a single network interface would 428 be useful. Essentially this means advanced ways to ensure that 429 applications use the right network interface, and that applications 430 do not accidentally use interfaces that will not support the 431 application or provide connetivity to the destination. Can 432 improvements be designed for IPv4 in spite of overlapping private 433 IPv4 address spaces, or only for IPv6? 435 5. Acknowledgements 437 Authors of the document would like to thank following people for 438 their input and feedback: Hui Deng, Jari Arkko. 440 This document was prepared using xml2rfc template and related web- 441 tool. 443 6. IANA Considerations 445 This memo includes no request to IANA. 447 7. Security Considerations 449 This draft describes current multiple-interface host implementations 450 on some common operating systems without any focus on security 451 considerations. 453 8. References 455 8.1. Normative References 457 [I-D.blanchet-mif-problem-statement] 458 Blanchet, M., "Multiple Interfaces Problem Statement", 459 draft-blanchet-mif-problem-statement-00 (work in 460 progress), December 2008. 462 8.2. Informative References 464 [ANDROID] Google Inc., "Android developers: package android.net", 465 2009, . 468 [BLACKBERRY] 469 Research In Motion Limited, "BlackBerry Java Development 470 Environment - Fundamentals Guide: Wireless gateways", 471 2009, . 474 [ISCDHCP] Internet Software Consortium, "ISC DHCP", 2009, 475 . 477 [OPENBSDDHCLIENT] 478 OpenBSD, "OpenBSD dhclient", 2009, 479 . 481 [PHYSTECHDHCPC] 482 Phystech, "dhcpcd", 2009, 483 . 485 [PUMP] RedHat, "PUMP", 2009, . 487 [S60] Nokia Corporation, "S60 Platform: IP Bearer Management", 488 2007, . 492 [UDHCP] Busybox, "uDHCP", 2009, . 495 [WINDOWSMOBILE] 496 Microsoft Corporation, "SDK Documentation for Windows 497 Mobile-Based Smartphones: Connection Manager", 2005, 498 . 500 Authors' Addresses 502 Margaret Wasserman (editor) 503 Sandstorm Enterprises 504 14 Summer Street 505 Malden, MA 02148 506 USA 508 Phone: +1 781 333 3200 509 Email: mrw@lilacglade.org 510 URI: http://www.sandstorm.net 512 Teemu Savolainen 513 Nokia 514 Hermiankatu 12 D 515 TAMPERE, FI-33720 516 Finland 518 Email: teemu.savolainen@nokia.com 520 Marc Blanchet 521 Viagenie 522 2600 boul. Laurier, suite 625 523 Quebec, QC G1V 4W1 524 Canada 526 Email: Marc.Blanchet@viagenie.ca 527 URI: http://www.viagenie.ca