idnits 2.17.1 draft-mrw-mif-current-practices-02.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.ii 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 (March 25, 2009) is 5509 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-01) exists of draft-blanchet-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 March 25, 2009 5 Expires: September 26, 2009 7 Current Practices for Multiple Interface Hosts 8 draft-mrw-mif-current-practices-02 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 September 26, 2009. 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 describes 49 how some common operating systems cope with the related challenges. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Current practices of some operating systems . . . . . . . . . 3 55 2.1. Nokia S60 3rd Edition, Feature Pack 2 . . . . . . . . . . 3 56 2.2. Microsoft Windows Mobile 2003 Second Edition . . . . . . . 5 57 2.3. BlackBerry . . . . . . . . . . . . . . . . . . . . . . . . 6 58 2.4. Google Android . . . . . . . . . . . . . . . . . . . . . . 6 59 2.5. Arena Connection Manager . . . . . . . . . . . . . . . . . 7 60 2.6. Microsoft Windows . . . . . . . . . . . . . . . . . . . . 7 61 2.6.1. Routing . . . . . . . . . . . . . . . . . . . . . . . 7 62 2.6.2. Outbound and Inbound Addresses . . . . . . . . . . . . 7 63 2.6.3. DNS Configuration . . . . . . . . . . . . . . . . . . 8 64 2.7. Linux and BSD-based Operating Systems . . . . . . . . . . 8 65 2.8. Apple Mac OS X . . . . . . . . . . . . . . . . . . . . . . 10 66 3. Common solutions . . . . . . . . . . . . . . . . . . . . . . . 10 67 3.1. Centralized connection management . . . . . . . . . . . . 10 68 3.2. Per application connection settings . . . . . . . . . . . 11 69 4. Common problems . . . . . . . . . . . . . . . . . . . . . . . 11 70 4.1. Selection of an interface providing access to a 71 destination . . . . . . . . . . . . . . . . . . . . . . . 11 72 4.2. Prioritization of interfaces for the same destination . . 11 73 4.3. Enablers for application multihoming . . . . . . . . . . . 12 74 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 75 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 76 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 77 8. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 12 78 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 13 79 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 80 10.1. Normative References . . . . . . . . . . . . . . . . . . . 13 81 10.2. Informative References . . . . . . . . . . . . . . . . . . 13 82 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15 84 1. Introduction 86 Multiple-interface hosts face several challenges not faced by single- 87 interface hosts, some of which are described in 88 [I-D.blanchet-mif-problem-statement]. 90 This document collects and analyzes publicly-available information 91 about the multiple-interface solutions implemented in some widely 92 used operating systems, including: Nokia S60 [S60], Microsoft Windows 93 Mobile [WINDOWSMOBILE], Blackberry [BLACKBERRY], Google Android 94 [ANDROID], Microsoft Windows, Apple Mac OS X, Linux and BSD-based 95 operating systems. 97 In section 3, common solutions implemented in different operating 98 systems are identified and generalized. 100 NOTE: Further input on the behaviour of these or other operating 101 systems (including newer versons) is very welcome. 103 2. Current practices of some operating systems 105 The following sections briefly describe the current multiple- 106 interface host implementations on some widely-used operating systems. 107 Please refer to the References section for pointers to original 108 documentation on most of these systems, including further details. 110 2.1. Nokia S60 3rd Edition, Feature Pack 2 112 Cellular devices typically run a variety of applications in parallel, 113 each with different requirements for IP connectivity. A typical 114 scenario is shown in figure 1, where a cellular device is utilizing 115 WLAN access for web browsing and GPRS access for transferring 116 multimedia messages (MMS). Another typical scenario would be a real- 117 time VoIP session over one network interface in parallel with best 118 effort web browsing on another network interface. Yet another 119 typical scenario would be global Internet access through one network 120 interface and local (e.g. corporate VPN) network access through 121 another. 123 Web server MMS Gateway 124 | | 125 -+--Internet---- ----Operator network--+- 126 | | 127 +-------+ +-------+ 128 |WLAN AP| | GGSN | 129 +-------+ +-------+ 130 | +--------+ | 131 +--------|Cellular|--------+ 132 |device | 133 +--------+ 135 A cellular device with two network interfaces 137 Figure 1 139 Different network access technologies require different settings. 140 For example, WLAN requires Service Set Identifier (SSID) and the GPRS 141 network requires the Access Point Name (APN) of the Gateway GPRS 142 Support Node (GGSN), among other parameters. It is common that 143 different accesses lead to different destination networks (e.g. to 144 "Internet", "Intranet", cellular network services, etc.). 146 S60 uses the concept of an Internet Access Point (IAP) [S60] that 147 contains all information required for opening a network connection 148 using a specific access technology. A device may have several IAPs 149 configured for different network technologies and settings (multiple 150 WLAN SSIDs, GPRS APNs, dial-up numbers, and so forth). There may 151 also be 'virtual' IAPs that define parameters needed for tunnel 152 establishment (e.g. for VPN). 154 For each application, a correct IAP needs to be selected at the point 155 when the application requires network connectivity. This is 156 essential, as the wrong IAP may not be able to support the 157 application or reach the desired destination. For example, MMS 158 application must use the correct IAP in order to reach the MMS 159 Gateway, which typically is not accessible from the public Internet. 160 As another example, an application might need to use the IAP 161 associated with its corporate VPN in order to reach internal 162 corporate servers. Binding applications to IAPs avoids several 163 problems, such as choosing the correct DNS server in the presence of 164 split DNS (as an application will use the DNS server list from its 165 bound IAP), and overlapping private IPv4 address spaces used for 166 different interfaces (as each application will use the default routes 167 from its bound IAP). 169 If multiple applications utilize the same IAP, the underlying network 170 connection can typically be shared. This is often the case when 171 multiple Internet-using applications are running in parallel. 173 The IAP for an application can be selected in multiple ways: 175 o Statically: e.g. from a configuration interface, via client 176 provisioning/device management system, or at build-time. 178 o Manually by the user: e.g. each time an application starts the 179 user may be asked to select the IAP to use. This may be needed, 180 for example, if a user sometimes wishes to access his corporate 181 intranet and other times would prefer to access the Internet 182 directly. 184 o Automatically by the system: after the destination network has 185 been selected statically or dynamically. 187 The static approach is fine for certain applications, like MMS, for 188 which configuration can be provisioned by the network operator and 189 does not change often. Manual selection works, but may be seen as 190 troublesome by the user. An automatic selection mechanism needs to 191 have some way of knowing which destination network the user, or an 192 application, is trying access. 194 S60 3rd Edition, Feature Pack 2, introduces a concept of Service 195 Network Access Points (SNAPs) that group together IAPs that lead to 196 the same destination. This enables static or manual selection of the 197 destination network for an application and leaves the problem of 198 selecting the best of the available IAPs within a SNAP to the 199 operating system. 201 When SNAPs are used, it it possibly for the operating system to 202 notify applications when a preferred IAP, leading to the same 203 destination, becomes available (for example, when a user comes within 204 range of his home WLAN access point), or when the currently used IAP 205 is no longer available and applications have to reconnect via another 206 IAP (for example, when a user goes out of range of his home WLAN and 207 must move to the cellular network). 209 Please see the source documentation for more details and screenshots: 210 [S60]. 212 2.2. Microsoft Windows Mobile 2003 Second Edition 214 A Connection Manager architecture is described in [WINDOWSMOBILE]. 215 This architecture centralizes and automates network connection 216 establishment and management, and makes it possible to automatically 217 select a connection, to dial-in automatically or by user initiation, 218 and to optimize connection and shared resource usage. Connection 219 Manager periodically re-evaluates the validity of the connection 220 selection. The Connection Manager uses various attributes such as 221 cost, security, bandwidth, error rate, and latency in its decision 222 making. 224 The Connection Manager selects the best possible connection for the 225 application based on the destination network the application wishes 226 to reach. The selection is made between available physical and 227 virtual connections (e.g. VPN, GPRS, WLAN, and wired Ethernet) that 228 are known to provide connectivity to the destination network, and the 229 selection is based on the costs associated with each connection. 230 Different applications are bundled to use the same network connection 231 when possible, but in conflict situations when a connection cannot be 232 shared, higher priority applications take precedence, and the lower 233 priority applications lose connectivity until the conflict situation 234 clears. 236 During operation, Connection Manager opens new connections as needed, 237 and also disconnects unused or idle connections. 239 To optimize resource use, such as battery power and bandwidth, 240 Connection Manager enables applications to synchronize network 241 connection usage by allowing applications to register their 242 requirements for periodic connectivity. An application is notified 243 when a suitable connection becomes available for its use. 245 2.3. BlackBerry 247 In BlackBerry devices [BLACKBERRY] Java applications can use one of 248 two wireless gateways to proxy the connection to the Internet or to a 249 corporate network. The application can be designed to always use the 250 default Internet gateway, or to use a more preferred enterprise 251 gateway when available. The intent is to hide connectivity issues 252 from users. 254 DISCUSS: How does the Blackberry decide when a WLAN interface, a 255 cellular interface or some other physical interface is used? 257 2.4. Google Android 259 The Android reference documentation describes the android.net package 260 [ANDROID] and the ConnectivityManager class that applications can use 261 to request a route to a specified destination address via a specified 262 network interface (Mobile or Wifi). Applications also ask Connection 263 Manager for permission to start using a network feature. The 264 Connectivity Manager monitors changes in network connectivity and 265 attempts to failover to another network if connectivity to an active 266 network is lost. When there are changes in network connectivity, 267 applications are notified. Applications are also able to ask for 268 information about all network interfaces, including their 269 availability, type and other information. 271 DISCUSS: Are applications bound to use one network type at a time, or 272 can one application use multiple network features in parallel? 274 2.5. Arena Connection Manager 276 The Arena Connection Manager is described in 277 [I-D.zhang-mif-connection-manager-arena] and 278 [I-D.yang-mif-connection-manager-impl-req]. The arena connection 279 manager provides a means for applications to register their 280 connectivity requirement with the Connection Manager. The Connection 281 Manager can then choose an interface that matches the application's 282 needs while considering other factors such as availability, cost and 283 stablility. Also, the Connection Manager can handle multi-interface 284 issues such as connection sharing. 286 2.6. Microsoft Windows 288 The multi-interface functionality currently implemented in Microsoft 289 Windows operation systems is described in more detail in 290 [I-D.montenegro-mif-multihoming]. 292 2.6.1. Routing 294 It is possible, although not often desirable, to configure default 295 routers on more than one Windows interface. In this configuration, 296 Windows will use the default route on the interface with the lowest 297 routing metric (i.e. the fastest interface). If multiple interfaces 298 share the same metric, the behaviour will differ based on the version 299 of Windows in use. Prior to Windows Vista, the packet would be 300 routed out of the first interface that was bound to the TCP/IP stack, 301 the preferred interface. In Windows vista, host-to-router load 302 sharing [RFC4311] is used for both IPv4 and IPv6. 304 2.6.2. Outbound and Inbound Addresses 306 If the source address of the outgoing packet has not been determined 307 by the application, Windows will choose from the addresses assigned 308 to its interfaces. Windows implements [RFC3484] for source address 309 selection in IPv6 and, in Windows Vista, for IPv4. Prior to Windows 310 Vista, IPv4 simply chose the first address on the outgoing interface. 312 For incoming packets, Windows will check if the destination address 313 matches one of the addresses assigned to its interfaces. Windows has 314 implemented the weak host model [RFC1122] on IPv4 in Windows 2000, 315 Windows XP and Windows Server 2003. The strong host model became the 316 default for IPv4 in Windows Vista and WIndows server 2008, however 317 the weak host model is available via per-interface configuration. 318 IPv6 has always implemented the strong host model. 320 2.6.3. DNS Configuration 322 Host-wide DNS configuration is input via static configuration or, in 323 sites that use Active Directory, Microsoft's Group Policy. The host- 324 wide configuration consists of a DNS suffix to be used for the local 325 host, as well as a list of domain names that can be appended to names 326 being queried. Before Windows Vista and Windows Server 2008, there 327 was also a host-wide DNS server list that took precendent over per- 328 interface DNS configuration. 330 Interface specific DNS configuration can be input via static 331 configuration or via DHCP. It includes: 333 o An interface-specific suffix list. 335 o A list of DNS server IP addresses. 337 In the list of DNS server addresses, the first server is considered 338 the "primary" server, with all other servers being secondary. 340 When a DNS query is performed in Windows, the query is first sent to 341 the primary DNS server on the preferred interface. If no response is 342 received in one second, the query is sent to the primary DNS servers 343 on all interfaces under consideration. If no response is received 344 for 2 more seconds, the DNS server sends the query to all of the DNS 345 servers on the DNS server lists for all interfaces under 346 consideration. If the host still doesn't receive a response after 4 347 seconds, it will send to all of the servers again and wait 8 seconds 348 for a response. 350 2.7. Linux and BSD-based Operating Systems 352 Most BSD and Linux distributions rely on their DHCP client to handle 353 the configuration of interface-specific information (such as an IP 354 address and netmask), and a set of system-wide configuration 355 information, (such a DNS server list, an NTP server list and default 356 routes). Users of these operating systems have the choice of using 357 any DHCP client available for their platform, with an operating 358 system default. This section discusses the behavior of several DHCP 359 clients that may be used with Linux and BSD distributions. 361 The Internet Systems Consortium (ISC) DHCP Client [ISCDHCP] and its 362 derivative for OpenBSD [OPENBSDDHCLIENT] can be configured with 363 specific instructions for each interface. However, each time new 364 configuration data is received by the host from a DHCP server, 365 regardless of which interface it is received on, the DHCP client 366 rewrites the global configuration data, such as the default routes 367 and the DNS server list (in /etc/resolv.conf) with the most recent 368 information received. Therefore, the last configured interface 369 always become the primary one. The ISC DHCPv6 client behaves 370 similarly. 372 The Phystech dhcpcd client [PHYSTECHDHCPC] behaves similarly to the 373 ISC client. It replaces the DNS server list in /etc/resolv.conf and 374 the default routes each time new DHCP information is received on any 375 interface. However, the -R flag can be used to instruct the client 376 to not replace the DNS servers in /etc/resolv.conf. However, this 377 flag is a global flag for the DHCP server, and is therefore 378 applicable to all interfaces. When dhcpd is called with the -R flag, 379 the DNS servers are never replaced. 381 The pump client [PUMP] also behaves similarly to the ISC client. It 382 replaces the DNS servers in /etc/resolv.conf and the default routes 383 each time new DHCP information is received on any interface. 384 However, the nodns and nogateway options can be specified on a per 385 interface basis, enabling the user to define which interface should 386 be used to obtain the global configuration information. 388 The udhcp client [UDHCP] is often used in embedded platforms based on 389 busybox. The udhcp client behaves similarly to the ISC client. It 390 rewrites default routes and the DNS server list each time new DHCP 391 information is received. 393 Redhat-based distributions, such as Redhat, Centos and Fedora have a 394 per-interface configuration option (PEERDNS) that indicates that the 395 DNS server list should not be updated based on configuration received 396 on that interface. 398 The most configurable DHCP clients can be set to define a primary 399 interface to use only that interface for the global configuration 400 data. However, this is limited, since a mobile host might not always 401 have the same set of interfaces available. Connection managers may 402 help in this situation. 404 Some distributions also have a connection manager. However, most 405 connection managers serve as a GUI to the DHCP client, therefore not 406 changing the functionality described above . TODO: Verify all 407 connection managers. 409 TODO: DHCPv6 clients 411 2.8. Apple Mac OS X 413 This section is based on testing Mac OS X (version 10.5.6). 415 When using multiple interfaces on Mac OS X, global configuration data 416 such as default routes and the DNS server list are taken from the 417 DHCP data received on the primary interface. Therefore, the order in 418 which the interfaces receive their configuration data is not 419 relevant. For example, if the primary interface receives its 420 configuration data first, then the second interface receives its 421 configuration data, the interface-specific information for the second 422 interface will be configured, but the global configuration 423 information such as the DNS server list and default routes is not 424 overwritten. 426 3. Common solutions 428 Essentially all operating systems use the same types of information 429 to make decisions about multiple-interface operation: user input, 430 operator/administrator provided information, and what has been 431 statically configured or hard-coded. It is possible to design clever 432 ways for tackling the problems related to multi-homing from the set 433 of dynamically available information, vendor specific policies and 434 design decisions. However, limitations on available information also 435 set limits on what different operating systems can theoretically 436 achieve. 438 This section describes what common solution approaches the analyzed 439 operating systems are known to utilize. 441 3.1. Centralized connection management 443 It seems to be common practice to have a centralized connection 444 manager entity, which does the network interface selection based on 445 application input. The information used by the connection manager 446 may be programmed into an application, learned from the users, or 447 provisioned. 449 Routing tables are not typically used for network interface 450 selection, as the criteria for network selection is not strictly IP- 451 based but is also dependent on other properties of the interface 452 (cost, type, etc.). Furthermore, multiple overlapping private IPv4 453 address spaces are often exposed to a multiple-interface host, making 454 it difficult to make interface selection decisions based on prefix 455 matching. 457 3.2. Per application connection settings 459 As each application has its particular connectivity needs, 460 applications are able to request what kind of connectivity they need. 462 4. Common problems 464 The current solutions are limited by the information available. This 465 section discusses what types of information IETF-designed protocols 466 could provide to allow implementations to improve functionality in 467 multi-inteface scenarios. 469 Please also see MIF problem statement document 470 [I-D.blanchet-mif-problem-statement]. 472 DISCUSS: is this section 4 required in this document, or should we 473 fully leave the problem descriptions to problem statement, or have 474 here some general problems, and in problem-statement more detailed 475 problems? 477 4.1. Selection of an interface providing access to a destination 479 As different network interfaces may provide connectivity to different 480 destination networks, a host needs to be able to choose a correct 481 network interface (or a set of interfaces, if the application can use 482 multiple interfaces in parallel) to allow the application or IP flow 483 to reach the intended destination. 485 4.2. Prioritization of interfaces for the same destination 487 As several interfaces may lead to the same destination network, a 488 host has to choose which one to use. It may be that if one network 489 has connectivity limitations, such as firewalls or NATs, and the 490 other network does not, it may be preferable to use the interface to 491 the less restricted network. This is not always the case, e.g. if 492 access to the restricted network is faster or cheaper, it might be 493 desirable to use that interface, if it can support the application 494 and reach the desired destination. Could the network somehow 495 indicate what limitations it is imposing, or could there be new 496 technologies that would help to determine the connectivity properties 497 of a network? 499 Improved source/destination address selection (underway in the 6man 500 address selection design team), more specific routes (RFC4191), or 501 other (TBD) technologies may be helpful in this area. 503 4.3. Enablers for application multihoming 505 When applications are bound to use single network interface at a 506 time, they are unable to benefit from technologies developed for 507 multihoming purposes. Therefore technologies that help to free 508 applications from being bound into a single network interface would 509 be useful. Essentially this means advanced ways to ensure that 510 applications use the right network interface, and that applications 511 do not accidentally use interfaces that will not support the 512 application or provide connetivity to the destination. Can 513 improvements be designed for IPv4 in spite of overlapping private 514 IPv4 address spaces, or only for IPv6? 516 5. Acknowledgements 518 Authors of the document would like to thank following people for 519 their input and feedback: Hui Deng, Jari Arkko. 521 This document was prepared using xml2rfc template and related web- 522 tool. 524 6. IANA Considerations 526 This memo includes no request to IANA. 528 7. Security Considerations 530 This draft describes current multiple-interface host implementations 531 on some common operating systems without any focus on security 532 considerations. 534 8. Change Log 536 The following changes were made between versions -00 and -01: 538 o Number of authors passed five, so moved to Contributors section. 540 o Added information on Microsoft Windows. 542 o Added information on Arena Connection Manager. 544 9. Contributors 546 The following people contributed most of the information found in 547 this document: 549 o Marc Blanchet, Viagenie 551 o Hua Chen, Leadcoretech, Ltd. 553 o Shunan Fan, Huawei Technology 555 o Gabriel Montenegro, Microsoft Corporation 557 o Teemu Savolainen, Nokia 559 o Shyam Seshadri, Microsoft Corporation 561 o Tao Sun, China Mobile 563 o Dave Thaler, Microsoft Corporation 565 o Jian Yang, Huawei Technology 567 o Yan Zhang, Leadcoretech Ltd. 569 10. References 571 10.1. Normative References 573 [I-D.blanchet-mif-problem-statement] 574 Blanchet, M., "Multiple Interfaces Problem Statement", 575 draft-blanchet-mif-problem-statement-00 (work in 576 progress), December 2008. 578 10.2. Informative References 580 [ANDROID] Google Inc., "Android developers: package android.net", 581 2009, . 584 [BLACKBERRY] 585 Research In Motion Limited, "BlackBerry Java Development 586 Environment - Fundamentals Guide: Wireless gateways", 587 2009, . 590 [I-D.montenegro-mif-multihoming] 591 Montenegro, G., Thaler, D., and S. Seshadri, "Multiple 592 Interfaces on Windows", 593 draft-montenegro-mif-multihoming-00 (work in progress), 594 March 2009. 596 [I-D.yang-mif-connection-manager-impl-req] 597 Yang, J., Sun, T., and S. Fan, "Multi-interface Connection 598 Manager Implementation and Requirements", 599 draft-yang-mif-connection-manager-impl-req-00 (work in 600 progress), March 2009. 602 [I-D.zhang-mif-connection-manager-arena] 603 Zhang, Y., Sun, T., and H. Chen, "Multi-interface Network 604 Connection Manager in Arena Platform", 605 draft-zhang-mif-connection-manager-arena-00 (work in 606 progress), February 2009. 608 [ISCDHCP] Internet Software Consortium, "ISC DHCP", 2009, 609 . 611 [OPENBSDDHCLIENT] 612 OpenBSD, "OpenBSD dhclient", 2009, 613 . 615 [PHYSTECHDHCPC] 616 Phystech, "dhcpcd", 2009, 617 . 619 [PUMP] RedHat, "PUMP", 2009, . 621 [RFC1122] Braden, R., "Requirements for Internet Hosts - 622 Communication Layers", STD 3, RFC 1122, October 1989. 624 [RFC3484] Draves, R., "Default Address Selection for Internet 625 Protocol version 6 (IPv6)", RFC 3484, February 2003. 627 [RFC4311] Hinden, R. and D. Thaler, "IPv6 Host-to-Router Load 628 Sharing", RFC 4311, November 2005. 630 [S60] Nokia Corporation, "S60 Platform: IP Bearer Management", 631 2007, . 635 [UDHCP] Busybox, "uDHCP", 2009, . 638 [WINDOWSMOBILE] 639 Microsoft Corporation, "SDK Documentation for Windows 640 Mobile-Based Smartphones: Connection Manager", 2005, 641 . 643 Author's Address 645 Margaret Wasserman (editor) 646 Sandstorm Enterprises 647 14 Summer Street 648 Malden, MA 02148 649 USA 651 Phone: +1 781 333 3200 652 Email: mrw@lilacglade.org 653 URI: http://www.sandstorm.net