One document matched: draft-mrw-mif-current-practices-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY I-D.blanchet-mif-problem-statement SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.blanchet-mif-problem-statement.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc strict="yes" ?>
<?rfc toc="yes"?>
<?rfc tocdepth="4"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<rfc category="info" docName="draft-mrw-mif-current-practices-00" ipr="trust200902">
<front>
<title abbrev="MIF Current Practices">Current Practices for Multiple Interface Hosts</title>
<author fullname="Margaret Wasserman" initials="M.W." surname="Wasserman"
role="editor">
<organization>Sandstorm Enterprises</organization>
<address>
<postal>
<street>14 Summer Street</street>
<city>Malden</city>
<region>MA</region>
<code>02148</code>
<country>USA</country>
</postal>
<phone>+1 781 333 3200</phone>
<email>mrw@lilacglade.org</email>
<uri>http://www.sandstorm.net</uri>
</address>
</author>
<author fullname="Teemu Savolainen" initials="T.S." surname="Savolainen">
<organization>Nokia</organization>
<address>
<postal>
<street>Hermiankatu 12 D</street>
<code>FI-33720</code>
<city>TAMPERE</city>
<region></region>
<country>Finland</country>
</postal>
<email>teemu.savolainen@nokia.com</email>
</address>
</author>
<author fullname="Marc Blanchet" initials="M.B." surname="Blanchet">
<organization>Viagenie</organization>
<address>
<postal>
<street>2600 boul. Laurier, suite 625</street>
<code>G1V 4W1</code>
<city>Quebec</city>
<region>QC</region>
<country>Canada</country>
</postal>
<email>Marc.Blanchet@viagenie.ca</email>
<uri>http://www.viagenie.ca</uri>
</address>
</author>
<date month="March" year="2009" />
<area>Internet</area>
<workgroup>Internet Engineering Task Force</workgroup>
<keyword>current practices, multi-homing, MIF</keyword>
<abstract>
<t>
An increasing number of hosts are operating in multiple-interface
environments, where different network interfaces are providing
unequal levels of service or connectivity. This document describes
how some common operating systems cope with the related challenges.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>
Multiple-interface hosts face several challenges
not faced by single-interface hosts, some of which are described
in <xref target="I-D.blanchet-mif-problem-statement"></xref>.
</t>
<t>
This document collects and analyzes publicly-available information
about the multiple-interface solutions implemented in some widely used
operating systems, including: Nokia S60 <xref target="S60"></xref>,
Microsoft Windows Mobile <xref target="WINDOWSMOBILE"></xref>,
Blackberry <xref target="BLACKBERRY"></xref>, Google
Android <xref target="ANDROID"></xref>, Apple Mac OS X, Linux and
BSD-based operating systems.
</t>
<t>
In section 3, common solutions implemented in different operating systems
are identified and generalized.
</t>
<t>
NOTE: Further input on the behaviour of these or other operating
systems (including newer versons) is very welcome.
</t>
</section>
<section title="Current practices of some operating systems">
<t>
The following sections briefly describe the current multiple-interface
host implementations on some widely-used operating systems. Please
refer to the References section for pointers to original documentation
on most of these systems, including further details.
</t>
<section title="Nokia S60 3rd Edition, Feature Pack 2">
<t>
Cellular devices typically run a variety of applications in parallel,
each with different requirements for IP connectivity. A typical
scenario is shown in figure 1, where a cellular device is utilizing
WLAN access for web browsing and GPRS access for transferring
multimedia messages (MMS). Another typical scenario would be a
real-time VoIP session over one network interface in parallel with
best effort web browsing on another network interface. Yet another
typical scenario would be global Internet access through one network
interface and local (e.g. corporate VPN) network access through
another.
</t>
<figure align="center" anchor="xml_fig1">
<preamble></preamble>
<artwork align="left"><![CDATA[
Web server MMS Gateway
| |
-+--Internet---- ----Operator network--+-
| |
+-------+ +-------+
|WLAN AP| | GGSN |
+-------+ +-------+
| +--------+ |
+--------|Cellular|--------+
|device |
+--------+
]]>
</artwork>
<postamble>A cellular device with two network interfaces</postamble>
</figure>
<t>
Different network access technologies require different settings. For
example, WLAN requires Service Set Identifier (SSID) and the GPRS
network requires the Access Point Name (APN) of the Gateway GPRS
Support Node (GGSN), among other parameters. It is common that
different accesses lead to different destination networks (e.g. to
"Internet", "Intranet", cellular network services, etc.).
</t>
<t>
S60 uses the concept of an Internet Access Point
(IAP) <xref target="S60"></xref> that contains all information
required for opening a network connection using a specific access
technology. A device may have several IAPs configured for different
network technologies and settings (multiple WLAN SSIDs, GPRS APNs,
dial-up numbers, and so forth). There may also be 'virtual' IAPs that
define parameters needed for tunnel establishment (e.g. for VPN).
</t>
<t>
For each application, a correct IAP needs to be selected at the point
when the application requires network connectivity. This is essential,
as the wrong IAP may not be able to support the application or reach
the desired destination. For example, MMS application must use the
correct IAP in order to reach the MMS Gateway, which typically is not
accessible from the public Internet. As another example, an
application might need to use the IAP associated with its corporate
VPN in order to reach internal corporate servers. Binding
applications to IAPs avoids several problems, such as choosing the
correct DNS server in the presence of split DNS (as an application
will use the DNS server list from its bound IAP), and overlapping
private IPv4 address spaces used for different interfaces (as each
application will use the default routes from its bound IAP).
</t>
<t>
If multiple applications utilize the same IAP, the underlying network
connection can typically be shared. This is often the case when
multiple Internet-using applications are running in parallel.
</t>
<t>
The IAP for an application can be selected in multiple ways:
</t>
<t>
<list style="symbols">
<t>
Statically: e.g. from a configuration interface, via client
provisioning/device management system, or at build-time.
</t>
<t>
Manually by the user: e.g. each time an application starts the
user may be asked to select the IAP to use. This may be needed,
for example, if a user sometimes wishes to access his corporate
intranet and other times would prefer to access the Internet
directly.
</t>
<t>
Automatically by the system: after the destination network has
been selected statically or dynamically.
</t>
</list>
</t>
<t>
The static approach is fine for certain applications, like MMS, for
which configuration can be provisioned by the network operator and
does not change often. Manual selection works, but may be seen as
troublesome by the user. An automatic selection mechanism needs to
have some way of knowing which destination network the user, or an
application, is trying access.
</t>
<t>
S60 3rd Edition, Feature Pack 2, introduces a concept of Service
Network Access Points (SNAPs) that group together IAPs that lead to
the same destination. This enables static or manual selection of the
destination network for an application and leaves the problem of
selecting the best of the available IAPs within a SNAP to the
operating system.
</t>
<t>
When SNAPs are used, it it possibly for the operating system to notify
applications when a preferred IAP, leading to the same destination,
becomes available (for example, when a user comes within range of his
home WLAN access point), or when the currently used IAP is no longer
available and applications have to reconnect via another IAP (for
example, when a user goes out of range of his home WLAN and must move
to the cellular network).
</t>
<t>
Please see the source documentation for more details and screenshots:
<xref target="S60"></xref>.
</t>
</section>
<section title="Microsoft Windows Mobile 2003 Second Edition">
<t>
A Connection Manager architecture is described
in <xref target="WINDOWSMOBILE"></xref>. This architecture
centralizes and automates network connection establishment and
management, and makes it possible to automatically select a
connection, to dial-in automatically or by user initiation, and to
optimize connection and shared resource usage. Connection Manager
periodically re-evaluates the validity of the connection
selection. The Connection Manager uses various attributes such as
cost, security, bandwidth, error rate, and latency in its decision
making.
</t>
<t>
The Connection Manager selects the best possible connection for the
application based on the destination network the application wishes to
reach. The selection is made between available physical and virtual
connections (e.g. VPN, GPRS, WLAN, and wired Ethernet) that are known
to provide connectivity to the destination network, and the selection
is based on the costs associated with each connection. Different
applications are bundled to use the same network connection when
possible, but in conflict situations when a connection cannot be
shared, higher priority applications take precedence, and the lower
priority applications lose connectivity until the conflict situation
clears.
</t>
<t>
During operation, Connection Manager opens new connections as
needed, and also disconnects unused or idle connections.
</t>
<t>
To optimize resource use, such as battery power and bandwidth,
Connection Manager enables applications to synchronize network
connection usage by allowing applications to register their
requirements for periodic connectivity. An application is notified
when a suitable connection becomes available for its use.
</t>
</section>
<section title="BlackBerry">
<t>
In BlackBerry devices <xref target="BLACKBERRY"></xref> Java
applications can use one of two wireless gateways to proxy the
connection to the Internet or to a corporate network. The application
can be designed to always use the default Internet gateway, or to use
a more preferred enterprise gateway when available. The intent is to
hide connectivity issues from users.
</t>
<t>
DISCUSS: How does the Blackberry decide when a WLAN interface, a
cellular interface or some other physical interface is used?
</t>
</section>
<section title="Google Android">
<t>
The Android reference documentation describes the android.net
package <xref target="ANDROID"></xref> and the ConnectivityManager
class that applications can use to request a route to a specified
destination address via a specified network interface
(Mobile or Wifi). Applications also ask Connection Manager for permission
to start using a network feature. The Connectivity Manager monitors
changes in network connectivity and attempts to failover to another
network if connectivity to an active network is lost. When there are
changes in network connectivity, applications are
notified. Applications are also able to ask for information about all
network interfaces, including their availability, type and other
information.
</t>
<t>
DISCUSS: Are applications bound to use one network type at a time, or
can one application use multiple network features in parallel?
</t>
</section>
<section title="Linux and BSD-based Operating Systems">
<t>
Most BSD and Linux distributions rely on their DHCP client to handle
the configuration of interface-specific information (such as an IP
address and netmask), and a set of system-wide configuration
information, (such a DNS server list, an NTP server list and default
routes). Users of these operating systems have the choice of using any
DHCP client available for their platform, with an operating system
default. This section discusses the behavior of several DHCP clients
that may be used with Linux and BSD distributions.
</t>
<t>
The Internet Systems Consortium (ISC) DHCP
Client <xref target="ISCDHCP"></xref> and its derivative for
OpenBSD <xref target="OPENBSDDHCLIENT"></xref> can be configured with
specific instructions for each interface. However, each time new
configuration data is received by the host from a DHCP server,
regardless of which interface it is received on, the DHCP client
rewrites the global configuration data, such as the default routes and
the DNS server list (in /etc/resolv.conf) with the most recent
information received. Therefore, the last configured interface always
become the primary one. The ISC DHCPv6 client behaves similarly.
</t>
<t>
The Phystech dhcpcd client <xref target="PHYSTECHDHCPC"></xref>
behaves similarly to the ISC client. It replaces the DNS server list
in /etc/resolv.conf and the default routes each time new DHCP
information is received on any interface. However, the -R flag can be
used to instruct the client to not replace the DNS servers in
/etc/resolv.conf. However, this flag is a global flag for the DHCP
server, and is therefore applicable to all interfaces. When dhcpd is
called with the -R flag, the DNS servers are never replaced.
</t>
<t>
The pump client <xref target="PUMP"></xref> also behaves similarly to
the ISC client. It replaces the DNS servers in /etc/resolv.conf and
the default routes each time new DHCP information is received on any
interface. However, the nodns and nogateway options can be specified
on a per interface basis, enabling the user to define which interface
should be used to obtain the global configuration information.
</t>
<t>
The udhcp client <xref target="UDHCP"></xref> is often used in
embedded platforms based on busybox. The udhcp client behaves
similarly to the ISC client. It rewrites default routes and the DNS
server list each time new DHCP information is received.
</t>
<t>
Redhat-based distributions, such as Redhat, Centos and Fedora have a
per-interface configuration option (PEERDNS) that indicates that the
DNS server list should not be updated based on configuration received
on that interface.
</t>
<t>
The most configurable DHCP clients can be set to define a primary
interface to use only that interface for the global configuration
data. However, this is limited, since a mobile host might not always
have the same set of interfaces available. Connection managers may help
in this situation.
</t>
<t>
Some distributions also have a connection manager. However, most
connection managers serve as a GUI to the DHCP client, therefore not changing
the functionality described above . TODO: Verify all connection managers.
</t>
<t>TODO: DHCPv6 clients</t>
</section>
<section title="Apple Mac OS X">
<t>
This section is based on testing Mac OS X (version 10.5.6).
</t>
<t>
When using multiple interfaces on Mac OS X, global configuration data
such as default routes and the DNS server list are taken from the DHCP
data received on the primary interface. Therefore, the order in which
the interfaces receive their configuration data is not relevant. For
example, if the primary interface receives its configuration data
first, then the second interface receives its configuration data, the
interface-specific information for the second interface will be
configured, but the global configuration information such as the DNS
server list and default routes is not overwritten.
</t>
</section>
</section>
<section title="Common solutions">
<t>
Essentially all operating systems use the same types of information
to make decisions about multiple-interface operation: user input,
operator/administrator provided information, and what has been
statically configured or hard-coded. It is possible to design
clever ways for tackling the problems related to multi-homing from the
set of dynamically available information, vendor specific policies and
design decisions. However, limitations on available information also
set limits on what different operating systems can theoretically
achieve.
</t>
<t>
This section describes what common solution approaches the analyzed
operating systems are known to utilize.
</t>
<section title="Centralized connection management">
<t>
It seems to be common practice to have a centralized connection
manager entity, which does the network interface selection based on
application input. The information used by the connection manager may
be programmed into an application, learned from the users, or
provisioned.
</t>
<t>
Routing tables are not typically used for network interface selection,
as the criteria for network selection is not strictly IP-based but is
also dependent on other properties of the interface (cost, type,
etc.). Furthermore, multiple overlapping private IPv4 address spaces
are often exposed to a multiple-interface host, making it difficult to
make interface selection decisions based on prefix matching.
</t>
</section>
<section title="Per application connection settings">
<t>
As each application has its particular connectivity needs,
applications are able to request what kind of connectivity they need.
</t>
</section>
</section>
<section title="Common problems">
<t>
The current solutions are limited by the information available. This
section discusses what types of information IETF-designed protocols
could provide to allow implementations to improve functionality in
multi-inteface scenarios.
</t>
<t>
Please also see MIF problem statement
document <xref target="I-D.blanchet-mif-problem-statement"></xref>.
</t>
<t>
DISCUSS: is this section 4 required in this document, or should we
fully leave the problem descriptions to problem statement, or have
here some general problems, and in problem-statement more detailed
problems?
</t>
<section title="Selection of an interface providing access to a destination">
<t>
As different network interfaces may provide connectivity to different
destination networks, a host needs to be able to choose a correct
network interface (or a set of interfaces, if the application can use
multiple interfaces in parallel) to allow the application or IP flow to
reach the intended destination.
</t>
</section>
<section title="Prioritization of interfaces for the same destination">
<t>
As several interfaces may lead to the same destination network, a host
has to choose which one to use. It may be that if one network has
connectivity limitations, such as firewalls or NATs, and the other
network does not, it may be preferable to use the interface to the
less restricted network. This is not always the case, e.g. if access
to the restricted network is faster or cheaper, it might be desirable
to use that interface, if it can support the application and reach the
desired destination. Could the network somehow indicate what
limitations it is imposing, or could there be new technologies that
would help to determine the connectivity properties of a network?
</t>
<t>
Improved source/destination address selection (underway in the 6man
address selection design team), more specific routes (RFC4191), or
other (TBD) technologies may be helpful in this area.
</t>
</section>
<section title="Enablers for application multihoming">
<t>
When applications are bound to use single network interface at a time,
they are unable to benefit from technologies developed for multihoming
purposes. Therefore technologies that help to free applications from
being bound into a single network interface would be useful.
Essentially this means advanced ways to ensure that applications use
the right network interface, and that applications do not accidentally
use interfaces that will not support the application or provide
connetivity to the destination. Can improvements be designed for IPv4
in spite of overlapping private IPv4 address spaces, or only for IPv6?
</t>
</section>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>
Authors of the document would like to thank following people for their
input and feedback: Hui Deng, Jari Arkko.
</t>
<t>
This document was prepared using xml2rfc template and related web-tool.
</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>
This memo includes no request to IANA.
</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>
This draft describes current multiple-interface host implementations on
some common operating systems without any focus on security
considerations.
</t>
</section>
</middle>
<back>
<references title="Normative References">
&I-D.blanchet-mif-problem-statement;
</references>
<references title="Informative References">
<reference anchor="S60"
target="http://www.forum.nokia.com/info/sw.nokia.com/id/190358c8-7cb1-4be3-9321-f9d6788ecae5/S60_Platform_IP_Bearer_Management_v1_0_en.pdf.html">
<front>
<title>S60 Platform: IP Bearer Management</title>
<author>
<organization>Nokia Corporation</organization>
</author>
<date year="2007" />
</front>
</reference>
<reference anchor="ANDROID"
target="http://developer.android.com/reference/android/net/ConnectivityManager.html">
<front>
<title>Android developers: package android.net</title>
<author>
<organization>Google Inc.</organization>
</author>
<date year="2009" />
</front>
</reference>
<reference anchor="WINDOWSMOBILE"
target="http://msdn.microsoft.com/en-us/library/aa457829.aspx">
<front>
<title>SDK Documentation for Windows Mobile-Based Smartphones: Connection Manager</title>
<author>
<organization>Microsoft Corporation</organization>
</author>
<date year="2005" />
</front>
</reference>
<reference anchor="BLACKBERRY"
target="http://na.blackberry.com/eng/deliverables/5827/Wireless_gateways_447132_11.jsp">
<front>
<title>BlackBerry Java Development Environment - Fundamentals Guide: Wireless gateways</title>
<author>
<organization>Research In Motion Limited</organization>
</author>
<date year="2009" />
</front>
</reference>
<reference anchor="ISCDHCP"
target="http://www.isc.org/software/dhcp">
<front>
<title>ISC DHCP</title>
<author>
<organization>Internet Software Consortium</organization>
</author>
<date year="2009" />
</front>
</reference>
<reference anchor="OPENBSDDHCLIENT"
target="http://www.openbsd.org/">
<front>
<title>OpenBSD dhclient</title>
<author>
<organization>OpenBSD</organization>
</author>
<date year="2009" />
</front>
</reference>
<reference anchor="PHYSTECHDHCPC"
target="http://www.phystech.com/download/dhcpcd.html">
<front>
<title>dhcpcd</title>
<author>
<organization>Phystech</organization>
</author>
<date year="2009" />
</front>
</reference>
<reference anchor="UDHCP"
target="http://sources.busybox.net/index.py/trunk/busybox/networking/udhcp/">
<front>
<title>uDHCP</title>
<author>
<organization>Busybox</organization>
</author>
<date year="2009" />
</front>
</reference>
<reference anchor="PUMP"
target="http://redhat.com">
<front>
<title>PUMP</title>
<author>
<organization>RedHat</organization>
</author>
<date year="2009" />
</front>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 04:21:29 |