draft-ietf-mif-current-practices-03.txt   draft-ietf-mif-current-practices-04.txt 
Internet Engineering Task Force M. Wasserman, Ed. Internet Engineering Task Force M. Wasserman, Ed.
Internet-Draft Painless Security, LLC Internet-Draft Painless Security, LLC
Intended status: Informational P. Seite, Ed. Intended status: Informational P. Seite, Ed.
Expires: February 12, 2011 France Telecom - Orange Expires: April 24, 2011 France Telecom - Orange
August 11, 2010 October 21, 2010
Current Practices for Multiple Interface Hosts Current Practices for Multiple Interface Hosts
draft-ietf-mif-current-practices-03 draft-ietf-mif-current-practices-04
Abstract Abstract
An increasing number of hosts are operating in multiple-interface An increasing number of hosts are operating in multiple-interface
environments, where different network interfaces are providing environments, where different network interfaces are providing
unequal levels of service or connectivity. This document summarizes unequal levels of service or connectivity. This document summarizes
current practices in this area, and describes in detail how some current practices in this area, and describes in detail how some
common operating systems cope with these challenges. common operating systems cope with these challenges.
Status of this Memo Status of this Memo
skipping to change at page 1, line 35 skipping to change at page 1, line 35
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. 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."
This Internet-Draft will expire on February 12, 2011. This Internet-Draft will expire on April 24, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 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 Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 26 skipping to change at page 2, line 26
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. Window Phone 7 . . . . . . . . . . . . . . . . . . . . 9 3.1.3. Window Phone 7 . . . . . . . . . . . . . . . . . . . . 9
3.1.4. BlackBerry . . . . . . . . . . . . . . . . . . . . . . 9 3.1.4. BlackBerry . . . . . . . . . . . . . . . . . . . . . . 9
3.1.5. Google Android . . . . . . . . . . . . . . . . . . . . 10 3.1.5. Google Android . . . . . . . . . . . . . . . . . . . . 10
3.1.6. Qualcomm Brew . . . . . . . . . . . . . . . . . . . . 10 3.1.6. Qualcomm Brew . . . . . . . . . . . . . . . . . . . . 10
3.1.7. Arena Connection Manager . . . . . . . . . . . . . . . 12 3.1.7. Arena Connection Manager . . . . . . . . . . . . . . . 12
3.1.8. Access selection . . . . . . . . . . . . . . . . . . . 12 3.1.8. Access selection . . . . . . . . . . . . . . . . . . . 12
3.2. Desktop Operating Systems . . . . . . . . . . . . . . . . 13 3.2. Desktop Operating Systems . . . . . . . . . . . . . . . . 14
3.2.1. Microsoft Windows . . . . . . . . . . . . . . . . . . 13 3.2.1. Microsoft Windows . . . . . . . . . . . . . . . . . . 14
3.2.1.1. Routing . . . . . . . . . . . . . . . . . . . . . 13 3.2.1.1. Routing . . . . . . . . . . . . . . . . . . . . . 14
3.2.1.2. Outbound and Inbound Addresses . . . . . . . . . . 14 3.2.1.2. Outbound and Inbound Addresses . . . . . . . . . . 14
3.2.1.3. DNS Configuration . . . . . . . . . . . . . . . . 14 3.2.1.3. DNS Configuration . . . . . . . . . . . . . . . . 14
3.2.2. Linux and BSD-based Operating Systems . . . . . . . . 15 3.2.2. Linux and BSD-based Operating Systems . . . . . . . . 16
3.2.3. Apple Mac OS X . . . . . . . . . . . . . . . . . . . . 16 3.2.3. Apple Mac OS X . . . . . . . . . . . . . . . . . . . . 17
4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17
7. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 17 7. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 18
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 18 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 18
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
9.1. Normative References . . . . . . . . . . . . . . . . . . . 18 9.1. Normative References . . . . . . . . . . . . . . . . . . . 19
9.2. Informative References . . . . . . . . . . . . . . . . . . 19 9.2. Informative References . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
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.
skipping to change at page 9, line 17 skipping to change at page 9, line 17
To optimize resource use, such as battery power and bandwidth, To optimize resource use, such as battery power and bandwidth,
Connection Manager enables applications to synchronize network Connection Manager enables applications to synchronize network
connection usage by allowing applications to register their connection usage by allowing applications to register their
requirements for periodic connectivity. An application is notified requirements for periodic connectivity. An application is notified
when a suitable connection becomes available for its use. when a suitable connection becomes available for its use.
3.1.3. Window Phone 7 3.1.3. Window Phone 7
In comparison to Windows Mobile 2003 SE, Windows phone 7 brings In comparison to Windows Mobile 2003 SE, Windows phone 7 brings
update of the routing functionnality which is worth to be mentioned update of the routing functionality in the case where the terminal
in a MIF context. Actually, Windows Phone 7 routes the traffic can be attached simultaneously to several interfaces. Actually,
through a preferred interface, which has a lower metric. When there Windows Phone 7 routes the traffic through a preferred interface,
are multiple interfaces, the applications system will, by default, which has a lower metric. When there are multiple interfaces, the
choose from an ordered list of available interfaces. The default applications system will, by default, choose from an ordered list of
connection policy will prefer wired over wireless and WiFi over available interfaces. The default connection policy will prefer
cellular. Hence, if an application wants to use cellular 3G as the wired over wireless and WLAN over cellular. Hence, if an application
active interface when WiFi is available, the application needs to wants to use cellular 3G as the active interface when WLAN is
override the default connection mapping policy. An application available, the application needs to override the default connection
specific mapping policy can be set via API or provisioned by the mapping policy. An application specific mapping policy can be set
Mobile Operator. The application, in compliance with the security via API or provisioned by the Mobile Operator. The application, in
model, can request connection type by interface (WiFi, cellular), by compliance with the security model, can request connection type by
minimum interface speed (x kbps, y mbps), or by name (Access Point interface (WLAN, cellular), by minimum interface speed (x kbps, y
Name). mbps), or by name (Access Point Name).
3.1.4. BlackBerry 3.1.4. BlackBerry
In BlackBerry devices [BLACKBERRY] Java applications can use one of Depending on the network configuration, Java applications in
two wireless gateways to proxy the connection to the Internet or to a BlackBerry devices [BLACKBERRY] can use can use direct TCP/IP
corporate network. The application can be designed to always use the connectivity or different application proxys to establish connections
default Internet gateway, or to use a more preferred enterprise over the wireless network. For instance, some wireless service
gateway when available. The intent is to hide connectivity issues providers provide an Internet gateway to offer direct TCP/IP
from users. 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 [BLACKBERRY] 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 to manage connections. The problem of gateway
selection is supposed to be managed independently by each Java
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.
A BlackBerry device [BLACKBERRY] can access different destinations A BlackBerry device [BLACKBERRY] can be attached to multiple networks
using multiple access (wireless/wired) networks simultaneously. A simultaneously (wireless/wired). In this case, Multiple network
device can also access the same destination using multiple access interfaces can be associated to a single IP stack or multiple IP
networks simultaneously. The device can select the network interface stacks. The device, or the application, can select the network
to be used in various ways. For instance, it can use the default interface to be used in various ways. For instance, the device can
network interface (or the default access network) or choose from always map the applications to the default network interface (or the
available active network interfaces based on cost, type-of-service default access network). When muliple IP stacks are associated to
and/or use preference. Multiple network interfaces can be associated multiple interfaces, the application can select the source address
with a single IP stack or multiple IP stacks. correponding to the preferred network interface. 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.
3.1.5. Google Android 3.1.5. 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 (3GPP or Wifi). Applications also ask Connection network interface (3GPP or WLAN). 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.
Applications are bound to use one network type at a time. For Depending on vendors implementation, applications may be bound to use
example, on a 3G/Wifi HTC Dream (Android 1.5), web browsing uses only one network type at a time. For example, on a 3G/WLAN HTC Dream
the Wifi access when both 3G and WiFi are available. However (Android 1.5), web browsing uses only the WLAN access when both 3G
different applications can use different access at the same time. and WLAN are available. However different applications can use
For instance, the HTC Dream can utilize WLAN access for web browsing different access at the same time. For instance, the HTC Dream can
and GPRS access for transferring multimedia messages (MMS). utilize WLAN access for web browsing and GPRS access for transferring
multimedia messages (MMS).
3.1.6. Qualcomm Brew 3.1.6. Qualcomm Brew
This section describes how multi-interface support is handled by This section describes how multi-interface support is handled by
Advanced Mobile Station Software (AMSS) that comes with Brew OS for Advanced Mobile Station Software (AMSS) that comes with Brew OS for
all Qualcomm chipsets (e.g., MSM, Snapdragon etc). AMSS is a low all Qualcomm chipsets (e.g., MSM, Snapdragon etc). AMSS is a low
level connectivity platform, on top of which manufacturers can build level connectivity platform, on top of which manufacturers can build
to provide the necessary connectivity to applications. The to provide the necessary connectivity to applications. The
interaction model between AMSS, the Operating System, and the interaction model between AMSS, the Operating System, and the
applications is not unique and depend on the design chosen by the applications is not unique and depend on the design chosen by the
manufacturer. The Mobile OS can let an application invoke the AMSS manufacturer. The Mobile OS can let an application invoke the AMSS
directly (via API), or provide its own connection manager that will directly (via API), or provide its own connection manager that will
request connectivity to the AMSS based on applications needs. The request connectivity to the AMSS based on applications needs. The
interaction between the OS connection manager and the applications is interaction between the OS connection manager and the applications is
OS dependent. OS dependent.
AMSS supports a concept of netpolicy which allows each application to AMSS supports a concept of netpolicy which allows each application to
specify the type of network connectivity desired. The netpolicy specify the type of network connectivity desired. The netpolicy
contains parameters such as access technology, IP version type and contains parameters such as access technology, IP version type and
network profile. Access technology could be a specific technology network profile. Access technology could be a specific technology
type such as CDMA or WiFi or could be a group of technologies, such 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, as ANY_Cellular or ANY_Wireless. IP version could be one of IPv4,
IPv6 or Default. The network profile identifies a type of network IPv6 or Default. The network profile identifies a type of network
domain or service within a certain network technology, such as 3GPP domain or service within a certain network technology, such as 3GPP
APN or Mobile IP Home Agent. It also specifies all the mandatory APN or Mobile IP Home Agent. It also specifies all the mandatory
parameters required to connect to the domain such authentication parameters required to connect to the domain such authentication
credentials and other optional parameters such as QoS attributes. credentials and other optional parameters such as QoS attributes.
Network Profile is technology specific and set of parameters Network Profile is technology specific and set of parameters
contained in the profile could vary for different technologies. contained in the profile could vary for different technologies.
Two models of network usage are supported: Two models of network usage are supported:
skipping to change at page 12, line 21 skipping to change at page 12, line 36
connectivity requirement. The Connection Manager can then choose an connectivity requirement. The Connection Manager can then choose an
interface that matches the application's needs while considering interface that matches the application's needs while considering
other factors such as availability, cost and stability. Also, the other factors such as availability, cost and stability. Also, the
Connection Manager can handle multi-interface issues such as Connection Manager can handle multi-interface issues such as
connection sharing. connection sharing.
3.1.8. Access selection 3.1.8. Access selection
This section describes the behavior of connection managers in This section describes the behavior of connection managers in
presence of multiple points of attachment for a same interface. The presence of multiple points of attachment for a same interface. The
section focuses on Wifi interface, it is described how does the section focuses on WLAN interface, it is described how does the
connection manager deal with the list of preferred SSID and how does connection manager deal with the list of preferred SSID and how does
it select the SSID for attachment. Current implementation of it select the SSID for attachment. Current implementation of
connection managers are considered for the following handsets: LG connection managers are considered for the following handsets: LG
Pathfinder, HTC Android, RIM BlackBerry , iPhone (3G and 3GS). Pathfinder, HTC Android, RIM BlackBerry , iPhone (3G and 3GS).
When the terminal is under coverage of different WiFi networks with When the terminal is under coverage of different WLAN networks with
different SSIDs: different SSIDs:
connection managers, excepted for the RIM Blackberry, construct connection managers, excepted for the RIM Blackberry, construct
the list of preferred SSID giving priority to the last SSID on the list of preferred SSID giving priority to the last SSID on
which they have managed to attach. The user is not allowed to which they have managed to attach. The user is not allowed to
define its preferred access. So, if the terminal discovers and define its preferred access. So, if the terminal discovers and
manages to attach to SSID1, SSID1 becomes the preferred access for manages to attach to SSID1, SSID1 becomes the preferred access for
future attachment. If the terminal moves out of SSID1 coverage future attachment. If the terminal moves out of SSID1 coverage
and attaches to a new SSID, SSID2. SSID2 will then be the and attaches to a new SSID, SSID2. SSID2 will then be the
preferred access of the connection manager. Then, if the terminal preferred access of the connection manager. Then, if the terminal
processes to Wifi attachment within both SSID1 and SSID2 coverage, processes to WLAN attachment within both SSID1 and SSID2 coverage,
the connection manager will select SSID2 for attachment. The RIM the connection manager will select SSID2 for attachment. The RIM
Blackberry behaves differently, the connection manager selects the Blackberry behaves differently, the connection manager selects the
first SSID on which it has managed to attach in the past. first SSID on which it has managed to attach in the past.
All connection managers behave in the same way when the terminals All connection managers behave in the same way when the terminals
fails to attach to the selected SSID: the connection manager fails to attach to the selected SSID: the connection manager
automatically selects the second SSID in the list of preferred automatically selects the second SSID in the list of preferred
SSID. Fallback come into play at expiration of a timeout from few SSID. Fallback come into play at expiration of a timeout from few
seconds to about 3 minutes. seconds to about 3 minutes.
When the IP stack fails to obtain an IP address, the handset, When the IP stack fails to obtain an IP address, the handset,
excepted the Iphone, restarts Wifi attachment selecting the second excepted the iPhone, restarts WLAN attachment selecting the second
SSID in the list. SSID in the list.
When the terminal receives signals from different point of attachment When the terminal receives signals from different point of attachment
with same SSID: with same SSID:
The connection manager selects the point of attachment with best The connection manager selects the point of attachment with best
signal strength; no other criteria (e.g. MAC address) is taken signal strength; no other criteria (e.g. MAC address) is taken
into account. If the handset fails to attach to the selected into account. If the handset fails to attach to the selected
point of attachment (e.g. due to L2 authentication failure), the point of attachment (e.g. due to L2 authentication failure), the
connection manager selects the point of attachment with lower connection manager selects the point of attachment with lower
signal strength. However, this fallback is not supported on the signal strength. However, this fallback is not supported on the
LG pathfinder. If no more points of attachment (corresponding to LG pathfinder. If no more points of attachment (corresponding to
the preferred SSID) are available, the connection manager selects the preferred SSID) are available, the connection manager selects
the second SSID in the list of preferred SSID. the second SSID in the list of preferred SSID.
Whatever is the handset, fallback on L3 attachment failure is not Whatever is the handset, fallback on L3 attachment failure is not
supported for motionless terminals. Actually, the connection supported if the terminal remains under coverage of the same WLAN
manager always selects the most powerful signal strength without access point. Actually, the connection manager always selects the
considering IP configuration results. In other words, if the most powerful signal strength without considering IP configuration
terminal is unable to set up the IP connectivity on one wifi results. In other words, if the terminal is unable to set up the
access, the connection manager will not try to attach to an IP connectivity on one WLAN access, the connection manager will
alternative point of attachment (or SSID) as long as the signal not try to attach to an alternative point of attachment (or SSID)
strength of the first radio link is the most powerful. Situation as long as the signal strength of the first radio link is the most
is not the same for mobile terminal since the signal strength of powerful. Situation is not the same for mobile terminal since the
the alternative point of attachment could become better while the signal strength of the alternative point of attachment could
terminal is moving. If so, the terminal automatically restarts IP become better while the terminal is moving. If so, the terminal
connectivity process (excepted the HTC Magic which requires the automatically restarts IP connectivity process (excepted the HTC
user to manually restart the L3 attachment). 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 18, line 46 skipping to change at page 19, line 18
o Aurelien Collet, Altran. o Aurelien Collet, Altran.
o Giyeong Son, RIM. o Giyeong Son, RIM.
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-05 (work in Statement", draft-ietf-mif-problem-statement-07 (work in
progress), July 2010. progress), August 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",
 End of changes. 19 change blocks. 
67 lines changed or deleted 86 lines changed or added

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