draft-ietf-mif-current-practices-07.txt   draft-ietf-mif-current-practices-08.txt 
Internet Engineering Task Force M. Wasserman Internet Engineering Task Force M. Wasserman
Internet-Draft Painless Security, LLC Internet-Draft Painless Security, LLC
Intended status: Informational P. Seite Intended status: Informational P. Seite
Expires: August 18, 2011 France Telecom - Orange Expires: September 1, 2011 France Telecom - Orange
February 14, 2011 February 28, 2011
Current Practices for Multiple Interface Hosts Current Practices for Multiple Interface Hosts
draft-ietf-mif-current-practices-07 draft-ietf-mif-current-practices-08
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 August 18, 2011. This Internet-Draft will expire on September 1, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 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 20 skipping to change at page 2, line 20
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 and Windows Phone 7 . . . . . 9 3.1.2. Microsoft Windows Mobile and Windows Phone 7 . . . . . 9
3.1.3. BlackBerry . . . . . . . . . . . . . . . . . . . . . . 10 3.1.3. RIM BlackBerry . . . . . . . . . . . . . . . . . . . . 10
3.1.4. Google Android . . . . . . . . . . . . . . . . . . . . 11 3.1.4. Google Android . . . . . . . . . . . . . . . . . . . . 11
3.1.5. Qualcomm Brew . . . . . . . . . . . . . . . . . . . . 12 3.1.5. Qualcomm Brew . . . . . . . . . . . . . . . . . . . . 12
3.1.6. Arena Connection Manager . . . . . . . . . . . . . . . 13 3.1.6. Leadcore Tech. Arena . . . . . . . . . . . . . . . . . 13
3.1.7. Current practices for network selection in handsets . 13 3.2. Desktop Operating Systems . . . . . . . . . . . . . . . . 13
3.2. Desktop Operating Systems . . . . . . . . . . . . . . . . 15 3.2.1. Microsoft Windows . . . . . . . . . . . . . . . . . . 14
3.2.1. Microsoft Windows . . . . . . . . . . . . . . . . . . 15 3.2.1.1. Routing . . . . . . . . . . . . . . . . . . . . . 14
3.2.1.1. Routing . . . . . . . . . . . . . . . . . . . . . 15 3.2.1.2. Outbound and Inbound Addresses . . . . . . . . . . 14
3.2.1.2. Outbound and Inbound Addresses . . . . . . . . . . 15 3.2.1.3. DNS Configuration . . . . . . . . . . . . . . . . 14
3.2.1.3. DNS Configuration . . . . . . . . . . . . . . . . 16 3.2.2. Linux and BSD-based Operating Systems . . . . . . . . 15
3.2.2. Linux and BSD-based Operating Systems . . . . . . . . 17 3.2.2.1. Routing . . . . . . . . . . . . . . . . . . . . . 16
3.2.2.1. Routing . . . . . . . . . . . . . . . . . . . . . 17 3.2.2.2. Outbound and Inbound Addresses . . . . . . . . . . 16
3.2.2.2. Outbound and Inbound Addresses . . . . . . . . . . 18 3.2.2.3. DNS Configuration . . . . . . . . . . . . . . . . 17
3.2.2.3. DNS Configuration . . . . . . . . . . . . . . . . 18 3.3. Focus on access network selection . . . . . . . . . . . . 18
4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
6. Security Considerations . . . . . . . . . . . . . . . . . . . 19 6. Security Considerations . . . . . . . . . . . . . . . . . . . 20
7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 20 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 20
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
8.1. Normative References . . . . . . . . . . . . . . . . . . . 21 8.1. Normative References . . . . . . . . . . . . . . . . . . . 21
8.2. Informative References . . . . . . . . . . . . . . . . . . 21 8.2. Informative References . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23
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 10, line 15 skipping to change at page 10, line 15
In dual-stack systems, Windows mobile and Windows phone 7 implement In dual-stack systems, Windows mobile and Windows phone 7 implement
adress selection rules as per [WNDS-RFC3484]. An administrator can adress selection rules as per [WNDS-RFC3484]. An administrator can
configure a policy table that can override the default behavior of configure a policy table that can override the default behavior of
the selection algorithms. It is reminded that the policy table the selection algorithms. It is reminded that the policy table
specifies precedence values and preferred source prefixes for specifies precedence values and preferred source prefixes for
destination prefixes (see [RFC3484], section 2.1, for details). If destination prefixes (see [RFC3484], section 2.1, for details). If
the system has not been configured, then the default policy table the system has not been configured, then the default policy table
specified in [RFC3484] is used. specified in [RFC3484] is used.
3.1.3. BlackBerry 3.1.3. RIM BlackBerry
Depending on the network configuration, applications in BlackBerry Depending on the network configuration, applications in reasearch In
devices [BLACKBERRY] can use can use direct TCP/IP connectivity or Motion (RIM) BlackBerry devices [BLACKBERRY] can use can use direct
different application proxys to establish connections over the TCP/IP connectivity or different application proxys to establish
wireless network. For instance, some wireless service providers connections over the wireless network. For instance, some wireless
provide an Internet gateway to offer direct TCP/IP connectivity to service providers provide an Internet gateway to offer direct TCP/IP
the Internet while some others can provide a WAP gateway that allows connectivity to the Internet while some others can provide a WAP
HTTP connections to occur over the WAP (Wireless Application gateway that allows HTTP connections to occur over the WAP (Wireless
Protocol) protocol. It is also possible to use the BlackBerry Application Protocol) protocol. It is also possible to use the
Enterprise Server [BLACKBERRY] as a network gateway, The BlackBerry BlackBerry Enterprise Server [BLACKBERRY] as a network gateway, The
Enterprise Server provides an HTTP and TCP/IP proxy service to allow BlackBerry Enterprise Server provides an HTTP and TCP/IP proxy
the application to use it as a secure gateway for managing HTTP and service to allow the application to use it as a secure gateway for
TCP/IP connections to the intranet or the Internet. An application managing HTTP and TCP/IP connections to the intranet or the Internet.
connecting to the Internet, can use either the BlackBerry Internet An application connecting to the Internet, can use either the
Service or the Internet gateway of the wireless server provider or BlackBerry Internet Service or the Internet gateway of the wireless
direct Internet connectivity over WLAN to manage connections. The server provider or direct Internet connectivity over WLAN to manage
problem of gateway selection is supposed to be managed independently connections. The problem of gateway selection is supposed to be
by each application. For instance, an application can be designed to managed independently by each application. For instance, an
always use the default Internet gateway, while another application application can be designed to always use the default Internet
can be designed to use a preferred proxy when available. gateway, while another application can be designed to use a preferred
proxy when available.
A BlackBerry device [BLACKBERRY] can be attached to multiple networks A BlackBerry device [BLACKBERRY] can be attached to multiple networks
simultaneously (wireless/wired). In this case, Multiple network simultaneously (wireless/wired). In this case, Multiple network
interfaces can be associated to a single IP stack or multiple IP interfaces can be associated to a single IP stack or multiple IP
stacks. The device, or the application, can select the network stacks. The device, or the application, can select the network
interface to be used in various ways. For instance, the device can interface to be used in various ways. For instance, the device can
always map the applications to the default network interface (or the always map the applications to the default network interface (or the
default access network). When muliple IP stacks are associated to default access network). When muliple IP stacks are associated to
multiple interfaces, the application can select the source address multiple interfaces, the application can select the source address
correponding to the preferred network interface. Per-interface IP correponding to the preferred network interface. Per-interface IP
skipping to change at page 11, line 35 skipping to change at page 11, line 35
configuration is node-scoped, even if DNS configuration can rely on configuration is node-scoped, even if DNS configuration can rely on
the DHCP client. For instance, the udhcp client [UDHCP], which is the DHCP client. For instance, the udhcp client [UDHCP], which is
also available for Linux, can be used on Android. Each time new also available for Linux, can be used on Android. Each time new
configuration data is received by the host from a DHCP server, configuration data is received by the host from a DHCP server,
regardless of which interface it is received on, the DHCP client regardless of which interface it is received on, the DHCP client
rewrites the global configuration data with the most recent rewrites the global configuration data with the most recent
information received. information received.
Actually, the main difference between Linux and Android is on the Actually, the main difference between Linux and Android is on the
address selection mechanism. Android version prior to 2.2 simply address selection mechanism. Android version prior to 2.2 simply
prefers IPv6 connectivity over IPv4. Android 2.2 has been updated prefers IPv6 connectivity over IPv4. However, it should be noted
with [ANDROID-RFC3484], which implements some of the address that, at the time of writing, IPv6 is available only on WiFi and
selection rules defined in [RFC3484]. All RFC3484 rules are virtual interfaces, but not on the cellular interface (without IPv6
supported, except rule 3 (avoid deprecated addresses), 4 (prefer home in IPv4 encapsulation). Android 2.2 has been updated with
addresses) and 7 (prefer native transport). Also, rule 9 (use [ANDROID-RFC3484], which implements some of the address selection
longest matching prefix) has been modified so it does not sort IPv4 rules defined in [RFC3484]. All RFC3484 rules are supported, except
addresses. 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.
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 WLAN). 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
skipping to change at page 13, line 34 skipping to change at page 13, line 36
which application making the DNS query is bound. Applications can which application making the DNS query is bound. Applications can
also specify a different netpolicy as part of DNS request to select also specify a different netpolicy as part of DNS request to select
another interface for DNS resolution. Regardless, all the DNS another interface for DNS resolution. Regardless, all the DNS
queries are sent only over this selected interface using the DNS queries are sent only over this selected interface using the DNS
configuration from the interface. DNS resolution is first attempted configuration from the interface. DNS resolution is first attempted
with the primary server configured in the interface. If a response with the primary server configured in the interface. If a response
is not received, the queries are sent to all the other servers is not received, the queries are sent to all the other servers
configured in the interface in a sequential manner using a backoff configured in the interface in a sequential manner using a backoff
mechanism. mechanism.
3.1.6. Arena Connection Manager 3.1.6. Leadcore Tech. Arena
Arena, a mobile OS based on Linux, provides a 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 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. 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 multiple-interfaces issues such as
connection sharing. connection sharing.
3.1.7. Current practices for network selection in handsets
This section describes behaviors of connection managers in presence
of multiple points of attachment for a same interface. In order to
illustrate different practices, a set of representative handsets
considered: LG Pathfinder, Android/HTC magic, RIM BlackBerry and
iPhone (3G and 3GS). 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.
When the terminal is under coverage of different WLAN 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. Excepted for the RIM
blackberry, 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 WLAN
attachment within both SSID1 and SSID2 coverage, the connection
manager will select SSID2 for attachment. The RIM Blackberry
behaves differently: the user is allowed to define its list of
preferred accesses. The connection manager selects the first SSID
of the preferred list of SSIDs configured in the device and that
is available based on the WLAN scan the device has performed.
All connection managers behave in the same way when the terminals
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 from few
seconds to about 3 minutes.
When the IP stack fails to obtain an IP address after successful
WLAN attachment, all the considered handsets, excepted the iPhone,
try to connect another SSID. LG Pathfinder and HTC just select
the next SSID in the list. The BlackBerry, performs a new WLAN
scan and, among the networks available, selects the next SSID in
the preferred 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 if the terminal remains under coverage of the same WLAN
access point. 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 WLAN 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 19, line 36 skipping to change at page 18, line 18
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. changing the functionality described above.
3.3. Focus on access network selection
This section describes behaviors of connection managers in presence
of multiple points of attachment for a same interface. In order to
illustrate different practices, a set of representative handsets
considered: LG Pathfinder, Android/HTC magic, RIM BlackBerry and
iPhone (3G and 3GS). 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.
When the terminal is under coverage of different WLAN 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. Excepted for the RIM
blackberry, 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 WLAN
attachment within both SSID1 and SSID2 coverage, the connection
manager will select SSID2 for attachment. The RIM Blackberry
behaves differently: the user is allowed to define its list of
preferred accesses. The connection manager selects the first SSID
of the preferred list of SSIDs configured in the device and that
is available based on the WLAN scan the device has performed.
All connection managers behave in the same way when the terminals
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 from few
seconds to about 3 minutes.
When the IP stack fails to obtain an IP address after successful
WLAN attachment, all the considered handsets, excepted the iPhone,
try to connect another SSID. LG Pathfinder and HTC just select
the next SSID in the list. The BlackBerry, performs a new WLAN
scan and, among the networks available, selects the next SSID in
the preferred 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 if the terminal remains under coverage of the same WLAN
access point. 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 WLAN 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).
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: Dan Wing, Hui Deng, Jari Arkko, Julien their input and feedback: Dan Wing, Hui Deng, Jari Arkko, Julien
Laganier and Steinar H. Gunderson. Laganier and Steinar H. Gunderson.
5. IANA Considerations 5. IANA Considerations
This memo includes no request to IANA. This memo includes no request to IANA.
 End of changes. 14 change blocks. 
119 lines changed or deleted 124 lines changed or added

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