draft-ietf-mif-current-practices-10.txt   draft-ietf-mif-current-practices-11.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: October 26, 2011 France Telecom - Orange Expires: October 29, 2011 France Telecom - Orange
April 24, 2011 April 27, 2011
Current Practices for Multiple Interface Hosts Current Practices for Multiple Interface Hosts
draft-ietf-mif-current-practices-10 draft-ietf-mif-current-practices-11
Abstract Abstract
An increasing number of hosts are operating in multiple-interface An increasing number of hosts are operating in multiple-interface
environments. This document summarizes current practices in this environments. This document summarizes current practices in this
area, and describes in detail how some common operating systems cope area, and describes in detail how some common operating systems cope
with challenges ensue from this context. with challenges ensue from this context.
Status of this Memo Status of this Memo
skipping to change at page 1, line 34 skipping to change at page 1, line 34
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 October 26, 2011. This Internet-Draft will expire on October 29, 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 32 skipping to change at page 2, line 32
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. First hop selection . . . . . . . . . . . . . . . 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. First hop selection . . . . . . . . . . . . . . . 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 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18
3.3.1. Android/HTC magic . . . . . . . . . . . . . . . . . . 18 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
3.3.2. RIM BlackBerry . . . . . . . . . . . . . . . . . . . . 19 6. Security Considerations . . . . . . . . . . . . . . . . . . . 18
4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 19
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
6. Security Considerations . . . . . . . . . . . . . . . . . . . 20 8.1. Normative References . . . . . . . . . . . . . . . . . . . 19
7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 21 8.2. Informative References . . . . . . . . . . . . . . . . . . 20
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21
8.1. Normative References . . . . . . . . . . . . . . . . . . . 21
8.2. Informative References . . . . . . . . . . . . . . . . . . 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
implemented in some widely used operating systems, including both implemented in some widely used operating systems, including both
mobile handset and desktop operating systems, is collected in this mobile handset and desktop operating systems, is collected in this
document, including: Nokia S60 [S60], Microsoft Windows Mobile document, including: Nokia S60 [S60], Microsoft Windows Mobile
[WINDOWSMOBILE], Blackberry [BLACKBERRY], Google Android [ANDROID], [WINDOWSMOBILE], Blackberry [BLACKBERRY], Google Android [ANDROID],
Microsoft Windows, Apple Mac OS X, Linux and BSD-based operating Microsoft Windows, Linux and BSD-based operating systems.
systems.
2. Summary of Current Approaches 2. Summary of Current Approaches
This section summarizes current approaches that are used to resolve This section summarizes current approaches that are used to resolve
the multi-interface issues described in the Multiple Interface the multi-interface issues described in the Multiple Interface
Problem Statement [I-D.ietf-mif-problem-statement]. These approaches Problem Statement [I-D.ietf-mif-problem-statement]. These approaches
can be broken down into three major categories: can be broken down into three major categories:
o Centralized connection management o Centralized connection management
o Per-application connection settings o Per-application connection settings
o Stack-level solutions to specific problems o Stack-level solutions to specific problems
2.1. Centralized Connection Management 2.1. Centralized Connection Management
It is a common practice for mobile handset operating systems to use a It is a common practice for mobile handset operating systems to use a
centralized connection manager that performs network interface centralized connection manager that performs network interface
selection based on application or user input. The information used selection based on application or user input. However, connection
managers usually restrict the problem to the selection of the
interface and do not cope with selection of the provisioning domain,
as defined in [I-D.ietf-mif-problem-statement]. The information used
by the connection manager may be programmed into an application or by the connection manager may be programmed into an application or
provisioned on a handset-wide basis. When information is not provisioned on a handset-wide basis. When information is not
available to make an interface selection, the connection manager will available to make an interface selection, the connection manager will
query the user to choose between available choices. query the user to choose between available choices.
Routing tables are not typically used for network interface selection Routing tables are not typically used for network interface selection
when a connection manager is in use, as the criteria for network when a connection manager is in use, as the criteria for network
selection is not strictly IP-based but is also dependent on other selection is not strictly IP-based but is also dependent on other
properties of the interface (cost, type, etc.). Furthermore, properties of the interface (cost, type, etc.). Furthermore,
multiple overlapping private IPv4 address spaces are often exposed to multiple overlapping private IPv4 address spaces are often exposed to
skipping to change at page 4, line 28 skipping to change at page 4, line 29
applications or users. These solutions tend to map well to the applications or users. These solutions tend to map well to the
problems listed in the problem statement: problems listed in the problem statement:
o DNS resolution issues o DNS resolution issues
o Routing o Routing
o Address selection policy o Address selection policy
The configuration information for desktop systems comes from one of The configuration information for desktop systems comes from one of
three sources: DHCP, proprietary configuration systems or manual the following sources: DHCP, router advertisements, proprietary
configuration. While these systems universally accept IP address configuration systems or manual configuration. While these systems
assignment on a per-interface basis, they differ in what set of universally accept IP address assignment on a per-interface basis,
information can be assigned on a per-interface basis and what can be they differ in what set of information can be assigned on a per-
configured only on a per-system basis. interface basis and what can be configured only on a per-system
basis.
When choosing between multiple sets of information provided, these When choosing between multiple sets of information provided, these
systems will typically give preference to information received on the systems will typically give preference to information received on the
"primary" interface. The mechanism for designating the "primary" "primary" interface. The mechanism for designating the "primary"
interface differs by system. interface differs by system.
There is very little commonality in how desktop operating systems There is very little commonality in how desktop operating systems
handle multiple sets of configuration information, with notable handle multiple sets of configuration information, with notable
variations between different versions of the same operating system variations between different versions of the same operating system
and/or within different software packages built for the same and/or within different software packages built for the same
skipping to change at page 8, line 19 skipping to change at page 8, line 19
have some way of knowing which destination network the user, or an have some way of knowing which destination network the user, or an
application, is trying access. application, is trying access.
S60 3rd Edition, Feature Pack 2, introduces a concept of Service S60 3rd Edition, Feature Pack 2, introduces a concept of Service
Network Access Points (SNAPs) that group together IAPs that lead to Network Access Points (SNAPs) that group together IAPs that lead to
the same destination. This enables static or manual selection of the the same destination. This enables static or manual selection of the
destination network for an application and leaves the problem of destination network for an application and leaves the problem of
selecting the best of the available IAPs within a SNAP to the selecting the best of the available IAPs within a SNAP to the
operating system. operating system.
When SNAPs are used, it is possibly for the operating system to When SNAPs are used, the operating system can notify applications
notify applications when a preferred IAP, leading to the same when a preferred IAP, leading to the same destination, becomes
destination, becomes available (for example, when a user comes within available (for example, when a user comes within range of his home
range of his home WLAN access point), or when the currently used IAP WLAN access point), or when the currently used IAP is no longer
is no longer available and applications have to reconnect via another available. If so, applications have to reconnect via another IAP
IAP (for example, when a user goes out of range of his home WLAN and (for example, when a user goes out of range of his home WLAN and must
must move to the cellular network). 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 bound to an DNS configuration is per-interface; an application bound to an
skipping to change at page 10, line 17 skipping to change at page 10, line 17
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. RIM BlackBerry 3.1.3. RIM BlackBerry
Depending on the network configuration, applications in reasearch In Depending on the network configuration, applications in Research In
Motion (RIM) BlackBerry devices [BLACKBERRY] can use can use direct Motion (RIM) BlackBerry devices [BLACKBERRY] can use direct TCP/IP
TCP/IP connectivity or different application proxys to establish connectivity or different application proxys to establish connections
connections over the wireless network. For instance, some wireless over the wireless network. For instance, some wireless service
service providers provide an Internet gateway to offer direct TCP/IP providers provide an Internet gateway to offer direct TCP/IP
connectivity to the Internet while some others can provide a WAP connectivity to the Internet while some others can provide a WAP
gateway that allows HTTP connections to occur over the WAP (Wireless gateway that allows HTTP connections to occur over the WAP (Wireless
Application Protocol) protocol. It is also possible to use the Application Protocol) protocol. It is also possible to use the
BlackBerry Enterprise Server [BLACKBERRY] as a network gateway, The BlackBerry Enterprise Server [BLACKBERRY] as a network gateway, The
BlackBerry Enterprise Server provides an HTTP and TCP/IP proxy BlackBerry Enterprise Server provides an HTTP and TCP/IP proxy
service to allow the application to use it as a secure gateway for 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. managing HTTP and TCP/IP connections to the intranet or the Internet.
An application connecting to the Internet, can use either the An application connecting to the Internet, can use either the
BlackBerry Internet Service or the Internet gateway of the wireless BlackBerry Internet Service or the Internet gateway of the wireless
server provider or direct Internet connectivity over WLAN to manage server provider or direct Internet connectivity over WLAN to manage
skipping to change at page 17, line 28 skipping to change at page 17, line 28
The Internet Systems Consortium (ISC) DHCP Client [ISCDHCP] and its The Internet Systems Consortium (ISC) DHCP Client [ISCDHCP] and its
derivative for OpenBSD [OPENBSDDHCLIENT] can be configured with derivative for OpenBSD [OPENBSDDHCLIENT] can be configured with
specific instructions for each interface. However, each time new specific instructions for each interface. However, 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, such as the default routes rewrites the global configuration data, such as the default routes
and the DNS server list (in /etc/resolv.conf) with the most recent and the DNS server list (in /etc/resolv.conf) with the most recent
information received. Therefore, the last configured interface information received. Therefore, the last configured interface
always become the primary one. The ISC DHCPv6 client behaves always become the primary one. The ISC DHCPv6 client behaves
similarly. similarly. However, OpenBSD provides two mechanisms allowing to not
overwrite the configuration that the user made manually:
o OPTION MODIFIERS (default, supersede, prepend, and append): this
mechanism allows the user to override the DHCP options. For
example, the supersede statement defines, for some options, the
values the client should always use rather than any value supplied
by the server.
o resolv.conf.tail: it allows the user to append anything to the
resolv.conf file created by the DHCP client.
The Phystech dhcpcd client [PHYSTECHDHCPC] behaves similarly to the The Phystech dhcpcd client [PHYSTECHDHCPC] behaves similarly to the
ISC client. It replaces the DNS server list in /etc/resolv.conf and ISC client. It replaces the DNS server list in /etc/resolv.conf and
the default routes each time new DHCP information is received on any the default routes each time new DHCP information is received on any
interface. However, the -R flag can be used to instruct the client interface. However, the -R flag can be used to instruct the client
to not replace the DNS servers in /etc/resolv.conf. However, this to not replace the DNS servers in /etc/resolv.conf. However, this
flag is a global flag for the DHCP server, and is therefore flag is a global flag for the DHCP server, and is therefore
applicable to all interfaces. When dhcpd is called with the -R flag, applicable to all interfaces. When dhcpd is called with the -R flag,
the DNS servers are never replaced. the DNS servers are never replaced.
skipping to change at page 18, line 18 skipping to change at page 18, line 29
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. 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. This section only
focuses on a specific use-case and some of the current
implementations; however further considerations on network discovery
and selection can be found in [RFC5113]. [RFC5113] 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
different SSIDs:
The connection manager selects the first SSID of the the list of
preferred access network. The connection manager constructs the
list of preferred SSID giving priority to the last SSID on which
it has managed to attach. The user is not allowed to define its
preferred access. So, if the terminal discovers and manages to
attach to SSID1, SSID1 becomes the preferred access for future
attachment. If the terminal moves out of SSID1 coverage and
attaches to a new SSID, e.g. 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.
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 handset tries to connect to the next SSID in
the list.
When the terminal receives signals from different point of attachment
with same SSID:
The connection manager selects the point of attachment with best
signal strength; no other criteria (e.g. MAC address) is taken
into account. If the handset fails to attach to the selected
point of attachment (e.g. due to L2 authentication failure), the
connection manager selects the 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
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. If no more points of attachment (corresponding
to the preferred SSID) are available, the connection manager
selects the next SSID in the list of preferred SSID.
The connection manager always selects the most powerful signal
strength without considering IP configuration results. 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 alternative SSID, as long as
the signal strength of the current access point is the most
powerful. If the user is moving and if the signal strength of an
alternative point of attachment become better, the terminal
automatically restarts layer 2 and IP connectivity processes on
that alternative access point.
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. 11 change blocks. 
141 lines changed or deleted 46 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/