idnits 2.17.1 draft-ietf-mif-current-practices-05.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 : ---------------------------------------------------------------------------- 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 (October 25, 2010) is 4925 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-15) exists of draft-ietf-mif-problem-statement-07 -- Obsolete informational reference (is this intentional?): RFC 3484 (Obsoleted by RFC 6724) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). 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 Painless Security, LLC 4 Intended status: Informational P. Seite, Ed. 5 Expires: April 28, 2011 France Telecom - Orange 6 October 25, 2010 8 Current Practices for Multiple Interface Hosts 9 draft-ietf-mif-current-practices-05 11 Abstract 13 An increasing number of hosts are operating in multiple-interface 14 environments, where different network interfaces are providing 15 unequal levels of service or connectivity. This document summarizes 16 current practices in this area, and describes in detail how some 17 common operating systems cope with these challenges. 19 Status of this Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on April 28, 2011. 36 Copyright Notice 38 Copyright (c) 2010 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 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Summary of Current Approaches . . . . . . . . . . . . . . . . 3 55 2.1. Centralized Connection Management . . . . . . . . . . . . 3 56 2.2. Per Application Connection Settings . . . . . . . . . . . 4 57 2.3. Stack-Level Solutions to Specific Problems . . . . . . . . 4 58 2.3.1. DNS Resolution Issues . . . . . . . . . . . . . . . . 5 59 2.3.2. Routing . . . . . . . . . . . . . . . . . . . . . . . 5 60 2.3.3. Address Selection Policy . . . . . . . . . . . . . . . 5 61 3. Current Practices in Some Operating Systems . . . . . . . . . 6 62 3.1. Mobile Handset Operating Systems . . . . . . . . . . . . . 6 63 3.1.1. Nokia S60 3rd Edition, Feature Pack 2 . . . . . . . . 7 64 3.1.2. Microsoft Windows Mobile 2003 Second Edition . . . . . 8 65 3.1.3. Window Phone 7 . . . . . . . . . . . . . . . . . . . . 9 66 3.1.4. BlackBerry . . . . . . . . . . . . . . . . . . . . . . 9 67 3.1.5. Google Android . . . . . . . . . . . . . . . . . . . . 10 68 3.1.6. Qualcomm Brew . . . . . . . . . . . . . . . . . . . . 10 69 3.1.7. Arena Connection Manager . . . . . . . . . . . . . . . 12 70 3.1.8. Access selection . . . . . . . . . . . . . . . . . . . 12 71 3.2. Desktop Operating Systems . . . . . . . . . . . . . . . . 14 72 3.2.1. Microsoft Windows . . . . . . . . . . . . . . . . . . 14 73 3.2.1.1. Routing . . . . . . . . . . . . . . . . . . . . . 14 74 3.2.1.2. Outbound and Inbound Addresses . . . . . . . . . . 14 75 3.2.1.3. DNS Configuration . . . . . . . . . . . . . . . . 14 76 3.2.2. Linux and BSD-based Operating Systems . . . . . . . . 16 77 3.2.3. Apple Mac OS X . . . . . . . . . . . . . . . . . . . . 17 78 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 79 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 80 6. Security Considerations . . . . . . . . . . . . . . . . . . . 18 81 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 18 82 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 83 8.1. Normative References . . . . . . . . . . . . . . . . . . . 19 84 8.2. Informative References . . . . . . . . . . . . . . . . . . 19 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 87 1. Introduction 89 Multiple-interface hosts face several challenges not faced by single- 90 interface hosts, some of which are described in the MIF problem 91 statement, [I-D.ietf-mif-problem-statement]. This document 92 summarizes how current implementations deal with the problems 93 identified in the MIF problem statement. 95 Publicly-available information about the multiple-interface solutions 96 implemented in some widely used operating systems, including both 97 mobile handset and desktop operating systems, is collected in this 98 document, including: Nokia S60 [S60], Microsoft Windows Mobile 99 [WINDOWSMOBILE], Blackberry [BLACKBERRY], Google Android [ANDROID], 100 Microsoft Windows, Apple Mac OS X, Linux and BSD-based operating 101 systems. 103 2. Summary of Current Approaches 105 This section summarizes current approaches that are used to resolve 106 the multi-interface issues described in the Multiple Interface 107 Problem Statement [I-D.ietf-mif-problem-statement]. These approaches 108 can be broken down into three major categories: 110 o Centralized connection management 112 o Per-application connection settings 114 o Stack-level solutions to specific problems 116 2.1. Centralized Connection Management 118 It is a common practice for mobile handset operating systems to use a 119 centralized connection manager that performs network interface 120 selection based on application or user input. The information used 121 by the connection manager may be programmed into an application or 122 provisioned on a handset-wide basis. When information is not 123 available to make an interface selection, the connection manager will 124 query the user to choose between available choices. 126 Routing tables are not typically used for network interface selection 127 when a connection manager is in use, as the criteria for network 128 selection is not strictly IP-based but is also dependent on other 129 properties of the interface (cost, type, etc.). Furthermore, 130 multiple overlapping private IPv4 address spaces are often exposed to 131 a multiple-interface host, making it difficult to make interface 132 selection decisions based on prefix matching. 134 2.2. Per Application Connection Settings 136 In mobile handsets, applications are often involved in choosing what 137 interface and related configuration information should be used. In 138 some cases, the application selects the interface directly, and in 139 other cases the application provides more abstract information to a 140 connection manager that makes the final interface choice. 142 2.3. Stack-Level Solutions to Specific Problems 144 In most desktop operating systems, multiple interface problems are 145 dealt with in the stack and related components, based on system- 146 level configuration information, without the benefit of input from 147 applications or users. These solutions tend to map well to the 148 problems listed in the problem statement: 150 o DNS resolution issues 152 o Routing 154 o Address selection policy 156 The configuration information for desktop systems comes from one of 157 three sources: DHCP, proprietary configuration systems or manual 158 configuration. While these systems universally accept IP address 159 assignment on a per-interface basis, they differ in what set of 160 information can be assigned on a per-interface basis and what can be 161 configured only on a per-system basis. 163 When choosing between multiple sets of information provided, these 164 systems will typically give preference to information received on the 165 "primary" interface. The mechanism for designating the "primary" 166 interface differs by system. 168 There is very little commonality in how desktop operating systems 169 handle multiple sets of configuration information, with notable 170 variations between different versions of the same operating system 171 and/or within different software packages built for the same 172 operating system. Although these systems differ widely, it is not 173 clear that any of them provide a completely satisfactory user 174 experience in multiple-interface environments. 176 The following sections discuss some of the solutions used in each of 177 the areas raised in the MIF problem statement. 179 2.3.1. DNS Resolution Issues 181 There is very little commonality in how desktop operating systems 182 handle the DNS server list. Some systems support per-interface DNS 183 server lists, while others only support a single system-wide list. 185 On hosts with per-interface DNS server lists, different mechanisms 186 are used to determine which DNS server is contacted for a given 187 query. In most cases, the first DNS server listed on the "primary" 188 interface is queried first, with back off to other servers if an 189 answer is not received. 191 Systems that support a single system-wide list differ in how they 192 select which DNS server to use in cases where they receive more than 193 one DNS server list to configure (e.g. from DHCP on multiple 194 interfaces). Some accept the information received on the "primary" 195 interface, while others use either the first or last set DNS server 196 list configured. 198 2.3.2. Routing 200 Routing information is also handled differently on different desktop 201 operating systems. While all systems maintain some sort of routing 202 cache, to handle redirects and/or statically configured routes, most 203 packets are routed based on configured default gateway information. 205 Some systems do allow the configuration of different default router 206 lists for different interfaces. These systems will always choose the 207 default gateway on the interface with the lowest routing metric, with 208 different behavior when two or more interfaces have the same routing 209 metric. 211 Most systems do not allow the configuration of more than one default 212 router list, choosing instead to use the first or last default router 213 list configured and/or the router list configured on the "primary" 214 interface. 216 2.3.3. Address Selection Policy 218 There is somewhat more commonality in how desktop hosts handle 219 address selection. Applications typically provide the destination 220 address for an outgoing packet, and the IP stack is responsible for 221 picking the source address. 223 IPv6 specifies a specific source address selection mechanism in 224 [RFC3484], and several systems implement this mechanism with similar 225 support for IPv4. However, many systems do not provide any mechanism 226 to update this default policy, and there is no standard way to do so. 228 In some cases, the routing decision (including which interface to 229 use) is made before source address selection is performed, and a 230 source address is chosen from the outbound interface. In other 231 cases, source address selection is performed before, or independently 232 from outbound interface selection. 234 3. Current Practices in Some Operating Systems 236 The following sections briefly describe the current multiple- 237 interface host implementations on some widely-used operating systems. 238 Please refer to the References section for pointers to original 239 documentation on most of these systems, including further details. 241 3.1. Mobile Handset Operating Systems 243 Cellular devices typically run a variety of applications in parallel, 244 each with different requirements for IP connectivity. A typical 245 scenario is shown in figure 1, where a cellular device is utilizing 246 WLAN access for web browsing and GPRS access for transferring 247 multimedia messages (MMS). Another typical scenario would be a real- 248 time VoIP session over one network interface in parallel with best 249 effort web browsing on another network interface. Yet another 250 typical scenario would be global Internet access through one network 251 interface and local (e.g. corporate VPN) network access through 252 another. 254 Web server MMS Gateway 255 | | 256 -+--Internet---- ----Operator network--+- 257 | | 258 +-------+ +-------+ 259 |WLAN AP| | GGSN | 260 +-------+ +-------+ 261 | +--------+ | 262 +--------|Cellular|--------+ 263 |device | 264 +--------+ 266 A cellular device with two network interfaces 268 Figure 1 270 Different network access technologies require different settings. 271 For example, WLAN requires Service Set Identifier (SSID) and the GPRS 272 network requires the Access Point Name (APN) of the Gateway GPRS 273 Support Node (GGSN), among other parameters. It is common that 274 different accesses lead to different destination networks (e.g. to 275 "Internet", "intranet", cellular network services, etc.). 277 3.1.1. Nokia S60 3rd Edition, Feature Pack 2 279 S60 uses the concept of an Internet Access Point (IAP) [S60] that 280 contains all information required for opening a network connection 281 using a specific access technology. A device may have several IAPs 282 configured for different network technologies and settings (multiple 283 WLAN SSIDs, GPRS APNs, dial-up numbers, and so forth). There may 284 also be 'virtual' IAPs that define parameters needed for tunnel 285 establishment (e.g. for VPN). 287 For each application, a correct IAP needs to be selected at the point 288 when the application requires network connectivity. This is 289 essential, as the wrong IAP may not be able to support the 290 application or reach the desired destination. For example, MMS 291 application must use the correct IAP in order to reach the MMS 292 Gateway, which typically is not accessible from the public Internet. 293 As another example, an application might need to use the IAP 294 associated with its corporate VPN in order to reach internal 295 corporate servers. Binding applications to IAPs avoids several 296 problems, such as choosing the correct DNS server in the presence of 297 split DNS (as an application will use the DNS server list from its 298 bound IAP), and overlapping private IPv4 address spaces used for 299 different interfaces (as each application will use the default routes 300 from its bound IAP). 302 If multiple applications utilize the same IAP, the underlying network 303 connection can typically be shared. This is often the case when 304 multiple Internet-using applications are running in parallel. 306 The IAP for an application can be selected in multiple ways: 308 o Statically: e.g. from a configuration interface, via client 309 provisioning/device management system, or at build-time. 311 o Manually by the user: e.g. each time an application starts the 312 user may be asked to select the IAP to use. This may be needed, 313 for example, if a user sometimes wishes to access his corporate 314 intranet and other times would prefer to access the Internet 315 directly. 317 o Automatically by the system: after the destination network has 318 been selected statically or dynamically. 320 The static approach is fine for certain applications, like MMS, for 321 which configuration can be provisioned by the network operator and 322 does not change often. Manual selection works, but may be seen as 323 troublesome by the user. An automatic selection mechanism needs to 324 have some way of knowing which destination network the user, or an 325 application, is trying access. 327 S60 3rd Edition, Feature Pack 2, introduces a concept of Service 328 Network Access Points (SNAPs) that group together IAPs that lead to 329 the same destination. This enables static or manual selection of the 330 destination network for an application and leaves the problem of 331 selecting the best of the available IAPs within a SNAP to the 332 operating system. 334 When SNAPs are used, it is possibly for the operating system to 335 notify applications when a preferred IAP, leading to the same 336 destination, becomes available (for example, when a user comes within 337 range of his home WLAN access point), or when the currently used IAP 338 is no longer available and applications have to reconnect via another 339 IAP (for example, when a user goes out of range of his home WLAN and 340 must move to the cellular network). 342 Please see the source documentation for more details and screenshots: 343 [S60]. 345 3.1.2. Microsoft Windows Mobile 2003 Second Edition 347 A Connection Manager architecture is described in [WINDOWSMOBILE]. 348 This architecture centralizes and automates network connection 349 establishment and management, and makes it possible to automatically 350 select a connection, to dial-in automatically or by user initiation, 351 and to optimize connection and shared resource usage. Connection 352 Manager periodically re-evaluates the validity of the connection 353 selection. The Connection Manager uses various attributes such as 354 cost, security, bandwidth, error rate, and latency in its decision 355 making. 357 The Connection Manager selects the best possible connection for the 358 application based on the destination network the application wishes 359 to reach. The selection is made between available physical and 360 virtual connections (e.g. VPN, GPRS, WLAN, and wired Ethernet) that 361 are known to provide connectivity to the destination network, and the 362 selection is based on the costs associated with each connection. 363 Different applications are bundled to use the same network connection 364 when possible, but in conflict situations when a connection cannot be 365 shared, higher priority applications take precedence, and the lower 366 priority applications lose connectivity until the conflict situation 367 clears. 369 During operation, Connection Manager opens new connections as needed, 370 and also disconnects unused or idle connections. 372 To optimize resource use, such as battery power and bandwidth, 373 Connection Manager enables applications to synchronize network 374 connection usage by allowing applications to register their 375 requirements for periodic connectivity. An application is notified 376 when a suitable connection becomes available for its use. 378 3.1.3. Window Phone 7 380 In comparison to Windows Mobile 2003 SE, Windows phone 7 brings 381 update of the routing functionality in the case where the terminal 382 can be attached simultaneously to several interfaces. Actually, 383 Windows Phone 7 routes the traffic through a preferred interface, 384 which has a lower metric. When there are multiple interfaces, the 385 applications system will, by default, choose from an ordered list of 386 available interfaces. The default connection policy will prefer 387 wired over wireless and WLAN over cellular. Hence, if an application 388 wants to use cellular 3G as the active interface when WLAN is 389 available, the application needs to override the default connection 390 mapping policy. An application specific mapping policy can be set 391 via API or provisioned by the Mobile Operator. The application, in 392 compliance with the security model, can request connection type by 393 interface (WLAN, cellular), by minimum interface speed (x kbps, y 394 mbps), or by name (Access Point Name). 396 3.1.4. BlackBerry 398 Depending on the network configuration, Java applications in 399 BlackBerry devices [BLACKBERRY] can use can use direct TCP/IP 400 connectivity or different application proxys to establish connections 401 over the wireless network. For instance, some wireless service 402 providers provide an Internet gateway to offer direct TCP/IP 403 connectivity to the Internet while some others can provide a WAP 404 gateway that allows HTTP connections to occur over the WAP (Wireless 405 Application Protocol) protocol. It is also possible to use the 406 BlackBerry Enterprise Server [BLACKBERRY] as a network gateway, The 407 BlackBerry Enterprise Server provides an HTTP and TCP/IP proxy 408 service to allow the application to use it as a secure gateway for 409 managing HTTP and TCP/IP connections to the intranet or the Internet. 410 An application connecting to the Internet, can use either the 411 BlackBerry Internet Service or the Internet gateway of the wireless 412 server provider to manage connections. The problem of gateway 413 selection is supposed to be managed independently by each Java 414 application. For instance, an application can be designed to always 415 use the default Internet gateway, while another application can be 416 designed to use a preferred proxy when available. 418 A BlackBerry device [BLACKBERRY] can be attached to multiple networks 419 simultaneously (wireless/wired). In this case, Multiple network 420 interfaces can be associated to a single IP stack or multiple IP 421 stacks. The device, or the application, can select the network 422 interface to be used in various ways. For instance, the device can 423 always map the applications to the default network interface (or the 424 default access network). When muliple IP stacks are associated to 425 multiple interfaces, the application can select the source address 426 correponding to the preferred network interface. When multiple 427 network interfaces are aggregated into a single IP stack, the device 428 associates each application to the more appropriate network 429 interface. The selection can be based on cost, type-of-service 430 and/or user preference. 432 3.1.5. Google Android 434 The Android reference documentation describes the android.net package 435 [ANDROID] and the ConnectivityManager class that applications can use 436 to request a route to a specified destination address via a specified 437 network interface (3GPP or WLAN). Applications also ask Connection 438 Manager for permission to start using a network feature. The 439 Connectivity Manager monitors changes in network connectivity and 440 attempts to failover to another network if connectivity to an active 441 network is lost. When there are changes in network connectivity, 442 applications are notified. Applications are also able to ask for 443 information about all network interfaces, including their 444 availability, type and other information. 446 Depending on vendors implementation, applications may be bound to use 447 one network type at a time. For example, on a 3G/WLAN HTC Dream 448 (Android 1.5), web browsing uses only the WLAN access when both 3G 449 and WLAN are available. However different applications can use 450 different access at the same time. For instance, the HTC Dream can 451 utilize WLAN access for web browsing and GPRS access for transferring 452 multimedia messages (MMS). 454 3.1.6. Qualcomm Brew 456 This section describes how multi-interface support is handled by 457 Advanced Mobile Station Software (AMSS) that comes with Brew OS for 458 all Qualcomm chipsets (e.g., MSM, Snapdragon etc). AMSS is a low 459 level connectivity platform, on top of which manufacturers can build 460 to provide the necessary connectivity to applications. The 461 interaction model between AMSS, the Operating System, and the 462 applications is not unique and depend on the design chosen by the 463 manufacturer. The Mobile OS can let an application invoke the AMSS 464 directly (via API), or provide its own connection manager that will 465 request connectivity to the AMSS based on applications needs. The 466 interaction between the OS connection manager and the applications is 467 OS dependent. 469 AMSS supports a concept of netpolicy which allows each application to 470 specify the type of network connectivity desired. The netpolicy 471 contains parameters such as access technology, IP version type and 472 network profile. Access technology could be a specific technology 473 type such as CDMA or WLAN or could be a group of technologies, such 474 as ANY_Cellular or ANY_Wireless. IP version could be one of IPv4, 475 IPv6 or Default. The network profile identifies a type of network 476 domain or service within a certain network technology, such as 3GPP 477 APN or Mobile IP Home Agent. It also specifies all the mandatory 478 parameters required to connect to the domain such authentication 479 credentials and other optional parameters such as QoS attributes. 480 Network Profile is technology specific and set of parameters 481 contained in the profile could vary for different technologies. 483 Two models of network usage are supported: 485 o Applications requiring network connectivity specify an appropriate 486 netpolicy in order to select the desired network. The netpolicy 487 may match one or more network interfaces. AMSS system selection 488 module selects the best interface out of the ones that match the 489 netpolicy based on various criteria such as cost, speed or other 490 provisioned rules. Application explicitly starts the selected 491 network interface and, as a result, the application also gets 492 bound to the corresponding network interface. All outbound 493 packets from this application are always routed over this bound 494 interface using the source address of the interface. 496 o Applications may rely on a separate connection manager to control 497 (e.g. start/stop) the network interface. In this model, 498 applications are not necessarily bound to any one interface. All 499 outbound packets from such applications are routed on one of the 500 interfaces that match its netpolicy. The routing decision is made 501 individually for each packet and selects the best interface based 502 on the criteria described above and the destination address. 503 Source address is always that assigned to the interface used to 504 transmit the packet. 506 All of the routing/interface selection decisions are based on the 507 netpolicy and not just on the destination address to avoid 508 overlapping private IPv4 address issue. This also allows multiple 509 interfaces to be configured with the same IP address, for example, to 510 handle certain tunnelling scenarios. Applications that do not 511 specify a netpolicy are routed by AMSS to the best possible interface 512 using the default netpolicy. Default netpolicy could be pre-defined 513 or provisioned by the administrator or operator. Hence default 514 interface could vary from device to device and also depends upon the 515 available networks at any given time. 517 AMSS allows each interface to be configured with its own set of DNS 518 configuration parameters (e.g. list of DNS servers, domain names 519 etc.). Interface selected to make a DNS resolution is the one to 520 which application making the DNS query is bound. Applications can 521 also specify a different netpolicy as part of DNS request to select 522 another interface for DNS resolution. Regardless, all the DNS 523 queries are sent only over this selected interface using the DNS 524 configuration from the interface. DNS resolution is first attempted 525 with the primary server configured in the interface. If a response 526 is not received, the queries are sent to all the other servers 527 configured in the interface in a sequential manner using a backoff 528 mechanism. 530 3.1.7. Arena Connection Manager 532 Arena, a mobile OS based on Linux, provides a Connection Manager, 533 which is described in [I-D.zhang-mif-connection-manager-arena] and 534 [I-D.yang-mif-connection-manager-impl-req]. The arena connection 535 manager provides a means for applications to register their 536 connectivity requirement. The Connection Manager can then choose an 537 interface that matches the application's needs while considering 538 other factors such as availability, cost and stability. Also, the 539 Connection Manager can handle multi-interface issues such as 540 connection sharing. 542 3.1.8. Access selection 544 This section describes the behavior of connection managers in 545 presence of multiple points of attachment for a same interface. The 546 section focuses on WLAN interface, it is described how does the 547 connection manager deal with the list of preferred SSID and how does 548 it select the SSID for attachment. Current implementation of 549 connection managers are considered for the following handsets: LG 550 Pathfinder, Android/HTC magic, RIM BlackBerry , iPhone (3G and 3GS). 552 When the terminal is under coverage of different WLAN networks with 553 different SSIDs: 555 connection managers, excepted for the RIM Blackberry, construct 556 the list of preferred SSID giving priority to the last SSID on 557 which they have managed to attach. The user is not allowed to 558 define its preferred access. So, if the terminal discovers and 559 manages to attach to SSID1, SSID1 becomes the preferred access for 560 future attachment. If the terminal moves out of SSID1 coverage 561 and attaches to a new SSID, SSID2. SSID2 will then be the 562 preferred access of the connection manager. Then, if the terminal 563 processes to WLAN attachment within both SSID1 and SSID2 coverage, 564 the connection manager will select SSID2 for attachment. The RIM 565 Blackberry behaves differently, the connection manager selects the 566 first SSID on which it has managed to attach in the past. 568 All connection managers behave in the same way when the terminals 569 fails to attach to the selected SSID: the connection manager 570 automatically selects the second SSID in the list of preferred 571 SSID. Fallback come into play at expiration of a timeout from few 572 seconds to about 3 minutes. 574 When the IP stack fails to obtain an IP address, the handset, 575 excepted the iPhone, restarts WLAN attachment selecting the second 576 SSID in the list. 578 When the terminal receives signals from different point of attachment 579 with same SSID: 581 The connection manager selects the point of attachment with best 582 signal strength; no other criteria (e.g. MAC address) is taken 583 into account. If the handset fails to attach to the selected 584 point of attachment (e.g. due to L2 authentication failure), the 585 connection manager selects the point of attachment with lower 586 signal strength. However, this fallback is not supported on the 587 LG pathfinder. If no more points of attachment (corresponding to 588 the preferred SSID) are available, the connection manager selects 589 the second SSID in the list of preferred SSID. 591 Whatever is the handset, fallback on L3 attachment failure is not 592 supported if the terminal remains under coverage of the same WLAN 593 access point. Actually, the connection manager always selects the 594 most powerful signal strength without considering IP configuration 595 results. In other words, if the terminal is unable to set up the 596 IP connectivity on one WLAN access, the connection manager will 597 not try to attach to an alternative point of attachment (or SSID) 598 as long as the signal strength of the first radio link is the most 599 powerful. Situation is not the same for mobile terminal since the 600 signal strength of the alternative point of attachment could 601 become better while the terminal is moving. If so, the terminal 602 automatically restarts IP connectivity process (excepted the HTC 603 Magic which requires the user to manually restart the L3 604 attachment). 606 3.2. Desktop Operating Systems 608 Multi-interface issues also occur in desktop environments in those 609 cases where a desktop host has multiple (logical or physical) 610 interfaces connected to networks with different reachability 611 properties, such as one interface connected to the global Internet, 612 while another interface is connected to a corporate VPN. 614 3.2.1. Microsoft Windows 616 The multi-interface functionality currently implemented in Microsoft 617 Windows operation systems is described in more detail in 618 [I-D.montenegro-mif-multihoming]. 620 3.2.1.1. Routing 622 It is possible, although not often desirable, to configure default 623 routers on more than one Windows interface. In this configuration, 624 Windows will use the default route on the interface with the lowest 625 routing metric (i.e. the fastest interface). If multiple interfaces 626 share the same metric, the behavior will differ based on the version 627 of Windows in use. Prior to Windows Vista, the packet would be 628 routed out of the first interface that was bound to the TCP/IP stack, 629 the preferred interface. In Windows vista, host-to-router load 630 sharing [RFC4311] is used for both IPv4 and IPv6. 632 3.2.1.2. Outbound and Inbound Addresses 634 If the source address of the outgoing packet has not been determined 635 by the application, Windows will choose from the addresses assigned 636 to its interfaces. Windows implements [RFC3484] for source address 637 selection in IPv6 and, in Windows Vista, for IPv4. Prior to Windows 638 Vista, IPv4 simply chose the first address on the outgoing interface. 640 For incoming packets, Windows will check if the destination address 641 matches one of the addresses assigned to its interfaces. Windows has 642 implemented the weak host model [RFC1122] on IPv4 in Windows 2000, 643 Windows XP and Windows Server 2003. The strong host model became the 644 default for IPv4 in Windows Vista and Windows server 2008, however 645 the weak host model is available via per-interface configuration. 646 IPv6 has always implemented the strong host model. 648 3.2.1.3. DNS Configuration 650 Windows largely relies on suffixes to solve DNS resolution issues. 651 Suffixes are used for four different purposes that are reminded 652 hereafter: 654 1. DNS Suffix Search List (aka domain search list): suffix is added 655 to non-FQDN names. 657 2. Interface-specific suffix list, which allows sending different 658 DNS queries to different DNS servers. 660 3. Suffix to control Dynamic DNS Updates: determine which DNS server 661 will receive a dynamic update for a name with a certain suffix. 663 4. Suffix in the Name Resolution Policy Table [NRPT] to aid in 664 identifying a Namespace that requires special handling (feature 665 available only after Windows 7 and its server counterpart, 666 Windows Server 2008 R2). 668 However, this section focuses on the interface-specific suffix list 669 since it is the only suffix usage in the scope of this document. 671 DNS configuration information can be host-wide or interface specific. 672 Host-wide DNS configuration is input via static configuration or, in 673 sites that use Active Directory, Microsoft's Group Policy. Interface 674 specific DNS configuration can be input via static configuration or 675 via DHCP. 677 The host-wide configuration consists of a primary DNS suffix to be 678 used for the local host, as well as a list of suffix that can be 679 appended to names being queried. Before Windows Vista and Windows 680 Server 2008, there was also a host-wide DNS server list that took 681 precedent over per-interface DNS configuration. 683 The interface-specific DNS configuration comprises an interface- 684 specific suffix list and a list of DNS server IP addresses. 686 Windows uses a host-wide "effective" server list for an actual query, 687 where the effective server list may be different for different names. 688 In the list of DNS server addresses, the first server is considered 689 the "primary" server, with all other servers being secondary. 691 When a DNS query is performed in Windows, the query is first sent to 692 the primary DNS server on the preferred interface. If no response is 693 received in one second, the query is sent to the primary DNS servers 694 on all interfaces under consideration. If no response is received 695 for 2 more seconds, the DNS server sends the query to all of the DNS 696 servers on the DNS server lists for all interfaces under 697 consideration. If the host still doesn't receive a response after 4 698 seconds, it will send to all of the servers again and wait 8 seconds 699 for a response. 701 3.2.2. Linux and BSD-based Operating Systems 703 Most BSD and Linux distributions rely on their DHCP client to handle 704 the configuration of interface-specific information (such as an IP 705 address and netmask), and a set of system-wide configuration 706 information, (such a DNS server list, an NTP server list and default 707 routes). Users of these operating systems have the choice of using 708 any DHCP client available for their platform, with an operating 709 system default. This section discusses the behavior of several DHCP 710 clients that may be used with Linux and BSD distributions. 712 The Internet Systems Consortium (ISC) DHCP Client [ISCDHCP] and its 713 derivative for OpenBSD [OPENBSDDHCLIENT] can be configured with 714 specific instructions for each interface. However, each time new 715 configuration data is received by the host from a DHCP server, 716 regardless of which interface it is received on, the DHCP client 717 rewrites the global configuration data, such as the default routes 718 and the DNS server list (in /etc/resolv.conf) with the most recent 719 information received. Therefore, the last configured interface 720 always become the primary one. The ISC DHCPv6 client behaves 721 similarly. 723 The Phystech dhcpcd client [PHYSTECHDHCPC] behaves similarly to the 724 ISC client. It replaces the DNS server list in /etc/resolv.conf and 725 the default routes each time new DHCP information is received on any 726 interface. However, the -R flag can be used to instruct the client 727 to not replace the DNS servers in /etc/resolv.conf. However, this 728 flag is a global flag for the DHCP server, and is therefore 729 applicable to all interfaces. When dhcpd is called with the -R flag, 730 the DNS servers are never replaced. 732 The pump client [PUMP] also behaves similarly to the ISC client. It 733 replaces the DNS servers in /etc/resolv.conf and the default routes 734 each time new DHCP information is received on any interface. 735 However, the nodns and nogateway options can be specified on a per 736 interface basis, enabling the user to define which interface should 737 be used to obtain the global configuration information. 739 The udhcp client [UDHCP] is often used in embedded platforms based on 740 busybox. The udhcp client behaves similarly to the ISC client. It 741 rewrites default routes and the DNS server list each time new DHCP 742 information is received. 744 Redhat-based distributions, such as Redhat, Centos and Fedora have a 745 per-interface configuration option (PEERDNS) that indicates that the 746 DNS server list should not be updated based on configuration received 747 on that interface. 749 The most configurable DHCP clients can be set to define a primary 750 interface to use only that interface for the global configuration 751 data. However, this is limited, since a mobile host might not always 752 have the same set of interfaces available. Connection managers may 753 help in this situation. 755 Some distributions also have a connection manager. However, most 756 connection managers serve as a GUI to the DHCP client, therefore not 757 changing the functionality described above. 759 Linux implements [RFC3484] for source address selection in IPv6. 760 However, the address sorting rules from [RFC3484] are not always 761 adequate. For this reason, Linux allows the system administrator to 762 dynamically change the sorting. This can be achieved with the /etc/ 763 gai.conf file. 765 For incoming packets, Linux will check if the destination address 766 matches one of the addresses assigned to its interfaces. By default, 767 Linux implements the weak host model [RFC1122] on both IPv4 and IPv6. 768 However, Linux can also be configured to support the strong host 769 model. 771 3.2.3. Apple Mac OS X 773 This section is based on testing Mac OS X (version 10.5.6). 775 When using multiple interfaces on Mac OS X, global configuration data 776 such as default routes and the DNS server list are taken from the 777 DHCP data received on the primary interface. Therefore, the order in 778 which the interfaces receive their configuration data is not 779 relevant. For example, if the primary interface receives its 780 configuration data first, then the second interface receives its 781 configuration data, the interface-specific information for the second 782 interface will be configured, but the global configuration 783 information such as the DNS server list and default routes is not 784 overwritten. 786 4. Acknowledgements 788 Authors of the document would like to thank following people for 789 their input and feedback: Dan Wing, Hui Deng, Jari Arkko, Julien 790 Laganier. 792 5. IANA Considerations 794 This memo includes no request to IANA. 796 6. Security Considerations 798 This document describes current operating system implementations and 799 how they handle the issues raised in the MIF problem statement. 800 While it is possible that the currently implemented mechanisms 801 described in this document may affect the security of the systems 802 described, this document merely reports on current practice. It does 803 not attempt to analyze the security properties (or any other 804 architectural properties) of the currently implemented mechanisms. 806 7. Contributors 808 The following people contributed most of the per-Operating System 809 information found in this document: 811 o Marc Blanchet, Viagenie 813 o Hua Chen, Leadcoretech, Ltd. 815 o Yan Zhang, Leadcoretech Ltd. 817 o Shunan Fan, Huawei Technology 819 o Jian Yang, Huawei Technology 821 o Gabriel Montenegro, Microsoft Corporation 823 o Shyam Seshadri, Microsoft Corporation 825 o Dave Thaler, Microsoft Corporation 827 o Kevin Chin, Microsoft Corporation 829 o Teemu Savolainen, Nokia 831 o Tao Sun, China Mobile 833 o George Tsirtsis, Qualcomm. 835 o David Freyermuth, France telecom. 837 o Aurelien Collet, Altran. 839 o Giyeong Son, RIM. 841 8. References 842 8.1. Normative References 844 [I-D.ietf-mif-problem-statement] 845 Blanchet, M. and P. Seite, "Multiple Interfaces Problem 846 Statement", draft-ietf-mif-problem-statement-07 (work in 847 progress), August 2010. 849 8.2. Informative References 851 [ANDROID] Google Inc., "Android developers: package android.net", 852 2009, . 855 [BLACKBERRY] 856 Research In Motion Limited, "BlackBerry Java Development 857 Environment - Fundamentals Guide: Wireless gateways", 858 2009, . 861 [I-D.montenegro-mif-multihoming] 862 Montenegro, G., Thaler, D., and S. Seshadri, "Multiple 863 Interfaces on Windows", 864 draft-montenegro-mif-multihoming-00 (work in progress), 865 March 2009. 867 [I-D.yang-mif-connection-manager-impl-req] 868 Yang, J., Sun, T., and S. Fan, "Multi-interface Connection 869 Manager Implementation and Requirements", 870 draft-yang-mif-connection-manager-impl-req-00 (work in 871 progress), March 2009. 873 [I-D.zhang-mif-connection-manager-arena] 874 Zhang, Y., Sun, T., and H. Chen, "Multi-interface Network 875 Connection Manager in Arena Platform", 876 draft-zhang-mif-connection-manager-arena-00 (work in 877 progress), February 2009. 879 [ISCDHCP] Internet Software Consortium, "ISC DHCP", 2009, 880 . 882 [NRPT] Windows, "Name Resolution Policy Table", February 2010, < 883 http://technet.microsoft.com/en-us/magazine/ 884 ff394369.aspx>. 886 [OPENBSDDHCLIENT] 887 OpenBSD, "OpenBSD dhclient", 2009, 888 . 890 [PHYSTECHDHCPC] 891 Phystech, "dhcpcd", 2009, 892 . 894 [PUMP] RedHat, "PUMP", 2009, . 896 [RFC1122] Braden, R., "Requirements for Internet Hosts - 897 Communication Layers", STD 3, RFC 1122, October 1989. 899 [RFC3484] Draves, R., "Default Address Selection for Internet 900 Protocol version 6 (IPv6)", RFC 3484, February 2003. 902 [RFC4311] Hinden, R. and D. Thaler, "IPv6 Host-to-Router Load 903 Sharing", RFC 4311, November 2005. 905 [S60] Nokia Corporation, "S60 Platform: IP Bearer Management", 906 2007, . 910 [UDHCP] Busybox, "uDHCP", 2009, . 913 [WINDOWSMOBILE] 914 Microsoft Corporation, "SDK Documentation for Windows 915 Mobile-Based Smartphones: Connection Manager", 2005, 916 . 918 Authors' Addresses 920 Margaret Wasserman (editor) 921 Painless Security, LLC 922 356 Abbott Street 923 North Andover, MA 01845 924 USA 926 Phone: +1 781 405-7464 927 Email: mrw@painless-security.com 928 URI: http://www.painless-security.com 929 Pierrick Seite (editor) 930 France Telecom - Orange 931 4, rue du clos courtel BP 91226 932 Cesson-Sevigne 35512 933 France 935 Email: pierrick.seite@orange-ftgroup.com