draft-ietf-mif-current-practices-09.txt   draft-ietf-mif-current-practices-10.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: September 29, 2011 France Telecom - Orange Expires: October 26, 2011 France Telecom - Orange
March 28, 2011 April 24, 2011
Current Practices for Multiple Interface Hosts Current Practices for Multiple Interface Hosts
draft-ietf-mif-current-practices-09 draft-ietf-mif-current-practices-10
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. This document summarizes current practices in this
unequal levels of service or connectivity. This document summarizes area, and describes in detail how some common operating systems cope
current practices in this area, and describes in detail how some with challenges ensue from this context.
common operating systems cope with these challenges.
Status of this Memo Status of this Memo
This Internet-Draft is submitted 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). 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 September 29, 2011. This Internet-Draft will expire on October 26, 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 14 skipping to change at page 2, line 13
described in the Simplified BSD License. described in the Simplified BSD License.
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. First hop selection . . . . . . . . . . . . . . . . . 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. RIM 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. Leadcore Tech. Arena . . . . . . . . . . . . . . . . . 13 3.1.6. Leadcore Tech. Arena . . . . . . . . . . . . . . . . . 13
3.2. Desktop Operating Systems . . . . . . . . . . . . . . . . 13 3.2. Desktop Operating Systems . . . . . . . . . . . . . . . . 13
3.2.1. Microsoft Windows . . . . . . . . . . . . . . . . . . 14 3.2.1. Microsoft Windows . . . . . . . . . . . . . . . . . . 14
3.2.1.1. Routing . . . . . . . . . . . . . . . . . . . . . 14 3.2.1.1. First hop selection . . . . . . . . . . . . . . . 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 . . . . . . . . 15
3.2.2.1. Routing . . . . . . . . . . . . . . . . . . . . . 16 3.2.2.1. First hop selection . . . . . . . . . . . . . . . 16
3.2.2.2. Outbound and Inbound Addresses . . . . . . . . . . 16 3.2.2.2. Outbound and Inbound Addresses . . . . . . . . . . 16
3.2.2.3. DNS Configuration . . . . . . . . . . . . . . . . 17 3.2.2.3. DNS Configuration . . . . . . . . . . . . . . . . 17
3.3. Focus on access network selection . . . . . . . . . . . . 18 3.3. Focus on access network selection . . . . . . . . . . . . 18
4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 3.3.1. Android/HTC magic . . . . . . . . . . . . . . . . . . 18
3.3.2. RIM BlackBerry . . . . . . . . . . . . . . . . . . . . 19
4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
6. Security Considerations . . . . . . . . . . . . . . . . . . . 20 6. Security Considerations . . . . . . . . . . . . . . . . . . . 20
7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 20 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 21
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 . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 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.
skipping to change at page 5, line 24 skipping to change at page 5, line 24
interface is queried first, with back off to other servers if an interface is queried first, with back off to other servers if an
answer is not received. answer is not received.
Systems that support a single system-wide list differ in how they Systems that support a single system-wide list differ in how they
select which DNS server to use in cases where they receive more than select which DNS server to use in cases where they receive more than
one DNS server list to configure (e.g. from DHCP on multiple one DNS server list to configure (e.g. from DHCP on multiple
interfaces). Some accept the information received on the "primary" interfaces). Some accept the information received on the "primary"
interface, while others use either the first or last set DNS server interface, while others use either the first or last set DNS server
list configured. list configured.
2.3.2. Routing 2.3.2. First hop selection
Routing information is also handled differently on different desktop Routing information is also handled differently on different desktop
operating systems. While all systems maintain some sort of routing operating systems. While all systems maintain some sort of routing
cache, to handle redirects and/or statically configured routes, most cache, to handle redirects and/or statically configured routes, most
packets are routed based on configured default gateway information. packets are routed based on configured default gateway information.
Some systems do allow the configuration of different default router Some systems do allow the configuration of different default router
lists for different interfaces. These systems will always choose the lists for different interfaces. These systems will always choose the
default gateway on the interface with the lowest routing metric, with default gateway on the interface with the lowest routing metric, with
different behavior when two or more interfaces have the same routing different behavior when two or more interfaces have the same routing
skipping to change at page 9, line 42 skipping to change at page 9, line 42
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.
In comparison to Windows Mobile connection management, Windows phone In comparison to Windows Mobile connection management, Windows phone
7 updates the routing functionality in the case where the terminal 7 updates the routing functionality in the case where the terminal
can be attached simultaneously to several interfaces. Windows Phone can be attached simultaneously to several interfaces. Windows Phone
7 routes the traffic through a preferred interface, which has a lower 7 selects the first hop corresponding to the interface which has a
metric. When there are multiple interfaces, the applications system lower metric. When there are multiple interfaces, the applications
will, by default, choose from an ordered list of available system will, by default, choose from an ordered list of available
interfaces. The default connection policy will prefer wired over interfaces. The default connection policy will prefer wired over
wireless and WLAN over cellular. Hence, if an application wants to wireless and WLAN over cellular. Hence, if an application wants to
use cellular 3G as the active interface when WLAN is available, the use cellular 3G as the active interface when WLAN is available, the
application needs to override the default connection mapping policy. application needs to override the default connection mapping policy.
An application specific mapping policy can be set via a microsoft API An application specific mapping policy can be set via a microsoft API
or provisioned by the Mobile Operator. The application, in or provisioned by the Mobile Operator. The application, in
compliance with the security model, can request connection type by compliance with the security model, can request connection type by
interface (WLAN, cellular), by minimum interface speed (x kbps, y interface (WLAN, cellular), by minimum interface speed (x kbps, y
mbps), or by name (Access Point Name). mbps), or by name (Access Point Name).
skipping to change at page 11, line 47 skipping to change at page 11, line 47
virtual interfaces, but not on the cellular interface (without IPv6 virtual interfaces, but not on the cellular interface (without IPv6
in IPv4 encapsulation). Android 2.2 has been updated with in IPv4 encapsulation). Android 2.2 has been updated with
[ANDROID-RFC3484], which implements some of the address selection [ANDROID-RFC3484], which implements some of the address selection
rules defined in [RFC3484]. All RFC3484 rules are supported, except rules defined in [RFC3484]. All RFC3484 rules are supported, except
rule 3 (avoid deprecated addresses), 4 (prefer home addresses) and 7 rule 3 (avoid deprecated addresses), 4 (prefer home addresses) and 7
(prefer native transport). Also, rule 9 (use longest matching (prefer native transport). Also, rule 9 (use longest matching
prefix) has been modified so it does not sort IPv4 addresses. 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 the first hop to a specified destination address via a
network interface (3GPP or WLAN). Applications also ask Connection specified network interface (3GPP or WLAN). Applications also ask
Manager for permission to start using a network feature. The Connection Manager for permission to start using a network feature.
Connectivity Manager monitors changes in network connectivity and The 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.
3.1.5. Qualcomm Brew 3.1.5. 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
skipping to change at page 14, line 14 skipping to change at page 14, line 14
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
The multi-interface functionality currently implemented in Microsoft The multi-interface functionality currently implemented in Microsoft
Windows operation systems is described in more detail in Windows operation systems is described in more detail in
[I-D.montenegro-mif-multihoming]. [I-D.montenegro-mif-multihoming].
3.2.1.1. Routing 3.2.1.1. First hop selection
It is possible, although not often desirable, to configure default It is possible, although not often desirable, to configure default
routers on more than one Windows interface. In this configuration, routers on more than one Windows interface. In this configuration,
Windows will use the default route on the interface with the lowest Windows will use the default route on the interface with the lowest
routing metric (i.e. the fastest interface). If multiple interfaces routing metric (i.e. the fastest interface). If multiple interfaces
share the same metric, the behavior will differ based on the version share the same metric, the behavior will differ based on the version
of Windows in use. Prior to Windows Vista, the packet would be of Windows in use. Prior to Windows Vista, the packet would be
routed out of the first interface that was bound to the TCP/IP stack, routed out of the first interface that was bound to the TCP/IP stack,
the preferred interface. In Windows vista, host-to-router load the preferred interface. In Windows vista, host-to-router load
sharing [RFC4311] is used for both IPv4 and IPv6. sharing [RFC4311] is used for both IPv4 and IPv6.
skipping to change at page 16, line 4 skipping to change at page 16, line 4
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
seconds, it will send to all of the servers again and wait 8 seconds seconds, it will send to all of the servers again and wait 8 seconds
for a response. for a response.
3.2.2. Linux and BSD-based Operating Systems 3.2.2. Linux and BSD-based Operating Systems
3.2.2.1. Routing 3.2.2.1. First hop selection
In addition to the two commonly used routing tables (the local and In addition to the two commonly used routing tables (the local and
main routing tables), the kernel can support up to 252 additional main routing tables), the kernel can support up to 252 additional
routing tables which can be added in the file /etc/iproute2/ routing tables which can be added in the file /etc/iproute2/
rt_tables. A routing table can contain an arbitrary number of rt_tables. A routing table can contain an arbitrary number of
routes, the selection of route is classically made according to the routes, the selection of route is classically made according to the
destination address of the packet. Linux also provides more flexible destination address of the packet. Linux also provides more flexible
routing selection based on the Type of Service, scope, output routing selection based on the Type of Service, scope, output
interface. In addition, since kernel version 2.2, Linux supports interface. In addition, since kernel version 2.2, Linux supports
policy based routing using the multiple routing tables capability and policy based routing using the multiple routing tables capability and
skipping to change at page 18, line 21 skipping to change at page 18, line 21
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 3.3. Focus on access network selection
This section describes behaviors of connection managers in presence This section describes behaviors of connection managers in presence
of multiple points of attachment for a same interface. In order to of multiple points of attachment for a same interface. The section
illustrate different practices, a set of representative handsets focuses on WLAN access technology, it is described how does the
considered: LG Pathfinder, Android/HTC magic, RIM BlackBerry and connection manager deal with the list of preferred SSID and how does
iPhone (3G and 3GS). The section focuses on WLAN access technology, it select the access point for attachment. Desktops are not covered
it is described how does the connection manager deal with the list of since many different connection managers can be easily installed,
preferred SSID and how does it select the access point for thus making hard to report a common behaviour. This section only
attachment. Desktops are not covered since many different connection focuses on a specific use-case and some of the current
managers can be easily installed, thus making hard to report a common implementations; however further considerations on network discovery
behaviour. This section only focuses on a specific use-case and and selection can be found in [RFC5113]. [RFC5113] describes the
current implementations; however further considerations on network network discovery and selection and discusses limitations and
discovery and selection can be found in [RFC5113]. [RFC5113] constraints on potential solutions.
describes the network discovery and selection and discusses
limitations and constraints on potential solutions. 3.3.1. Android/HTC magic
When the terminal is under coverage of different WLAN 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 The connection manager selects the first SSID of the the list of
the list of preferred SSID giving priority to the last SSID on preferred access network. The connection manager constructs the
which they have managed to attach. Excepted for the RIM list of preferred SSID giving priority to the last SSID on which
blackberry, the user is not allowed to define its preferred it has managed to attach. The user is not allowed to define its
access. So, if the terminal discovers and manages to attach to preferred access. So, if the terminal discovers and manages to
SSID1, SSID1 becomes the preferred access for future attachment. attach to SSID1, SSID1 becomes the preferred access for future
If the terminal moves out of SSID1 coverage and attaches to a new attachment. If the terminal moves out of SSID1 coverage and
SSID, SSID2. SSID2 will then be the preferred access of the attaches to a new SSID, e.g. SSID2. SSID2 will then be the
connection manager. Then, if the terminal processes to WLAN preferred access of the connection manager. Then, if the terminal
attachment within both SSID1 and SSID2 coverage, the connection processes to WLAN attachment within both SSID1 and SSID2 coverage,
manager will select SSID2 for attachment. The RIM Blackberry the connection manager will select SSID2 for attachment.
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 When the layer 2 fails to attach to the selected SSID, the
fails to attach to the selected SSID: the connection manager connection manager automatically selects the next SSID in the list
automatically selects the next SSID in the list of preferred SSID. of preferred SSID. Fallback come into play at expiration of a
Fallback come into play at expiration of a timeout from few timeout which can be configured.
seconds to about 3 minutes.
When the IP stack fails to obtain an IP address after successful When the IP stack fails to obtain an IP address after successful
WLAN attachment, all the considered handsets, excepted the iPhone, WLAN attachment, the handset tries to connect to the next SSID in
try to connect another SSID. LG Pathfinder and HTC just select the list.
the next SSID in the list. The BlackBerry, performs a new WLAN
scan and, among the networks available, selects the next SSID in When the terminal receives signals from different point of attachment
the preferred list. 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 next point of attachment with
higher signal strength. If no more points of attachment, with
this SSID, is available, the connection manager selects the next
SSID in the list of preferred SSID.
If the terminal is unable to set up the IP connectivity on one
WLAN access, the connection manager will not try to attach to an
alternative point of attachment, or to an alternative SSID, as
long as the signal strength of the first radio link is the most
powerful. In other words, fallback on L3 attachment failure is
not supported if the terminal remains under coverage of the same
WLAN access point.
3.3.2. RIM BlackBerry
When the terminal is under coverage of different WLAN networks with
different SSIDs:
The device scans the WLAN frequency band. Then, if some SSIDs are
in the list of preferred SSID, the connection manager selects the
top of this list. The user can define its list of preferred
accesses. This list can be also enriched after successful
attachment to a new SSID. If so, the SSID is added at the end of
the list.
When the layer 2 fails to attach to the selected SSID, the
connection manager automatically selects the next SSID in the list
of preferred SSID. Fallback come into play at expiration of a
timeout which can be configured.
When the IP stack fails to obtain an IP address after successful
WLAN attachment, the BlackBerry tries to connect to the next SSID
in the list.
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. If no more points of attachment (corresponding
LG pathfinder. If no more points of attachment (corresponding to to the preferred SSID) are available, the connection manager
the preferred SSID) are available, the connection manager selects selects the next 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 The connection manager always selects the most powerful signal
supported if the terminal remains under coverage of the same WLAN strength without considering IP configuration results. If the
access point. Actually, the connection manager always selects the terminal is unable to set up the IP connectivity on one WLAN
most powerful signal strength without considering IP configuration access, the connection manager will not try to attach to an
results. In other words, if the terminal is unable to set up the alternative point of attachment, or alternative SSID, as long as
IP connectivity on one WLAN access, the connection manager will the signal strength of the current access point is the most
not try to attach to an alternative point of attachment (or SSID) powerful. If the user is moving and if the signal strength of an
as long as the signal strength of the first radio link is the most alternative point of attachment become better, the terminal
powerful. Situation is not the same for mobile terminal since the automatically restarts layer 2 and IP connectivity processes on
signal strength of the alternative point of attachment could that alternative access point.
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.
skipping to change at page 21, line 18 skipping to change at page 21, line 47
o Giyeong Son, RIM. o Giyeong Son, RIM.
8. References 8. References
8.1. Normative References 8.1. Normative References
[I-D.ietf-mif-problem-statement] [I-D.ietf-mif-problem-statement]
Blanchet, M. and P. Seite, "Multiple Interfaces and Blanchet, M. and P. Seite, "Multiple Interfaces and
Provisioning Domains Problem Statement", Provisioning Domains Problem Statement",
draft-ietf-mif-problem-statement-11 (work in progress), draft-ietf-mif-problem-statement-13 (work in progress),
March 2011. April 2011.
8.2. Informative References 8.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>.
[ANDROID-RFC3484] [ANDROID-RFC3484]
Gunderson, S., "RFC 3484 support for Android", 2010, <http Gunderson, S., "RFC 3484 support for Android", 2010, <http
://gitorious.org/0xdroid/bionic/commit/ ://gitorious.org/0xdroid/bionic/commit/
 End of changes. 22 change blocks. 
82 lines changed or deleted 111 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/