draft-ietf-mif-current-practices-06.txt   draft-ietf-mif-current-practices-07.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 5, 2011 France Telecom - Orange Expires: August 18, 2011 France Telecom - Orange
February 1, 2011 February 14, 2011
Current Practices for Multiple Interface Hosts Current Practices for Multiple Interface Hosts
draft-ietf-mif-current-practices-06 draft-ietf-mif-current-practices-07
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 5, 2011. This Internet-Draft will expire on August 18, 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 19 skipping to change at page 2, line 19
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 and 3.1.2. Microsoft Windows Mobile and Windows Phone 7 . . . . . 9
Windows Phone 7 . . . . . . . . . . . . . . . . . . . 8
3.1.3. BlackBerry . . . . . . . . . . . . . . . . . . . . . . 10 3.1.3. BlackBerry . . . . . . . . . . . . . . . . . . . . . . 10
3.1.4. Google Android . . . . . . . . . . . . . . . . . . . . 10 3.1.4. Google Android . . . . . . . . . . . . . . . . . . . . 11
3.1.5. Qualcomm Brew . . . . . . . . . . . . . . . . . . . . 11 3.1.5. Qualcomm Brew . . . . . . . . . . . . . . . . . . . . 12
3.1.6. Arena Connection Manager . . . . . . . . . . . . . . . 13 3.1.6. Arena Connection Manager . . . . . . . . . . . . . . . 13
3.1.7. Current practices for network selection in handsets . 13 3.1.7. Current practices for network selection in handsets . 13
3.2. Desktop Operating Systems . . . . . . . . . . . . . . . . 14 3.2. Desktop Operating Systems . . . . . . . . . . . . . . . . 15
3.2.1. Microsoft Windows . . . . . . . . . . . . . . . . . . 15 3.2.1. Microsoft Windows . . . . . . . . . . . . . . . . . . 15
3.2.1.1. Routing . . . . . . . . . . . . . . . . . . . . . 15 3.2.1.1. Routing . . . . . . . . . . . . . . . . . . . . . 15
3.2.1.2. Outbound and Inbound Addresses . . . . . . . . . . 15 3.2.1.2. Outbound and Inbound Addresses . . . . . . . . . . 15
3.2.1.3. DNS Configuration . . . . . . . . . . . . . . . . 15 3.2.1.3. DNS Configuration . . . . . . . . . . . . . . . . 16
3.2.2. Linux and BSD-based Operating Systems . . . . . . . . 16 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 . . . . . . . . . . 17 3.2.2.2. Outbound and Inbound Addresses . . . . . . . . . . 18
3.2.2.3. DNS Configuration . . . . . . . . . . . . . . . . 17 3.2.2.3. DNS Configuration . . . . . . . . . . . . . . . . 18
4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
6. Security Considerations . . . . . . . . . . . . . . . . . . . 19 6. Security Considerations . . . . . . . . . . . . . . . . . . . 19
7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 19 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 20
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
8.1. Normative References . . . . . . . . . . . . . . . . . . . 20 8.1. Normative References . . . . . . . . . . . . . . . . . . . 21
8.2. Informative References . . . . . . . . . . . . . . . . . . 20 8.2. Informative References . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22
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 7, line 10 skipping to change at page 7, line 10
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 is a software platform for mobile devices running on the Symbian
contains all information required for opening a network connection OS. S60 uses the concept of an Internet Access Point (IAP) [S60]
using a specific access technology. A device may have several IAPs that contains all information required for opening a network
configured for different network technologies and settings (multiple connection using a specific access technology. A device may have
WLAN SSIDs, GPRS APNs, dial-up numbers, and so forth). There may several IAPs configured for different network technologies and
also be 'virtual' IAPs that define parameters needed for tunnel settings (multiple WLAN SSIDs, GPRS APNs, dial-up numbers, and so
establishment (e.g. for VPN). forth). There may also be 'virtual' IAPs that define parameters
needed for tunnel establishment (e.g. for VPN).
For each application, a correct IAP needs to be selected at the point For each application, a correct IAP needs to be selected at the point
when the application requires network connectivity. This is when the application requires network connectivity. This is
essential, as the wrong IAP may not be able to support the essential, as the wrong IAP may not be able to support the
application or reach the desired destination. For example, MMS application or reach the desired destination. For example, MMS
application must use the correct IAP in order to reach the MMS application must use the correct IAP in order to reach the MMS
Gateway, which typically is not accessible from the public Internet. Gateway, which typically is not accessible from the public Internet.
As another example, an application might need to use the IAP As another example, an application might need to use the IAP
associated with its corporate VPN in order to reach internal associated with its corporate VPN in order to reach internal
corporate servers. Binding applications to IAPs avoids several corporate servers. Binding applications to IAPs avoids several
skipping to change at page 8, line 33 skipping to change at page 8, line 35
must move to the cellular network). must move to the cellular network).
In S60 3.2 does not support RFC 3484 for source address selection In S60 3.2 does not support RFC 3484 for source address selection
mechanisms. Applications are tightly bound the network interface mechanisms. Applications are tightly bound the network interface
selected for them or by them. E.g. an application may be connected selected for them or by them. E.g. an application may be connected
to IPv6 3G connection, IPv4 3G connection, WLAN connection, or VPN to IPv6 3G connection, IPv4 3G connection, WLAN connection, or VPN
connection. The application can change between the connections, but connection. The application can change between the connections, but
uses only one at a time. If the interface happens to be dual-stack, uses only one at a time. If the interface happens to be dual-stack,
then IPv4 is preferred over IPv6. then IPv4 is preferred over IPv6.
DNS configuration is per-interface; an application bounded to an DNS configuration is per-interface; an application bound to an
interface will always use the DNS settings for that interface. Hence interface will always use the DNS settings for that interface. Hence
the device itself remembers these pieces of information for each the device itself remembers these pieces of information for each
interface separately. interface separately.
The S60 3.2 manages with totally overlapping addresses spaces. Each The S60 3.2 manages with totally overlapping addresses spaces. Each
interface can even have same IPv4 address configured on it without interface can even have same IPv4 address configured on it without
issues. This is so because interfaces are kept totally separate from issues. This is so because interfaces are kept totally separate from
each other. This also implies that the interface selection has to be each other. This also implies that the interface selection has to be
done at application layer, as from network layer point of view device done at application layer, as from network layer point of view device
is not multihomed in the IP-sense. is not multihomed in the IP-sense.
Please see the source documentation for more details and screenshots: Please see the source documentation for more details and screenshots:
[S60]. [S60].
3.1.2. Microsoft Windows Mobile 2003 Second Edition and Windows Phone 7 3.1.2. Microsoft Windows Mobile and Windows Phone 7
A Connection Manager architecture is described in [WINDOWSMOBILE]. Microsoft Windows Mobile leverages on a Connection Manager
This architecture centralizes and automates network connection [WINDOWSMOBILE] to handle multiple network connections. This
architecture centralizes and automates network connection
establishment and management, and makes it possible to automatically establishment and management, and makes it possible to automatically
select a connection, to dial-in automatically or by user initiation, select a connection, to dial-in automatically or by user initiation,
and to optimize connection and shared resource usage. Connection and to optimize connection and shared resource usage. Connection
Manager periodically re-evaluates the validity of the connection Manager periodically re-evaluates the validity of the connection
selection. The Connection Manager uses various attributes such as selection. The Connection Manager uses various attributes such as
cost, security, bandwidth, error rate, and latency in its decision cost, security, bandwidth, error rate, and latency in its decision
making. making.
The Connection Manager selects the best possible connection for the The Connection Manager selects the best possible connection for the
application based on the destination network the application wishes application based on the destination network the application wishes
skipping to change at page 9, line 33 skipping to change at page 9, line 39
During operation, Connection Manager opens new connections as needed, During operation, Connection Manager opens new connections as needed,
and also disconnects unused or idle connections. and also disconnects unused or idle connections.
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 2003 SE, Windows phone 7 brings In comparison to Windows Mobile connection management, Windows phone
update of 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. Actually, can be attached simultaneously to several interfaces. Windows Phone
Windows Phone 7 routes the traffic through a preferred interface, 7 routes the traffic through a preferred interface, which has a lower
which has a lower metric. When there are multiple interfaces, the metric. When there are multiple interfaces, the applications system
applications system will, by default, choose from an ordered list of will, by default, choose from an ordered list of available
available interfaces. The default connection policy will prefer interfaces. The default connection policy will prefer wired over
wired over wireless and WLAN over cellular. Hence, if an application wireless and WLAN over cellular. Hence, if an application wants to
wants to use cellular 3G as the active interface when WLAN is use cellular 3G as the active interface when WLAN is available, the
available, the application needs to override the default connection application needs to override the default connection mapping policy.
mapping policy. An application specific mapping policy can be set An application specific mapping policy can be set via a microsoft API
via 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).
In dual-stack systems, Windows mobile and Windows phone 7 implement
adress selection rules as per [WNDS-RFC3484]. An administrator can
configure a policy table that can override the default behavior of
the selection algorithms. It is reminded that the policy table
specifies precedence values and preferred source prefixes for
destination prefixes (see [RFC3484], section 2.1, for details). If
the system has not been configured, then the default policy table
specified in [RFC3484] is used.
3.1.3. BlackBerry 3.1.3. BlackBerry
Depending on the network configuration, Java applications in Depending on the network configuration, applications in BlackBerry
BlackBerry devices [BLACKBERRY] can use can use direct TCP/IP devices [BLACKBERRY] can use can use direct TCP/IP connectivity or
connectivity or different application proxys to establish connections different application proxys to establish connections over the
over the wireless network. For instance, some wireless service wireless network. For instance, some wireless service providers
providers provide an Internet gateway to offer direct TCP/IP provide an Internet gateway to offer direct TCP/IP connectivity to
connectivity to the Internet while some others can provide a WAP the Internet while some others can provide a WAP gateway that allows
gateway that allows HTTP connections to occur over the WAP (Wireless HTTP connections to occur over the WAP (Wireless Application
Application Protocol) protocol. It is also possible to use the Protocol) protocol. It is also possible to use the BlackBerry
BlackBerry Enterprise Server [BLACKBERRY] as a network gateway, The Enterprise Server [BLACKBERRY] as a network gateway, The BlackBerry
BlackBerry Enterprise Server provides an HTTP and TCP/IP proxy Enterprise Server provides an HTTP and TCP/IP proxy service to allow
service to allow the application to use it as a secure gateway for the application to use it as a secure gateway for managing HTTP and
managing HTTP and TCP/IP connections to the intranet or the Internet. TCP/IP connections to the intranet or the Internet. An application
An application connecting to the Internet, can use either the connecting to the Internet, can use either the BlackBerry Internet
BlackBerry Internet Service or the Internet gateway of the wireless Service or the Internet gateway of the wireless server provider or
server provider to manage connections. The problem of gateway direct Internet connectivity over WLAN to manage connections. The
selection is supposed to be managed independently by each Java problem of gateway selection is supposed to be managed independently
application. For instance, an application can be designed to always by each application. For instance, an application can be designed to
use the default Internet gateway, while another application can be always use the default Internet gateway, while another application
designed to use a preferred proxy when available. 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. When multiple correponding to the preferred network interface. Per-interface IP
network interfaces are aggregated into a single IP stack, the device stacks also allow to manage overlapping addresses spaces. When
associates each application to the more appropriate network multiple network interfaces are aggregated into a single IP stack,
interface. The selection can be based on cost, type-of-service the device associates each application to the more appropriate
and/or user preference. network interface. The selection can be based on cost, type-of-
service and/or user preference.
The BlackBerry uses per-interface DNS configuration; applications
bound to a specific interface will use the DNS settings for that
interface.
3.1.4. Google Android 3.1.4. Google Android
Android is based on a Linux kernel and, in many situations, behaves Android is based on a Linux kernel and, in many situations, behaves
like a Linux device as described in Section 3.2.2. As per Linux, like a Linux device as described in Section 3.2.2. As per Linux,
Android can manage multiple routing tables and rely on policy based Android can manage multiple routing tables and rely on policy based
routing associated with packet filtering capabilities (see routing associated with packet filtering capabilities (see
Section 3.2.2.1 for details). Such a framework can be used to solve Section 3.2.2.1 for details). Such a framework can be used to solve
complex routing issue brought by multiple interfaces terminals, e.g. complex routing issue brought by multiple interfaces terminals, e.g.
address space overlapping. address space overlapping.
skipping to change at page 13, line 32 skipping to change at page 13, line 48
[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 multi-interface issues such as
connection sharing. connection sharing.
3.1.7. Current practices for network selection in handsets 3.1.7. Current practices for network selection in handsets
This section describes the behavior of connection managers in This section describes behaviors of connection managers in presence
presence of multiple points of attachment for a same interface. The of multiple points of attachment for a same interface. In order to
section focuses on WLAN interface, it is described how does the illustrate different practices, a set of representative handsets
connection manager deal with the list of preferred SSID and how does considered: LG Pathfinder, Android/HTC magic, RIM BlackBerry and
it select the SSID for attachment. Current implementation of iPhone (3G and 3GS). The section focuses on WLAN access technology,
connection managers are considered for the following handsets: LG it is described how does the connection manager deal with the list of
Pathfinder, Android/HTC magic, RIM BlackBerry , iPhone (3G and 3GS). preferred SSID and how does it select the access point for
attachment.
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 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. Excepted for the RIM
define its preferred access. So, if the terminal discovers and blackberry, the user is not allowed to define its preferred
manages to attach to SSID1, SSID1 becomes the preferred access for access. So, if the terminal discovers and manages to attach to
future attachment. If the terminal moves out of SSID1 coverage SSID1, SSID1 becomes the preferred access for future attachment.
and attaches to a new SSID, SSID2. SSID2 will then be the If the terminal moves out of SSID1 coverage and attaches to a new
preferred access of the connection manager. Then, if the terminal SSID, SSID2. SSID2 will then be the preferred access of the
processes to WLAN attachment within both SSID1 and SSID2 coverage, connection manager. Then, if the terminal processes to WLAN
the connection manager will select SSID2 for attachment. The RIM attachment within both SSID1 and SSID2 coverage, the connection
Blackberry behaves differently, the connection manager selects the manager will select SSID2 for attachment. The RIM Blackberry
first SSID on which it has managed to attach in the past. 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 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 next SSID in the list of preferred SSID.
SSID. Fallback come into play at expiration of a timeout from few 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 after successful
excepted the iPhone, restarts WLAN attachment selecting the second WLAN attachment, all the considered handsets, excepted the iPhone,
SSID in the list. 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 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
skipping to change at page 22, line 11 skipping to change at page 22, line 38
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>.
[WNDS-RFC3484]
Microsoft Corporation, "SDK Documentation for Windows
Mobile-Based Smartphones: Default Address Selection for
IPv6", 2005,
<http://msdn.microsoft.com/en-us/library/aa925716.aspx>.
Authors' Addresses Authors' Addresses
Margaret Wasserman Margaret Wasserman
Painless Security, LLC Painless Security, LLC
356 Abbott Street 356 Abbott Street
North Andover, MA 01845 North Andover, MA 01845
USA USA
Phone: +1 781 405-7464 Phone: +1 781 405-7464
Email: mrw@painless-security.com Email: mrw@painless-security.com
 End of changes. 22 change blocks. 
88 lines changed or deleted 116 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/