idnits 2.17.1 draft-ietf-mif-current-practices-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 19, 2009) is 5302 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-00 -- Obsolete informational reference (is this intentional?): RFC 3484 (Obsoleted by RFC 6724) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force M. Wasserman, Ed. 3 Internet-Draft Sandstorm Enterprises 4 Intended status: Informational October 19, 2009 5 Expires: April 22, 2010 7 Current Practices for Multiple Interface Hosts 8 draft-ietf-mif-current-practices-00 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on April 22, 2010. 33 Copyright Notice 35 Copyright (c) 2009 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents in effect on the date of 40 publication of this document (http://trustee.ietf.org/license-info). 41 Please review these documents carefully, as they describe your rights 42 and restrictions with respect to this document. 44 Abstract 46 An increasing number of hosts are operating in multiple-interface 47 environments, where different network interfaces are providing 48 unequal levels of service or connectivity. This document summarizes 49 current practices in this area, and describes in detail how some 50 common operating systems cope with these challenges. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Summary of Current Approaches . . . . . . . . . . . . . . . . 3 56 2.1. Centralized Connection Management . . . . . . . . . . . . 3 57 2.2. Per Application Connection Settings . . . . . . . . . . . 4 58 2.3. Stack-Level Solutions to Specific Problems . . . . . . . . 4 59 2.3.1. DNS Resolution Issues . . . . . . . . . . . . . . . . 5 60 2.3.2. Routing . . . . . . . . . . . . . . . . . . . . . . . 5 61 2.3.3. Address Selection Policy . . . . . . . . . . . . . . . 5 62 3. Current Practices in Some Operating Systems . . . . . . . . . 6 63 3.1. Mobile Handset Operating Systems . . . . . . . . . . . . . 6 64 3.1.1. Nokia S60 3rd Edition, Feature Pack 2 . . . . . . . . 7 65 3.1.2. Microsoft Windows Mobile 2003 Second Edition . . . . . 8 66 3.1.3. BlackBerry . . . . . . . . . . . . . . . . . . . . . . 9 67 3.1.4. Google Android . . . . . . . . . . . . . . . . . . . . 9 68 3.1.5. Arena Connection Manager . . . . . . . . . . . . . . . 9 69 3.2. Desktop Operating Systems . . . . . . . . . . . . . . . . 10 70 3.2.1. Microsoft Windows . . . . . . . . . . . . . . . . . . 10 71 3.2.1.1. Routing . . . . . . . . . . . . . . . . . . . . . 10 72 3.2.1.2. Outbound and Inbound Addresses . . . . . . . . . . 10 73 3.2.1.3. DNS Configuration . . . . . . . . . . . . . . . . 10 74 3.2.2. Linux and BSD-based Operating Systems . . . . . . . . 11 75 3.2.3. Apple Mac OS X . . . . . . . . . . . . . . . . . . . . 12 76 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 77 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 78 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 79 7. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 13 80 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 14 81 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 82 9.1. Normative References . . . . . . . . . . . . . . . . . . . 14 83 9.2. Informative References . . . . . . . . . . . . . . . . . . 15 84 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16 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, Apple Mac OS X, Linux and BSD-based operating 100 systems. 102 2. Summary of Current Approaches 104 This section summarizes current approaches that are used to resolve 105 the multi-interface issues described in the Multiple Interface 106 Problem Statement [I-D.ietf-mif-problem-statement]. These approaches 107 can be broken down into three major categories: 109 o Centralized connection management 111 o Per-application connection settings 113 o Stack-level solutions to specific problems 115 2.1. Centralized Connection Management 117 It is a common practice for mobile handset operating systems to use a 118 centralized connection manager that performs network interface 119 selection based on application or user input. The information used 120 by the connection manager may be programmed into an application or 121 provisioned on a handset-wide basis. When information is not 122 available to make an interface selection, the connection manager will 123 query the user to choose between available choices. 125 Routing tables are not typically used for network interface selection 126 when a connection manager is in use, as the criteria for network 127 selection is not strictly IP-based but is also dependent on other 128 properties of the interface (cost, type, etc.). Furthermore, 129 multiple overlapping private IPv4 address spaces are often exposed to 130 a multiple-interface host, making it difficult to make interface 131 selection decisions based on prefix matching. 133 2.2. Per Application Connection Settings 135 In mobile handsets, applications are often involved in choosing what 136 interface and related configuration information should be used. In 137 some cases, the application selects the interface directly, and in 138 other cases the application provides more abstract information to a 139 connection manager that makes the final interface choice. 141 2.3. Stack-Level Solutions to Specific Problems 143 In most desktop operating systems, multiple interface problems are 144 dealt with in the stack and related components, based on system- 145 level configuration information, without the benefit of input from 146 applications or users. These solutions tend to map well to the 147 problems listed in the problem statement: 149 o DNS resolution issues 151 o Routing 153 o Address selection policy 155 The configuration information for desktop systems comes from one of 156 three sources: DHCP, proprietary configuration systems or manual 157 configuration. While these systems universally accept IP address 158 assignment on a per-interface basis, they differ in what set of 159 information can be assigned on a per-interface basis and what can be 160 configured only on a per-system basis. 162 When choosing between multiple sets of information provided, these 163 systems will typically give preference to information received on the 164 "primary" interface. The mechanism for designating the "primary" 165 interface differs by system. 167 There is very little commonality in how desktop operating systems 168 handle multiple sets of configuration information, with notable 169 variations between different versions of the same operating system 170 and/or within different software packages built for the same 171 operating system. Although these systems differ widely, it is not 172 clear that any of them provide a completely satisfactory user 173 experience in multiple-interface environments. 175 The following sections discuss some of the solutions used in each of 176 the areas raised in the MIF problem statement. 178 2.3.1. DNS Resolution Issues 180 There is very little commonality in how desktop operating systems 181 handle the DNS server list. Some systems support per-interface DNS 182 server lists, while others only support a single system-wide list. 184 On hosts with per-interface DNS server lists, different mechanisms 185 are used to determine which DNS server is contacted for a given 186 query. In most cases, the first DNS server listed on the "primary" 187 interface is queried first, with back off to other servers if an 188 answer is not received. 190 Systems that support a single system-wide list differ in how they 191 select which DNS server to use in cases where they receive more than 192 one DNS server list to configure (e.g. from DHCP on multiple 193 interfaces). Some accept the information received on the "primary" 194 interface, while others use either the first or last set DNS server 195 list configured. 197 2.3.2. Routing 199 Routing information is also handled differently on different desktop 200 operating systems. While all systems maintain some sort of routing 201 cache, to handle redirects and/or statically configured routes, most 202 packets are routed based on configured default gateway information. 204 Some systems do allow the configuration of different default router 205 lists for different interfaces. These systems will always choose the 206 default gateway on the interface with the lowest routing metric, with 207 different behavior when two or more interfaces have the same routing 208 metric. 210 Most systems do not allow the configuration of more than one default 211 router list, choosing instead to use the first or last default router 212 list configured and/or the router list configured on the "primary" 213 interface. 215 2.3.3. Address Selection Policy 217 There is somewhat more commonality in how desktop hosts handle 218 address selection. Applications typically provide the destination 219 address for an outgoing packet, and the IP stack is responsible for 220 picking the source address. 222 IPv6 specifies a specific source address selection mechanism in 223 [RFC3484], and several systems implement this mechanism with similar 224 support for IPv4. However, many systems do not provide any mechanism 225 to update this default policy, and there is no standard way to do so. 227 In some cases, the routing decision (including which interface to 228 use) is made before source address selection is performed, and a 229 source address is chosen from the outbound interface. In other 230 cases, source address selection is performed before, or independently 231 from outbound interface selection. 233 3. Current Practices in Some Operating Systems 235 The following sections briefly describe the current multiple- 236 interface host implementations on some widely-used operating systems. 237 Please refer to the References section for pointers to original 238 documentation on most of these systems, including further details. 240 3.1. Mobile Handset Operating Systems 242 Cellular devices typically run a variety of applications in parallel, 243 each with different requirements for IP connectivity. A typical 244 scenario is shown in figure 1, where a cellular device is utilizing 245 WLAN access for web browsing and GPRS access for transferring 246 multimedia messages (MMS). Another typical scenario would be a real- 247 time VoIP session over one network interface in parallel with best 248 effort web browsing on another network interface. Yet another 249 typical scenario would be global Internet access through one network 250 interface and local (e.g. corporate VPN) network access through 251 another. 253 Web server MMS Gateway 254 | | 255 -+--Internet---- ----Operator network--+- 256 | | 257 +-------+ +-------+ 258 |WLAN AP| | GGSN | 259 +-------+ +-------+ 260 | +--------+ | 261 +--------|Cellular|--------+ 262 |device | 263 +--------+ 265 A cellular device with two network interfaces 267 Figure 1 269 Different network access technologies require different settings. 270 For example, WLAN requires Service Set Identifier (SSID) and the GPRS 271 network requires the Access Point Name (APN) of the Gateway GPRS 272 Support Node (GGSN), among other parameters. It is common that 273 different accesses lead to different destination networks (e.g. to 274 "Internet", "Intranet", cellular network services, etc.). 276 3.1.1. Nokia S60 3rd Edition, Feature Pack 2 278 S60 uses the concept of an Internet Access Point (IAP) [S60] that 279 contains all information required for opening a network connection 280 using a specific access technology. A device may have several IAPs 281 configured for different network technologies and settings (multiple 282 WLAN SSIDs, GPRS APNs, dial-up numbers, and so forth). There may 283 also be 'virtual' IAPs that define parameters needed for tunnel 284 establishment (e.g. for VPN). 286 For each application, a correct IAP needs to be selected at the point 287 when the application requires network connectivity. This is 288 essential, as the wrong IAP may not be able to support the 289 application or reach the desired destination. For example, MMS 290 application must use the correct IAP in order to reach the MMS 291 Gateway, which typically is not accessible from the public Internet. 292 As another example, an application might need to use the IAP 293 associated with its corporate VPN in order to reach internal 294 corporate servers. Binding applications to IAPs avoids several 295 problems, such as choosing the correct DNS server in the presence of 296 split DNS (as an application will use the DNS server list from its 297 bound IAP), and overlapping private IPv4 address spaces used for 298 different interfaces (as each application will use the default routes 299 from its bound IAP). 301 If multiple applications utilize the same IAP, the underlying network 302 connection can typically be shared. This is often the case when 303 multiple Internet-using applications are running in parallel. 305 The IAP for an application can be selected in multiple ways: 307 o Statically: e.g. from a configuration interface, via client 308 provisioning/device management system, or at build-time. 310 o Manually by the user: e.g. each time an application starts the 311 user may be asked to select the IAP to use. This may be needed, 312 for example, if a user sometimes wishes to access his corporate 313 intranet and other times would prefer to access the Internet 314 directly. 316 o Automatically by the system: after the destination network has 317 been selected statically or dynamically. 319 The static approach is fine for certain applications, like MMS, for 320 which configuration can be provisioned by the network operator and 321 does not change often. Manual selection works, but may be seen as 322 troublesome by the user. An automatic selection mechanism needs to 323 have some way of knowing which destination network the user, or an 324 application, is trying access. 326 S60 3rd Edition, Feature Pack 2, introduces a concept of Service 327 Network Access Points (SNAPs) that group together IAPs that lead to 328 the same destination. This enables static or manual selection of the 329 destination network for an application and leaves the problem of 330 selecting the best of the available IAPs within a SNAP to the 331 operating system. 333 When SNAPs are used, it is possibly for the operating system to 334 notify applications when a preferred IAP, leading to the same 335 destination, becomes available (for example, when a user comes within 336 range of his home WLAN access point), or when the currently used IAP 337 is no longer available and applications have to reconnect via another 338 IAP (for example, when a user goes out of range of his home WLAN and 339 must move to the cellular network). 341 Please see the source documentation for more details and screenshots: 342 [S60]. 344 3.1.2. Microsoft Windows Mobile 2003 Second Edition 346 A Connection Manager architecture is described in [WINDOWSMOBILE]. 347 This architecture centralizes and automates network connection 348 establishment and management, and makes it possible to automatically 349 select a connection, to dial-in automatically or by user initiation, 350 and to optimize connection and shared resource usage. Connection 351 Manager periodically re-evaluates the validity of the connection 352 selection. The Connection Manager uses various attributes such as 353 cost, security, bandwidth, error rate, and latency in its decision 354 making. 356 The Connection Manager selects the best possible connection for the 357 application based on the destination network the application wishes 358 to reach. The selection is made between available physical and 359 virtual connections (e.g. VPN, GPRS, WLAN, and wired Ethernet) that 360 are known to provide connectivity to the destination network, and the 361 selection is based on the costs associated with each connection. 362 Different applications are bundled to use the same network connection 363 when possible, but in conflict situations when a connection cannot be 364 shared, higher priority applications take precedence, and the lower 365 priority applications lose connectivity until the conflict situation 366 clears. 368 During operation, Connection Manager opens new connections as needed, 369 and also disconnects unused or idle connections. 371 To optimize resource use, such as battery power and bandwidth, 372 Connection Manager enables applications to synchronize network 373 connection usage by allowing applications to register their 374 requirements for periodic connectivity. An application is notified 375 when a suitable connection becomes available for its use. 377 3.1.3. BlackBerry 379 In BlackBerry devices [BLACKBERRY] Java applications can use one of 380 two wireless gateways to proxy the connection to the Internet or to a 381 corporate network. The application can be designed to always use the 382 default Internet gateway, or to use a more preferred enterprise 383 gateway when available. The intent is to hide connectivity issues 384 from users. 386 DISCUSS: How does the Blackberry decides when a WLAN interface, a 387 cellular interface or some other physical interface is used? 389 3.1.4. Google Android 391 The Android reference documentation describes the android.net package 392 [ANDROID] and the ConnectivityManager class that applications can use 393 to request a route to a specified destination address via a specified 394 network interface (Mobile or Wifi). Applications also ask Connection 395 Manager for permission to start using a network feature. The 396 Connectivity Manager monitors changes in network connectivity and 397 attempts to failover to another network if connectivity to an active 398 network is lost. When there are changes in network connectivity, 399 applications are notified. Applications are also able to ask for 400 information about all network interfaces, including their 401 availability, type and other information. 403 DISCUSS: Are applications bound to use one network type at a time, or 404 can one application use multiple network features in parallel? 406 3.1.5. Arena Connection Manager 408 The Arena Connection Manager is described in 409 [I-D.zhang-mif-connection-manager-arena] and 410 [I-D.yang-mif-connection-manager-impl-req]. The arena connection 411 manager provides a means for applications to register their 412 connectivity requirement with the Connection Manager. The Connection 413 Manager can then choose an interface that matches the application's 414 needs while considering other factors such as availability, cost and 415 stability. Also, the Connection Manager can handle multi-interface 416 issues such as connection sharing. 418 3.2. Desktop Operating Systems 420 Multi-interface issues also occur in desktop environments in those 421 cases where a desktop host has multiple (logical or physical) 422 interfaces connected to networks with different reachability 423 properties, such as one interface connected to the global Internet, 424 while another interface is connected to a corporate VPN. 426 3.2.1. Microsoft Windows 428 The multi-interface functionality currently implemented in Microsoft 429 Windows operation systems is described in more detail in 430 [I-D.montenegro-mif-multihoming]. 432 3.2.1.1. Routing 434 It is possible, although not often desirable, to configure default 435 routers on more than one Windows interface. In this configuration, 436 Windows will use the default route on the interface with the lowest 437 routing metric (i.e. the fastest interface). If multiple interfaces 438 share the same metric, the behavior will differ based on the version 439 of Windows in use. Prior to Windows Vista, the packet would be 440 routed out of the first interface that was bound to the TCP/IP stack, 441 the preferred interface. In Windows vista, host-to-router load 442 sharing [RFC4311] is used for both IPv4 and IPv6. 444 3.2.1.2. Outbound and Inbound Addresses 446 If the source address of the outgoing packet has not been determined 447 by the application, Windows will choose from the addresses assigned 448 to its interfaces. Windows implements [RFC3484] for source address 449 selection in IPv6 and, in Windows Vista, for IPv4. Prior to Windows 450 Vista, IPv4 simply chose the first address on the outgoing interface. 452 For incoming packets, Windows will check if the destination address 453 matches one of the addresses assigned to its interfaces. Windows has 454 implemented the weak host model [RFC1122] on IPv4 in Windows 2000, 455 Windows XP and Windows Server 2003. The strong host model became the 456 default for IPv4 in Windows Vista and Windows server 2008, however 457 the weak host model is available via per-interface configuration. 458 IPv6 has always implemented the strong host model. 460 3.2.1.3. DNS Configuration 462 Host-wide DNS configuration is input via static configuration or, in 463 sites that use Active Directory, Microsoft's Group Policy. The host- 464 wide configuration consists of a DNS suffix to be used for the local 465 host, as well as a list of domain names that can be appended to names 466 being queried. Before Windows Vista and Windows Server 2008, there 467 was also a host-wide DNS server list that took precedent over per- 468 interface DNS configuration. 470 Interface specific DNS configuration can be input via static 471 configuration or via DHCP. It includes: 473 o An interface-specific suffix list. 475 o A list of DNS server IP addresses. 477 In the list of DNS server addresses, the first server is considered 478 the "primary" server, with all other servers being secondary. 480 When a DNS query is performed in Windows, the query is first sent to 481 the primary DNS server on the preferred interface. If no response is 482 received in one second, the query is sent to the primary DNS servers 483 on all interfaces under consideration. If no response is received 484 for 2 more seconds, the DNS server sends the query to all of the DNS 485 servers on the DNS server lists for all interfaces under 486 consideration. If the host still doesn't receive a response after 4 487 seconds, it will send to all of the servers again and wait 8 seconds 488 for a response. 490 3.2.2. Linux and BSD-based Operating Systems 492 Most BSD and Linux distributions rely on their DHCP client to handle 493 the configuration of interface-specific information (such as an IP 494 address and netmask), and a set of system-wide configuration 495 information, (such a DNS server list, an NTP server list and default 496 routes). Users of these operating systems have the choice of using 497 any DHCP client available for their platform, with an operating 498 system default. This section discusses the behavior of several DHCP 499 clients that may be used with Linux and BSD distributions. 501 The Internet Systems Consortium (ISC) DHCP Client [ISCDHCP] and its 502 derivative for OpenBSD [OPENBSDDHCLIENT] can be configured with 503 specific instructions for each interface. However, each time new 504 configuration data is received by the host from a DHCP server, 505 regardless of which interface it is received on, the DHCP client 506 rewrites the global configuration data, such as the default routes 507 and the DNS server list (in /etc/resolv.conf) with the most recent 508 information received. Therefore, the last configured interface 509 always become the primary one. The ISC DHCPv6 client behaves 510 similarly. 512 The Phystech dhcpcd client [PHYSTECHDHCPC] behaves similarly to the 513 ISC client. It replaces the DNS server list in /etc/resolv.conf and 514 the default routes each time new DHCP information is received on any 515 interface. However, the -R flag can be used to instruct the client 516 to not replace the DNS servers in /etc/resolv.conf. However, this 517 flag is a global flag for the DHCP server, and is therefore 518 applicable to all interfaces. When dhcpd is called with the -R flag, 519 the DNS servers are never replaced. 521 The pump client [PUMP] also behaves similarly to the ISC client. It 522 replaces the DNS servers in /etc/resolv.conf and the default routes 523 each time new DHCP information is received on any interface. 524 However, the nodns and nogateway options can be specified on a per 525 interface basis, enabling the user to define which interface should 526 be used to obtain the global configuration information. 528 The udhcp client [UDHCP] is often used in embedded platforms based on 529 busybox. The udhcp client behaves similarly to the ISC client. It 530 rewrites default routes and the DNS server list each time new DHCP 531 information is received. 533 Redhat-based distributions, such as Redhat, Centos and Fedora have a 534 per-interface configuration option (PEERDNS) that indicates that the 535 DNS server list should not be updated based on configuration received 536 on that interface. 538 The most configurable DHCP clients can be set to define a primary 539 interface to use only that interface for the global configuration 540 data. However, this is limited, since a mobile host might not always 541 have the same set of interfaces available. Connection managers may 542 help in this situation. 544 Some distributions also have a connection manager. However, most 545 connection managers serve as a GUI to the DHCP client, therefore not 546 changing the functionality described above . TODO: Verify all 547 connection managers. 549 TODO: DHCPv6 clients 551 3.2.3. Apple Mac OS X 553 This section is based on testing Mac OS X (version 10.5.6). 555 When using multiple interfaces on Mac OS X, global configuration data 556 such as default routes and the DNS server list are taken from the 557 DHCP data received on the primary interface. Therefore, the order in 558 which the interfaces receive their configuration data is not 559 relevant. For example, if the primary interface receives its 560 configuration data first, then the second interface receives its 561 configuration data, the interface-specific information for the second 562 interface will be configured, but the global configuration 563 information such as the DNS server list and default routes is not 564 overwritten. 566 4. Acknowledgements 568 Authors of the document would like to thank following people for 569 their input and feedback: Hui Deng, Jari Arkko. 571 This document was prepared using xml2rfc template and related web- 572 tool. 574 5. IANA Considerations 576 This memo includes no request to IANA. 578 6. Security Considerations 580 This document describes current operating system implementations and 581 how they handle the issues raised in the MIF problem statement. 582 While it is possible that the currently implemented mechanisms 583 described in this document may affect the security of the systems 584 described, this document merely reports on current practice. It does 585 not attempt to analyze the security properties (or any other 586 architectural properties) of the currently implemented mechanisms. 588 7. Change Log 590 The following changes were made between 591 draft-mrw-mif-current-practices and 592 draft-ietf-mif-current-practices-00.txt. 594 o Updated operating system info based on new information supplied. 596 o Renamed "Current Solutions" to "Summary of Current Solutions" and 597 moved above OS specifics. Modified this section substantially to 598 match problems in problem statement. 600 o Removed "Current Problems" section, as it duplicated information 601 in the problem statement. 603 o Broke OS specifics into separate sections for mobile handsets and 604 desktop operating systems. 606 The following changes were made between versions -00 and -01: 608 o Number of authors passed five, so moved to Contributors section. 610 o Added information on Microsoft Windows. 612 o Added information on Arena Connection Manager. 614 8. Contributors 616 The following people contributed most of the per-Operating System 617 information found in this document: 619 o Marc Blanchet, Viagenie 621 o Hua Chen, Leadcoretech, Ltd. 623 o Shunan Fan, Huawei Technology 625 o Gabriel Montenegro, Microsoft Corporation 627 o Teemu Savolainen, Nokia 629 o Shyam Seshadri, Microsoft Corporation 631 o Tao Sun, China Mobile 633 o Dave Thaler, Microsoft Corporation 635 o Jian Yang, Huawei Technology 637 o Yan Zhang, Leadcoretech Ltd. 639 9. References 641 9.1. Normative References 643 [I-D.ietf-mif-problem-statement] 644 Blanchet, M. and P. Seite, "Multiple Interfaces Problem 645 Statement", draft-ietf-mif-problem-statement-00 (work in 646 progress), October 2009. 648 9.2. Informative References 650 [ANDROID] Google Inc., "Android developers: package android.net", 651 2009, . 654 [BLACKBERRY] 655 Research In Motion Limited, "BlackBerry Java Development 656 Environment - Fundamentals Guide: Wireless gateways", 657 2009, . 660 [I-D.montenegro-mif-multihoming] 661 Montenegro, G., Thaler, D., and S. Seshadri, "Multiple 662 Interfaces on Windows", 663 draft-montenegro-mif-multihoming-00 (work in progress), 664 March 2009. 666 [I-D.yang-mif-connection-manager-impl-req] 667 Yang, J., Sun, T., and S. Fan, "Multi-interface Connection 668 Manager Implementation and Requirements", 669 draft-yang-mif-connection-manager-impl-req-00 (work in 670 progress), March 2009. 672 [I-D.zhang-mif-connection-manager-arena] 673 Zhang, Y., Sun, T., and H. Chen, "Multi-interface Network 674 Connection Manager in Arena Platform", 675 draft-zhang-mif-connection-manager-arena-00 (work in 676 progress), February 2009. 678 [ISCDHCP] Internet Software Consortium, "ISC DHCP", 2009, 679 . 681 [OPENBSDDHCLIENT] 682 OpenBSD, "OpenBSD dhclient", 2009, 683 . 685 [PHYSTECHDHCPC] 686 Phystech, "dhcpcd", 2009, 687 . 689 [PUMP] RedHat, "PUMP", 2009, . 691 [RFC1122] Braden, R., "Requirements for Internet Hosts - 692 Communication Layers", STD 3, RFC 1122, October 1989. 694 [RFC3484] Draves, R., "Default Address Selection for Internet 695 Protocol version 6 (IPv6)", RFC 3484, February 2003. 697 [RFC4311] Hinden, R. and D. Thaler, "IPv6 Host-to-Router Load 698 Sharing", RFC 4311, November 2005. 700 [S60] Nokia Corporation, "S60 Platform: IP Bearer Management", 701 2007, . 705 [UDHCP] Busybox, "uDHCP", 2009, . 708 [WINDOWSMOBILE] 709 Microsoft Corporation, "SDK Documentation for Windows 710 Mobile-Based Smartphones: Connection Manager", 2005, 711 . 713 Author's Address 715 Margaret Wasserman (editor) 716 Sandstorm Enterprises 717 14 Summer Street 718 Malden, MA 02148 719 USA 721 Phone: +1 781 333 3200 722 Email: mrw@lilacglade.org 723 URI: http://www.sandstorm.net