idnits 2.17.1 draft-ietf-mif-current-practices-12.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 : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 28, 2011) is 4648 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC5113' is defined on line 956, but no explicit reference was found in the text -- 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) -- Duplicate reference: RFC3484, mentioned in 'WNDS-RFC3484', was also mentioned in 'RFC3484'. -- Obsolete informational reference (is this intentional?): RFC 3484 (Obsoleted by RFC 6724) Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 6 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: January 29, 2012 France Telecom - Orange 6 July 28, 2011 8 Current Practices for Multiple Interface Hosts 9 draft-ietf-mif-current-practices-12 11 Abstract 13 An increasing number of hosts are operating in multiple-interface 14 environments. This document summarizes current practices in this 15 area, and describes in detail how some common operating systems cope 16 with challenges ensue from this context. 18 Status of this Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on January 29, 2012. 35 Copyright Notice 37 Copyright (c) 2011 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Summary of Current Approaches . . . . . . . . . . . . . . . . 3 54 2.1. Centralized Connection Management . . . . . . . . . . . . 3 55 2.2. Per Application Connection Settings . . . . . . . . . . . 4 56 2.3. Stack-Level Solutions to Specific Problems . . . . . . . . 4 57 2.3.1. DNS Resolution Issues . . . . . . . . . . . . . . . . 5 58 2.3.2. First hop selection . . . . . . . . . . . . . . . . . 5 59 2.3.3. Address Selection Policy . . . . . . . . . . . . . . . 5 60 3. Current Practices in Some Operating Systems . . . . . . . . . 6 61 3.1. Mobile Handset Operating Systems . . . . . . . . . . . . . 6 62 3.1.1. Nokia S60 3rd Edition, Feature Pack 2 . . . . . . . . 7 63 3.1.2. Microsoft Windows Mobile and Windows Phone 7 . . . . . 9 64 3.1.3. RIM BlackBerry . . . . . . . . . . . . . . . . . . . . 10 65 3.1.4. Google Android . . . . . . . . . . . . . . . . . . . . 11 66 3.1.5. Qualcomm Brew . . . . . . . . . . . . . . . . . . . . 12 67 3.1.6. Leadcore Tech. Arena . . . . . . . . . . . . . . . . . 14 68 3.2. Desktop Operating Systems . . . . . . . . . . . . . . . . 14 69 3.2.1. Microsoft Windows . . . . . . . . . . . . . . . . . . 14 70 3.2.1.1. First hop selection . . . . . . . . . . . . . . . 14 71 3.2.1.2. Outbound and Inbound Addresses . . . . . . . . . . 14 72 3.2.1.3. DNS Configuration . . . . . . . . . . . . . . . . 15 73 3.2.2. Linux and BSD-based Operating Systems . . . . . . . . 16 74 3.2.2.1. First hop selection . . . . . . . . . . . . . . . 16 75 3.2.2.2. Outbound and Inbound Addresses . . . . . . . . . . 17 76 3.2.2.3. DNS Configuration . . . . . . . . . . . . . . . . 17 77 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 78 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 79 6. Security Considerations . . . . . . . . . . . . . . . . . . . 19 80 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 19 81 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 82 8.1. Normative References . . . . . . . . . . . . . . . . . . . 20 83 8.2. Informative References . . . . . . . . . . . . . . . . . . 20 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 86 1. Introduction 88 Multiple-interface hosts face several challenges not faced by single- 89 interface hosts, some of which are described in the MIF problem 90 statement, [I-D.ietf-mif-problem-statement]. This document 91 summarizes how current implementations deal with the problems 92 identified in the MIF problem statement. 94 Publicly-available information about the multiple-interface solutions 95 implemented in some widely used operating systems, including both 96 mobile handset and desktop operating systems, is collected in this 97 document, including: Nokia S60 [S60], Microsoft Windows Mobile 98 [WINDOWSMOBILE], Blackberry [BLACKBERRY], Google Android [ANDROID], 99 Microsoft Windows, Linux and BSD-based operating systems. 101 2. Summary of Current Approaches 103 This section summarizes current approaches that are used to resolve 104 the multi-interface issues described in the Multiple Interface 105 Problem Statement [I-D.ietf-mif-problem-statement]. These approaches 106 can be broken down into three major categories: 108 o Centralized connection management 110 o Per-application connection settings 112 o Stack-level solutions to specific problems 114 2.1. Centralized Connection Management 116 It is a common practice for mobile handset operating systems to use a 117 centralized connection manager that performs network interface 118 selection based on application or user input. However, connection 119 managers usually restrict the problem to the selection of the 120 interface and do not cope with selection of the provisioning domain, 121 as defined in [I-D.ietf-mif-problem-statement]. The information used 122 by the connection manager may be programmed into an application or 123 provisioned on a handset-wide basis. When information is not 124 available to make an interface selection, the connection manager will 125 query the user to choose between available choices. 127 Routing tables are not typically used for network interface selection 128 when a connection manager is in use, as the criteria for network 129 selection is not strictly IP-based but is also dependent on other 130 properties of the interface (cost, type, etc.). Furthermore, 131 multiple overlapping private IPv4 address spaces are often exposed to 132 a multiple-interface host, making it difficult to make interface 133 selection decisions based on prefix matching. 135 2.2. Per Application Connection Settings 137 In mobile handsets, applications are often involved in choosing what 138 interface and related configuration information should be used. In 139 some cases, the application selects the interface directly, and in 140 other cases the application provides more abstract information to a 141 connection manager that makes the final interface choice. 143 2.3. Stack-Level Solutions to Specific Problems 145 In most desktop operating systems, multiple interface problems are 146 dealt with in the stack and related components, based on system- 147 level configuration information, without the benefit of input from 148 applications or users. These solutions tend to map well to the 149 problems listed in the problem statement: 151 o DNS resolution issues 153 o Routing 155 o Address selection policy 157 The configuration information for desktop systems comes from one of 158 the following sources: DHCP, router advertisements, proprietary 159 configuration systems or manual configuration. While these systems 160 universally accept IP address assignment on a per-interface basis, 161 they differ in what set of information can be assigned on a per- 162 interface basis and what can be configured only on a per-system 163 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. First hop selection 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 material presented in this section is derived from contributions 239 from people familiar with the Operating Systems described, and those 240 people are listed in Section 7. The authors and the IETF take no 241 position about the Operating Systems described, and understand that 242 other Operating Systems also exist. Furthermore, it should be 243 understood that Section 3 describes particular behaviors that were 244 believed to be current at the time of documentation: earlier and 245 later versions of the Operating Systems described may exhibit 246 different behaviors. Please refer to the References section for 247 pointers to original documentation, including further details. 249 3.1. Mobile Handset Operating Systems 251 Cellular devices typically run a variety of applications in parallel, 252 each with different requirements for IP connectivity. A typical 253 scenario is shown in figure 1, where a cellular device is utilizing 254 WLAN access for web browsing and GPRS access for transferring 255 multimedia messages (MMS). Another typical scenario would be a real- 256 time VoIP session over one network interface in parallel with best 257 effort web browsing on another network interface. Yet another 258 typical scenario would be global Internet access through one network 259 interface and local (e.g. corporate VPN) network access through 260 another. 262 Web server MMS Gateway 263 | | 264 -+--Internet---- ----Operator network--+- 265 | | 266 +-------+ +-------+ 267 |WLAN AP| | GGSN | 268 +-------+ +-------+ 269 | +--------+ | 270 +--------|Cellular|--------+ 271 |device | 272 +--------+ 274 A cellular device with two network interfaces 276 Figure 1 278 Different network access technologies require different settings. 279 For example, WLAN requires Service Set Identifier (SSID) and the GPRS 280 network requires the Access Point Name (APN) of the Gateway GPRS 281 Support Node (GGSN), among other parameters. It is common that 282 different accesses lead to different destination networks (e.g. to 283 "Internet", "intranet", cellular network services, etc.). 285 3.1.1. Nokia S60 3rd Edition, Feature Pack 2 287 S60 is a software platform for mobile devices running on the Symbian 288 OS. S60 uses the concept of an Internet Access Point (IAP) [S60] 289 that contains all information required for opening a network 290 connection using a specific access technology. A device may have 291 several IAPs configured for different network technologies and 292 settings (multiple WLAN SSIDs, GPRS APNs, dial-up numbers, and so 293 forth). There may also be 'virtual' IAPs that define parameters 294 needed for tunnel establishment (e.g. for VPN). 296 For each application, a correct IAP needs to be selected at the point 297 when the application requires network connectivity. This is 298 essential, as the wrong IAP may not be able to support the 299 application or reach the desired destination. For example, MMS 300 application must use the correct IAP in order to reach the MMS 301 Gateway, which typically is not accessible from the public Internet. 302 As another example, an application might need to use the IAP 303 associated with its corporate VPN in order to reach internal 304 corporate servers. Binding applications to IAPs avoids several 305 problems, such as choosing the correct DNS server in the presence of 306 split DNS (as an application will use the DNS server list from its 307 bound IAP), and overlapping private IPv4 address spaces used for 308 different interfaces (as each application will use the default routes 309 from its bound IAP). 311 If multiple applications utilize the same IAP, the underlying network 312 connection can typically be shared. This is often the case when 313 multiple Internet-using applications are running in parallel. 315 The IAP for an application can be selected in multiple ways: 317 o Statically: e.g. from a configuration interface, via client 318 provisioning/device management system, or at build-time. 320 o Manually by the user: e.g. each time an application starts the 321 user may be asked to select the IAP to use. This may be needed, 322 for example, if a user sometimes wishes to access his corporate 323 intranet and other times would prefer to access the Internet 324 directly. 326 o Automatically by the system: after the destination network has 327 been selected statically or dynamically. 329 The static approach is fine for certain applications, like MMS, for 330 which configuration can be provisioned by the network operator and 331 does not change often. Manual selection works, but may be seen as 332 troublesome by the user. An automatic selection mechanism needs to 333 have some way of knowing which destination network the user, or an 334 application, is trying access. 336 S60 3rd Edition, Feature Pack 2, introduces a concept of Service 337 Network Access Points (SNAPs) that group together IAPs that lead to 338 the same destination. This enables static or manual selection of the 339 destination network for an application and leaves the problem of 340 selecting the best of the available IAPs within a SNAP to the 341 operating system. 343 When SNAPs are used, the operating system can notify applications 344 when a preferred IAP, leading to the same destination, becomes 345 available (for example, when a user comes within range of his home 346 WLAN access point), or when the currently used IAP is no longer 347 available. If so, applications have to reconnect via another IAP 348 (for example, when a user goes out of range of his home WLAN and must 349 move to the cellular network). 351 In S60 3.2 does not support RFC 3484 for source address selection 352 mechanisms. Applications are tightly bound the network interface 353 selected for them or by them. E.g. an application may be connected 354 to IPv6 3G connection, IPv4 3G connection, WLAN connection, or VPN 355 connection. The application can change between the connections, but 356 uses only one at a time. If the interface happens to be dual-stack, 357 then IPv4 is preferred over IPv6. 359 DNS configuration is per-interface; an application bound to an 360 interface will always use the DNS settings for that interface. Hence 361 the device itself remembers these pieces of information for each 362 interface separately. 364 The S60 3.2 manages with totally overlapping addresses spaces. Each 365 interface can even have same IPv4 address configured on it without 366 issues. This is so because interfaces are kept totally separate from 367 each other. This also implies that the interface selection has to be 368 done at application layer, as from network layer point of view device 369 is not multihomed in the IP-sense. 371 Please see the source documentation for more details and screenshots: 372 [S60]. 374 3.1.2. Microsoft Windows Mobile and Windows Phone 7 376 Microsoft Windows Mobile leverages on a Connection Manager 377 [WINDOWSMOBILE] to handle multiple network connections. This 378 architecture centralizes and automates network connection 379 establishment and management, and makes it possible to automatically 380 select a connection, to dial-in automatically or by user initiation, 381 and to optimize connection and shared resource usage. Connection 382 Manager periodically re-evaluates the validity of the connection 383 selection. The Connection Manager uses various attributes such as 384 cost, security, bandwidth, error rate, and latency in its decision 385 making. 387 The Connection Manager selects the best possible connection for the 388 application based on the destination network the application wishes 389 to reach. The selection is made between available physical and 390 virtual connections (e.g. VPN, GPRS, WLAN, and wired Ethernet) that 391 are known to provide connectivity to the destination network, and the 392 selection is based on the costs associated with each connection. 393 Different applications are bundled to use the same network connection 394 when possible, but in conflict situations when a connection cannot be 395 shared, higher priority applications take precedence, and the lower 396 priority applications lose connectivity until the conflict situation 397 clears. 399 During operation, Connection Manager opens new connections as needed, 400 and also disconnects unused or idle connections. 402 To optimize resource use, such as battery power and bandwidth, 403 Connection Manager enables applications to synchronize network 404 connection usage by allowing applications to register their 405 requirements for periodic connectivity. An application is notified 406 when a suitable connection becomes available for its use. 408 In comparison to Windows Mobile connection management, Windows phone 409 7 updates the routing functionality in the case where the terminal 410 can be attached simultaneously to several interfaces. Windows Phone 411 7 selects the first hop corresponding to the interface which has a 412 lower metric. When there are multiple interfaces, the applications 413 system will, by default, choose from an ordered list of available 414 interfaces. The default connection policy will prefer wired over 415 wireless and WLAN over cellular. Hence, if an application wants to 416 use cellular 3G as the active interface when WLAN is available, the 417 application needs to override the default connection mapping policy. 418 An application specific mapping policy can be set via a microsoft API 419 or provisioned by the Mobile Operator. The application, in 420 compliance with the security model, can request connection type by 421 interface (WLAN, cellular), by minimum interface speed (x kbps, y 422 mbps), or by name (Access Point Name). 424 In dual-stack systems, Windows mobile and Windows phone 7 implement 425 adress selection rules as per [WNDS-RFC3484]. An administrator can 426 configure a policy table that can override the default behavior of 427 the selection algorithms. It is reminded that the policy table 428 specifies precedence values and preferred source prefixes for 429 destination prefixes (see [RFC3484], section 2.1, for details). If 430 the system has not been configured, then the default policy table 431 specified in [RFC3484] is used. 433 3.1.3. RIM BlackBerry 435 Depending on the network configuration, applications in Research In 436 Motion (RIM) BlackBerry devices [BLACKBERRY] can use direct TCP/IP 437 connectivity or different application proxys to establish connections 438 over the wireless network. For instance, some wireless service 439 providers provide an Internet gateway to offer direct TCP/IP 440 connectivity to the Internet while some others can provide a WAP 441 gateway that allows HTTP connections to occur over the WAP (Wireless 442 Application Protocol) protocol. It is also possible to use the 443 BlackBerry Enterprise Server [BLACKBERRY] as a network gateway, The 444 BlackBerry Enterprise Server provides an HTTP and TCP/IP proxy 445 service to allow the application to use it as a secure gateway for 446 managing HTTP and TCP/IP connections to the intranet or the Internet. 447 An application connecting to the Internet, can use either the 448 BlackBerry Internet Service or the Internet gateway of the wireless 449 server provider or direct Internet connectivity over WLAN to manage 450 connections. The problem of gateway selection is supposed to be 451 managed independently by each application. For instance, an 452 application can be designed to always use the default Internet 453 gateway, while another application can be designed to use a preferred 454 proxy when available. 456 A BlackBerry device [BLACKBERRY] can be attached to multiple networks 457 simultaneously (wireless/wired). In this case, Multiple network 458 interfaces can be associated to a single IP stack or multiple IP 459 stacks. The device, or the application, can select the network 460 interface to be used in various ways. For instance, the device can 461 always map the applications to the default network interface (or the 462 default access network). When muliple IP stacks are associated to 463 multiple interfaces, the application can select the source address 464 correponding to the preferred network interface. Per-interface IP 465 stacks also allow to manage overlapping addresses spaces. When 466 multiple network interfaces are aggregated into a single IP stack, 467 the device associates each application to the more appropriate 468 network interface. The selection can be based on cost, type-of- 469 service and/or user preference. 471 The BlackBerry uses per-interface DNS configuration; applications 472 bound to a specific interface will use the DNS settings for that 473 interface. 475 3.1.4. Google Android 477 Android is based on a Linux kernel and, in many situations, behaves 478 like a Linux device as described in Section 3.2.2. As per Linux, 479 Android can manage multiple routing tables and rely on policy based 480 routing associated with packet filtering capabilities (see 481 Section 3.2.2.1 for details). Such a framework can be used to solve 482 complex routing issue brought by multiple interfaces terminals, e.g. 483 address space overlapping. 485 For incoming packets, Android implements the weak host model 486 [RFC1122] on both IPv4 and IPv6. However, Android can also be 487 configured to support the strong host model. 489 Regarding DNS configuration, Android does not list the DNS servers in 490 the file /etc/resolv.conf, used by Linux. However, as per Linux, DNS 491 configuration is node-scoped, even if DNS configuration can rely on 492 the DHCP client. For instance, the udhcp client [UDHCP], which is 493 also available for Linux, can be used on Android. Each time new 494 configuration data is received by the host from a DHCP server, 495 regardless of which interface it is received on, the DHCP client 496 rewrites the global configuration data with the most recent 497 information received. 499 Actually, the main difference between Linux and Android is on the 500 address selection mechanism. Android version prior to 2.2 simply 501 prefers IPv6 connectivity over IPv4. However, it should be noted 502 that, at the time of writing, IPv6 is available only on WiFi and 503 virtual interfaces, but not on the cellular interface (without IPv6 504 in IPv4 encapsulation). Android 2.2 has been updated with 505 [ANDROID-RFC3484], which implements some of the address selection 506 rules defined in [RFC3484]. All RFC3484 rules are supported, except 507 rule 3 (avoid deprecated addresses), 4 (prefer home addresses) and 7 508 (prefer native transport). Also, rule 9 (use longest matching 509 prefix) has been modified so it does not sort IPv4 addresses. 511 The Android reference documentation describes the android.net package 512 [ANDROID] and the ConnectivityManager class that applications can use 513 to request the first hop to a specified destination address via a 514 specified network interface (3GPP or WLAN). Applications also ask 515 Connection Manager for permission to start using a network feature. 516 The Connectivity Manager monitors changes in network connectivity and 517 attempts to failover to another network if connectivity to an active 518 network is lost. When there are changes in network connectivity, 519 applications are notified. Applications are also able to ask for 520 information about all network interfaces, including their 521 availability, type and other information. 523 3.1.5. Qualcomm Brew 525 This section describes how multi-interface support is handled by 526 Advanced Mobile Station Software (AMSS) that comes with Brew OS for 527 all Qualcomm chipsets (e.g., MSM, Snapdragon etc). AMSS is a low 528 level connectivity platform, on top of which manufacturers can build 529 to provide the necessary connectivity to applications. The 530 interaction model between AMSS, the Operating System, and the 531 applications is not unique and depend on the design chosen by the 532 manufacturer. The Mobile OS can let an application invoke the AMSS 533 directly (via API), or provide its own connection manager that will 534 request connectivity to the AMSS based on applications needs. The 535 interaction between the OS connection manager and the applications is 536 OS dependent. 538 AMSS supports a concept of netpolicy which allows each application to 539 specify the type of network connectivity desired. The netpolicy 540 contains parameters such as access technology, IP version type and 541 network profile. Access technology could be a specific technology 542 type such as CDMA or WLAN or could be a group of technologies, such 543 as ANY_Cellular or ANY_Wireless. IP version could be one of IPv4, 544 IPv6 or Default. The network profile identifies a type of network 545 domain or service within a certain network technology, such as 3GPP 546 APN or Mobile IP Home Agent. It also specifies all the mandatory 547 parameters required to connect to the domain such authentication 548 credentials and other optional parameters such as QoS attributes. 550 Network Profile is technology specific and set of parameters 551 contained in the profile could vary for different technologies. 553 Two models of network usage are supported: 555 o Applications requiring network connectivity specify an appropriate 556 netpolicy in order to select the desired network. The netpolicy 557 may match one or more network interfaces. AMSS system selection 558 module selects the best interface out of the ones that match the 559 netpolicy based on various criteria such as cost, speed or other 560 provisioned rules. Application explicitly starts the selected 561 network interface and, as a result, the application also gets 562 bound to the corresponding network interface. All outbound 563 packets from this application are always routed over this bound 564 interface using the source address of the interface. 566 o Applications may rely on a separate connection manager to control 567 (e.g. start/stop) the network interface. In this model, 568 applications are not necessarily bound to any one interface. All 569 outbound packets from such applications are routed on one of the 570 interfaces that match its netpolicy. The routing decision is made 571 individually for each packet and selects the best interface based 572 on the criteria described above and the destination address. 573 Source address is always that assigned to the interface used to 574 transmit the packet. 576 All of the routing/interface selection decisions are based on the 577 netpolicy and not just on the destination address to avoid 578 overlapping private IPv4 address issue. This also allows multiple 579 interfaces to be configured with the same IP address, for example, to 580 handle certain tunnelling scenarios. Applications that do not 581 specify a netpolicy are routed by AMSS to the best possible interface 582 using the default netpolicy. Default netpolicy could be pre-defined 583 or provisioned by the administrator or operator. Hence default 584 interface could vary from device to device and also depends upon the 585 available networks at any given time. 587 AMSS allows each interface to be configured with its own set of DNS 588 configuration parameters (e.g. list of DNS servers, domain names 589 etc.). Interface selected to make a DNS resolution is the one to 590 which application making the DNS query is bound. Applications can 591 also specify a different netpolicy as part of DNS request to select 592 another interface for DNS resolution. Regardless, all the DNS 593 queries are sent only over this selected interface using the DNS 594 configuration from the interface. DNS resolution is first attempted 595 with the primary server configured in the interface. If a response 596 is not received, the queries are sent to all the other servers 597 configured in the interface in a sequential manner using a backoff 598 mechanism. 600 3.1.6. Leadcore Tech. Arena 602 Arena, a mobile OS based on Linux, provides a Connection Manager, 603 which is described in [I-D.zhang-mif-connection-manager-arena] and 604 [I-D.yang-mif-connection-manager-impl-req]. The arena connection 605 manager provides a means for applications to register their 606 connectivity requirement. The Connection Manager can then choose an 607 interface that matches the application's needs while considering 608 other factors such as availability, cost and stability. Also, the 609 Connection Manager can handle multiple-interfaces issues such as 610 connection sharing. 612 3.2. Desktop Operating Systems 614 Multi-interface issues also occur in desktop environments in those 615 cases where a desktop host has multiple (logical or physical) 616 interfaces connected to networks with different reachability 617 properties, such as one interface connected to the global Internet, 618 while another interface is connected to a corporate VPN. 620 3.2.1. Microsoft Windows 622 The multi-interface functionality currently implemented in Microsoft 623 Windows operation systems is described in more detail in 624 [I-D.montenegro-mif-multihoming]. 626 3.2.1.1. First hop selection 628 It is possible, although not often desirable, to configure default 629 routers on more than one Windows interface. In this configuration, 630 Windows will use the default route on the interface with the lowest 631 routing metric (i.e. the fastest interface). If multiple interfaces 632 share the same metric, the behavior will differ based on the version 633 of Windows in use. Prior to Windows Vista, the packet would be 634 routed out of the first interface that was bound to the TCP/IP stack, 635 the preferred interface. In Windows vista, host-to-router load 636 sharing [RFC4311] is used for both IPv4 and IPv6. 638 3.2.1.2. Outbound and Inbound Addresses 640 If the source address of the outgoing packet has not been determined 641 by the application, Windows will choose from the addresses assigned 642 to its interfaces. Windows implements [RFC3484] for source address 643 selection in IPv6 and, in Windows Vista, for IPv4. Prior to Windows 644 Vista, IPv4 simply chose the first address on the outgoing interface. 646 For incoming packets, Windows will check if the destination address 647 matches one of the addresses assigned to its interfaces. Windows has 648 implemented the weak host model [RFC1122] on IPv4 in Windows 2000, 649 Windows XP and Windows Server 2003. The strong host model became the 650 default for IPv4 in Windows Vista and Windows server 2008, however 651 the weak host model is available via per-interface configuration. 652 IPv6 has always implemented the strong host model. 654 3.2.1.3. DNS Configuration 656 Windows largely relies on suffixes to solve DNS resolution issues. 657 Suffixes are used for four different purposes that are reminded 658 hereafter: 660 1. DNS Suffix Search List (aka domain search list): suffix is added 661 to non-FQDN names. 663 2. Interface-specific suffix list, which allows sending different 664 DNS queries to different DNS servers. 666 3. Suffix to control Dynamic DNS Updates: determine which DNS server 667 will receive a dynamic update for a name with a certain suffix. 669 4. Suffix in the Name Resolution Policy Table [NRPT] to aid in 670 identifying a Namespace that requires special handling (feature 671 available only after Windows 7 and its server counterpart, 672 Windows Server 2008 R2). 674 However, this section focuses on the interface-specific suffix list 675 since it is the only suffix usage in the scope of this document. 677 DNS configuration information can be host-wide or interface specific. 678 Host-wide DNS configuration is input via static configuration or, in 679 sites that use Active Directory, Microsoft's Group Policy. Interface 680 specific DNS configuration can be input via static configuration or 681 via DHCP. 683 The host-wide configuration consists of a primary DNS suffix to be 684 used for the local host, as well as a list of suffix that can be 685 appended to names being queried. Before Windows Vista and Windows 686 Server 2008, there was also a host-wide DNS server list that took 687 precedent over per-interface DNS configuration. 689 The interface-specific DNS configuration comprises an interface- 690 specific suffix list and a list of DNS server IP addresses. 692 Windows uses a host-wide "effective" server list for an actual query, 693 where the effective server list may be different for different names. 695 In the list of DNS server addresses, the first server is considered 696 the "primary" server, with all other servers being secondary. 698 When a DNS query is performed in Windows, the query is first sent to 699 the primary DNS server on the preferred interface. If no response is 700 received in one second, the query is sent to the primary DNS servers 701 on all interfaces under consideration. If no response is received 702 for 2 more seconds, the DNS server sends the query to all of the DNS 703 servers on the DNS server lists for all interfaces under 704 consideration. If the host still doesn't receive a response after 4 705 seconds, it will send to all of the servers again and wait 8 seconds 706 for a response. 708 3.2.2. Linux and BSD-based Operating Systems 710 3.2.2.1. First hop selection 712 In addition to the two commonly used routing tables (the local and 713 main routing tables), the kernel can support up to 252 additional 714 routing tables which can be added in the file /etc/iproute2/ 715 rt_tables. A routing table can contain an arbitrary number of 716 routes, the selection of route is classically made according to the 717 destination address of the packet. Linux also provides more flexible 718 routing selection based on the Type of Service, scope, output 719 interface. In addition, since kernel version 2.2, Linux supports 720 policy based routing using the multiple routing tables capability and 721 a routing policy database. This database contains routing rules used 722 by the kernel. Using policy based routing, the source address, the 723 ToS flags, the interface name and an "fwmark" (a mark carried through 724 added in the data structure representing the packet) can be used as 725 route selectors. 727 Policy based routing can be used in addition to Linux packet 728 filtering capabilities, e.g provided by the "iptables" tool. In a 729 multiple interfaces context, this tool can be used to mark the 730 packets, i.e assign a number to fwmark, in order to select the 731 routing rule according to the type of traffic. This mark can be 732 assigned according to parameters like protocol, source and/or 733 destination addresses, port number and so on. 735 Such a routing management framework allows to deal with complex 736 situation such as address space overlapping. In this situation, the 737 administrator can use packet marking and policy based routing to 738 select the correct interface. 740 3.2.2.2. Outbound and Inbound Addresses 742 By default, source address selection follows the following basics 743 rules: the initial source address for an outbound packet can be 744 chosen by the application using the bind() call. Without information 745 from the application, the kernel chooses the first address configured 746 on the interface which belongs to the same subnet than the 747 destination address or the nexthop router. 749 Linux also implements [RFC3484] for source address selection for IPv6 750 and dual-stack configurations. However, the address sorting rules 751 from [RFC3484] are not always adequate. For this reason, Linux 752 allows the system administrator to dynamically change the sorting. 753 This can be achieved with the /etc/gai.conf file. 755 For incoming packets, Linux checks if the destination address matches 756 one of the addresses assigned to its interfaces then, processes the 757 packet according the configured host model. By default, Linux 758 implements the weak host model [RFC1122] on both IPv4 and IPv6. 759 However, Linux can also be configured to support the strong host 760 model. 762 3.2.2.3. DNS Configuration 764 Most BSD and Linux distributions rely on their DHCP client to handle 765 the configuration of interface-specific information (such as an IP 766 address and netmask), and a set of system-wide configuration 767 information, (such a DNS server list, an NTP server list and default 768 routes). Users of these operating systems have the choice of using 769 any DHCP client available for their platform, with an operating 770 system default. This section discusses the behavior of several DHCP 771 clients that may be used with Linux and BSD distributions. 773 The Internet Systems Consortium (ISC) DHCP Client [ISCDHCP] and its 774 derivative for OpenBSD [OPENBSDDHCLIENT] can be configured with 775 specific instructions for each interface. However, each time new 776 configuration data is received by the host from a DHCP server, 777 regardless of which interface it is received on, the DHCP client 778 rewrites the global configuration data, such as the default routes 779 and the DNS server list (in /etc/resolv.conf) with the most recent 780 information received. Therefore, the last configured interface 781 always become the primary one. The ISC DHCPv6 client behaves 782 similarly. However, OpenBSD provides two mechanisms allowing to not 783 overwrite the configuration that the user made manually: 785 o OPTION MODIFIERS (default, supersede, prepend, and append): this 786 mechanism allows the user to override the DHCP options. For 787 example, the supersede statement defines, for some options, the 788 values the client should always use rather than any value supplied 789 by the server. 791 o resolv.conf.tail: it allows the user to append anything to the 792 resolv.conf file created by the DHCP client. 794 The Phystech dhcpcd client [PHYSTECHDHCPC] behaves similarly to the 795 ISC client. It replaces the DNS server list in /etc/resolv.conf and 796 the default routes each time new DHCP information is received on any 797 interface. However, the -R flag can be used to instruct the client 798 to not replace the DNS servers in /etc/resolv.conf. However, this 799 flag is a global flag for the DHCP server, and is therefore 800 applicable to all interfaces. When dhcpd is called with the -R flag, 801 the DNS servers are never replaced. 803 The pump client [PUMP] also behaves similarly to the ISC client. It 804 replaces the DNS servers in /etc/resolv.conf and the default routes 805 each time new DHCP information is received on any interface. 806 However, the nodns and nogateway options can be specified on a per 807 interface basis, enabling the user to define which interface should 808 be used to obtain the global configuration information. 810 The udhcp client [UDHCP] is often used in embedded platforms based on 811 busybox. The udhcp client behaves similarly to the ISC client. It 812 rewrites default routes and the DNS server list each time new DHCP 813 information is received. 815 Redhat-based distributions, such as Redhat, Centos and Fedora have a 816 per-interface configuration option (PEERDNS) that indicates that the 817 DNS server list should not be updated based on configuration received 818 on that interface. 820 The most configurable DHCP clients can be set to define a primary 821 interface to use only that interface for the global configuration 822 data. However, this is limited, since a mobile host might not always 823 have the same set of interfaces available. Connection managers may 824 help in this situation. 826 Some distributions also have a connection manager. However, most 827 connection managers serve as a GUI to the DHCP client, therefore not 828 changing the functionality described above. 830 4. Acknowledgements 832 Authors of the document would like to thank following people for 833 their input and feedback: Dan Wing, Hui Deng, Jari Arkko, Julien 834 Laganier and Steinar H. Gunderson. 836 5. IANA Considerations 838 This memo includes no request to IANA. 840 6. Security Considerations 842 This document describes current operating system implementations and 843 how they handle the issues raised in the MIF problem statement. 844 While it is possible that the currently implemented mechanisms 845 described in this document may affect the security of the systems 846 described, this document merely reports on current practice. It does 847 not attempt to analyze the security properties (or any other 848 architectural properties) of the currently implemented mechanisms. 850 7. Contributors 852 The following people contributed most of the per-Operating System 853 information found in this document: 855 o Marc Blanchet, Viagenie 857 o Hua Chen, Leadcoretech, Ltd. 859 o Yan Zhang, Leadcoretech Ltd. 861 o Shunan Fan, Huawei Technology 863 o Jian Yang, Huawei Technology 865 o Gabriel Montenegro, Microsoft Corporation 867 o Shyam Seshadri, Microsoft Corporation 869 o Dave Thaler, Microsoft Corporation 871 o Kevin Chin, Microsoft Corporation 873 o Teemu Savolainen, Nokia 875 o Tao Sun, China Mobile 877 o George Tsirtsis, Qualcomm. 879 o David Freyermuth, France telecom. 881 o Aurelien Collet, Altran. 883 o Giyeong Son, RIM. 885 8. References 887 8.1. Normative References 889 [I-D.ietf-mif-problem-statement] 890 Blanchet, M. and P. Seite, "Multiple Interfaces and 891 Provisioning Domains Problem Statement", 892 draft-ietf-mif-problem-statement-15 (work in progress), 893 May 2011. 895 8.2. Informative References 897 [ANDROID] Google Inc., "Android developers: package android.net", 898 2009, . 901 [ANDROID-RFC3484] 902 Gunderson, S., "RFC 3484 support for Android", 2010, . 906 [BLACKBERRY] 907 Research In Motion Limited, "BlackBerry Java Development 908 Environment - Fundamentals Guide: Wireless gateways", 909 2009, . 912 [I-D.montenegro-mif-multihoming] 913 Montenegro, G., Thaler, D., and S. Seshadri, "Multiple 914 Interfaces on Windows", 915 draft-montenegro-mif-multihoming-00 (work in progress), 916 March 2009. 918 [I-D.yang-mif-connection-manager-impl-req] 919 Yang, J., Sun, T., and S. Fan, "Multi-interface Connection 920 Manager Implementation and Requirements", 921 draft-yang-mif-connection-manager-impl-req-00 (work in 922 progress), March 2009. 924 [I-D.zhang-mif-connection-manager-arena] 925 Zhang, Y., Sun, T., and H. Chen, "Multi-interface Network 926 Connection Manager in Arena Platform", 927 draft-zhang-mif-connection-manager-arena-00 (work in 928 progress), February 2009. 930 [ISCDHCP] Internet Software Consortium, "ISC DHCP", 2009, 931 . 933 [NRPT] Windows, "Name Resolution Policy Table", February 2010, < 934 http://technet.microsoft.com/en-us/magazine/ 935 ff394369.aspx>. 937 [OPENBSDDHCLIENT] 938 OpenBSD, "OpenBSD dhclient", 2009, 939 . 941 [PHYSTECHDHCPC] 942 Phystech, "dhcpcd", 2009, 943 . 945 [PUMP] RedHat, "PUMP", 2009, . 947 [RFC1122] Braden, R., "Requirements for Internet Hosts - 948 Communication Layers", STD 3, RFC 1122, October 1989. 950 [RFC3484] Draves, R., "Default Address Selection for Internet 951 Protocol version 6 (IPv6)", RFC 3484, February 2003. 953 [RFC4311] Hinden, R. and D. Thaler, "IPv6 Host-to-Router Load 954 Sharing", RFC 4311, November 2005. 956 [RFC5113] Arkko, J., Aboba, B., Korhonen, J., and F. Bari, "Network 957 Discovery and Selection Problem", RFC 5113, January 2008. 959 [S60] Nokia Corporation, "S60 Platform: IP Bearer Management", 960 2007, . 964 [UDHCP] Busybox, "uDHCP", 2009, . 967 [WINDOWSMOBILE] 968 Microsoft Corporation, "SDK Documentation for Windows 969 Mobile-Based Smartphones: Connection Manager", 2005, 970 . 972 [WNDS-RFC3484] 973 Microsoft Corporation, "SDK Documentation for Windows 974 Mobile-Based Smartphones: Default Address Selection for 975 IPv6", 2005, 976 . 978 Authors' Addresses 980 Margaret Wasserman 981 Painless Security, LLC 982 356 Abbott Street 983 North Andover, MA 01845 984 USA 986 Phone: +1 781 405-7464 987 Email: mrw@painless-security.com 988 URI: http://www.painless-security.com 990 Pierrick Seite 991 France Telecom - Orange 992 4, rue du clos courtel BP 91226 993 Cesson-Sevigne 35512 994 France 996 Email: pierrick.seite@orange-ftgroup.com