One document matched: draft-ietf-mif-current-practices-10.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY I-D.ietf-mif-problem-statement SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-mif-problem-statement.xml">
<!ENTITY I-D.yang-mif-connection-manager-impl-req SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.yang-mif-connection-manager-impl-req.xml">
<!ENTITY I-D.zhang-mif-connection-manager-arena SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.zhang-mif-connection-manager-arena.xml">
<!ENTITY I-D.montenegro-mif-multihoming SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.montenegro-mif-multihoming.xml">
<!ENTITY rfc4311 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4311.xml'>
<!ENTITY rfc3484 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3484.xml'>
<!ENTITY rfc5113 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5113.xml'>
<!ENTITY rfc1122 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.1122.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-ietf-mif-current-practices-10" ipr="trust200902">
<front>
<title abbrev="MIF Current Practices">Current Practices for Multiple Interface Hosts</title>
<author fullname="Margaret Wasserman" initials="M." surname="Wasserman" >
<organization>Painless Security, LLC</organization>
<address>
<postal>
<street>356 Abbott Street</street>
<city>North Andover</city>
<region>MA</region>
<code>01845</code>
<country>USA</country>
</postal>
<phone>+1 781 405-7464</phone>
<email>mrw@painless-security.com</email>
<uri>http://www.painless-security.com</uri>
</address>
</author>
<author fullname="Pierrick Seite" initials="P.S." surname="Seite" >
<organization>France Telecom - Orange</organization>
<address>
<postal>
<street>4, rue du clos courtel BP 91226</street>
<city>Cesson-Sevigne</city>
<code>35512</code>
<country>France</country>
</postal>
<email>pierrick.seite@orange-ftgroup.com</email>
</address>
</author>
<date month="April" year="2011" />
<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. This document summarizes current
practices in this area, and describes in detail how some common
operating systems cope with challenges ensue from this context.
</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 the MIF problem
statement, <xref target="I-D.ietf-mif-problem-statement"></xref>.
This document summarizes how current implementations deal with the
problems identified in the MIF problem statement.
</t>
<t>
Publicly-available information about the multiple-interface solutions
implemented in some widely used operating systems, including both
mobile handset and desktop operating systems, is collected in
this document, 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>, Microsoft Windows, Apple Mac
OS X, Linux and BSD-based operating systems.
</t>
</section>
<section title="Summary of Current Approaches">
<t>
This section summarizes current approaches that are used to resolve
the multi-interface issues described in the Multiple Interface Problem
Statement <xref target="I-D.ietf-mif-problem-statement"></xref>.
These approaches can be broken down into three major categories:
</t>
<t>
<list style="symbols">
<t>Centralized connection management</t>
<t>Per-application connection settings</t>
<t>Stack-level solutions to specific problems</t>
</list>
</t>
<section title="Centralized Connection Management">
<t>
It is a common practice for mobile handset operating systems to
use a centralized connection manager that performs network interface
selection based on application or user input. The information used by
the connection manager may be programmed into an application or
provisioned on a handset-wide basis. When information is not
available to make an interface selection, the connection manager will
query the user to choose between available choices.
</t>
<t>
Routing tables are not typically used for network interface selection
when a connection manager is in use, 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>
In mobile handsets, applications are often involved in choosing what
interface and related configuration information should be used. In
some cases, the application selects the interface directly, and in
other cases the application provides more abstract information to
a connection manager that makes the final interface choice.
</t>
</section>
<section title="Stack-Level Solutions to Specific Problems">
<t>
In most desktop operating systems, multiple interface problems are
dealt with in the stack and related components, based on system- level
configuration information, without the benefit of input from
applications or users. These solutions tend to map well to the
problems listed in the problem statement:
</t>
<t>
<list style="symbols">
<t>DNS resolution issues</t>
<t>Routing</t>
<t>Address selection policy</t>
</list>
</t>
<t>
The configuration information for desktop systems comes from one of
three sources: DHCP, proprietary configuration systems or manual
configuration. While these systems universally accept IP address
assignment on a per-interface basis, they differ in what set of
information can be assigned on a per-interface basis and what
can be configured only on a per-system basis.
</t>
<t>
When choosing between multiple sets of information provided, these
systems will typically give preference to information received on
the "primary" interface. The mechanism for designating the "primary"
interface differs by system.
</t>
<t>
There is very little commonality in how desktop operating systems
handle multiple sets of configuration information, with notable
variations between different versions of the same operating system
and/or within different software packages built for the same
operating system. Although these systems differ widely, it is
not clear that any of them provide a completely satisfactory
user experience in multiple-interface environments.
</t>
<t>
The following sections discuss some of the solutions used in each of
the areas raised in the MIF problem statement.
</t>
<section title="DNS Resolution Issues">
<t>
There is very little commonality in how desktop operating systems
handle the DNS server list. Some systems support per-interface DNS
server lists, while others only support a single system-wide list.
</t>
<t>
On hosts with per-interface DNS server lists, different mechanisms
are used to determine which DNS server is contacted for a given
query. In most cases, the first DNS server listed on the "primary"
interface is queried first, with back off to other servers if an
answer is not received.
</t>
<t>
Systems that support a single system-wide list differ in how they
select which DNS server to use in cases where they receive more than
one DNS server list to configure (e.g. from DHCP on multiple
interfaces). Some accept the information received on the "primary"
interface, while others use either the first or last set DNS server
list configured.
</t>
</section>
<section title="First hop selection">
<t>
Routing information is also handled differently on different desktop
operating systems. While all systems maintain some sort of routing
cache, to handle redirects and/or statically configured routes, most
packets are routed based on configured default gateway information.
</t>
<t>
Some systems do allow the configuration of different default router
lists for different interfaces. These systems will always choose the
default gateway on the interface with the lowest routing metric, with
different behavior when two or more interfaces have the same routing
metric.
</t>
<t>
Most systems do not allow the configuration of more than one default
router list, choosing instead to use the first or last default router
list configured and/or the router list configured on the "primary"
interface.
</t>
</section>
<section title="Address Selection Policy">
<t>
There is somewhat more commonality in how desktop hosts handle
address selection. Applications typically provide the destination
address for an outgoing packet, and the IP stack is responsible
for picking the source address.
</t>
<t>
IPv6 specifies a specific source address selection mechanism in
<xref target="RFC3484"/>, and several systems implement this
mechanism with similar support for IPv4. However, many systems
do not provide any mechanism to update this default policy, and
there is no standard way to do so.
</t>
<t>
In some cases, the routing decision (including which interface to
use) is made before source address selection is performed, and a
source address is chosen from the outbound interface. In other
cases, source address selection is performed before, or independently
from outbound interface selection.
</t>
</section>
</section>
</section>
<section title="Current Practices in 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="Mobile Handset Operating Systems">
<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>
<section title="Nokia S60 3rd Edition, Feature Pack 2">
<t>
S60 is a software platform for mobile devices running on the Symbian OS.
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 is 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>
In S60 3.2 does not support RFC 3484 for source address selection mechanisms.
Applications are tightly bound the network interface selected for them or by them. E.g. an application may
be connected to IPv6 3G connection, IPv4 3G connection, WLAN connection, or VPN connection.
The application can change between the connections, but uses only one at a time.
If the interface happens to be dual-stack, then IPv4 is preferred over IPv6.
</t>
<t>
DNS configuration is per-interface; an application bound to an interface will always use
the DNS settings for that interface. Hence the device itself remembers these pieces of information
for each interface separately.
</t>
<t>
The S60 3.2 manages with totally overlapping addresses spaces. Each interface can even
have same IPv4 address configured on it without issues. This is so because interfaces are
kept totally separate from each other. This also implies that the interface selection has to be done at
application layer, as from network layer point of view device is not multihomed in the IP-sense.
</t>
<t>
Please see the source documentation for more details and screenshots:
<xref target="S60"></xref>.
</t>
</section>
<section title="Microsoft Windows Mobile and Windows Phone 7">
<t>
Microsoft Windows Mobile leverages on a Connection Manager <xref target="WINDOWSMOBILE"></xref> to handle multiple network connections. 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>
<t>
In comparison to Windows Mobile connection management, Windows phone 7 updates the routing functionality in the case where the terminal can be attached simultaneously to several interfaces. Windows Phone 7 selects the first hop corresponding to the interface which has a lower metric. When there are multiple interfaces, the applications system will, by default, choose from an ordered list of available interfaces. The default connection policy will prefer wired over wireless and WLAN over cellular. Hence, if an application wants to use cellular 3G as the active interface when WLAN is available, the application needs to override the default connection mapping policy. An application specific mapping policy can be set via a microsoft API or provisioned by the Mobile Operator. The application, in compliance with the security model, can request connection type by interface (WLAN, cellular), by minimum interface speed (x kbps, y mbps), or by name (Access Point Name).
</t>
<t>
In dual-stack systems, Windows mobile and Windows phone 7 implement adress selection rules as per <xref target="WNDS-RFC3484"></xref>.
An administrator can configure a policy table that can override the default behavior of the selection algorithms. It is reminded that the policy table specifies precedence values and preferred source prefixes for destination prefixes (see <xref target="RFC3484"/>, section 2.1, for details). If the system has not been configured, then the default policy table specified in <xref target="RFC3484"/> is used.
</t>
</section>
<section title="RIM BlackBerry">
<t>
Depending on the network configuration, applications in reasearch In Motion (RIM) BlackBerry devices <xref target="BLACKBERRY"></xref> can use
can use direct TCP/IP connectivity or different application proxys to establish connections
over the wireless network. For instance, some wireless
service providers provide an Internet gateway to offer direct TCP/IP connectivity to the Internet while some others can provide
a WAP gateway that allows HTTP connections to occur over the WAP (Wireless Application Protocol)
protocol.
It is also possible to use the BlackBerry Enterprise Server <xref target="BLACKBERRY"></xref> as a network gateway,
The BlackBerry Enterprise Server provides an HTTP and TCP/IP proxy service to allow the
application to use it as a secure gateway for managing HTTP and TCP/IP connections
to the intranet or the Internet. An application connecting to the Internet,
can use either the BlackBerry Internet Service or the Internet gateway of
the wireless server provider or direct Internet connectivity over WLAN to manage connections.
The problem of gateway selection is supposed to be managed independently by each application.
For instance, an application can be designed to always use the default Internet gateway, while another application can be designed to use a preferred proxy when available.
</t>
<t>
A BlackBerry device <xref target="BLACKBERRY"></xref> can be attached to multiple networks simultaneously
(wireless/wired). In this case, Multiple network interfaces can be associated to a single IP stack or multiple IP stacks. The device, or the application, can select the network interface to be used in various ways. For instance, the device can always map the applications to the default network interface (or the default access network).
When muliple IP stacks are associated to multiple interfaces, the application can select the source address correponding to the preferred network interface. Per-interface IP stacks also allow to manage overlapping addresses spaces. When multiple network interfaces are aggregated into a single IP stack, the device associates each application to the more appropriate network interface. The selection can be based on cost, type-of-service and/or user preference.
</t>
<t>
The BlackBerry uses per-interface DNS configuration; applications bound to a specific interface will use the DNS settings for that interface.
</t>
</section>
<section title="Google Android">
<t>
Android is based on a Linux kernel and, in many situations, behaves like a Linux device as
described in <xref target="Linux"/>. As per Linux, Androïd can manage multiple routing tables and rely on
policy based routing associated with packet filtering capabilities (see <xref target="Linux-routing"/> for details).
Such a framework can be used
to solve complex routing issue brought by multiple interfaces terminals, e.g. address space overlapping.
</t>
<t>
For incoming packets, Androïd implements the weak host model <xref target="RFC1122"/> on both IPv4
and IPv6. However, Androïd can also be configured to support the strong host model.
</t>
<t>
Regarding DNS configuration, Androïd does not list the DNS servers in the file /etc/resolv.conf,
used by Linux. However, as per Linux, DNS configuration is node-scoped, even if DNS configuration
can rely on the DHCP client. For instance, the udhcp client <xref target="UDHCP"></xref>,
which is also available for Linux, can be used on Androïd.
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 with the most recent information received.
</t>
<t>
Actually, the main difference between Linux and Androïd is on the address selection mechanism.
Android version prior to 2.2 simply prefers IPv6 connectivity over IPv4. However, it should be noted that, at the time of writing,
IPv6 is available only on WiFi and virtual interfaces, but not on the cellular interface (without IPv6 in IPv4 encapsulation).
Android 2.2 has been updated with <xref target="ANDROID-RFC3484"></xref>, which implements some
of the address selection rules defined in <xref target="RFC3484"/>.
All RFC3484 rules are supported, except rule 3 (avoid deprecated addresses), 4 (prefer home addresses)
and 7 (prefer native transport). Also, rule 9 (use longest matching prefix) has been modified so it
does not sort IPv4 addresses.
</t>
<t>
The Android reference documentation describes the android.net
package <xref target="ANDROID"></xref> and the ConnectivityManager
class that applications can use to request the first hop to a specified
destination address via a specified network interface
(3GPP or WLAN). 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>
</section>
<section title="Qualcomm Brew">
<t>
This section describes how multi-interface support is handled by Advanced Mobile Station Software (AMSS)
that comes with Brew OS for all Qualcomm chipsets (e.g., MSM, Snapdragon etc).
AMSS is a low level connectivity platform, on top of which manufacturers can build to provide the necessary
connectivity to applications. The interaction model between AMSS, the Operating System, and the applications
is not unique and depend on the design chosen by the manufacturer. The Mobile OS can let an application invoke
the AMSS directly (via API), or provide its own connection manager that will request connectivity to the AMSS
based on applications needs. The interaction between the OS connection manager and the applications is OS dependent.
</t>
<t>
AMSS supports a concept of netpolicy which allows each application
to specify the type of network connectivity desired.
The netpolicy contains parameters such as access technology, IP version type and
network profile. Access technology could be a specific technology
type such as CDMA or WLAN or could be a group of technologies, such as
ANY_Cellular or ANY_Wireless. IP version could be one of IPv4, IPv6
or Default. The network profile identifies a type of network domain
or service within a certain network technology, such as 3GPP APN or
Mobile IP Home Agent. It also specifies all the mandatory parameters
required to connect to the domain such authentication credentials and
other optional parameters such as QoS attributes. Network Profile is
technology specific and set of parameters contained in the profile
could vary for different technologies.
</t>
<t>
Two models of network usage are supported:
<list style="symbols">
<t>
Applications requiring network connectivity specify an appropriate
netpolicy in order to select the desired network. The netpolicy may
match one or more network interfaces. AMSS system selection module
selects the best interface out of the ones that match the netpolicy
based on various criteria such as cost, speed or other provisioned
rules. Application explicitly starts the selected network interface
and, as a result, the application also gets bound to the corresponding
network interface. All outbound packets from this application are
always routed over this bound interface using the source address of
the interface.
</t>
<t>
Applications may rely on a separate connection manager to
control (e.g. start/stop) the network interface. In this model,
applications are not necessarily bound to any one interface. All
outbound packets from such applications are routed on one of the
interfaces that match its netpolicy. The routing decision is made
individually for each packet and selects the best interface based on
the criteria described above and the destination address. Source
address is always that assigned to the interface used to transmit the
packet.
</t>
</list>
</t>
<t>
All of the routing/interface selection decisions are based
on the netpolicy and not just on the destination address to avoid overlapping
private IPv4 address issue. This also allows multiple
interfaces to be configured with the same IP address, for example, to
handle certain tunnelling scenarios. Applications that do not
specify a netpolicy are routed by AMSS to the best possible interface
using the default netpolicy. Default netpolicy could be pre-defined
or provisioned by the administrator or operator. Hence default
interface could vary from device to device and also depends upon the
available networks at any given time.
</t>
<t>
AMSS allows each interface to be configured with its own set of DNS
configuration parameters (e.g. list of DNS servers, domain names etc.).
Interface selected to make a DNS resolution is the one to which
application making the DNS query is bound. Applications can also
specify a different netpolicy as part of DNS request to select another
interface for DNS resolution. Regardless, all the DNS queries are
sent only over this selected interface using the DNS configuration
from the interface. DNS resolution is first attempted with the
primary server configured in the interface. If a response is not
received, the queries are sent to all the other servers configured in
the interface in a sequential manner using a backoff mechanism.
</t>
</section>
<section title="Leadcore Tech. Arena">
<t>
Arena, a mobile OS based on Linux, provides a Connection Manager, which is described in
<xref target="I-D.zhang-mif-connection-manager-arena"/> and
<xref target="I-D.yang-mif-connection-manager-impl-req"/>. The
arena connection manager provides a means for applications to
register their connectivity requirement.
The Connection Manager can then choose an interface that matches
the application's needs while considering other factors such as
availability, cost and stability. Also, the Connection Manager
can handle multiple-interfaces issues such as connection sharing.
</t>
</section>
</section>
<section title="Desktop Operating Systems">
<t>
Multi-interface issues also occur in desktop environments in those
cases where a desktop host has multiple (logical or physical)
interfaces connected to networks with different reachability
properties, such as one interface connected to the global Internet,
while another interface is connected to a corporate VPN.
</t>
<section title="Microsoft Windows">
<t>
The multi-interface functionality currently implemented in Microsoft
Windows operation systems is described in more detail
in <xref target="I-D.montenegro-mif-multihoming"/>.
</t>
<section title="First hop selection">
<t>
It is possible, although not often desirable, to configure default
routers on more than one Windows interface. In this configuration,
Windows will use the default route on the interface with the lowest
routing metric (i.e. the fastest interface). If multiple interfaces
share the same metric, the behavior will differ based on the version
of Windows in use. Prior to Windows Vista, the packet would be routed
out of the first interface that was bound to the TCP/IP stack, the
preferred interface. In Windows vista, host-to-router load
sharing <xref target="RFC4311"/> is used for both IPv4 and IPv6.
</t>
</section>
<section title="Outbound and Inbound Addresses">
<t>
If the source address of the outgoing packet has not been determined
by the application, Windows will choose from the addresses assigned to
its interfaces. Windows implements <xref target="RFC3484"/> for source
address selection in IPv6 and, in Windows Vista, for IPv4. Prior to
Windows Vista, IPv4 simply chose the first address on the outgoing
interface.
</t>
<t>
For incoming packets, Windows will check if the destination address
matches one of the addresses assigned to its interfaces. Windows has
implemented the weak host model <xref target="RFC1122"/> on IPv4 in
Windows 2000, Windows XP and Windows Server 2003. The strong host
model became the default for IPv4 in Windows Vista and Windows server
2008, however the weak host model is available via per-interface
configuration. IPv6 has always implemented the strong host model.
</t>
</section>
<section title="DNS Configuration">
<t>
Windows largely relies on suffixes to solve DNS resolution issues. Suffixes are used for four different purposes that are reminded hereafter:
<list style="numbers">
<t>DNS Suffix Search List (aka domain search list): suffix is added to non-FQDN names.</t>
<t>Interface-specific suffix list, which allows sending different DNS queries to different DNS servers.</t>
<t>Suffix to control Dynamic DNS Updates: determine which DNS server will receive a dynamic update for a name with a certain suffix.</t>
<t>Suffix in the Name Resolution Policy Table <xref target="NRPT"></xref> to aid in identifying a Namespace that requires special handling
(feature available only after Windows 7 and its server counterpart, Windows Server 2008 R2).</t>
</list>
However, this section focuses on the interface-specific suffix list since it is the only suffix usage in the scope of this document.
</t>
<t>
DNS configuration information can be host-wide or interface specific. Host-wide DNS configuration is
input via static configuration or, in sites that use Active Directory, Microsoft's Group Policy.
Interface specific DNS configuration can be input via static configuration
or via DHCP.
</t>
<t>
The host-wide configuration consists of a primary DNS suffix to be used for the local host, as
well as a list of suffix that can be appended to names being queried.
Before Windows Vista and Windows Server 2008, there was also a host-wide
DNS server list that took precedent over per-interface DNS configuration.
</t>
<t>
The interface-specific DNS configuration comprises an interface-specific suffix list
and a list of DNS server IP addresses.
</t>
<t>
Windows uses a host-wide "effective" server list for an actual query,
where the effective server list may be different for different names.
In the list of DNS server addresses, the first server is considered the
"primary" server, with all other servers being secondary.
</t>
<t>
When a DNS query is performed in Windows, the query is first sent to
the primary DNS server on the preferred interface. If no response is
received in one second, the query is sent to the primary DNS servers
on all interfaces under consideration. If no response is received for
2 more seconds, the DNS server sends the query to all of the DNS
servers on the DNS server lists for all interfaces under
consideration. If the host still doesn't receive a response after 4
seconds, it will send to all of the servers again and wait 8 seconds
for a response.
</t>
</section>
</section>
<section title="Linux and BSD-based Operating Systems" anchor="Linux">
<section title="First hop selection" anchor="Linux-routing">
<t>
In addition to the two commonly used routing tables (the local and main routing tables), the kernel can
support up to 252 additional routing tables which can be added in the file /etc/iproute2/rt_tables.
A routing table can contain an arbitrary number of routes, the selection of route is classically made
according to the destination address of the packet. Linux also provides more flexible routing
selection based on the Type of Service, scope, output interface. In addition, since kernel version 2.2,
Linux supports policy based routing using the multiple routing tables capability and a routing policy
database. This database contains routing rules used by the kernel. Using policy based routing, the source
address, the ToS flags, the interface name and an "fwmark" (a mark carried through added in the data
structure representing the packet) can be used as route selectors.
</t>
<t>
Policy based routing can be used in addition to Linux packet filtering capabilities,
e.g provided by the "iptables" tool. In a multiple interfaces context, this tool can be used to mark
the packets, i.e assign a number to fwmark, in order to select the routing rule according to the type of
traffic. This mark can be assigned according to parameters like protocol, source and/or destination
addresses, port number and so on.
</t>
<t>
Such a routing management framework allows to deal with complex situation such as address space overlapping.
In this situation, the administrator can use packet marking and policy based routing to select
the correct interface.
</t>
</section>
<section title="Outbound and Inbound Addresses">
<t>
By default, source address selection follows the following basics rules: the initial source address
for an outbound packet can be chosen by the application using the bind() call.
Without information from the application, the kernel chooses the first address configured on the
interface which belongs to the same subnet than the destination address or the nexthop router.
</t>
<t>
Linux also implements <xref target="RFC3484"/> for source address selection for IPv6
and dual-stack configurations.
However, the address sorting rules from <xref target="RFC3484"/> are not always adequate.
For this reason, Linux allows the system administrator to dynamically change the sorting.
This can be achieved with the /etc/gai.conf file.
</t>
<t>
For incoming packets, Linux checks if the destination address
matches one of the addresses assigned to its interfaces then, processes the packet according
the configured host model. By default, Linux implements
the weak host model <xref target="RFC1122"/> on both IPv4 and IPv6. However, Linux can
also be configured to support the strong host model.
</t>
</section>
<section title="DNS Configuration">
<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.
</t>
</section>
</section>
</section>
<section title="Focus on access network selection">
<t>
This section describes behaviors of connection managers in presence of multiple points of attachment
for a same interface. The section focuses on WLAN access technology, it is described how does the connection manager
deal with the list of preferred SSID and how does it select the access point for attachment.
Desktops are not covered since many different connection managers can be easily installed, thus making hard to report a common behaviour. This section only focuses on a specific use-case and some of the current implementations; however further considerations on network discovery and selection can be found in <xref target="RFC5113"/>. <xref target="RFC5113"/> describes the network discovery and selection and discusses limitations and constraints on potential solutions.
</t>
<section title="Android/HTC magic">
<t>
When the terminal is under coverage of different WLAN networks with different SSIDs:
<list style="empty">
<t>
The connection manager selects the first SSID of the the list of preferred access network. The connection manager constructs the list of preferred SSID giving priority to the last SSID on which it has managed to attach. The user is not allowed to define its preferred access. So, if the terminal discovers and manages to attach to SSID1, SSID1 becomes the preferred access for future attachment. If the terminal moves out of SSID1 coverage and attaches to a new SSID, e.g. SSID2. SSID2 will then be the preferred access of the connection manager. Then, if the terminal processes to WLAN attachment within both SSID1 and SSID2 coverage, the connection manager will select SSID2 for attachment.
</t>
<t>
When the layer 2 fails to attach to the selected SSID, the connection manager automatically selects the next SSID
in the list of preferred SSID. Fallback come into play at expiration of a timeout which can be configured.
</t>
<t>
When the IP stack fails to obtain an IP address after successful WLAN attachment, the handset tries to connect to the next SSID in the list.
</t>
</list>
</t>
<t>
When the terminal receives signals from different point of attachment with same SSID:
<list style="empty">
<t>
The connection manager selects the point of attachment with best signal strength;
no other criteria (e.g. MAC address) is taken into account. If the handset fails to attach to the selected point of attachment (e.g. due to L2 authentication failure), the connection manager selects the next point of attachment with higher signal strength. If no more points of attachment, with this SSID, is available, the connection manager selects the next SSID in the list of preferred SSID.
</t>
<t>
If the terminal is unable to set up the IP connectivity on one WLAN access, the connection manager will not try to attach to an alternative point of attachment, or to an alternative SSID, as long as the signal strength of the first radio link is the most powerful. In other words, fallback on L3 attachment failure is not supported if the terminal remains under coverage of the same WLAN access point.
</t>
</list>
</t>
</section>
<section title="RIM BlackBerry">
<t>
When the terminal is under coverage of different WLAN networks with different SSIDs:
<list style="empty">
<t>
The device scans the WLAN frequency band. Then, if some SSIDs are in the list of preferred SSID, the connection manager selects the top of this list. The user can define its list of preferred accesses. This list can be also enriched after successful attachment to a new SSID. If so, the SSID is added at the end of the list.
</t>
<t>
When the layer 2 fails to attach to the selected SSID, the connection manager automatically selects the next SSID
in the list of preferred SSID. Fallback come into play at expiration of a timeout which can be configured.
</t>
<t>
When the IP stack fails to obtain an IP address after successful WLAN attachment, the BlackBerry tries to connect to the next SSID in the list.
</t>
</list>
</t>
<t>
When the terminal receives signals from different point of attachment with same SSID:
<list style="empty">
<t>
The connection manager selects the point of attachment with best signal strength;
no other criteria (e.g. MAC address) is taken into account. If the handset fails to attach to the selected point of attachment (e.g. due to L2 authentication failure),
the connection manager selects the point of attachment with lower signal strength. If no more points of attachment
(corresponding to the preferred SSID) are available,
the connection manager selects the next SSID in the list of preferred SSID.
</t>
<t>
The connection manager always selects the most powerful signal strength without considering IP configuration results.
If the terminal is unable to set up the IP connectivity on one WLAN access, the connection manager will not try to attach to an alternative point of attachment, or alternative SSID, as long as the signal strength of the current access point is the most powerful. If the user is moving and if the signal strength of an alternative point of attachment become better, the terminal automatically
restarts layer 2 and IP connectivity processes on that alternative access point.
</t>
</list>
</t>
</section>
</section>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>
Authors of the document would like to thank following people for their
input and feedback: Dan Wing, Hui Deng, Jari Arkko, Julien Laganier and Steinar H. Gunderson.
</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 document describes current operating system implementations and
how they handle the issues raised in the MIF problem statement. While
it is possible that the currently implemented mechanisms described in
this document may affect the security of the systems described, this
document merely reports on current practice. It does not attempt to
analyze the security properties (or any other architectural
properties) of the currently implemented mechanisms.
</t>
</section>
<section title="Contributors">
<t>
The following people contributed most of the per-Operating System
information found in this document:
<list style="symbols">
<t>Marc Blanchet, Viagenie</t>
<t>Hua Chen, Leadcoretech, Ltd.</t>
<t>Yan Zhang, Leadcoretech Ltd.</t>
<t>Shunan Fan, Huawei Technology</t>
<t>Jian Yang, Huawei Technology</t>
<t>Gabriel Montenegro, Microsoft Corporation</t>
<t>Shyam Seshadri, Microsoft Corporation </t>
<t>Dave Thaler, Microsoft Corporation</t>
<t>Kevin Chin, Microsoft Corporation</t>
<t>Teemu Savolainen, Nokia</t>
<t>Tao Sun, China Mobile</t>
<t>George Tsirtsis, Qualcomm.</t>
<t>David Freyermuth, France telecom.</t>
<t>Aurelien Collet, Altran.</t>
<t>Giyeong Son, RIM.</t>
</list>
</t>
</section>
</middle>
<back>
<references title="Normative References">
&I-D.ietf-mif-problem-statement;
</references>
<references title="Informative References">
&I-D.zhang-mif-connection-manager-arena;
&I-D.yang-mif-connection-manager-impl-req;
&I-D.montenegro-mif-multihoming;
&rfc4311;
&rfc3484;
&rfc1122;
&rfc5113;
<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="WNDS-RFC3484"
target="http://msdn.microsoft.com/en-us/library/aa925716.aspx">
<front>
<title>SDK Documentation for Windows Mobile-Based Smartphones: Default Address Selection for IPv6</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>
<reference anchor="NRPT"
target=" http://technet.microsoft.com/en-us/magazine/ff394369.aspx">
<front>
<title>Name Resolution Policy Table</title>
<author>
<organization>Windows</organization>
</author>
<date month="February" year="2010" />
</front>
</reference>
<reference anchor="ANDROID-RFC3484"
target="http://gitorious.org/0xdroid/bionic/commit/9ab75d4cc803e91b7f1b656ffbe2ad32c52a86f9">
<front>
<title>RFC 3484 support for Androïd</title>
<author initials="S." surname="Gunderson"
fullname="Steinar H. Gunderson">
<organization>Google Inc.</organization>
</author>
<date year="2010" />
</front>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 02:38:35 |