draft-ietf-mif-current-practices-00.txt   draft-ietf-mif-current-practices-01.txt 
Internet Engineering Task Force M. Wasserman, Ed. Internet Engineering Task Force M. Wasserman, Ed.
Internet-Draft Sandstorm Enterprises Internet-Draft Painless Security, LLC
Intended status: Informational October 19, 2009 Intended status: Informational P. Seite, Ed.
Expires: April 22, 2010 Expires: December 12, 2010 France Telecom - Orange
June 10, 2010
Current Practices for Multiple Interface Hosts Current Practices for Multiple Interface Hosts
draft-ietf-mif-current-practices-00 draft-ietf-mif-current-practices-01
Abstract
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 summarizes
current practices in this area, and describes in detail how some
common operating systems cope with these challenges.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF). Note that other groups may also distribute
other groups may also distribute working documents as Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at This Internet-Draft will expire on December 12, 2010.
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 22, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents
publication of this document (http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Abstract include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
An increasing number of hosts are operating in multiple-interface described in the Simplified BSD License.
environments, where different network interfaces are providing
unequal levels of service or connectivity. This document summarizes
current practices in this area, and describes in detail how some
common operating systems cope with these challenges.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Summary of Current Approaches . . . . . . . . . . . . . . . . 3 2. Summary of Current Approaches . . . . . . . . . . . . . . . . 3
2.1. Centralized Connection Management . . . . . . . . . . . . 3 2.1. Centralized Connection Management . . . . . . . . . . . . 3
2.2. Per Application Connection Settings . . . . . . . . . . . 4 2.2. Per Application Connection Settings . . . . . . . . . . . 4
2.3. Stack-Level Solutions to Specific Problems . . . . . . . . 4 2.3. Stack-Level Solutions to Specific Problems . . . . . . . . 4
2.3.1. DNS Resolution Issues . . . . . . . . . . . . . . . . 5 2.3.1. DNS Resolution Issues . . . . . . . . . . . . . . . . 5
2.3.2. Routing . . . . . . . . . . . . . . . . . . . . . . . 5 2.3.2. Routing . . . . . . . . . . . . . . . . . . . . . . . 5
2.3.3. Address Selection Policy . . . . . . . . . . . . . . . 5 2.3.3. Address Selection Policy . . . . . . . . . . . . . . . 5
3. Current Practices in Some Operating Systems . . . . . . . . . 6 3. Current Practices in Some Operating Systems . . . . . . . . . 6
3.1. Mobile Handset Operating Systems . . . . . . . . . . . . . 6 3.1. Mobile Handset Operating Systems . . . . . . . . . . . . . 6
3.1.1. Nokia S60 3rd Edition, Feature Pack 2 . . . . . . . . 7 3.1.1. Nokia S60 3rd Edition, Feature Pack 2 . . . . . . . . 7
3.1.2. Microsoft Windows Mobile 2003 Second Edition . . . . . 8 3.1.2. Microsoft Windows Mobile 2003 Second Edition . . . . . 8
3.1.3. BlackBerry . . . . . . . . . . . . . . . . . . . . . . 9 3.1.3. BlackBerry . . . . . . . . . . . . . . . . . . . . . . 9
3.1.4. Google Android . . . . . . . . . . . . . . . . . . . . 9 3.1.4. Google Android . . . . . . . . . . . . . . . . . . . . 9
3.1.5. Arena Connection Manager . . . . . . . . . . . . . . . 9 3.1.5. Qualcomm Brew . . . . . . . . . . . . . . . . . . . . 9
3.2. Desktop Operating Systems . . . . . . . . . . . . . . . . 10 3.1.6. Arena Connection Manager . . . . . . . . . . . . . . . 11
3.2.1. Microsoft Windows . . . . . . . . . . . . . . . . . . 10 3.1.7. Access selection . . . . . . . . . . . . . . . . . . . 11
3.2.1.1. Routing . . . . . . . . . . . . . . . . . . . . . 10 3.2. Desktop Operating Systems . . . . . . . . . . . . . . . . 13
3.2.1.2. Outbound and Inbound Addresses . . . . . . . . . . 10 3.2.1. Microsoft Windows . . . . . . . . . . . . . . . . . . 13
3.2.1.3. DNS Configuration . . . . . . . . . . . . . . . . 10 3.2.1.1. Routing . . . . . . . . . . . . . . . . . . . . . 13
3.2.2. Linux and BSD-based Operating Systems . . . . . . . . 11 3.2.1.2. Outbound and Inbound Addresses . . . . . . . . . . 13
3.2.3. Apple Mac OS X . . . . . . . . . . . . . . . . . . . . 12 3.2.1.3. DNS Configuration . . . . . . . . . . . . . . . . 13
4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 3.2.2. Linux and BSD-based Operating Systems . . . . . . . . 15
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 3.2.3. Apple Mac OS X . . . . . . . . . . . . . . . . . . . . 16
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
7. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 13 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 14 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 7. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 17
9.1. Normative References . . . . . . . . . . . . . . . . . . . 14 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 17
9.2. Informative References . . . . . . . . . . . . . . . . . . 15 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16 9.1. Normative References . . . . . . . . . . . . . . . . . . . 18
9.2. Informative References . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction 1. Introduction
Multiple-interface hosts face several challenges not faced by single- Multiple-interface hosts face several challenges not faced by single-
interface hosts, some of which are described in the MIF problem interface hosts, some of which are described in the MIF problem
statement, [I-D.ietf-mif-problem-statement]. This document statement, [I-D.ietf-mif-problem-statement]. This document
summarizes how current implementations deal with the problems summarizes how current implementations deal with the problems
identified in the MIF problem statement. identified in the MIF problem statement.
Publicly-available information about the multiple-interface solutions Publicly-available information about the multiple-interface solutions
skipping to change at page 7, line 6 skipping to change at page 7, line 6
A cellular device with two network interfaces A cellular device with two network interfaces
Figure 1 Figure 1
Different network access technologies require different settings. Different network access technologies require different settings.
For example, WLAN requires Service Set Identifier (SSID) and the GPRS For example, WLAN requires Service Set Identifier (SSID) and the GPRS
network requires the Access Point Name (APN) of the Gateway GPRS network requires the Access Point Name (APN) of the Gateway GPRS
Support Node (GGSN), among other parameters. It is common that Support Node (GGSN), among other parameters. It is common that
different accesses lead to different destination networks (e.g. to different accesses lead to different destination networks (e.g. to
"Internet", "Intranet", cellular network services, etc.). "Internet", "intranet", cellular network services, etc.).
3.1.1. Nokia S60 3rd Edition, Feature Pack 2 3.1.1. Nokia S60 3rd Edition, Feature Pack 2
S60 uses the concept of an Internet Access Point (IAP) [S60] that S60 uses the concept of an Internet Access Point (IAP) [S60] that
contains all information required for opening a network connection contains all information required for opening a network connection
using a specific access technology. A device may have several IAPs using a specific access technology. A device may have several IAPs
configured for different network technologies and settings (multiple configured for different network technologies and settings (multiple
WLAN SSIDs, GPRS APNs, dial-up numbers, and so forth). There may WLAN SSIDs, GPRS APNs, dial-up numbers, and so forth). There may
also be 'virtual' IAPs that define parameters needed for tunnel also be 'virtual' IAPs that define parameters needed for tunnel
establishment (e.g. for VPN). establishment (e.g. for VPN).
skipping to change at page 9, line 31 skipping to change at page 9, line 31
from users. from users.
DISCUSS: How does the Blackberry decides when a WLAN interface, a DISCUSS: How does the Blackberry decides when a WLAN interface, a
cellular interface or some other physical interface is used? cellular interface or some other physical interface is used?
3.1.4. Google Android 3.1.4. Google Android
The Android reference documentation describes the android.net package The Android reference documentation describes the android.net package
[ANDROID] and the ConnectivityManager class that applications can use [ANDROID] and the ConnectivityManager class that applications can use
to request a route to a specified destination address via a specified to request a route to a specified destination address via a specified
network interface (Mobile or Wifi). Applications also ask Connection network interface (3GPP or Wifi). Applications also ask Connection
Manager for permission to start using a network feature. The Manager for permission to start using a network feature. The
Connectivity Manager monitors changes in network connectivity and Connectivity Manager monitors changes in network connectivity and
attempts to failover to another network if connectivity to an active attempts to failover to another network if connectivity to an active
network is lost. When there are changes in network connectivity, network is lost. When there are changes in network connectivity,
applications are notified. Applications are also able to ask for applications are notified. Applications are also able to ask for
information about all network interfaces, including their information about all network interfaces, including their
availability, type and other information. availability, type and other information.
DISCUSS: Are applications bound to use one network type at a time, or Applications are bound to use one network type at a time. For
can one application use multiple network features in parallel? example, on a 3G/Wifi HTC Dream (Android 1.5), web browsing uses only
the Wifi access when both 3G and WiFi are available. However
different applications can use different access at the same time.
For instance, the HTC Dream can utilize WLAN access for web browsing
and GPRS access for transferring multimedia messages (MMS).
3.1.5. Arena Connection Manager 3.1.5. Qualcomm Brew
The Arena Connection Manager is described in This section describes how multi-interface support is handled by
[I-D.zhang-mif-connection-manager-arena] and 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.
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 WiFi 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.
Two models of network usage are supported:
o 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.
o 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.
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.
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.
3.1.6. Arena Connection Manager
Arena, a mobile OS based on Linux, provides a Connection Manager,
which is described in [I-D.zhang-mif-connection-manager-arena] and
[I-D.yang-mif-connection-manager-impl-req]. The arena connection [I-D.yang-mif-connection-manager-impl-req]. The arena connection
manager provides a means for applications to register their manager provides a means for applications to register their
connectivity requirement with the Connection Manager. The Connection connectivity requirement. The Connection Manager can then choose an
Manager can then choose an interface that matches the application's interface that matches the application's needs while considering
needs while considering other factors such as availability, cost and other factors such as availability, cost and stability. Also, the
stability. Also, the Connection Manager can handle multi-interface Connection Manager can handle multi-interface issues such as
issues such as connection sharing. connection sharing.
3.1.7. Access selection
This section describes the behavior of connection managers in
presence of multiple points of attachment for a same interface. The
section focuses on Wifi interface, it is described how does the
connection manager deal with the list of preferred SSID and how does
it select the SSID for attachment. Current implementation of
connection managers are considered for the following handsets: LG
Pathfinder, HTC Android, RIM BlackBerry , iPhone (3G and 3GS).
When the terminal is under coverage of different WiFi networks with
different SSIDs:
connection managers, excepted for the RIM Blackberry, construct
the list of preferred SSID giving priority to the last SSID on
which they have 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, SSID2. SSID2 will then be the
preferred access of the connection manager. Then, if the terminal
processes to Wifi attachment within both SSID1 and SSID2 coverage,
the connection manager will select SSID2 for attachment. The RIM
Blackberry behaves differently, the connection manager selects the
first SSID on which it has managed to attach in the past.
All connection managers behave in the same way when the terminals
fails to attach to the selected SSID: the connection manager
automatically selects the second SSID in the list of preferred
SSID. Fallback come into play at expiration of a timeout from few
seconds to about 3 minutes.
When the IP stack fails to obtain an IP address, the handset,
excepted the Iphone, restarts Wifi attachment selecting the second
SSID in the list.
When the terminal receives signals from different point of attachment
with same SSID:
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. However, this fallback is not supported on the
LG pathfinder. If no more points of attachment (corresponding to
the preferred SSID) are available, the connection manager selects
the second SSID in the list of preferred SSID.
Whatever is the handset, fallback on L3 attachment failure is not
supported for motionless terminals. Actually, the connection
manager always selects the most powerful signal strength without
considering IP configuration results. In other words, if the
terminal is unable to set up the IP connectivity on one wifi
access, the connection manager will not try to attach to an
alternative point of attachment (or SSID) as long as the signal
strength of the first radio link is the most powerful. Situation
is not the same for mobile terminal since the signal strength of
the alternative point of attachment could become better while the
terminal is moving. If so, the terminal automatically restarts IP
connectivity process (excepted the HTC Magic which requires the
user to manually restart the L3 attachment).
3.2. Desktop Operating Systems 3.2. Desktop Operating Systems
Multi-interface issues also occur in desktop environments in those Multi-interface issues also occur in desktop environments in those
cases where a desktop host has multiple (logical or physical) cases where a desktop host has multiple (logical or physical)
interfaces connected to networks with different reachability interfaces connected to networks with different reachability
properties, such as one interface connected to the global Internet, properties, such as one interface connected to the global Internet,
while another interface is connected to a corporate VPN. while another interface is connected to a corporate VPN.
3.2.1. Microsoft Windows 3.2.1. Microsoft Windows
skipping to change at page 10, line 50 skipping to change at page 13, line 50
For incoming packets, Windows will check if the destination address For incoming packets, Windows will check if the destination address
matches one of the addresses assigned to its interfaces. Windows has matches one of the addresses assigned to its interfaces. Windows has
implemented the weak host model [RFC1122] on IPv4 in Windows 2000, implemented the weak host model [RFC1122] on IPv4 in Windows 2000,
Windows XP and Windows Server 2003. The strong host model became the Windows XP and Windows Server 2003. The strong host model became the
default for IPv4 in Windows Vista and Windows server 2008, however default for IPv4 in Windows Vista and Windows server 2008, however
the weak host model is available via per-interface configuration. the weak host model is available via per-interface configuration.
IPv6 has always implemented the strong host model. IPv6 has always implemented the strong host model.
3.2.1.3. DNS Configuration 3.2.1.3. DNS Configuration
Host-wide DNS configuration is input via static configuration or, in Windows largely relies on suffixes to solve DNS resolution issues.
sites that use Active Directory, Microsoft's Group Policy. The host- Suffixes are used for four different purposes that are reminded
wide configuration consists of a DNS suffix to be used for the local hereafter:
host, as well as a list of domain names 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.
Interface specific DNS configuration can be input via static 1. DNS Suffix Search List (aka domain search list): suffix is added
configuration or via DHCP. It includes: to non-FQDN names.
o An interface-specific suffix list. 2. Interface-specific suffix list, which allows sending different
DNS queries to different DNS servers.
o A list of DNS server IP addresses. 3. Suffix to control Dynamic DNS Updates: determine which DNS server
will receive a dynamic update for a name with a certain suffix.
4. Suffix in the Name Resolution Policy Table [NRPT] to aid in
identifying a Namespace that requires special handling (feature
available only after Windows 7 and its server counterpart,
Windows Server 2008 R2).
However, this section focuses on the interface-specific suffix list
since it is the only suffix usage in the scope of MIF.
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.
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.
The interface-specific DNS configuration comprises an interface-
specific suffix list and a list of DNS server IP addresses.
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 In the list of DNS server addresses, the first server is considered
the "primary" server, with all other servers being secondary. the "primary" server, with all other servers being secondary.
When a DNS query is performed in Windows, the query is first sent to 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 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 received in one second, the query is sent to the primary DNS servers
on all interfaces under consideration. If no response is received 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 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 servers on the DNS server lists for all interfaces under
consideration. If the host still doesn't receive a response after 4 consideration. If the host still doesn't receive a response after 4
skipping to change at page 12, line 39 skipping to change at page 16, line 13
on that interface. on that interface.
The most configurable DHCP clients can be set to define a primary The most configurable DHCP clients can be set to define a primary
interface to use only that interface for the global configuration interface to use only that interface for the global configuration
data. However, this is limited, since a mobile host might not always data. However, this is limited, since a mobile host might not always
have the same set of interfaces available. Connection managers may have the same set of interfaces available. Connection managers may
help in this situation. help in this situation.
Some distributions also have a connection manager. However, most Some distributions also have a connection manager. However, most
connection managers serve as a GUI to the DHCP client, therefore not connection managers serve as a GUI to the DHCP client, therefore not
changing the functionality described above . TODO: Verify all changing the functionality described above.
connection managers.
TODO: DHCPv6 clients
3.2.3. Apple Mac OS X 3.2.3. Apple Mac OS X
This section is based on testing Mac OS X (version 10.5.6). This section is based on testing Mac OS X (version 10.5.6).
When using multiple interfaces on Mac OS X, global configuration data When using multiple interfaces on Mac OS X, global configuration data
such as default routes and the DNS server list are taken from the such as default routes and the DNS server list are taken from the
DHCP data received on the primary interface. Therefore, the order in DHCP data received on the primary interface. Therefore, the order in
which the interfaces receive their configuration data is not which the interfaces receive their configuration data is not
relevant. For example, if the primary interface receives its relevant. For example, if the primary interface receives its
configuration data first, then the second interface receives its configuration data first, then the second interface receives its
configuration data, the interface-specific information for the second configuration data, the interface-specific information for the second
interface will be configured, but the global configuration interface will be configured, but the global configuration
information such as the DNS server list and default routes is not information such as the DNS server list and default routes is not
overwritten. overwritten.
4. Acknowledgements 4. Acknowledgements
Authors of the document would like to thank following people for Authors of the document would like to thank following people for
their input and feedback: Hui Deng, Jari Arkko. their input and feedback: Dan Wing, Hui Deng, Jari Arkko, Julien
Laganier.
This document was prepared using xml2rfc template and related web-
tool.
5. IANA Considerations 5. IANA Considerations
This memo includes no request to IANA. This memo includes no request to IANA.
6. Security Considerations 6. Security Considerations
This document describes current operating system implementations and This document describes current operating system implementations and
how they handle the issues raised in the MIF problem statement. how they handle the issues raised in the MIF problem statement.
While it is possible that the currently implemented mechanisms While it is possible that the currently implemented mechanisms
described in this document may affect the security of the systems described in this document may affect the security of the systems
described, this document merely reports on current practice. It does described, this document merely reports on current practice. It does
not attempt to analyze the security properties (or any other not attempt to analyze the security properties (or any other
architectural properties) of the currently implemented mechanisms. architectural properties) of the currently implemented mechanisms.
7. Change Log 7. Change Log
The following changes were made between The following changes were made between versions -00 and -01:
draft-mrw-mif-current-practices and
draft-ietf-mif-current-practices-00.txt.
o Updated operating system info based on new information supplied.
o Renamed "Current Solutions" to "Summary of Current Solutions" and
moved above OS specifics. Modified this section substantially to
match problems in problem statement.
o Removed "Current Problems" section, as it duplicated information o Added information on usage of suffix with Windows.
in the problem statement.
o Broke OS specifics into separate sections for mobile handsets and o new section describing Qualcomm AMSS/Brew Multi-interface handling
desktop operating systems.
The following changes were made between versions -00 and -01: o Considerations on access selection for some current connection
managers.
o Number of authors passed five, so moved to Contributors section. o Added information on multiple-interface scenarios with Google
Android.
o Added information on Microsoft Windows. o Clarifications of Arena connection manager
o Added information on Arena Connection Manager. o Added new contributors.
8. Contributors 8. Contributors
The following people contributed most of the per-Operating System The following people contributed most of the per-Operating System
information found in this document: information found in this document:
o Marc Blanchet, Viagenie o Marc Blanchet, Viagenie
o Hua Chen, Leadcoretech, Ltd. o Hua Chen, Leadcoretech, Ltd.
o Yan Zhang, Leadcoretech Ltd.
o Shunan Fan, Huawei Technology o Shunan Fan, Huawei Technology
o Gabriel Montenegro, Microsoft Corporation o Jian Yang, Huawei Technology
o Teemu Savolainen, Nokia o Gabriel Montenegro, Microsoft Corporation
o Shyam Seshadri, Microsoft Corporation o Shyam Seshadri, Microsoft Corporation
o Dave Thaler, Microsoft Corporation
o Teemu Savolainen, Nokia
o Tao Sun, China Mobile o Tao Sun, China Mobile
o Dave Thaler, Microsoft Corporation o George Tsirtsis, Qualcomm.
o Jian Yang, Huawei Technology o David Freyermuth, France telecom.
o Yan Zhang, Leadcoretech Ltd. o Aurelien Collet, Altran.
9. References 9. References
9.1. Normative References 9.1. Normative References
[I-D.ietf-mif-problem-statement] [I-D.ietf-mif-problem-statement]
Blanchet, M. and P. Seite, "Multiple Interfaces Problem Blanchet, M. and P. Seite, "Multiple Interfaces Problem
Statement", draft-ietf-mif-problem-statement-00 (work in Statement", draft-ietf-mif-problem-statement-04 (work in
progress), October 2009. progress), May 2010.
9.2. Informative References 9.2. Informative References
[ANDROID] Google Inc., "Android developers: package android.net", [ANDROID] Google Inc., "Android developers: package android.net",
2009, <http://developer.android.com/reference/android/net/ 2009, <http://developer.android.com/reference/android/net/
ConnectivityManager.html>. ConnectivityManager.html>.
[BLACKBERRY] [BLACKBERRY]
Research In Motion Limited, "BlackBerry Java Development Research In Motion Limited, "BlackBerry Java Development
Environment - Fundamentals Guide: Wireless gateways", Environment - Fundamentals Guide: Wireless gateways",
skipping to change at page 15, line 38 skipping to change at page 18, line 49
[I-D.zhang-mif-connection-manager-arena] [I-D.zhang-mif-connection-manager-arena]
Zhang, Y., Sun, T., and H. Chen, "Multi-interface Network Zhang, Y., Sun, T., and H. Chen, "Multi-interface Network
Connection Manager in Arena Platform", Connection Manager in Arena Platform",
draft-zhang-mif-connection-manager-arena-00 (work in draft-zhang-mif-connection-manager-arena-00 (work in
progress), February 2009. progress), February 2009.
[ISCDHCP] Internet Software Consortium, "ISC DHCP", 2009, [ISCDHCP] Internet Software Consortium, "ISC DHCP", 2009,
<http://www.isc.org/software/dhcp>. <http://www.isc.org/software/dhcp>.
[NRPT] Windows, "Name Resolution Policy Table", February 2010, <
http://technet.microsoft.com/en-us/magazine/
ff394369.aspx>.
[OPENBSDDHCLIENT] [OPENBSDDHCLIENT]
OpenBSD, "OpenBSD dhclient", 2009, OpenBSD, "OpenBSD dhclient", 2009,
<http://www.openbsd.org/>. <http://www.openbsd.org/>.
[PHYSTECHDHCPC] [PHYSTECHDHCPC]
Phystech, "dhcpcd", 2009, Phystech, "dhcpcd", 2009,
<http://www.phystech.com/download/dhcpcd.html>. <http://www.phystech.com/download/dhcpcd.html>.
[PUMP] RedHat, "PUMP", 2009, <http://redhat.com>. [PUMP] RedHat, "PUMP", 2009, <http://redhat.com>.
skipping to change at page 16, line 21 skipping to change at page 19, line 37
S60_Platform_IP_Bearer_Management_v1_0_en.pdf.html>. S60_Platform_IP_Bearer_Management_v1_0_en.pdf.html>.
[UDHCP] Busybox, "uDHCP", 2009, <http://sources.busybox.net/ [UDHCP] Busybox, "uDHCP", 2009, <http://sources.busybox.net/
index.py/trunk/busybox/networking/udhcp/>. index.py/trunk/busybox/networking/udhcp/>.
[WINDOWSMOBILE] [WINDOWSMOBILE]
Microsoft Corporation, "SDK Documentation for Windows Microsoft Corporation, "SDK Documentation for Windows
Mobile-Based Smartphones: Connection Manager", 2005, Mobile-Based Smartphones: Connection Manager", 2005,
<http://msdn.microsoft.com/en-us/library/aa457829.aspx>. <http://msdn.microsoft.com/en-us/library/aa457829.aspx>.
Author's Address Authors' Addresses
Margaret Wasserman (editor) Margaret Wasserman (editor)
Sandstorm Enterprises Painless Security, LLC
14 Summer Street 356 Abbott Street
Malden, MA 02148 North Andover, MA 01845
USA USA
Phone: +1 781 333 3200 Phone: +1 781 405-7464
Email: mrw@lilacglade.org Email: mrw@painless-security.com
URI: http://www.sandstorm.net URI: http://www.painless-security.com
Pierrick Seite (editor)
France Telecom - Orange
4, rue du clos courtel BP 91226
Cesson-Sevigne 35512
France
Email: pierrick.seite@orange-ftgroup.com
 End of changes. 40 change blocks. 
104 lines changed or deleted 268 lines changed or added

This html diff was produced by rfcdiff 1.38. The latest version is available from http://tools.ietf.org/tools/rfcdiff/