idnits 2.17.1 draft-ietf-mif-current-practices-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- 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 (June 28, 2010) is 5050 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-04 -- 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: December 30, 2010 France Telecom - Orange 6 June 28, 2010 8 Current Practices for Multiple Interface Hosts 9 draft-ietf-mif-current-practices-02 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 December 30, 2010. 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. BlackBerry . . . . . . . . . . . . . . . . . . . . . . 9 66 3.1.4. Google Android . . . . . . . . . . . . . . . . . . . . 9 67 3.1.5. Qualcomm Brew . . . . . . . . . . . . . . . . . . . . 10 68 3.1.6. Arena Connection Manager . . . . . . . . . . . . . . . 11 69 3.1.7. Access selection . . . . . . . . . . . . . . . . . . . 11 70 3.2. Desktop Operating Systems . . . . . . . . . . . . . . . . 13 71 3.2.1. Microsoft Windows . . . . . . . . . . . . . . . . . . 13 72 3.2.1.1. Routing . . . . . . . . . . . . . . . . . . . . . 13 73 3.2.1.2. Outbound and Inbound Addresses . . . . . . . . . . 13 74 3.2.1.3. DNS Configuration . . . . . . . . . . . . . . . . 14 75 3.2.2. Linux and BSD-based Operating Systems . . . . . . . . 15 76 3.2.3. Apple Mac OS X . . . . . . . . . . . . . . . . . . . . 16 77 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 78 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 79 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 80 7. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 17 81 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 17 82 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 83 9.1. Normative References . . . . . . . . . . . . . . . . . . . 18 84 9.2. Informative References . . . . . . . . . . . . . . . . . . 18 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 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. BlackBerry 380 In BlackBerry devices [BLACKBERRY] Java applications can use one of 381 two wireless gateways to proxy the connection to the Internet or to a 382 corporate network. The application can be designed to always use the 383 default Internet gateway, or to use a more preferred enterprise 384 gateway when available. The intent is to hide connectivity issues 385 from users. 387 A BlackBerry device [BLACKBERRY] can access different destinations 388 using multiple access (wireless/wired) networks simultaneously. A 389 device can also access the same destination using multiple access 390 networks simultaneously. The device can select the network interface 391 to be used in various ways. For instance, it can use the default 392 network interface (or the default access network) or choose from 393 available active network interfaces based on cost, type-of-service 394 and/or use preference. Multiple network interfaces can be associated 395 with a single IP stack or multiple IP stacks. 397 3.1.4. Google Android 399 The Android reference documentation describes the android.net package 400 [ANDROID] and the ConnectivityManager class that applications can use 401 to request a route to a specified destination address via a specified 402 network interface (3GPP or Wifi). Applications also ask Connection 403 Manager for permission to start using a network feature. The 404 Connectivity Manager monitors changes in network connectivity and 405 attempts to failover to another network if connectivity to an active 406 network is lost. When there are changes in network connectivity, 407 applications are notified. Applications are also able to ask for 408 information about all network interfaces, including their 409 availability, type and other information. 411 Applications are bound to use one network type at a time. For 412 example, on a 3G/Wifi HTC Dream (Android 1.5), web browsing uses only 413 the Wifi access when both 3G and WiFi are available. However 414 different applications can use different access at the same time. 415 For instance, the HTC Dream can utilize WLAN access for web browsing 416 and GPRS access for transferring multimedia messages (MMS). 418 3.1.5. Qualcomm Brew 420 This section describes how multi-interface support is handled by 421 Advanced Mobile Station Software (AMSS) that comes with Brew OS for 422 all Qualcomm chipsets (e.g., MSM, Snapdragon etc). AMSS is a low 423 level connectivity platform, on top of which manufacturers can build 424 to provide the necessary connectivity to applications. The 425 interaction model between AMSS, the Operating System, and the 426 applications is not unique and depend on the design chosen by the 427 manufacturer. The Mobile OS can let an application invoke the AMSS 428 directly (via API), or provide its own connection manager that will 429 request connectivity to the AMSS based on applications needs. The 430 interaction between the OS connection manager and the applications is 431 OS dependent. 433 AMSS supports a concept of netpolicy which allows each application to 434 specify the type of network connectivity desired. The netpolicy 435 contains parameters such as access technology, IP version type and 436 network profile. Access technology could be a specific technology 437 type such as CDMA or WiFi or could be a group of technologies, such 438 as ANY_Cellular or ANY_Wireless. IP version could be one of IPv4, 439 IPv6 or Default. The network profile identifies a type of network 440 domain or service within a certain network technology, such as 3GPP 441 APN or Mobile IP Home Agent. It also specifies all the mandatory 442 parameters required to connect to the domain such authentication 443 credentials and other optional parameters such as QoS attributes. 444 Network Profile is technology specific and set of parameters 445 contained in the profile could vary for different technologies. 447 Two models of network usage are supported: 449 o Applications requiring network connectivity specify an appropriate 450 netpolicy in order to select the desired network. The netpolicy 451 may match one or more network interfaces. AMSS system selection 452 module selects the best interface out of the ones that match the 453 netpolicy based on various criteria such as cost, speed or other 454 provisioned rules. Application explicitly starts the selected 455 network interface and, as a result, the application also gets 456 bound to the corresponding network interface. All outbound 457 packets from this application are always routed over this bound 458 interface using the source address of the interface. 460 o Applications may rely on a separate connection manager to control 461 (e.g. start/stop) the network interface. In this model, 462 applications are not necessarily bound to any one interface. All 463 outbound packets from such applications are routed on one of the 464 interfaces that match its netpolicy. The routing decision is made 465 individually for each packet and selects the best interface based 466 on the criteria described above and the destination address. 467 Source address is always that assigned to the interface used to 468 transmit the packet. 470 All of the routing/interface selection decisions are based on the 471 netpolicy and not just on the destination address to avoid 472 overlapping private IPv4 address issue. This also allows multiple 473 interfaces to be configured with the same IP address, for example, to 474 handle certain tunnelling scenarios. Applications that do not 475 specify a netpolicy are routed by AMSS to the best possible interface 476 using the default netpolicy. Default netpolicy could be pre-defined 477 or provisioned by the administrator or operator. Hence default 478 interface could vary from device to device and also depends upon the 479 available networks at any given time. 481 AMSS allows each interface to be configured with its own set of DNS 482 configuration parameters (e.g. list of DNS servers, domain names 483 etc.). Interface selected to make a DNS resolution is the one to 484 which application making the DNS query is bound. Applications can 485 also specify a different netpolicy as part of DNS request to select 486 another interface for DNS resolution. Regardless, all the DNS 487 queries are sent only over this selected interface using the DNS 488 configuration from the interface. DNS resolution is first attempted 489 with the primary server configured in the interface. If a response 490 is not received, the queries are sent to all the other servers 491 configured in the interface in a sequential manner using a backoff 492 mechanism. 494 3.1.6. Arena Connection Manager 496 Arena, a mobile OS based on Linux, provides a Connection Manager, 497 which is described in [I-D.zhang-mif-connection-manager-arena] and 498 [I-D.yang-mif-connection-manager-impl-req]. The arena connection 499 manager provides a means for applications to register their 500 connectivity requirement. The Connection Manager can then choose an 501 interface that matches the application's needs while considering 502 other factors such as availability, cost and stability. Also, the 503 Connection Manager can handle multi-interface issues such as 504 connection sharing. 506 3.1.7. Access selection 508 This section describes the behavior of connection managers in 509 presence of multiple points of attachment for a same interface. The 510 section focuses on Wifi interface, it is described how does the 511 connection manager deal with the list of preferred SSID and how does 512 it select the SSID for attachment. Current implementation of 513 connection managers are considered for the following handsets: LG 514 Pathfinder, HTC Android, RIM BlackBerry , iPhone (3G and 3GS). 516 When the terminal is under coverage of different WiFi networks with 517 different SSIDs: 519 connection managers, excepted for the RIM Blackberry, construct 520 the list of preferred SSID giving priority to the last SSID on 521 which they have managed to attach. The user is not allowed to 522 define its preferred access. So, if the terminal discovers and 523 manages to attach to SSID1, SSID1 becomes the preferred access for 524 future attachment. If the terminal moves out of SSID1 coverage 525 and attaches to a new SSID, SSID2. SSID2 will then be the 526 preferred access of the connection manager. Then, if the terminal 527 processes to Wifi attachment within both SSID1 and SSID2 coverage, 528 the connection manager will select SSID2 for attachment. The RIM 529 Blackberry behaves differently, the connection manager selects the 530 first SSID on which it has managed to attach in the past. 532 All connection managers behave in the same way when the terminals 533 fails to attach to the selected SSID: the connection manager 534 automatically selects the second SSID in the list of preferred 535 SSID. Fallback come into play at expiration of a timeout from few 536 seconds to about 3 minutes. 538 When the IP stack fails to obtain an IP address, the handset, 539 excepted the Iphone, restarts Wifi attachment selecting the second 540 SSID in the list. 542 When the terminal receives signals from different point of attachment 543 with same SSID: 545 The connection manager selects the point of attachment with best 546 signal strength; no other criteria (e.g. MAC address) is taken 547 into account. If the handset fails to attach to the selected 548 point of attachment (e.g. due to L2 authentication failure), the 549 connection manager selects the point of attachment with lower 550 signal strength. However, this fallback is not supported on the 551 LG pathfinder. If no more points of attachment (corresponding to 552 the preferred SSID) are available, the connection manager selects 553 the second SSID in the list of preferred SSID. 555 Whatever is the handset, fallback on L3 attachment failure is not 556 supported for motionless terminals. Actually, the connection 557 manager always selects the most powerful signal strength without 558 considering IP configuration results. In other words, if the 559 terminal is unable to set up the IP connectivity on one wifi 560 access, the connection manager will not try to attach to an 561 alternative point of attachment (or SSID) as long as the signal 562 strength of the first radio link is the most powerful. Situation 563 is not the same for mobile terminal since the signal strength of 564 the alternative point of attachment could become better while the 565 terminal is moving. If so, the terminal automatically restarts IP 566 connectivity process (excepted the HTC Magic which requires the 567 user to manually restart the L3 attachment). 569 3.2. Desktop Operating Systems 571 Multi-interface issues also occur in desktop environments in those 572 cases where a desktop host has multiple (logical or physical) 573 interfaces connected to networks with different reachability 574 properties, such as one interface connected to the global Internet, 575 while another interface is connected to a corporate VPN. 577 3.2.1. Microsoft Windows 579 The multi-interface functionality currently implemented in Microsoft 580 Windows operation systems is described in more detail in 581 [I-D.montenegro-mif-multihoming]. 583 3.2.1.1. Routing 585 It is possible, although not often desirable, to configure default 586 routers on more than one Windows interface. In this configuration, 587 Windows will use the default route on the interface with the lowest 588 routing metric (i.e. the fastest interface). If multiple interfaces 589 share the same metric, the behavior will differ based on the version 590 of Windows in use. Prior to Windows Vista, the packet would be 591 routed out of the first interface that was bound to the TCP/IP stack, 592 the preferred interface. In Windows vista, host-to-router load 593 sharing [RFC4311] is used for both IPv4 and IPv6. 595 3.2.1.2. Outbound and Inbound Addresses 597 If the source address of the outgoing packet has not been determined 598 by the application, Windows will choose from the addresses assigned 599 to its interfaces. Windows implements [RFC3484] for source address 600 selection in IPv6 and, in Windows Vista, for IPv4. Prior to Windows 601 Vista, IPv4 simply chose the first address on the outgoing interface. 603 For incoming packets, Windows will check if the destination address 604 matches one of the addresses assigned to its interfaces. Windows has 605 implemented the weak host model [RFC1122] on IPv4 in Windows 2000, 606 Windows XP and Windows Server 2003. The strong host model became the 607 default for IPv4 in Windows Vista and Windows server 2008, however 608 the weak host model is available via per-interface configuration. 609 IPv6 has always implemented the strong host model. 611 3.2.1.3. DNS Configuration 613 Windows largely relies on suffixes to solve DNS resolution issues. 614 Suffixes are used for four different purposes that are reminded 615 hereafter: 617 1. DNS Suffix Search List (aka domain search list): suffix is added 618 to non-FQDN names. 620 2. Interface-specific suffix list, which allows sending different 621 DNS queries to different DNS servers. 623 3. Suffix to control Dynamic DNS Updates: determine which DNS server 624 will receive a dynamic update for a name with a certain suffix. 626 4. Suffix in the Name Resolution Policy Table [NRPT] to aid in 627 identifying a Namespace that requires special handling (feature 628 available only after Windows 7 and its server counterpart, 629 Windows Server 2008 R2). 631 However, this section focuses on the interface-specific suffix list 632 since it is the only suffix usage in the scope of MIF. 634 DNS configuration information can be host-wide or interface specific. 635 Host-wide DNS configuration is input via static configuration or, in 636 sites that use Active Directory, Microsoft's Group Policy. Interface 637 specific DNS configuration can be input via static configuration or 638 via DHCP. 640 The host-wide configuration consists of a primary DNS suffix to be 641 used for the local host, as well as a list of suffix that can be 642 appended to names being queried. Before Windows Vista and Windows 643 Server 2008, there was also a host-wide DNS server list that took 644 precedent over per-interface DNS configuration. 646 The interface-specific DNS configuration comprises an interface- 647 specific suffix list and a list of DNS server IP addresses. 649 Windows uses a host-wide "effective" server list for an actual query, 650 where the effective server list may be different for different names. 651 In the list of DNS server addresses, the first server is considered 652 the "primary" server, with all other servers being secondary. 654 When a DNS query is performed in Windows, the query is first sent to 655 the primary DNS server on the preferred interface. If no response is 656 received in one second, the query is sent to the primary DNS servers 657 on all interfaces under consideration. If no response is received 658 for 2 more seconds, the DNS server sends the query to all of the DNS 659 servers on the DNS server lists for all interfaces under 660 consideration. If the host still doesn't receive a response after 4 661 seconds, it will send to all of the servers again and wait 8 seconds 662 for a response. 664 3.2.2. Linux and BSD-based Operating Systems 666 Most BSD and Linux distributions rely on their DHCP client to handle 667 the configuration of interface-specific information (such as an IP 668 address and netmask), and a set of system-wide configuration 669 information, (such a DNS server list, an NTP server list and default 670 routes). Users of these operating systems have the choice of using 671 any DHCP client available for their platform, with an operating 672 system default. This section discusses the behavior of several DHCP 673 clients that may be used with Linux and BSD distributions. 675 The Internet Systems Consortium (ISC) DHCP Client [ISCDHCP] and its 676 derivative for OpenBSD [OPENBSDDHCLIENT] can be configured with 677 specific instructions for each interface. However, each time new 678 configuration data is received by the host from a DHCP server, 679 regardless of which interface it is received on, the DHCP client 680 rewrites the global configuration data, such as the default routes 681 and the DNS server list (in /etc/resolv.conf) with the most recent 682 information received. Therefore, the last configured interface 683 always become the primary one. The ISC DHCPv6 client behaves 684 similarly. 686 The Phystech dhcpcd client [PHYSTECHDHCPC] behaves similarly to the 687 ISC client. It replaces the DNS server list in /etc/resolv.conf and 688 the default routes each time new DHCP information is received on any 689 interface. However, the -R flag can be used to instruct the client 690 to not replace the DNS servers in /etc/resolv.conf. However, this 691 flag is a global flag for the DHCP server, and is therefore 692 applicable to all interfaces. When dhcpd is called with the -R flag, 693 the DNS servers are never replaced. 695 The pump client [PUMP] also behaves similarly to the ISC client. It 696 replaces the DNS servers in /etc/resolv.conf and the default routes 697 each time new DHCP information is received on any interface. 698 However, the nodns and nogateway options can be specified on a per 699 interface basis, enabling the user to define which interface should 700 be used to obtain the global configuration information. 702 The udhcp client [UDHCP] is often used in embedded platforms based on 703 busybox. The udhcp client behaves similarly to the ISC client. It 704 rewrites default routes and the DNS server list each time new DHCP 705 information is received. 707 Redhat-based distributions, such as Redhat, Centos and Fedora have a 708 per-interface configuration option (PEERDNS) that indicates that the 709 DNS server list should not be updated based on configuration received 710 on that interface. 712 The most configurable DHCP clients can be set to define a primary 713 interface to use only that interface for the global configuration 714 data. However, this is limited, since a mobile host might not always 715 have the same set of interfaces available. Connection managers may 716 help in this situation. 718 Some distributions also have a connection manager. However, most 719 connection managers serve as a GUI to the DHCP client, therefore not 720 changing the functionality described above. 722 3.2.3. Apple Mac OS X 724 This section is based on testing Mac OS X (version 10.5.6). 726 When using multiple interfaces on Mac OS X, global configuration data 727 such as default routes and the DNS server list are taken from the 728 DHCP data received on the primary interface. Therefore, the order in 729 which the interfaces receive their configuration data is not 730 relevant. For example, if the primary interface receives its 731 configuration data first, then the second interface receives its 732 configuration data, the interface-specific information for the second 733 interface will be configured, but the global configuration 734 information such as the DNS server list and default routes is not 735 overwritten. 737 4. Acknowledgements 739 Authors of the document would like to thank following people for 740 their input and feedback: Dan Wing, Hui Deng, Jari Arkko, Julien 741 Laganier. 743 5. IANA Considerations 745 This memo includes no request to IANA. 747 6. Security Considerations 749 This document describes current operating system implementations and 750 how they handle the issues raised in the MIF problem statement. 751 While it is possible that the currently implemented mechanisms 752 described in this document may affect the security of the systems 753 described, this document merely reports on current practice. It does 754 not attempt to analyze the security properties (or any other 755 architectural properties) of the currently implemented mechanisms. 757 7. Change Log 759 The following changes were made between versions -00 and -02: 761 o Added information on usage of suffix with Windows. 763 o new section describing Qualcomm AMSS/Brew Multi-interface handling 765 o Considerations on access selection for some current connection 766 managers. 768 o Added information on multiple-interface scenarios with Google 769 Android. 771 o Clarifications on Arena connection manager 773 o Clarifications on multiple interface handling with RIM blackberry. 775 o Added new contributors. 777 8. Contributors 779 The following people contributed most of the per-Operating System 780 information found in this document: 782 o Marc Blanchet, Viagenie 784 o Hua Chen, Leadcoretech, Ltd. 786 o Yan Zhang, Leadcoretech Ltd. 788 o Shunan Fan, Huawei Technology 790 o Jian Yang, Huawei Technology 792 o Gabriel Montenegro, Microsoft Corporation 794 o Shyam Seshadri, Microsoft Corporation 796 o Dave Thaler, Microsoft Corporation 797 o Teemu Savolainen, Nokia 799 o Tao Sun, China Mobile 801 o George Tsirtsis, Qualcomm. 803 o David Freyermuth, France telecom. 805 o Aurelien Collet, Altran. 807 o Giyeong Son, RIM. 809 9. References 811 9.1. Normative References 813 [I-D.ietf-mif-problem-statement] 814 Blanchet, M. and P. Seite, "Multiple Interfaces Problem 815 Statement", draft-ietf-mif-problem-statement-04 (work in 816 progress), May 2010. 818 9.2. Informative References 820 [ANDROID] Google Inc., "Android developers: package android.net", 821 2009, . 824 [BLACKBERRY] 825 Research In Motion Limited, "BlackBerry Java Development 826 Environment - Fundamentals Guide: Wireless gateways", 827 2009, . 830 [I-D.montenegro-mif-multihoming] 831 Montenegro, G., Thaler, D., and S. Seshadri, "Multiple 832 Interfaces on Windows", 833 draft-montenegro-mif-multihoming-00 (work in progress), 834 March 2009. 836 [I-D.yang-mif-connection-manager-impl-req] 837 Yang, J., Sun, T., and S. Fan, "Multi-interface Connection 838 Manager Implementation and Requirements", 839 draft-yang-mif-connection-manager-impl-req-00 (work in 840 progress), March 2009. 842 [I-D.zhang-mif-connection-manager-arena] 843 Zhang, Y., Sun, T., and H. Chen, "Multi-interface Network 844 Connection Manager in Arena Platform", 845 draft-zhang-mif-connection-manager-arena-00 (work in 846 progress), February 2009. 848 [ISCDHCP] Internet Software Consortium, "ISC DHCP", 2009, 849 . 851 [NRPT] Windows, "Name Resolution Policy Table", February 2010, < 852 http://technet.microsoft.com/en-us/magazine/ 853 ff394369.aspx>. 855 [OPENBSDDHCLIENT] 856 OpenBSD, "OpenBSD dhclient", 2009, 857 . 859 [PHYSTECHDHCPC] 860 Phystech, "dhcpcd", 2009, 861 . 863 [PUMP] RedHat, "PUMP", 2009, . 865 [RFC1122] Braden, R., "Requirements for Internet Hosts - 866 Communication Layers", STD 3, RFC 1122, October 1989. 868 [RFC3484] Draves, R., "Default Address Selection for Internet 869 Protocol version 6 (IPv6)", RFC 3484, February 2003. 871 [RFC4311] Hinden, R. and D. Thaler, "IPv6 Host-to-Router Load 872 Sharing", RFC 4311, November 2005. 874 [S60] Nokia Corporation, "S60 Platform: IP Bearer Management", 875 2007, . 879 [UDHCP] Busybox, "uDHCP", 2009, . 882 [WINDOWSMOBILE] 883 Microsoft Corporation, "SDK Documentation for Windows 884 Mobile-Based Smartphones: Connection Manager", 2005, 885 . 887 Authors' Addresses 889 Margaret Wasserman (editor) 890 Painless Security, LLC 891 356 Abbott Street 892 North Andover, MA 01845 893 USA 895 Phone: +1 781 405-7464 896 Email: mrw@painless-security.com 897 URI: http://www.painless-security.com 899 Pierrick Seite (editor) 900 France Telecom - Orange 901 4, rue du clos courtel BP 91226 902 Cesson-Sevigne 35512 903 France 905 Email: pierrick.seite@orange-ftgroup.com