idnits 2.17.1 draft-ietf-mif-current-practices-06.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 (February 1, 2011) is 4833 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-09 -- Obsolete informational reference (is this intentional?): RFC 3484 (Obsoleted by RFC 6724) -- Duplicate reference: RFC3484, mentioned in 'RFC3484', was also mentioned in 'ANDROID-RFC3484'. -- Obsolete informational reference (is this intentional?): RFC 3484 (Obsoleted by RFC 6724) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force M. Wasserman 3 Internet-Draft Painless Security, LLC 4 Intended status: Informational P. Seite 5 Expires: August 5, 2011 France Telecom - Orange 6 February 1, 2011 8 Current Practices for Multiple Interface Hosts 9 draft-ietf-mif-current-practices-06 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 August 5, 2011. 36 Copyright Notice 38 Copyright (c) 2011 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 and 65 Windows Phone 7 . . . . . . . . . . . . . . . . . . . 8 66 3.1.3. BlackBerry . . . . . . . . . . . . . . . . . . . . . . 10 67 3.1.4. Google Android . . . . . . . . . . . . . . . . . . . . 10 68 3.1.5. Qualcomm Brew . . . . . . . . . . . . . . . . . . . . 11 69 3.1.6. Arena Connection Manager . . . . . . . . . . . . . . . 13 70 3.1.7. Current practices for network selection in handsets . 13 71 3.2. Desktop Operating Systems . . . . . . . . . . . . . . . . 14 72 3.2.1. Microsoft Windows . . . . . . . . . . . . . . . . . . 15 73 3.2.1.1. Routing . . . . . . . . . . . . . . . . . . . . . 15 74 3.2.1.2. Outbound and Inbound Addresses . . . . . . . . . . 15 75 3.2.1.3. DNS Configuration . . . . . . . . . . . . . . . . 15 76 3.2.2. Linux and BSD-based Operating Systems . . . . . . . . 16 77 3.2.2.1. Routing . . . . . . . . . . . . . . . . . . . . . 16 78 3.2.2.2. Outbound and Inbound Addresses . . . . . . . . . . 17 79 3.2.2.3. DNS Configuration . . . . . . . . . . . . . . . . 17 80 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 81 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 82 6. Security Considerations . . . . . . . . . . . . . . . . . . . 19 83 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 19 84 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 85 8.1. Normative References . . . . . . . . . . . . . . . . . . . 20 86 8.2. Informative References . . . . . . . . . . . . . . . . . . 20 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 89 1. Introduction 91 Multiple-interface hosts face several challenges not faced by single- 92 interface hosts, some of which are described in the MIF problem 93 statement, [I-D.ietf-mif-problem-statement]. This document 94 summarizes how current implementations deal with the problems 95 identified in the MIF problem statement. 97 Publicly-available information about the multiple-interface solutions 98 implemented in some widely used operating systems, including both 99 mobile handset and desktop operating systems, is collected in this 100 document, including: Nokia S60 [S60], Microsoft Windows Mobile 101 [WINDOWSMOBILE], Blackberry [BLACKBERRY], Google Android [ANDROID], 102 Microsoft Windows, Apple Mac OS X, Linux and BSD-based operating 103 systems. 105 2. Summary of Current Approaches 107 This section summarizes current approaches that are used to resolve 108 the multi-interface issues described in the Multiple Interface 109 Problem Statement [I-D.ietf-mif-problem-statement]. These approaches 110 can be broken down into three major categories: 112 o Centralized connection management 114 o Per-application connection settings 116 o Stack-level solutions to specific problems 118 2.1. Centralized Connection Management 120 It is a common practice for mobile handset operating systems to use a 121 centralized connection manager that performs network interface 122 selection based on application or user input. The information used 123 by the connection manager may be programmed into an application or 124 provisioned on a handset-wide basis. When information is not 125 available to make an interface selection, the connection manager will 126 query the user to choose between available choices. 128 Routing tables are not typically used for network interface selection 129 when a connection manager is in use, as the criteria for network 130 selection is not strictly IP-based but is also dependent on other 131 properties of the interface (cost, type, etc.). Furthermore, 132 multiple overlapping private IPv4 address spaces are often exposed to 133 a multiple-interface host, making it difficult to make interface 134 selection decisions based on prefix matching. 136 2.2. Per Application Connection Settings 138 In mobile handsets, applications are often involved in choosing what 139 interface and related configuration information should be used. In 140 some cases, the application selects the interface directly, and in 141 other cases the application provides more abstract information to a 142 connection manager that makes the final interface choice. 144 2.3. Stack-Level Solutions to Specific Problems 146 In most desktop operating systems, multiple interface problems are 147 dealt with in the stack and related components, based on system- 148 level configuration information, without the benefit of input from 149 applications or users. These solutions tend to map well to the 150 problems listed in the problem statement: 152 o DNS resolution issues 154 o Routing 156 o Address selection policy 158 The configuration information for desktop systems comes from one of 159 three sources: DHCP, proprietary configuration systems or manual 160 configuration. While these systems universally accept IP address 161 assignment on a per-interface basis, they differ in what set of 162 information can be assigned on a per-interface basis and what can be 163 configured only on a per-system basis. 165 When choosing between multiple sets of information provided, these 166 systems will typically give preference to information received on the 167 "primary" interface. The mechanism for designating the "primary" 168 interface differs by system. 170 There is very little commonality in how desktop operating systems 171 handle multiple sets of configuration information, with notable 172 variations between different versions of the same operating system 173 and/or within different software packages built for the same 174 operating system. Although these systems differ widely, it is not 175 clear that any of them provide a completely satisfactory user 176 experience in multiple-interface environments. 178 The following sections discuss some of the solutions used in each of 179 the areas raised in the MIF problem statement. 181 2.3.1. DNS Resolution Issues 183 There is very little commonality in how desktop operating systems 184 handle the DNS server list. Some systems support per-interface DNS 185 server lists, while others only support a single system-wide list. 187 On hosts with per-interface DNS server lists, different mechanisms 188 are used to determine which DNS server is contacted for a given 189 query. In most cases, the first DNS server listed on the "primary" 190 interface is queried first, with back off to other servers if an 191 answer is not received. 193 Systems that support a single system-wide list differ in how they 194 select which DNS server to use in cases where they receive more than 195 one DNS server list to configure (e.g. from DHCP on multiple 196 interfaces). Some accept the information received on the "primary" 197 interface, while others use either the first or last set DNS server 198 list configured. 200 2.3.2. Routing 202 Routing information is also handled differently on different desktop 203 operating systems. While all systems maintain some sort of routing 204 cache, to handle redirects and/or statically configured routes, most 205 packets are routed based on configured default gateway information. 207 Some systems do allow the configuration of different default router 208 lists for different interfaces. These systems will always choose the 209 default gateway on the interface with the lowest routing metric, with 210 different behavior when two or more interfaces have the same routing 211 metric. 213 Most systems do not allow the configuration of more than one default 214 router list, choosing instead to use the first or last default router 215 list configured and/or the router list configured on the "primary" 216 interface. 218 2.3.3. Address Selection Policy 220 There is somewhat more commonality in how desktop hosts handle 221 address selection. Applications typically provide the destination 222 address for an outgoing packet, and the IP stack is responsible for 223 picking the source address. 225 IPv6 specifies a specific source address selection mechanism in 226 [RFC3484], and several systems implement this mechanism with similar 227 support for IPv4. However, many systems do not provide any mechanism 228 to update this default policy, and there is no standard way to do so. 230 In some cases, the routing decision (including which interface to 231 use) is made before source address selection is performed, and a 232 source address is chosen from the outbound interface. In other 233 cases, source address selection is performed before, or independently 234 from outbound interface selection. 236 3. Current Practices in Some Operating Systems 238 The following sections briefly describe the current multiple- 239 interface host implementations on some widely-used operating systems. 240 Please refer to the References section for pointers to original 241 documentation on most of these systems, including further details. 243 3.1. Mobile Handset Operating Systems 245 Cellular devices typically run a variety of applications in parallel, 246 each with different requirements for IP connectivity. A typical 247 scenario is shown in figure 1, where a cellular device is utilizing 248 WLAN access for web browsing and GPRS access for transferring 249 multimedia messages (MMS). Another typical scenario would be a real- 250 time VoIP session over one network interface in parallel with best 251 effort web browsing on another network interface. Yet another 252 typical scenario would be global Internet access through one network 253 interface and local (e.g. corporate VPN) network access through 254 another. 256 Web server MMS Gateway 257 | | 258 -+--Internet---- ----Operator network--+- 259 | | 260 +-------+ +-------+ 261 |WLAN AP| | GGSN | 262 +-------+ +-------+ 263 | +--------+ | 264 +--------|Cellular|--------+ 265 |device | 266 +--------+ 268 A cellular device with two network interfaces 270 Figure 1 272 Different network access technologies require different settings. 273 For example, WLAN requires Service Set Identifier (SSID) and the GPRS 274 network requires the Access Point Name (APN) of the Gateway GPRS 275 Support Node (GGSN), among other parameters. It is common that 276 different accesses lead to different destination networks (e.g. to 277 "Internet", "intranet", cellular network services, etc.). 279 3.1.1. Nokia S60 3rd Edition, Feature Pack 2 281 S60 uses the concept of an Internet Access Point (IAP) [S60] that 282 contains all information required for opening a network connection 283 using a specific access technology. A device may have several IAPs 284 configured for different network technologies and settings (multiple 285 WLAN SSIDs, GPRS APNs, dial-up numbers, and so forth). There may 286 also be 'virtual' IAPs that define parameters needed for tunnel 287 establishment (e.g. for VPN). 289 For each application, a correct IAP needs to be selected at the point 290 when the application requires network connectivity. This is 291 essential, as the wrong IAP may not be able to support the 292 application or reach the desired destination. For example, MMS 293 application must use the correct IAP in order to reach the MMS 294 Gateway, which typically is not accessible from the public Internet. 295 As another example, an application might need to use the IAP 296 associated with its corporate VPN in order to reach internal 297 corporate servers. Binding applications to IAPs avoids several 298 problems, such as choosing the correct DNS server in the presence of 299 split DNS (as an application will use the DNS server list from its 300 bound IAP), and overlapping private IPv4 address spaces used for 301 different interfaces (as each application will use the default routes 302 from its bound IAP). 304 If multiple applications utilize the same IAP, the underlying network 305 connection can typically be shared. This is often the case when 306 multiple Internet-using applications are running in parallel. 308 The IAP for an application can be selected in multiple ways: 310 o Statically: e.g. from a configuration interface, via client 311 provisioning/device management system, or at build-time. 313 o Manually by the user: e.g. each time an application starts the 314 user may be asked to select the IAP to use. This may be needed, 315 for example, if a user sometimes wishes to access his corporate 316 intranet and other times would prefer to access the Internet 317 directly. 319 o Automatically by the system: after the destination network has 320 been selected statically or dynamically. 322 The static approach is fine for certain applications, like MMS, for 323 which configuration can be provisioned by the network operator and 324 does not change often. Manual selection works, but may be seen as 325 troublesome by the user. An automatic selection mechanism needs to 326 have some way of knowing which destination network the user, or an 327 application, is trying access. 329 S60 3rd Edition, Feature Pack 2, introduces a concept of Service 330 Network Access Points (SNAPs) that group together IAPs that lead to 331 the same destination. This enables static or manual selection of the 332 destination network for an application and leaves the problem of 333 selecting the best of the available IAPs within a SNAP to the 334 operating system. 336 When SNAPs are used, it is possibly for the operating system to 337 notify applications when a preferred IAP, leading to the same 338 destination, becomes available (for example, when a user comes within 339 range of his home WLAN access point), or when the currently used IAP 340 is no longer available and applications have to reconnect via another 341 IAP (for example, when a user goes out of range of his home WLAN and 342 must move to the cellular network). 344 In S60 3.2 does not support RFC 3484 for source address selection 345 mechanisms. Applications are tightly bound the network interface 346 selected for them or by them. E.g. an application may be connected 347 to IPv6 3G connection, IPv4 3G connection, WLAN connection, or VPN 348 connection. The application can change between the connections, but 349 uses only one at a time. If the interface happens to be dual-stack, 350 then IPv4 is preferred over IPv6. 352 DNS configuration is per-interface; an application bounded to an 353 interface will always use the DNS settings for that interface. Hence 354 the device itself remembers these pieces of information for each 355 interface separately. 357 The S60 3.2 manages with totally overlapping addresses spaces. Each 358 interface can even have same IPv4 address configured on it without 359 issues. This is so because interfaces are kept totally separate from 360 each other. This also implies that the interface selection has to be 361 done at application layer, as from network layer point of view device 362 is not multihomed in the IP-sense. 364 Please see the source documentation for more details and screenshots: 365 [S60]. 367 3.1.2. Microsoft Windows Mobile 2003 Second Edition and Windows Phone 7 369 A Connection Manager architecture is described in [WINDOWSMOBILE]. 370 This architecture centralizes and automates network connection 371 establishment and management, and makes it possible to automatically 372 select a connection, to dial-in automatically or by user initiation, 373 and to optimize connection and shared resource usage. Connection 374 Manager periodically re-evaluates the validity of the connection 375 selection. The Connection Manager uses various attributes such as 376 cost, security, bandwidth, error rate, and latency in its decision 377 making. 379 The Connection Manager selects the best possible connection for the 380 application based on the destination network the application wishes 381 to reach. The selection is made between available physical and 382 virtual connections (e.g. VPN, GPRS, WLAN, and wired Ethernet) that 383 are known to provide connectivity to the destination network, and the 384 selection is based on the costs associated with each connection. 385 Different applications are bundled to use the same network connection 386 when possible, but in conflict situations when a connection cannot be 387 shared, higher priority applications take precedence, and the lower 388 priority applications lose connectivity until the conflict situation 389 clears. 391 During operation, Connection Manager opens new connections as needed, 392 and also disconnects unused or idle connections. 394 To optimize resource use, such as battery power and bandwidth, 395 Connection Manager enables applications to synchronize network 396 connection usage by allowing applications to register their 397 requirements for periodic connectivity. An application is notified 398 when a suitable connection becomes available for its use. 400 In comparison to Windows Mobile 2003 SE, Windows phone 7 brings 401 update of the routing functionality in the case where the terminal 402 can be attached simultaneously to several interfaces. Actually, 403 Windows Phone 7 routes the traffic through a preferred interface, 404 which has a lower metric. When there are multiple interfaces, the 405 applications system will, by default, choose from an ordered list of 406 available interfaces. The default connection policy will prefer 407 wired over wireless and WLAN over cellular. Hence, if an application 408 wants to use cellular 3G as the active interface when WLAN is 409 available, the application needs to override the default connection 410 mapping policy. An application specific mapping policy can be set 411 via API or provisioned by the Mobile Operator. The application, in 412 compliance with the security model, can request connection type by 413 interface (WLAN, cellular), by minimum interface speed (x kbps, y 414 mbps), or by name (Access Point Name). 416 3.1.3. BlackBerry 418 Depending on the network configuration, Java applications in 419 BlackBerry devices [BLACKBERRY] can use can use direct TCP/IP 420 connectivity or different application proxys to establish connections 421 over the wireless network. For instance, some wireless service 422 providers provide an Internet gateway to offer direct TCP/IP 423 connectivity to the Internet while some others can provide a WAP 424 gateway that allows HTTP connections to occur over the WAP (Wireless 425 Application Protocol) protocol. It is also possible to use the 426 BlackBerry Enterprise Server [BLACKBERRY] as a network gateway, The 427 BlackBerry Enterprise Server provides an HTTP and TCP/IP proxy 428 service to allow the application to use it as a secure gateway for 429 managing HTTP and TCP/IP connections to the intranet or the Internet. 430 An application connecting to the Internet, can use either the 431 BlackBerry Internet Service or the Internet gateway of the wireless 432 server provider to manage connections. The problem of gateway 433 selection is supposed to be managed independently by each Java 434 application. For instance, an application can be designed to always 435 use the default Internet gateway, while another application can be 436 designed to use a preferred proxy when available. 438 A BlackBerry device [BLACKBERRY] can be attached to multiple networks 439 simultaneously (wireless/wired). In this case, Multiple network 440 interfaces can be associated to a single IP stack or multiple IP 441 stacks. The device, or the application, can select the network 442 interface to be used in various ways. For instance, the device can 443 always map the applications to the default network interface (or the 444 default access network). When muliple IP stacks are associated to 445 multiple interfaces, the application can select the source address 446 correponding to the preferred network interface. When multiple 447 network interfaces are aggregated into a single IP stack, the device 448 associates each application to the more appropriate network 449 interface. The selection can be based on cost, type-of-service 450 and/or user preference. 452 3.1.4. Google Android 454 Android is based on a Linux kernel and, in many situations, behaves 455 like a Linux device as described in Section 3.2.2. As per Linux, 456 Android can manage multiple routing tables and rely on policy based 457 routing associated with packet filtering capabilities (see 458 Section 3.2.2.1 for details). Such a framework can be used to solve 459 complex routing issue brought by multiple interfaces terminals, e.g. 460 address space overlapping. 462 For incoming packets, Android implements the weak host model 463 [RFC1122] on both IPv4 and IPv6. However, Android can also be 464 configured to support the strong host model. 466 Regarding DNS configuration, Android does not list the DNS servers in 467 the file /etc/resolv.conf, used by Linux. However, as per Linux, DNS 468 configuration is node-scoped, even if DNS configuration can rely on 469 the DHCP client. For instance, the udhcp client [UDHCP], which is 470 also available for Linux, can be used on Android. Each time new 471 configuration data is received by the host from a DHCP server, 472 regardless of which interface it is received on, the DHCP client 473 rewrites the global configuration data with the most recent 474 information received. 476 Actually, the main difference between Linux and Android is on the 477 address selection mechanism. Android version prior to 2.2 simply 478 prefers IPv6 connectivity over IPv4. Android 2.2 has been updated 479 with [ANDROID-RFC3484], which implements some of the address 480 selection rules defined in [RFC3484]. All RFC3484 rules are 481 supported, except rule 3 (avoid deprecated addresses), 4 (prefer home 482 addresses) and 7 (prefer native transport). Also, rule 9 (use 483 longest matching prefix) has been modified so it does not sort IPv4 484 addresses. 486 The Android reference documentation describes the android.net package 487 [ANDROID] and the ConnectivityManager class that applications can use 488 to request a route to a specified destination address via a specified 489 network interface (3GPP or WLAN). Applications also ask Connection 490 Manager for permission to start using a network feature. The 491 Connectivity Manager monitors changes in network connectivity and 492 attempts to failover to another network if connectivity to an active 493 network is lost. When there are changes in network connectivity, 494 applications are notified. Applications are also able to ask for 495 information about all network interfaces, including their 496 availability, type and other information. 498 3.1.5. Qualcomm Brew 500 This section describes how multi-interface support is handled by 501 Advanced Mobile Station Software (AMSS) that comes with Brew OS for 502 all Qualcomm chipsets (e.g., MSM, Snapdragon etc). AMSS is a low 503 level connectivity platform, on top of which manufacturers can build 504 to provide the necessary connectivity to applications. The 505 interaction model between AMSS, the Operating System, and the 506 applications is not unique and depend on the design chosen by the 507 manufacturer. The Mobile OS can let an application invoke the AMSS 508 directly (via API), or provide its own connection manager that will 509 request connectivity to the AMSS based on applications needs. The 510 interaction between the OS connection manager and the applications is 511 OS dependent. 513 AMSS supports a concept of netpolicy which allows each application to 514 specify the type of network connectivity desired. The netpolicy 515 contains parameters such as access technology, IP version type and 516 network profile. Access technology could be a specific technology 517 type such as CDMA or WLAN or could be a group of technologies, such 518 as ANY_Cellular or ANY_Wireless. IP version could be one of IPv4, 519 IPv6 or Default. The network profile identifies a type of network 520 domain or service within a certain network technology, such as 3GPP 521 APN or Mobile IP Home Agent. It also specifies all the mandatory 522 parameters required to connect to the domain such authentication 523 credentials and other optional parameters such as QoS attributes. 524 Network Profile is technology specific and set of parameters 525 contained in the profile could vary for different technologies. 527 Two models of network usage are supported: 529 o Applications requiring network connectivity specify an appropriate 530 netpolicy in order to select the desired network. The netpolicy 531 may match one or more network interfaces. AMSS system selection 532 module selects the best interface out of the ones that match the 533 netpolicy based on various criteria such as cost, speed or other 534 provisioned rules. Application explicitly starts the selected 535 network interface and, as a result, the application also gets 536 bound to the corresponding network interface. All outbound 537 packets from this application are always routed over this bound 538 interface using the source address of the interface. 540 o Applications may rely on a separate connection manager to control 541 (e.g. start/stop) the network interface. In this model, 542 applications are not necessarily bound to any one interface. All 543 outbound packets from such applications are routed on one of the 544 interfaces that match its netpolicy. The routing decision is made 545 individually for each packet and selects the best interface based 546 on the criteria described above and the destination address. 547 Source address is always that assigned to the interface used to 548 transmit the packet. 550 All of the routing/interface selection decisions are based on the 551 netpolicy and not just on the destination address to avoid 552 overlapping private IPv4 address issue. This also allows multiple 553 interfaces to be configured with the same IP address, for example, to 554 handle certain tunnelling scenarios. Applications that do not 555 specify a netpolicy are routed by AMSS to the best possible interface 556 using the default netpolicy. Default netpolicy could be pre-defined 557 or provisioned by the administrator or operator. Hence default 558 interface could vary from device to device and also depends upon the 559 available networks at any given time. 561 AMSS allows each interface to be configured with its own set of DNS 562 configuration parameters (e.g. list of DNS servers, domain names 563 etc.). Interface selected to make a DNS resolution is the one to 564 which application making the DNS query is bound. Applications can 565 also specify a different netpolicy as part of DNS request to select 566 another interface for DNS resolution. Regardless, all the DNS 567 queries are sent only over this selected interface using the DNS 568 configuration from the interface. DNS resolution is first attempted 569 with the primary server configured in the interface. If a response 570 is not received, the queries are sent to all the other servers 571 configured in the interface in a sequential manner using a backoff 572 mechanism. 574 3.1.6. Arena Connection Manager 576 Arena, a mobile OS based on Linux, provides a Connection Manager, 577 which is described in [I-D.zhang-mif-connection-manager-arena] and 578 [I-D.yang-mif-connection-manager-impl-req]. The arena connection 579 manager provides a means for applications to register their 580 connectivity requirement. The Connection Manager can then choose an 581 interface that matches the application's needs while considering 582 other factors such as availability, cost and stability. Also, the 583 Connection Manager can handle multi-interface issues such as 584 connection sharing. 586 3.1.7. Current practices for network selection in handsets 588 This section describes the behavior of connection managers in 589 presence of multiple points of attachment for a same interface. The 590 section focuses on WLAN interface, it is described how does the 591 connection manager deal with the list of preferred SSID and how does 592 it select the SSID for attachment. Current implementation of 593 connection managers are considered for the following handsets: LG 594 Pathfinder, Android/HTC magic, RIM BlackBerry , iPhone (3G and 3GS). 596 When the terminal is under coverage of different WLAN networks with 597 different SSIDs: 599 connection managers, excepted for the RIM Blackberry, construct 600 the list of preferred SSID giving priority to the last SSID on 601 which they have managed to attach. The user is not allowed to 602 define its preferred access. So, if the terminal discovers and 603 manages to attach to SSID1, SSID1 becomes the preferred access for 604 future attachment. If the terminal moves out of SSID1 coverage 605 and attaches to a new SSID, SSID2. SSID2 will then be the 606 preferred access of the connection manager. Then, if the terminal 607 processes to WLAN attachment within both SSID1 and SSID2 coverage, 608 the connection manager will select SSID2 for attachment. The RIM 609 Blackberry behaves differently, the connection manager selects the 610 first SSID on which it has managed to attach in the past. 612 All connection managers behave in the same way when the terminals 613 fails to attach to the selected SSID: the connection manager 614 automatically selects the second SSID in the list of preferred 615 SSID. Fallback come into play at expiration of a timeout from few 616 seconds to about 3 minutes. 618 When the IP stack fails to obtain an IP address, the handset, 619 excepted the iPhone, restarts WLAN attachment selecting the second 620 SSID in the list. 622 When the terminal receives signals from different point of attachment 623 with same SSID: 625 The connection manager selects the point of attachment with best 626 signal strength; no other criteria (e.g. MAC address) is taken 627 into account. If the handset fails to attach to the selected 628 point of attachment (e.g. due to L2 authentication failure), the 629 connection manager selects the point of attachment with lower 630 signal strength. However, this fallback is not supported on the 631 LG pathfinder. If no more points of attachment (corresponding to 632 the preferred SSID) are available, the connection manager selects 633 the second SSID in the list of preferred SSID. 635 Whatever is the handset, fallback on L3 attachment failure is not 636 supported if the terminal remains under coverage of the same WLAN 637 access point. Actually, the connection manager always selects the 638 most powerful signal strength without considering IP configuration 639 results. In other words, if the terminal is unable to set up the 640 IP connectivity on one WLAN access, the connection manager will 641 not try to attach to an alternative point of attachment (or SSID) 642 as long as the signal strength of the first radio link is the most 643 powerful. Situation is not the same for mobile terminal since the 644 signal strength of the alternative point of attachment could 645 become better while the terminal is moving. If so, the terminal 646 automatically restarts IP connectivity process (excepted the HTC 647 Magic which requires the user to manually restart the L3 648 attachment). 650 3.2. Desktop Operating Systems 652 Multi-interface issues also occur in desktop environments in those 653 cases where a desktop host has multiple (logical or physical) 654 interfaces connected to networks with different reachability 655 properties, such as one interface connected to the global Internet, 656 while another interface is connected to a corporate VPN. 658 3.2.1. Microsoft Windows 660 The multi-interface functionality currently implemented in Microsoft 661 Windows operation systems is described in more detail in 662 [I-D.montenegro-mif-multihoming]. 664 3.2.1.1. Routing 666 It is possible, although not often desirable, to configure default 667 routers on more than one Windows interface. In this configuration, 668 Windows will use the default route on the interface with the lowest 669 routing metric (i.e. the fastest interface). If multiple interfaces 670 share the same metric, the behavior will differ based on the version 671 of Windows in use. Prior to Windows Vista, the packet would be 672 routed out of the first interface that was bound to the TCP/IP stack, 673 the preferred interface. In Windows vista, host-to-router load 674 sharing [RFC4311] is used for both IPv4 and IPv6. 676 3.2.1.2. Outbound and Inbound Addresses 678 If the source address of the outgoing packet has not been determined 679 by the application, Windows will choose from the addresses assigned 680 to its interfaces. Windows implements [RFC3484] for source address 681 selection in IPv6 and, in Windows Vista, for IPv4. Prior to Windows 682 Vista, IPv4 simply chose the first address on the outgoing interface. 684 For incoming packets, Windows will check if the destination address 685 matches one of the addresses assigned to its interfaces. Windows has 686 implemented the weak host model [RFC1122] on IPv4 in Windows 2000, 687 Windows XP and Windows Server 2003. The strong host model became the 688 default for IPv4 in Windows Vista and Windows server 2008, however 689 the weak host model is available via per-interface configuration. 690 IPv6 has always implemented the strong host model. 692 3.2.1.3. DNS Configuration 694 Windows largely relies on suffixes to solve DNS resolution issues. 695 Suffixes are used for four different purposes that are reminded 696 hereafter: 698 1. DNS Suffix Search List (aka domain search list): suffix is added 699 to non-FQDN names. 701 2. Interface-specific suffix list, which allows sending different 702 DNS queries to different DNS servers. 704 3. Suffix to control Dynamic DNS Updates: determine which DNS server 705 will receive a dynamic update for a name with a certain suffix. 707 4. Suffix in the Name Resolution Policy Table [NRPT] to aid in 708 identifying a Namespace that requires special handling (feature 709 available only after Windows 7 and its server counterpart, 710 Windows Server 2008 R2). 712 However, this section focuses on the interface-specific suffix list 713 since it is the only suffix usage in the scope of this document. 715 DNS configuration information can be host-wide or interface specific. 716 Host-wide DNS configuration is input via static configuration or, in 717 sites that use Active Directory, Microsoft's Group Policy. Interface 718 specific DNS configuration can be input via static configuration or 719 via DHCP. 721 The host-wide configuration consists of a primary DNS suffix to be 722 used for the local host, as well as a list of suffix that can be 723 appended to names being queried. Before Windows Vista and Windows 724 Server 2008, there was also a host-wide DNS server list that took 725 precedent over per-interface DNS configuration. 727 The interface-specific DNS configuration comprises an interface- 728 specific suffix list and a list of DNS server IP addresses. 730 Windows uses a host-wide "effective" server list for an actual query, 731 where the effective server list may be different for different names. 732 In the list of DNS server addresses, the first server is considered 733 the "primary" server, with all other servers being secondary. 735 When a DNS query is performed in Windows, the query is first sent to 736 the primary DNS server on the preferred interface. If no response is 737 received in one second, the query is sent to the primary DNS servers 738 on all interfaces under consideration. If no response is received 739 for 2 more seconds, the DNS server sends the query to all of the DNS 740 servers on the DNS server lists for all interfaces under 741 consideration. If the host still doesn't receive a response after 4 742 seconds, it will send to all of the servers again and wait 8 seconds 743 for a response. 745 3.2.2. Linux and BSD-based Operating Systems 747 3.2.2.1. Routing 749 In addition to the two commonly used routing tables (the local and 750 main routing tables), the kernel can support up to 252 additional 751 routing tables which can be added in the file /etc/iproute2/ 752 rt_tables. A routing table can contain an arbitrary number of 753 routes, the selection of route is classically made according to the 754 destination address of the packet. Linux also provides more flexible 755 routing selection based on the Type of Service, scope, output 756 interface. In addition, since kernel version 2.2, Linux supports 757 policy based routing using the multiple routing tables capability and 758 a routing policy database. This database contains routing rules used 759 by the kernel. Using policy based routing, the source address, the 760 ToS flags, the interface name and an "fwmark" (a mark carried through 761 added in the data structure representing the packet) can be used as 762 route selectors. 764 Policy based routing can be used in addition to Linux packet 765 filtering capabilities, e.g provided by the "iptables" tool. In a 766 multiple interfaces context, this tool can be used to mark the 767 packets, i.e assign a number to fwmark, in order to select the 768 routing rule according to the type of traffic. This mark can be 769 assigned according to parameters like protocol, source and/or 770 destination addresses, port number and so on. 772 Such a routing management framework allows to deal with complex 773 situation such as address space overlaping. In this situation, the 774 administrator can use packet marking and policy based routing to 775 select the correct interface. 777 3.2.2.2. Outbound and Inbound Addresses 779 By default, source address selection follows the following basics 780 rules: the initial source address for an outbound packet can be 781 chosen by the application using the bind() call. Without information 782 from the application, the kernel chooses the first address configured 783 on the interface which belongs to the same subnet than the 784 destination address or the nexthop router. 786 Linux also implements [RFC3484] for source address selection for IPv6 787 and dual-stack configurations. However, the address sorting rules 788 from [RFC3484] are not always adequate. For this reason, Linux 789 allows the system administrator to dynamically change the sorting. 790 This can be achieved with the /etc/gai.conf file. 792 For incoming packets, Linux checks if the destination address matches 793 one of the addresses assigned to its interfaces then, processes the 794 packet according the configured host model. By default, Linux 795 implements the weak host model [RFC1122] on both IPv4 and IPv6. 796 However, Linux can also be configured to support the strong host 797 model. 799 3.2.2.3. DNS Configuration 801 Most BSD and Linux distributions rely on their DHCP client to handle 802 the configuration of interface-specific information (such as an IP 803 address and netmask), and a set of system-wide configuration 804 information, (such a DNS server list, an NTP server list and default 805 routes). Users of these operating systems have the choice of using 806 any DHCP client available for their platform, with an operating 807 system default. This section discusses the behavior of several DHCP 808 clients that may be used with Linux and BSD distributions. 810 The Internet Systems Consortium (ISC) DHCP Client [ISCDHCP] and its 811 derivative for OpenBSD [OPENBSDDHCLIENT] can be configured with 812 specific instructions for each interface. However, each time new 813 configuration data is received by the host from a DHCP server, 814 regardless of which interface it is received on, the DHCP client 815 rewrites the global configuration data, such as the default routes 816 and the DNS server list (in /etc/resolv.conf) with the most recent 817 information received. Therefore, the last configured interface 818 always become the primary one. The ISC DHCPv6 client behaves 819 similarly. 821 The Phystech dhcpcd client [PHYSTECHDHCPC] behaves similarly to the 822 ISC client. It replaces the DNS server list in /etc/resolv.conf and 823 the default routes each time new DHCP information is received on any 824 interface. However, the -R flag can be used to instruct the client 825 to not replace the DNS servers in /etc/resolv.conf. However, this 826 flag is a global flag for the DHCP server, and is therefore 827 applicable to all interfaces. When dhcpd is called with the -R flag, 828 the DNS servers are never replaced. 830 The pump client [PUMP] also behaves similarly to the ISC client. It 831 replaces the DNS servers in /etc/resolv.conf and the default routes 832 each time new DHCP information is received on any interface. 833 However, the nodns and nogateway options can be specified on a per 834 interface basis, enabling the user to define which interface should 835 be used to obtain the global configuration information. 837 The udhcp client [UDHCP] is often used in embedded platforms based on 838 busybox. The udhcp client behaves similarly to the ISC client. It 839 rewrites default routes and the DNS server list each time new DHCP 840 information is received. 842 Redhat-based distributions, such as Redhat, Centos and Fedora have a 843 per-interface configuration option (PEERDNS) that indicates that the 844 DNS server list should not be updated based on configuration received 845 on that interface. 847 The most configurable DHCP clients can be set to define a primary 848 interface to use only that interface for the global configuration 849 data. However, this is limited, since a mobile host might not always 850 have the same set of interfaces available. Connection managers may 851 help in this situation. 853 Some distributions also have a connection manager. However, most 854 connection managers serve as a GUI to the DHCP client, therefore not 855 changing the functionality described above. 857 4. Acknowledgements 859 Authors of the document would like to thank following people for 860 their input and feedback: Dan Wing, Hui Deng, Jari Arkko, Julien 861 Laganier and Steinar H. Gunderson. 863 5. IANA Considerations 865 This memo includes no request to IANA. 867 6. Security Considerations 869 This document describes current operating system implementations and 870 how they handle the issues raised in the MIF problem statement. 871 While it is possible that the currently implemented mechanisms 872 described in this document may affect the security of the systems 873 described, this document merely reports on current practice. It does 874 not attempt to analyze the security properties (or any other 875 architectural properties) of the currently implemented mechanisms. 877 7. Contributors 879 The following people contributed most of the per-Operating System 880 information found in this document: 882 o Marc Blanchet, Viagenie 884 o Hua Chen, Leadcoretech, Ltd. 886 o Yan Zhang, Leadcoretech Ltd. 888 o Shunan Fan, Huawei Technology 890 o Jian Yang, Huawei Technology 892 o Gabriel Montenegro, Microsoft Corporation 893 o Shyam Seshadri, Microsoft Corporation 895 o Dave Thaler, Microsoft Corporation 897 o Kevin Chin, Microsoft Corporation 899 o Teemu Savolainen, Nokia 901 o Tao Sun, China Mobile 903 o George Tsirtsis, Qualcomm. 905 o David Freyermuth, France telecom. 907 o Aurelien Collet, Altran. 909 o Giyeong Son, RIM. 911 8. References 913 8.1. Normative References 915 [I-D.ietf-mif-problem-statement] 916 Blanchet, M. and P. Seite, "Multiple Interfaces and 917 Provisioning Domains Problem Statement", 918 draft-ietf-mif-problem-statement-09 (work in progress), 919 October 2010. 921 8.2. Informative References 923 [ANDROID] Google Inc., "Android developers: package android.net", 924 2009, . 927 [ANDROID-RFC3484] 928 Gunderson, S., "RFC 3484 support for Android", 2010, . 932 [BLACKBERRY] 933 Research In Motion Limited, "BlackBerry Java Development 934 Environment - Fundamentals Guide: Wireless gateways", 935 2009, . 938 [I-D.montenegro-mif-multihoming] 939 Montenegro, G., Thaler, D., and S. Seshadri, "Multiple 940 Interfaces on Windows", 941 draft-montenegro-mif-multihoming-00 (work in progress), 942 March 2009. 944 [I-D.yang-mif-connection-manager-impl-req] 945 Yang, J., Sun, T., and S. Fan, "Multi-interface Connection 946 Manager Implementation and Requirements", 947 draft-yang-mif-connection-manager-impl-req-00 (work in 948 progress), March 2009. 950 [I-D.zhang-mif-connection-manager-arena] 951 Zhang, Y., Sun, T., and H. Chen, "Multi-interface Network 952 Connection Manager in Arena Platform", 953 draft-zhang-mif-connection-manager-arena-00 (work in 954 progress), February 2009. 956 [ISCDHCP] Internet Software Consortium, "ISC DHCP", 2009, 957 . 959 [NRPT] Windows, "Name Resolution Policy Table", February 2010, < 960 http://technet.microsoft.com/en-us/magazine/ 961 ff394369.aspx>. 963 [OPENBSDDHCLIENT] 964 OpenBSD, "OpenBSD dhclient", 2009, 965 . 967 [PHYSTECHDHCPC] 968 Phystech, "dhcpcd", 2009, 969 . 971 [PUMP] RedHat, "PUMP", 2009, . 973 [RFC1122] Braden, R., "Requirements for Internet Hosts - 974 Communication Layers", STD 3, RFC 1122, October 1989. 976 [RFC3484] Draves, R., "Default Address Selection for Internet 977 Protocol version 6 (IPv6)", RFC 3484, February 2003. 979 [RFC4311] Hinden, R. and D. Thaler, "IPv6 Host-to-Router Load 980 Sharing", RFC 4311, November 2005. 982 [S60] Nokia Corporation, "S60 Platform: IP Bearer Management", 983 2007, . 987 [UDHCP] Busybox, "uDHCP", 2009, . 990 [WINDOWSMOBILE] 991 Microsoft Corporation, "SDK Documentation for Windows 992 Mobile-Based Smartphones: Connection Manager", 2005, 993 . 995 Authors' Addresses 997 Margaret Wasserman 998 Painless Security, LLC 999 356 Abbott Street 1000 North Andover, MA 01845 1001 USA 1003 Phone: +1 781 405-7464 1004 Email: mrw@painless-security.com 1005 URI: http://www.painless-security.com 1007 Pierrick Seite 1008 France Telecom - Orange 1009 4, rue du clos courtel BP 91226 1010 Cesson-Sevigne 35512 1011 France 1013 Email: pierrick.seite@orange-ftgroup.com