draft-ietf-mif-current-practices-05.txt   draft-ietf-mif-current-practices-06.txt 
Internet Engineering Task Force M. Wasserman, Ed. Internet Engineering Task Force M. Wasserman
Internet-Draft Painless Security, LLC Internet-Draft Painless Security, LLC
Intended status: Informational P. Seite, Ed. Intended status: Informational P. Seite
Expires: April 28, 2011 France Telecom - Orange Expires: August 5, 2011 France Telecom - Orange
October 25, 2010 February 1, 2011
Current Practices for Multiple Interface Hosts Current Practices for Multiple Interface Hosts
draft-ietf-mif-current-practices-05 draft-ietf-mif-current-practices-06
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 April 28, 2011. This Internet-Draft will expire on August 5, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
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 . . . . . 8 3.1.2. Microsoft Windows Mobile 2003 Second Edition and
3.1.3. Window Phone 7 . . . . . . . . . . . . . . . . . . . . 9 Windows Phone 7 . . . . . . . . . . . . . . . . . . . 8
3.1.4. BlackBerry . . . . . . . . . . . . . . . . . . . . . . 9 3.1.3. BlackBerry . . . . . . . . . . . . . . . . . . . . . . 10
3.1.5. Google Android . . . . . . . . . . . . . . . . . . . . 10 3.1.4. Google Android . . . . . . . . . . . . . . . . . . . . 10
3.1.6. Qualcomm Brew . . . . . . . . . . . . . . . . . . . . 10 3.1.5. Qualcomm Brew . . . . . . . . . . . . . . . . . . . . 11
3.1.7. Arena Connection Manager . . . . . . . . . . . . . . . 12 3.1.6. Arena Connection Manager . . . . . . . . . . . . . . . 13
3.1.8. Access selection . . . . . . . . . . . . . . . . . . . 12 3.1.7. Current practices for network selection in handsets . 13
3.2. Desktop Operating Systems . . . . . . . . . . . . . . . . 14 3.2. Desktop Operating Systems . . . . . . . . . . . . . . . . 14
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 . . . . . . . . . . . . . . . . 15
3.2.2. Linux and BSD-based Operating Systems . . . . . . . . 16 3.2.2. Linux and BSD-based Operating Systems . . . . . . . . 16
3.2.3. Apple Mac OS X . . . . . . . . . . . . . . . . . . . . 17 3.2.2.1. Routing . . . . . . . . . . . . . . . . . . . . . 16
4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 3.2.2.2. Outbound and Inbound Addresses . . . . . . . . . . 17
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 3.2.2.3. DNS Configuration . . . . . . . . . . . . . . . . 17
6. Security Considerations . . . . . . . . . . . . . . . . . . . 18 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19
7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 18 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 6. Security Considerations . . . . . . . . . . . . . . . . . . . 19
8.1. Normative References . . . . . . . . . . . . . . . . . . . 19 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 19
8.2. Informative References . . . . . . . . . . . . . . . . . . 19 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 8.1. Normative References . . . . . . . . . . . . . . . . . . . 20
8.2. Informative References . . . . . . . . . . . . . . . . . . 20
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.
Publicly-available information about the multiple-interface solutions Publicly-available information about the multiple-interface solutions
skipping to change at page 8, line 25 skipping to change at page 8, line 25
operating system. operating system.
When SNAPs are used, it is possibly for the operating system to When SNAPs are used, it is possibly for the operating system to
notify applications when a preferred IAP, leading to the same notify applications when a preferred IAP, leading to the same
destination, becomes available (for example, when a user comes within destination, becomes available (for example, when a user comes within
range of his home WLAN access point), or when the currently used IAP range of his home WLAN access point), or when the currently used IAP
is no longer available and applications have to reconnect via another is no longer available and applications have to reconnect via another
IAP (for example, when a user goes out of range of his home WLAN and IAP (for example, when a user goes out of range of his home WLAN and
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
mechanisms. Applications are tightly bound the network interface
selected for them or by them. E.g. an application may be connected
to IPv6 3G connection, IPv4 3G connection, WLAN connection, or VPN
connection. The application can change between the connections, but
uses only one at a time. If the interface happens to be dual-stack,
then IPv4 is preferred over IPv6.
DNS configuration is per-interface; an application bounded to an
interface will always use the DNS settings for that interface. Hence
the device itself remembers these pieces of information for each
interface separately.
The S60 3.2 manages with totally overlapping addresses spaces. Each
interface can even have same IPv4 address configured on it without
issues. This is so because interfaces are kept totally separate from
each other. This also implies that the interface selection has to be
done at application layer, as from network layer point of view device
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 3.1.2. Microsoft Windows Mobile 2003 Second Edition and Windows Phone 7
A Connection Manager architecture is described in [WINDOWSMOBILE]. A Connection Manager architecture is described in [WINDOWSMOBILE].
This architecture centralizes and automates network connection 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.
skipping to change at page 9, line 14 skipping to change at page 9, line 33
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.
3.1.3. Window Phone 7
In comparison to Windows Mobile 2003 SE, Windows phone 7 brings In comparison to Windows Mobile 2003 SE, Windows phone 7 brings
update of the routing functionality in the case where the terminal update of the routing functionality in the case where the terminal
can be attached simultaneously to several interfaces. Actually, can be attached simultaneously to several interfaces. Actually,
Windows Phone 7 routes the traffic through a preferred interface, Windows Phone 7 routes the traffic through a preferred interface,
which has a lower metric. When there are multiple interfaces, the which has a lower metric. When there are multiple interfaces, the
applications system will, by default, choose from an ordered list of applications system will, by default, choose from an ordered list of
available interfaces. The default connection policy will prefer available interfaces. The default connection policy will prefer
wired over wireless and WLAN over cellular. Hence, if an application wired over wireless and WLAN over cellular. Hence, if an application
wants to use cellular 3G as the active interface when WLAN is wants to use cellular 3G as the active interface when WLAN is
available, the application needs to override the default connection available, the application needs to override the default connection
mapping policy. An application specific mapping policy can be set mapping policy. An application specific mapping policy can be set
via API or provisioned by the Mobile Operator. The application, in via API 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).
3.1.4. BlackBerry 3.1.3. BlackBerry
Depending on the network configuration, Java applications in Depending on the network configuration, Java applications in
BlackBerry devices [BLACKBERRY] can use can use direct TCP/IP BlackBerry devices [BLACKBERRY] can use can use direct TCP/IP
connectivity or different application proxys to establish connections connectivity or different application proxys to establish connections
over the wireless network. For instance, some wireless service over the wireless network. For instance, some wireless 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
skipping to change at page 10, line 19 skipping to change at page 10, line 41
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. When multiple
network interfaces are aggregated into a single IP stack, the device network interfaces are aggregated into a single IP stack, the device
associates each application to the more appropriate network associates each application to the more appropriate network
interface. The selection can be based on cost, type-of-service interface. The selection can be based on cost, type-of-service
and/or user preference. and/or user preference.
3.1.5. Google Android 3.1.4. Google Android
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,
Android can manage multiple routing tables and rely on policy based
routing associated with packet filtering capabilities (see
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.
address space overlapping.
For incoming packets, Android implements the weak host model
[RFC1122] on both IPv4 and IPv6. However, Android can also be
configured to support the strong host model.
Regarding DNS configuration, Android does not list the DNS servers in
the file /etc/resolv.conf, used by Linux. However, as per Linux, DNS
configuration is node-scoped, even if DNS configuration can rely on
the DHCP client. For instance, the udhcp client [UDHCP], which is
also available for Linux, can be used on Android. Each time new
configuration data is received by the host from a DHCP server,
regardless of which interface it is received on, the DHCP client
rewrites the global configuration data with the most recent
information received.
Actually, the main difference between Linux and Android is on the
address selection mechanism. Android version prior to 2.2 simply
prefers IPv6 connectivity over IPv4. Android 2.2 has been updated
with [ANDROID-RFC3484], which implements some of the address
selection rules defined in [RFC3484]. All RFC3484 rules are
supported, except 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
information about all network interfaces, including their information about all network interfaces, including their
availability, type and other information. availability, type and other information.
Depending on vendors implementation, applications may be bound to use 3.1.5. Qualcomm Brew
one network type at a time. For example, on a 3G/WLAN HTC Dream
(Android 1.5), web browsing uses only the WLAN access when both 3G
and WLAN are available. However different applications can use
different access at the same time. For instance, the HTC Dream can
utilize WLAN access for web browsing and GPRS access for transferring
multimedia messages (MMS).
3.1.6. Qualcomm Brew
This section describes how multi-interface support is handled by This section describes how multi-interface support is handled by
Advanced Mobile Station Software (AMSS) that comes with Brew OS for Advanced Mobile Station Software (AMSS) that comes with Brew OS for
all Qualcomm chipsets (e.g., MSM, Snapdragon etc). AMSS is a low all Qualcomm chipsets (e.g., MSM, Snapdragon etc). AMSS is a low
level connectivity platform, on top of which manufacturers can build level connectivity platform, on top of which manufacturers can build
to provide the necessary connectivity to applications. The to provide the necessary connectivity to applications. The
interaction model between AMSS, the Operating System, and the interaction model between AMSS, the Operating System, and the
applications is not unique and depend on the design chosen by the applications is not unique and depend on the design chosen by the
manufacturer. The Mobile OS can let an application invoke the AMSS manufacturer. The Mobile OS can let an application invoke the AMSS
directly (via API), or provide its own connection manager that will directly (via API), or provide its own connection manager that will
skipping to change at page 12, line 20 skipping to change at page 13, line 18
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.7. Arena Connection Manager 3.1.6. Arena Connection Manager
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 multi-interface issues such as
connection sharing. connection sharing.
3.1.8. Access selection 3.1.7. Current practices for network selection in handsets
This section describes the behavior of connection managers in This section describes the behavior of connection managers in
presence of multiple points of attachment for a same interface. The presence of multiple points of attachment for a same interface. The
section focuses on WLAN interface, it is described how does the section focuses on WLAN interface, it is described how does the
connection manager deal with the list of preferred SSID and how does connection manager deal with the list of preferred SSID and how does
it select the SSID for attachment. Current implementation of it select the SSID for attachment. Current implementation of
connection managers are considered for the following handsets: LG connection managers are considered for the following handsets: LG
Pathfinder, Android/HTC magic, RIM BlackBerry , iPhone (3G and 3GS). Pathfinder, Android/HTC magic, RIM BlackBerry , iPhone (3G and 3GS).
When the terminal is under coverage of different WLAN networks with When the terminal is under coverage of different WLAN networks with
skipping to change at page 16, line 7 skipping to change at page 16, line 45
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
In addition to the two commonly used routing tables (the local and
main routing tables), the kernel can support up to 252 additional
routing tables which can be added in the file /etc/iproute2/
rt_tables. A routing table can contain an arbitrary number of
routes, the selection of route is classically made according to the
destination address of the packet. Linux also provides more flexible
routing selection based on the Type of Service, scope, output
interface. In addition, since kernel version 2.2, Linux supports
policy based routing using the multiple routing tables capability and
a routing policy database. This database contains routing rules used
by the kernel. Using policy based routing, the source address, the
ToS flags, the interface name and an "fwmark" (a mark carried through
added in the data structure representing the packet) can be used as
route selectors.
Policy based routing can be used in addition to Linux packet
filtering capabilities, e.g provided by the "iptables" tool. In a
multiple interfaces context, this tool can be used to mark the
packets, i.e assign a number to fwmark, in order to select the
routing rule according to the type of traffic. This mark can be
assigned according to parameters like protocol, source and/or
destination addresses, port number and so on.
Such a routing management framework allows to deal with complex
situation such as address space overlaping. In this situation, the
administrator can use packet marking and policy based routing to
select the correct interface.
3.2.2.2. Outbound and Inbound Addresses
By default, source address selection follows the following basics
rules: the initial source address for an outbound packet can be
chosen by the application using the bind() call. Without information
from the application, the kernel chooses the first address configured
on the interface which belongs to the same subnet than the
destination address or the nexthop router.
Linux also implements [RFC3484] for source address selection for IPv6
and dual-stack configurations. However, the address sorting rules
from [RFC3484] are not always adequate. For this reason, Linux
allows the system administrator to dynamically change the sorting.
This can be achieved with the /etc/gai.conf file.
For incoming packets, Linux checks if the destination address matches
one of the addresses assigned to its interfaces then, processes the
packet according the configured host model. By default, Linux
implements the weak host model [RFC1122] on both IPv4 and IPv6.
However, Linux can also be configured to support the strong host
model.
3.2.2.3. DNS Configuration
Most BSD and Linux distributions rely on their DHCP client to handle Most BSD and Linux distributions rely on their DHCP client to handle
the configuration of interface-specific information (such as an IP the configuration of interface-specific information (such as an IP
address and netmask), and a set of system-wide configuration address and netmask), and a set of system-wide configuration
information, (such a DNS server list, an NTP server list and default information, (such a DNS server list, an NTP server list and default
routes). Users of these operating systems have the choice of using routes). Users of these operating systems have the choice of using
any DHCP client available for their platform, with an operating any DHCP client available for their platform, with an operating
system default. This section discusses the behavior of several DHCP system default. This section discusses the behavior of several DHCP
clients that may be used with Linux and BSD distributions. clients that may be used with Linux and BSD distributions.
The Internet Systems Consortium (ISC) DHCP Client [ISCDHCP] and its The Internet Systems Consortium (ISC) DHCP Client [ISCDHCP] and its
skipping to change at page 17, line 15 skipping to change at page 19, line 10
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.
Linux implements [RFC3484] for source address selection in IPv6.
However, the address sorting rules from [RFC3484] are not always
adequate. For this reason, Linux allows the system administrator to
dynamically change the sorting. This can be achieved with the /etc/
gai.conf file.
For incoming packets, Linux will check if the destination address
matches one of the addresses assigned to its interfaces. By default,
Linux implements the weak host model [RFC1122] on both IPv4 and IPv6.
However, Linux can also be configured to support the strong host
model.
3.2.3. Apple Mac OS X
This section is based on testing Mac OS X (version 10.5.6).
When using multiple interfaces on Mac OS X, global configuration data
such as default routes and the DNS server list are taken from the
DHCP data received on the primary interface. Therefore, the order in
which the interfaces receive their configuration data is not
relevant. For example, if the primary interface receives its
configuration data first, then the second interface receives its
configuration data, the interface-specific information for the second
interface will be configured, but the global configuration
information such as the DNS server list and default routes is not
overwritten.
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. 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.
6. Security Considerations 6. Security Considerations
This document describes current operating system implementations and This document describes current operating system implementations and
how they handle the issues raised in the MIF problem statement. how they handle the issues raised in the MIF problem statement.
While it is possible that the currently implemented mechanisms While it is possible that the currently implemented mechanisms
skipping to change at page 19, line 4 skipping to change at page 20, line 23
o George Tsirtsis, Qualcomm. o George Tsirtsis, Qualcomm.
o David Freyermuth, France telecom. o David Freyermuth, France telecom.
o Aurelien Collet, Altran. o Aurelien Collet, Altran.
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 Problem Blanchet, M. and P. Seite, "Multiple Interfaces and
Statement", draft-ietf-mif-problem-statement-07 (work in Provisioning Domains Problem Statement",
progress), August 2010. draft-ietf-mif-problem-statement-09 (work in progress),
October 2010.
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]
Gunderson, S., "RFC 3484 support for Android", 2010, <http
://gitorious.org/0xdroid/bionic/commit/
9ab75d4cc803e91b7f1b656ffbe2ad32c52a86f9>.
[BLACKBERRY] [BLACKBERRY]
Research In Motion Limited, "BlackBerry Java Development Research In Motion Limited, "BlackBerry Java Development
Environment - Fundamentals Guide: Wireless gateways", Environment - Fundamentals Guide: Wireless gateways",
2009, <http://na.blackberry.com/eng/deliverables/5827/ 2009, <http://na.blackberry.com/eng/deliverables/5827/
Wireless_gateways_447132_11.jsp>. Wireless_gateways_447132_11.jsp>.
[I-D.montenegro-mif-multihoming] [I-D.montenegro-mif-multihoming]
Montenegro, G., Thaler, D., and S. Seshadri, "Multiple Montenegro, G., Thaler, D., and S. Seshadri, "Multiple
Interfaces on Windows", Interfaces on Windows",
draft-montenegro-mif-multihoming-00 (work in progress), draft-montenegro-mif-multihoming-00 (work in progress),
skipping to change at page 20, line 35 skipping to change at page 22, line 13
[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>.
Authors' Addresses Authors' Addresses
Margaret Wasserman (editor) 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
URI: http://www.painless-security.com URI: http://www.painless-security.com
Pierrick Seite (editor)
Pierrick Seite
France Telecom - Orange France Telecom - Orange
4, rue du clos courtel BP 91226 4, rue du clos courtel BP 91226
Cesson-Sevigne 35512 Cesson-Sevigne 35512
France France
Email: pierrick.seite@orange-ftgroup.com Email: pierrick.seite@orange-ftgroup.com
 End of changes. 24 change blocks. 
76 lines changed or deleted 155 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/