idnits 2.17.1 draft-ietf-mif-current-practices-04.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 21, 2010) is 4934 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 24, 2011 France Telecom - Orange 6 October 21, 2010 8 Current Practices for Multiple Interface Hosts 9 draft-ietf-mif-current-practices-04 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 24, 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 . . . . . . . . . . . . . . . . . . . 17 81 7. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 18 82 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 18 83 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 84 9.1. Normative References . . . . . . . . . . . . . . . . . . . 19 85 9.2. Informative References . . . . . . . . . . . . . . . . . . 19 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 88 1. Introduction 90 Multiple-interface hosts face several challenges not faced by single- 91 interface hosts, some of which are described in the MIF problem 92 statement, [I-D.ietf-mif-problem-statement]. This document 93 summarizes how current implementations deal with the problems 94 identified in the MIF problem statement. 96 Publicly-available information about the multiple-interface solutions 97 implemented in some widely used operating systems, including both 98 mobile handset and desktop operating systems, is collected in this 99 document, including: Nokia S60 [S60], Microsoft Windows Mobile 100 [WINDOWSMOBILE], Blackberry [BLACKBERRY], Google Android [ANDROID], 101 Microsoft Windows, Apple Mac OS X, Linux and BSD-based operating 102 systems. 104 2. Summary of Current Approaches 106 This section summarizes current approaches that are used to resolve 107 the multi-interface issues described in the Multiple Interface 108 Problem Statement [I-D.ietf-mif-problem-statement]. These approaches 109 can be broken down into three major categories: 111 o Centralized connection management 113 o Per-application connection settings 115 o Stack-level solutions to specific problems 117 2.1. Centralized Connection Management 119 It is a common practice for mobile handset operating systems to use a 120 centralized connection manager that performs network interface 121 selection based on application or user input. The information used 122 by the connection manager may be programmed into an application or 123 provisioned on a handset-wide basis. When information is not 124 available to make an interface selection, the connection manager will 125 query the user to choose between available choices. 127 Routing tables are not typically used for network interface selection 128 when a connection manager is in use, as the criteria for network 129 selection is not strictly IP-based but is also dependent on other 130 properties of the interface (cost, type, etc.). Furthermore, 131 multiple overlapping private IPv4 address spaces are often exposed to 132 a multiple-interface host, making it difficult to make interface 133 selection decisions based on prefix matching. 135 2.2. Per Application Connection Settings 137 In mobile handsets, applications are often involved in choosing what 138 interface and related configuration information should be used. In 139 some cases, the application selects the interface directly, and in 140 other cases the application provides more abstract information to a 141 connection manager that makes the final interface choice. 143 2.3. Stack-Level Solutions to Specific Problems 145 In most desktop operating systems, multiple interface problems are 146 dealt with in the stack and related components, based on system- 147 level configuration information, without the benefit of input from 148 applications or users. These solutions tend to map well to the 149 problems listed in the problem statement: 151 o DNS resolution issues 153 o Routing 155 o Address selection policy 157 The configuration information for desktop systems comes from one of 158 three sources: DHCP, proprietary configuration systems or manual 159 configuration. While these systems universally accept IP address 160 assignment on a per-interface basis, they differ in what set of 161 information can be assigned on a per-interface basis and what can be 162 configured only on a per-system basis. 164 When choosing between multiple sets of information provided, these 165 systems will typically give preference to information received on the 166 "primary" interface. The mechanism for designating the "primary" 167 interface differs by system. 169 There is very little commonality in how desktop operating systems 170 handle multiple sets of configuration information, with notable 171 variations between different versions of the same operating system 172 and/or within different software packages built for the same 173 operating system. Although these systems differ widely, it is not 174 clear that any of them provide a completely satisfactory user 175 experience in multiple-interface environments. 177 The following sections discuss some of the solutions used in each of 178 the areas raised in the MIF problem statement. 180 2.3.1. DNS Resolution Issues 182 There is very little commonality in how desktop operating systems 183 handle the DNS server list. Some systems support per-interface DNS 184 server lists, while others only support a single system-wide list. 186 On hosts with per-interface DNS server lists, different mechanisms 187 are used to determine which DNS server is contacted for a given 188 query. In most cases, the first DNS server listed on the "primary" 189 interface is queried first, with back off to other servers if an 190 answer is not received. 192 Systems that support a single system-wide list differ in how they 193 select which DNS server to use in cases where they receive more than 194 one DNS server list to configure (e.g. from DHCP on multiple 195 interfaces). Some accept the information received on the "primary" 196 interface, while others use either the first or last set DNS server 197 list configured. 199 2.3.2. Routing 201 Routing information is also handled differently on different desktop 202 operating systems. While all systems maintain some sort of routing 203 cache, to handle redirects and/or statically configured routes, most 204 packets are routed based on configured default gateway information. 206 Some systems do allow the configuration of different default router 207 lists for different interfaces. These systems will always choose the 208 default gateway on the interface with the lowest routing metric, with 209 different behavior when two or more interfaces have the same routing 210 metric. 212 Most systems do not allow the configuration of more than one default 213 router list, choosing instead to use the first or last default router 214 list configured and/or the router list configured on the "primary" 215 interface. 217 2.3.3. Address Selection Policy 219 There is somewhat more commonality in how desktop hosts handle 220 address selection. Applications typically provide the destination 221 address for an outgoing packet, and the IP stack is responsible for 222 picking the source address. 224 IPv6 specifies a specific source address selection mechanism in 225 [RFC3484], and several systems implement this mechanism with similar 226 support for IPv4. However, many systems do not provide any mechanism 227 to update this default policy, and there is no standard way to do so. 229 In some cases, the routing decision (including which interface to 230 use) is made before source address selection is performed, and a 231 source address is chosen from the outbound interface. In other 232 cases, source address selection is performed before, or independently 233 from outbound interface selection. 235 3. Current Practices in Some Operating Systems 237 The following sections briefly describe the current multiple- 238 interface host implementations on some widely-used operating systems. 239 Please refer to the References section for pointers to original 240 documentation on most of these systems, including further details. 242 3.1. Mobile Handset Operating Systems 244 Cellular devices typically run a variety of applications in parallel, 245 each with different requirements for IP connectivity. A typical 246 scenario is shown in figure 1, where a cellular device is utilizing 247 WLAN access for web browsing and GPRS access for transferring 248 multimedia messages (MMS). Another typical scenario would be a real- 249 time VoIP session over one network interface in parallel with best 250 effort web browsing on another network interface. Yet another 251 typical scenario would be global Internet access through one network 252 interface and local (e.g. corporate VPN) network access through 253 another. 255 Web server MMS Gateway 256 | | 257 -+--Internet---- ----Operator network--+- 258 | | 259 +-------+ +-------+ 260 |WLAN AP| | GGSN | 261 +-------+ +-------+ 262 | +--------+ | 263 +--------|Cellular|--------+ 264 |device | 265 +--------+ 267 A cellular device with two network interfaces 269 Figure 1 271 Different network access technologies require different settings. 272 For example, WLAN requires Service Set Identifier (SSID) and the GPRS 273 network requires the Access Point Name (APN) of the Gateway GPRS 274 Support Node (GGSN), among other parameters. It is common that 275 different accesses lead to different destination networks (e.g. to 276 "Internet", "intranet", cellular network services, etc.). 278 3.1.1. Nokia S60 3rd Edition, Feature Pack 2 280 S60 uses the concept of an Internet Access Point (IAP) [S60] that 281 contains all information required for opening a network connection 282 using a specific access technology. A device may have several IAPs 283 configured for different network technologies and settings (multiple 284 WLAN SSIDs, GPRS APNs, dial-up numbers, and so forth). There may 285 also be 'virtual' IAPs that define parameters needed for tunnel 286 establishment (e.g. for VPN). 288 For each application, a correct IAP needs to be selected at the point 289 when the application requires network connectivity. This is 290 essential, as the wrong IAP may not be able to support the 291 application or reach the desired destination. For example, MMS 292 application must use the correct IAP in order to reach the MMS 293 Gateway, which typically is not accessible from the public Internet. 294 As another example, an application might need to use the IAP 295 associated with its corporate VPN in order to reach internal 296 corporate servers. Binding applications to IAPs avoids several 297 problems, such as choosing the correct DNS server in the presence of 298 split DNS (as an application will use the DNS server list from its 299 bound IAP), and overlapping private IPv4 address spaces used for 300 different interfaces (as each application will use the default routes 301 from its bound IAP). 303 If multiple applications utilize the same IAP, the underlying network 304 connection can typically be shared. This is often the case when 305 multiple Internet-using applications are running in parallel. 307 The IAP for an application can be selected in multiple ways: 309 o Statically: e.g. from a configuration interface, via client 310 provisioning/device management system, or at build-time. 312 o Manually by the user: e.g. each time an application starts the 313 user may be asked to select the IAP to use. This may be needed, 314 for example, if a user sometimes wishes to access his corporate 315 intranet and other times would prefer to access the Internet 316 directly. 318 o Automatically by the system: after the destination network has 319 been selected statically or dynamically. 321 The static approach is fine for certain applications, like MMS, for 322 which configuration can be provisioned by the network operator and 323 does not change often. Manual selection works, but may be seen as 324 troublesome by the user. An automatic selection mechanism needs to 325 have some way of knowing which destination network the user, or an 326 application, is trying access. 328 S60 3rd Edition, Feature Pack 2, introduces a concept of Service 329 Network Access Points (SNAPs) that group together IAPs that lead to 330 the same destination. This enables static or manual selection of the 331 destination network for an application and leaves the problem of 332 selecting the best of the available IAPs within a SNAP to the 333 operating system. 335 When SNAPs are used, it is possibly for the operating system to 336 notify applications when a preferred IAP, leading to the same 337 destination, becomes available (for example, when a user comes within 338 range of his home WLAN access point), or when the currently used IAP 339 is no longer available and applications have to reconnect via another 340 IAP (for example, when a user goes out of range of his home WLAN and 341 must move to the cellular network). 343 Please see the source documentation for more details and screenshots: 344 [S60]. 346 3.1.2. Microsoft Windows Mobile 2003 Second Edition 348 A Connection Manager architecture is described in [WINDOWSMOBILE]. 349 This architecture centralizes and automates network connection 350 establishment and management, and makes it possible to automatically 351 select a connection, to dial-in automatically or by user initiation, 352 and to optimize connection and shared resource usage. Connection 353 Manager periodically re-evaluates the validity of the connection 354 selection. The Connection Manager uses various attributes such as 355 cost, security, bandwidth, error rate, and latency in its decision 356 making. 358 The Connection Manager selects the best possible connection for the 359 application based on the destination network the application wishes 360 to reach. The selection is made between available physical and 361 virtual connections (e.g. VPN, GPRS, WLAN, and wired Ethernet) that 362 are known to provide connectivity to the destination network, and the 363 selection is based on the costs associated with each connection. 364 Different applications are bundled to use the same network connection 365 when possible, but in conflict situations when a connection cannot be 366 shared, higher priority applications take precedence, and the lower 367 priority applications lose connectivity until the conflict situation 368 clears. 370 During operation, Connection Manager opens new connections as needed, 371 and also disconnects unused or idle connections. 373 To optimize resource use, such as battery power and bandwidth, 374 Connection Manager enables applications to synchronize network 375 connection usage by allowing applications to register their 376 requirements for periodic connectivity. An application is notified 377 when a suitable connection becomes available for its use. 379 3.1.3. Window Phone 7 381 In comparison to Windows Mobile 2003 SE, Windows phone 7 brings 382 update of the routing functionality in the case where the terminal 383 can be attached simultaneously to several interfaces. Actually, 384 Windows Phone 7 routes the traffic through a preferred interface, 385 which has a lower metric. When there are multiple interfaces, the 386 applications system will, by default, choose from an ordered list of 387 available interfaces. The default connection policy will prefer 388 wired over wireless and WLAN over cellular. Hence, if an application 389 wants to use cellular 3G as the active interface when WLAN is 390 available, the application needs to override the default connection 391 mapping policy. An application specific mapping policy can be set 392 via API or provisioned by the Mobile Operator. The application, in 393 compliance with the security model, can request connection type by 394 interface (WLAN, cellular), by minimum interface speed (x kbps, y 395 mbps), or by name (Access Point Name). 397 3.1.4. BlackBerry 399 Depending on the network configuration, Java applications in 400 BlackBerry devices [BLACKBERRY] can use can use direct TCP/IP 401 connectivity or different application proxys to establish connections 402 over the wireless network. For instance, some wireless service 403 providers provide an Internet gateway to offer direct TCP/IP 404 connectivity to the Internet while some others can provide a WAP 405 gateway that allows HTTP connections to occur over the WAP (Wireless 406 Application Protocol) protocol. It is also possible to use the 407 BlackBerry Enterprise Server [BLACKBERRY] as a network gateway, The 408 BlackBerry Enterprise Server provides an HTTP and TCP/IP proxy 409 service to allow the application to use it as a secure gateway for 410 managing HTTP and TCP/IP connections to the intranet or the Internet. 411 An application connecting to the Internet, can use either the 412 BlackBerry Internet Service or the Internet gateway of the wireless 413 server provider to manage connections. The problem of gateway 414 selection is supposed to be managed independently by each Java 415 application. For instance, an application can be designed to always 416 use the default Internet gateway, while another application can be 417 designed to use a preferred proxy when available. 419 A BlackBerry device [BLACKBERRY] can be attached to multiple networks 420 simultaneously (wireless/wired). In this case, Multiple network 421 interfaces can be associated to a single IP stack or multiple IP 422 stacks. The device, or the application, can select the network 423 interface to be used in various ways. For instance, the device can 424 always map the applications to the default network interface (or the 425 default access network). When muliple IP stacks are associated to 426 multiple interfaces, the application can select the source address 427 correponding to the preferred network interface. When multiple 428 network interfaces are aggregated into a single IP stack, the device 429 associates each application to the more appropriate network 430 interface. The selection can be based on cost, type-of-service 431 and/or user preference. 433 3.1.5. Google Android 435 The Android reference documentation describes the android.net package 436 [ANDROID] and the ConnectivityManager class that applications can use 437 to request a route to a specified destination address via a specified 438 network interface (3GPP or WLAN). Applications also ask Connection 439 Manager for permission to start using a network feature. The 440 Connectivity Manager monitors changes in network connectivity and 441 attempts to failover to another network if connectivity to an active 442 network is lost. When there are changes in network connectivity, 443 applications are notified. Applications are also able to ask for 444 information about all network interfaces, including their 445 availability, type and other information. 447 Depending on vendors implementation, applications may be bound to use 448 one network type at a time. For example, on a 3G/WLAN HTC Dream 449 (Android 1.5), web browsing uses only the WLAN access when both 3G 450 and WLAN are available. However different applications can use 451 different access at the same time. For instance, the HTC Dream can 452 utilize WLAN access for web browsing and GPRS access for transferring 453 multimedia messages (MMS). 455 3.1.6. Qualcomm Brew 457 This section describes how multi-interface support is handled by 458 Advanced Mobile Station Software (AMSS) that comes with Brew OS for 459 all Qualcomm chipsets (e.g., MSM, Snapdragon etc). AMSS is a low 460 level connectivity platform, on top of which manufacturers can build 461 to provide the necessary connectivity to applications. The 462 interaction model between AMSS, the Operating System, and the 463 applications is not unique and depend on the design chosen by the 464 manufacturer. The Mobile OS can let an application invoke the AMSS 465 directly (via API), or provide its own connection manager that will 466 request connectivity to the AMSS based on applications needs. The 467 interaction between the OS connection manager and the applications is 468 OS dependent. 470 AMSS supports a concept of netpolicy which allows each application to 471 specify the type of network connectivity desired. The netpolicy 472 contains parameters such as access technology, IP version type and 473 network profile. Access technology could be a specific technology 474 type such as CDMA or WLAN or could be a group of technologies, such 475 as ANY_Cellular or ANY_Wireless. IP version could be one of IPv4, 476 IPv6 or Default. The network profile identifies a type of network 477 domain or service within a certain network technology, such as 3GPP 478 APN or Mobile IP Home Agent. It also specifies all the mandatory 479 parameters required to connect to the domain such authentication 480 credentials and other optional parameters such as QoS attributes. 481 Network Profile is technology specific and set of parameters 482 contained in the profile could vary for different technologies. 484 Two models of network usage are supported: 486 o Applications requiring network connectivity specify an appropriate 487 netpolicy in order to select the desired network. The netpolicy 488 may match one or more network interfaces. AMSS system selection 489 module selects the best interface out of the ones that match the 490 netpolicy based on various criteria such as cost, speed or other 491 provisioned rules. Application explicitly starts the selected 492 network interface and, as a result, the application also gets 493 bound to the corresponding network interface. All outbound 494 packets from this application are always routed over this bound 495 interface using the source address of the interface. 497 o Applications may rely on a separate connection manager to control 498 (e.g. start/stop) the network interface. In this model, 499 applications are not necessarily bound to any one interface. All 500 outbound packets from such applications are routed on one of the 501 interfaces that match its netpolicy. The routing decision is made 502 individually for each packet and selects the best interface based 503 on the criteria described above and the destination address. 504 Source address is always that assigned to the interface used to 505 transmit the packet. 507 All of the routing/interface selection decisions are based on the 508 netpolicy and not just on the destination address to avoid 509 overlapping private IPv4 address issue. This also allows multiple 510 interfaces to be configured with the same IP address, for example, to 511 handle certain tunnelling scenarios. Applications that do not 512 specify a netpolicy are routed by AMSS to the best possible interface 513 using the default netpolicy. Default netpolicy could be pre-defined 514 or provisioned by the administrator or operator. Hence default 515 interface could vary from device to device and also depends upon the 516 available networks at any given time. 518 AMSS allows each interface to be configured with its own set of DNS 519 configuration parameters (e.g. list of DNS servers, domain names 520 etc.). Interface selected to make a DNS resolution is the one to 521 which application making the DNS query is bound. Applications can 522 also specify a different netpolicy as part of DNS request to select 523 another interface for DNS resolution. Regardless, all the DNS 524 queries are sent only over this selected interface using the DNS 525 configuration from the interface. DNS resolution is first attempted 526 with the primary server configured in the interface. If a response 527 is not received, the queries are sent to all the other servers 528 configured in the interface in a sequential manner using a backoff 529 mechanism. 531 3.1.7. Arena Connection Manager 533 Arena, a mobile OS based on Linux, provides a Connection Manager, 534 which is described in [I-D.zhang-mif-connection-manager-arena] and 535 [I-D.yang-mif-connection-manager-impl-req]. The arena connection 536 manager provides a means for applications to register their 537 connectivity requirement. The Connection Manager can then choose an 538 interface that matches the application's needs while considering 539 other factors such as availability, cost and stability. Also, the 540 Connection Manager can handle multi-interface issues such as 541 connection sharing. 543 3.1.8. Access selection 545 This section describes the behavior of connection managers in 546 presence of multiple points of attachment for a same interface. The 547 section focuses on WLAN interface, it is described how does the 548 connection manager deal with the list of preferred SSID and how does 549 it select the SSID for attachment. Current implementation of 550 connection managers are considered for the following handsets: LG 551 Pathfinder, HTC Android, RIM BlackBerry , iPhone (3G and 3GS). 553 When the terminal is under coverage of different WLAN networks with 554 different SSIDs: 556 connection managers, excepted for the RIM Blackberry, construct 557 the list of preferred SSID giving priority to the last SSID on 558 which they have managed to attach. The user is not allowed to 559 define its preferred access. So, if the terminal discovers and 560 manages to attach to SSID1, SSID1 becomes the preferred access for 561 future attachment. If the terminal moves out of SSID1 coverage 562 and attaches to a new SSID, SSID2. SSID2 will then be the 563 preferred access of the connection manager. Then, if the terminal 564 processes to WLAN attachment within both SSID1 and SSID2 coverage, 565 the connection manager will select SSID2 for attachment. The RIM 566 Blackberry behaves differently, the connection manager selects the 567 first SSID on which it has managed to attach in the past. 569 All connection managers behave in the same way when the terminals 570 fails to attach to the selected SSID: the connection manager 571 automatically selects the second SSID in the list of preferred 572 SSID. Fallback come into play at expiration of a timeout from few 573 seconds to about 3 minutes. 575 When the IP stack fails to obtain an IP address, the handset, 576 excepted the iPhone, restarts WLAN attachment selecting the second 577 SSID in the list. 579 When the terminal receives signals from different point of attachment 580 with same SSID: 582 The connection manager selects the point of attachment with best 583 signal strength; no other criteria (e.g. MAC address) is taken 584 into account. If the handset fails to attach to the selected 585 point of attachment (e.g. due to L2 authentication failure), the 586 connection manager selects the point of attachment with lower 587 signal strength. However, this fallback is not supported on the 588 LG pathfinder. If no more points of attachment (corresponding to 589 the preferred SSID) are available, the connection manager selects 590 the second SSID in the list of preferred SSID. 592 Whatever is the handset, fallback on L3 attachment failure is not 593 supported if the terminal remains under coverage of the same WLAN 594 access point. Actually, the connection manager always selects the 595 most powerful signal strength without considering IP configuration 596 results. In other words, if the terminal is unable to set up the 597 IP connectivity on one WLAN access, the connection manager will 598 not try to attach to an alternative point of attachment (or SSID) 599 as long as the signal strength of the first radio link is the most 600 powerful. Situation is not the same for mobile terminal since the 601 signal strength of the alternative point of attachment could 602 become better while the terminal is moving. If so, the terminal 603 automatically restarts IP connectivity process (excepted the HTC 604 Magic which requires the user to manually restart the L3 605 attachment). 607 3.2. Desktop Operating Systems 609 Multi-interface issues also occur in desktop environments in those 610 cases where a desktop host has multiple (logical or physical) 611 interfaces connected to networks with different reachability 612 properties, such as one interface connected to the global Internet, 613 while another interface is connected to a corporate VPN. 615 3.2.1. Microsoft Windows 617 The multi-interface functionality currently implemented in Microsoft 618 Windows operation systems is described in more detail in 619 [I-D.montenegro-mif-multihoming]. 621 3.2.1.1. Routing 623 It is possible, although not often desirable, to configure default 624 routers on more than one Windows interface. In this configuration, 625 Windows will use the default route on the interface with the lowest 626 routing metric (i.e. the fastest interface). If multiple interfaces 627 share the same metric, the behavior will differ based on the version 628 of Windows in use. Prior to Windows Vista, the packet would be 629 routed out of the first interface that was bound to the TCP/IP stack, 630 the preferred interface. In Windows vista, host-to-router load 631 sharing [RFC4311] is used for both IPv4 and IPv6. 633 3.2.1.2. Outbound and Inbound Addresses 635 If the source address of the outgoing packet has not been determined 636 by the application, Windows will choose from the addresses assigned 637 to its interfaces. Windows implements [RFC3484] for source address 638 selection in IPv6 and, in Windows Vista, for IPv4. Prior to Windows 639 Vista, IPv4 simply chose the first address on the outgoing interface. 641 For incoming packets, Windows will check if the destination address 642 matches one of the addresses assigned to its interfaces. Windows has 643 implemented the weak host model [RFC1122] on IPv4 in Windows 2000, 644 Windows XP and Windows Server 2003. The strong host model became the 645 default for IPv4 in Windows Vista and Windows server 2008, however 646 the weak host model is available via per-interface configuration. 647 IPv6 has always implemented the strong host model. 649 3.2.1.3. DNS Configuration 651 Windows largely relies on suffixes to solve DNS resolution issues. 652 Suffixes are used for four different purposes that are reminded 653 hereafter: 655 1. DNS Suffix Search List (aka domain search list): suffix is added 656 to non-FQDN names. 658 2. Interface-specific suffix list, which allows sending different 659 DNS queries to different DNS servers. 661 3. Suffix to control Dynamic DNS Updates: determine which DNS server 662 will receive a dynamic update for a name with a certain suffix. 664 4. Suffix in the Name Resolution Policy Table [NRPT] to aid in 665 identifying a Namespace that requires special handling (feature 666 available only after Windows 7 and its server counterpart, 667 Windows Server 2008 R2). 669 However, this section focuses on the interface-specific suffix list 670 since it is the only suffix usage in the scope of MIF. 672 DNS configuration information can be host-wide or interface specific. 673 Host-wide DNS configuration is input via static configuration or, in 674 sites that use Active Directory, Microsoft's Group Policy. Interface 675 specific DNS configuration can be input via static configuration or 676 via DHCP. 678 The host-wide configuration consists of a primary DNS suffix to be 679 used for the local host, as well as a list of suffix that can be 680 appended to names being queried. Before Windows Vista and Windows 681 Server 2008, there was also a host-wide DNS server list that took 682 precedent over per-interface DNS configuration. 684 The interface-specific DNS configuration comprises an interface- 685 specific suffix list and a list of DNS server IP addresses. 687 Windows uses a host-wide "effective" server list for an actual query, 688 where the effective server list may be different for different names. 689 In the list of DNS server addresses, the first server is considered 690 the "primary" server, with all other servers being secondary. 692 When a DNS query is performed in Windows, the query is first sent to 693 the primary DNS server on the preferred interface. If no response is 694 received in one second, the query is sent to the primary DNS servers 695 on all interfaces under consideration. If no response is received 696 for 2 more seconds, the DNS server sends the query to all of the DNS 697 servers on the DNS server lists for all interfaces under 698 consideration. If the host still doesn't receive a response after 4 699 seconds, it will send to all of the servers again and wait 8 seconds 700 for a response. 702 3.2.2. Linux and BSD-based Operating Systems 704 Most BSD and Linux distributions rely on their DHCP client to handle 705 the configuration of interface-specific information (such as an IP 706 address and netmask), and a set of system-wide configuration 707 information, (such a DNS server list, an NTP server list and default 708 routes). Users of these operating systems have the choice of using 709 any DHCP client available for their platform, with an operating 710 system default. This section discusses the behavior of several DHCP 711 clients that may be used with Linux and BSD distributions. 713 The Internet Systems Consortium (ISC) DHCP Client [ISCDHCP] and its 714 derivative for OpenBSD [OPENBSDDHCLIENT] can be configured with 715 specific instructions for each interface. However, each time new 716 configuration data is received by the host from a DHCP server, 717 regardless of which interface it is received on, the DHCP client 718 rewrites the global configuration data, such as the default routes 719 and the DNS server list (in /etc/resolv.conf) with the most recent 720 information received. Therefore, the last configured interface 721 always become the primary one. The ISC DHCPv6 client behaves 722 similarly. 724 The Phystech dhcpcd client [PHYSTECHDHCPC] behaves similarly to the 725 ISC client. It replaces the DNS server list in /etc/resolv.conf and 726 the default routes each time new DHCP information is received on any 727 interface. However, the -R flag can be used to instruct the client 728 to not replace the DNS servers in /etc/resolv.conf. However, this 729 flag is a global flag for the DHCP server, and is therefore 730 applicable to all interfaces. When dhcpd is called with the -R flag, 731 the DNS servers are never replaced. 733 The pump client [PUMP] also behaves similarly to the ISC client. It 734 replaces the DNS servers in /etc/resolv.conf and the default routes 735 each time new DHCP information is received on any interface. 736 However, the nodns and nogateway options can be specified on a per 737 interface basis, enabling the user to define which interface should 738 be used to obtain the global configuration information. 740 The udhcp client [UDHCP] is often used in embedded platforms based on 741 busybox. The udhcp client behaves similarly to the ISC client. It 742 rewrites default routes and the DNS server list each time new DHCP 743 information is received. 745 Redhat-based distributions, such as Redhat, Centos and Fedora have a 746 per-interface configuration option (PEERDNS) that indicates that the 747 DNS server list should not be updated based on configuration received 748 on that interface. 750 The most configurable DHCP clients can be set to define a primary 751 interface to use only that interface for the global configuration 752 data. However, this is limited, since a mobile host might not always 753 have the same set of interfaces available. Connection managers may 754 help in this situation. 756 Some distributions also have a connection manager. However, most 757 connection managers serve as a GUI to the DHCP client, therefore not 758 changing the functionality described above. 760 3.2.3. Apple Mac OS X 762 This section is based on testing Mac OS X (version 10.5.6). 764 When using multiple interfaces on Mac OS X, global configuration data 765 such as default routes and the DNS server list are taken from the 766 DHCP data received on the primary interface. Therefore, the order in 767 which the interfaces receive their configuration data is not 768 relevant. For example, if the primary interface receives its 769 configuration data first, then the second interface receives its 770 configuration data, the interface-specific information for the second 771 interface will be configured, but the global configuration 772 information such as the DNS server list and default routes is not 773 overwritten. 775 4. Acknowledgements 777 Authors of the document would like to thank following people for 778 their input and feedback: Dan Wing, Hui Deng, Jari Arkko, Julien 779 Laganier. 781 5. IANA Considerations 783 This memo includes no request to IANA. 785 6. Security Considerations 787 This document describes current operating system implementations and 788 how they handle the issues raised in the MIF problem statement. 789 While it is possible that the currently implemented mechanisms 790 described in this document may affect the security of the systems 791 described, this document merely reports on current practice. It does 792 not attempt to analyze the security properties (or any other 793 architectural properties) of the currently implemented mechanisms. 795 7. Change Log 797 The following changes were made between versions -00 and -02: 799 o Added information on usage of suffix with Windows. 801 o new section describing Qualcomm AMSS/Brew Multi-interface handling 803 o Considerations on access selection for some current connection 804 managers. 806 o Added information on multiple-interface scenarios with Google 807 Android. 809 o Clarifications on Arena connection manager 811 o Clarifications on multiple interface handling with RIM blackberry. 813 o Added new contributors. 815 8. Contributors 817 The following people contributed most of the per-Operating System 818 information found in this document: 820 o Marc Blanchet, Viagenie 822 o Hua Chen, Leadcoretech, Ltd. 824 o Yan Zhang, Leadcoretech Ltd. 826 o Shunan Fan, Huawei Technology 828 o Jian Yang, Huawei Technology 830 o Gabriel Montenegro, Microsoft Corporation 832 o Shyam Seshadri, Microsoft Corporation 834 o Dave Thaler, Microsoft Corporation 836 o Kevin Chin, Microsoft Corporation 838 o Teemu Savolainen, Nokia 840 o Tao Sun, China Mobile 841 o George Tsirtsis, Qualcomm. 843 o David Freyermuth, France telecom. 845 o Aurelien Collet, Altran. 847 o Giyeong Son, RIM. 849 9. References 851 9.1. Normative References 853 [I-D.ietf-mif-problem-statement] 854 Blanchet, M. and P. Seite, "Multiple Interfaces Problem 855 Statement", draft-ietf-mif-problem-statement-07 (work in 856 progress), August 2010. 858 9.2. Informative References 860 [ANDROID] Google Inc., "Android developers: package android.net", 861 2009, . 864 [BLACKBERRY] 865 Research In Motion Limited, "BlackBerry Java Development 866 Environment - Fundamentals Guide: Wireless gateways", 867 2009, . 870 [I-D.montenegro-mif-multihoming] 871 Montenegro, G., Thaler, D., and S. Seshadri, "Multiple 872 Interfaces on Windows", 873 draft-montenegro-mif-multihoming-00 (work in progress), 874 March 2009. 876 [I-D.yang-mif-connection-manager-impl-req] 877 Yang, J., Sun, T., and S. Fan, "Multi-interface Connection 878 Manager Implementation and Requirements", 879 draft-yang-mif-connection-manager-impl-req-00 (work in 880 progress), March 2009. 882 [I-D.zhang-mif-connection-manager-arena] 883 Zhang, Y., Sun, T., and H. Chen, "Multi-interface Network 884 Connection Manager in Arena Platform", 885 draft-zhang-mif-connection-manager-arena-00 (work in 886 progress), February 2009. 888 [ISCDHCP] Internet Software Consortium, "ISC DHCP", 2009, 889 . 891 [NRPT] Windows, "Name Resolution Policy Table", February 2010, < 892 http://technet.microsoft.com/en-us/magazine/ 893 ff394369.aspx>. 895 [OPENBSDDHCLIENT] 896 OpenBSD, "OpenBSD dhclient", 2009, 897 . 899 [PHYSTECHDHCPC] 900 Phystech, "dhcpcd", 2009, 901 . 903 [PUMP] RedHat, "PUMP", 2009, . 905 [RFC1122] Braden, R., "Requirements for Internet Hosts - 906 Communication Layers", STD 3, RFC 1122, October 1989. 908 [RFC3484] Draves, R., "Default Address Selection for Internet 909 Protocol version 6 (IPv6)", RFC 3484, February 2003. 911 [RFC4311] Hinden, R. and D. Thaler, "IPv6 Host-to-Router Load 912 Sharing", RFC 4311, November 2005. 914 [S60] Nokia Corporation, "S60 Platform: IP Bearer Management", 915 2007, . 919 [UDHCP] Busybox, "uDHCP", 2009, . 922 [WINDOWSMOBILE] 923 Microsoft Corporation, "SDK Documentation for Windows 924 Mobile-Based Smartphones: Connection Manager", 2005, 925 . 927 Authors' Addresses 929 Margaret Wasserman (editor) 930 Painless Security, LLC 931 356 Abbott Street 932 North Andover, MA 01845 933 USA 935 Phone: +1 781 405-7464 936 Email: mrw@painless-security.com 937 URI: http://www.painless-security.com 939 Pierrick Seite (editor) 940 France Telecom - Orange 941 4, rue du clos courtel BP 91226 942 Cesson-Sevigne 35512 943 France 945 Email: pierrick.seite@orange-ftgroup.com