GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc6419

Internet Engineering Task Force (IETF) M. Wasserman Request for Comments: 6419 Painless Security, LLC Category: Informational P. Seite ISSN: 2070-1721 France Telecom - Orange

                                                         November 2011
           Current Practices for Multiple-Interface Hosts

Abstract

 An increasing number of hosts are operating in multiple-interface
 environments.  This document summarizes current practices in this
 area and describes in detail how some common operating systems cope
 with challenges that ensue from this context.

Status of This Memo

 This document is not an Internet Standards Track specification; it is
 published for informational purposes.
 This document is a product of the Internet Engineering Task Force
 (IETF).  It represents the consensus of the IETF community.  It has
 received public review and has been approved for publication by the
 Internet Engineering Steering Group (IESG).  Not all documents
 approved by the IESG are a candidate for any level of Internet
 Standard; see Section 2 of RFC 5741.
 Information about the current status of this document, any errata,
 and how to provide feedback on it may be obtained at
 http://www.rfc-editor.org/info/rfc6419.

Copyright Notice

 Copyright (c) 2011 IETF Trust and the persons identified as the
 document authors.  All rights reserved.
 This document is subject to BCP 78 and the IETF Trust's Legal
 Provisions Relating to IETF Documents
 (http://trustee.ietf.org/license-info) in effect on the date of
 publication of this document.  Please review these documents
 carefully, as they describe your rights and restrictions with respect
 to this document.  Code Components extracted from this document must
 include Simplified BSD License text as described in Section 4.e of
 the Trust Legal Provisions and are provided without warranty as
 described in the Simplified BSD License.

Wasserman & Seite Informational [Page 1] RFC 6419 MIF Current Practices November 2011

Table of Contents

 1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
 2.  Summary of Current Approaches  . . . . . . . . . . . . . . . .  3
   2.1.  Centralized Connection Management  . . . . . . . . . . . .  3
   2.2.  Per-Application Connection Settings  . . . . . . . . . . .  4
   2.3.  Stack-Level Solutions to Specific Problems . . . . . . . .  4
     2.3.1.  DNS Resolution Issues  . . . . . . . . . . . . . . . .  5
     2.3.2.  First-Hop Selection  . . . . . . . . . . . . . . . . .  5
     2.3.3.  Address Selection Policy . . . . . . . . . . . . . . .  5
 3.  Current Practices in Some Operating Systems  . . . . . . . . .  6
   3.1.  Mobile Handset Operating Systems . . . . . . . . . . . . .  6
     3.1.1.  Nokia S60 3rd Edition, Feature Pack 2  . . . . . . . .  7
     3.1.2.  Microsoft Windows Mobile and Windows Phone 7 . . . . .  9
     3.1.3.  RIM BlackBerry . . . . . . . . . . . . . . . . . . . . 10
     3.1.4.  Google Android . . . . . . . . . . . . . . . . . . . . 11
     3.1.5.  Qualcomm Brew  . . . . . . . . . . . . . . . . . . . . 12
     3.1.6.  Leadcore Technology Arena  . . . . . . . . . . . . . . 13
   3.2.  Desktop Operating Systems  . . . . . . . . . . . . . . . . 14
     3.2.1.  Microsoft Windows  . . . . . . . . . . . . . . . . . . 14
       3.2.1.1.  First-Hop Selection  . . . . . . . . . . . . . . . 14
       3.2.1.2.  Outbound and Inbound Addresses . . . . . . . . . . 14
       3.2.1.3.  DNS Configuration  . . . . . . . . . . . . . . . . 15
     3.2.2.  Linux and BSD-Based Operating Systems  . . . . . . . . 16
       3.2.2.1.  First-Hop Selection  . . . . . . . . . . . . . . . 16
       3.2.2.2.  Outbound and Inbound Addresses . . . . . . . . . . 16
       3.2.2.3.  DNS Configuration  . . . . . . . . . . . . . . . . 17
 4.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18
 5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 18
 6.  Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 19
 7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
   7.1.  Normative References . . . . . . . . . . . . . . . . . . . 19
   7.2.  Informative References . . . . . . . . . . . . . . . . . . 19

Wasserman & Seite Informational [Page 2] RFC 6419 MIF Current Practices November 2011

1. Introduction

 Multiple-interface hosts face several challenges not faced by single-
 interface hosts, some of which are described in the multiple
 interfaces (MIF) problem statement [RFC6418].  This document
 summarizes how current implementations deal with the problems
 identified in the MIF problem statement.
 Publicly available information about the multiple-interface solutions
 implemented in some widely used operating systems, including both
 mobile handset and desktop operating systems, is collected in this
 document, including Nokia S60 [S60], Microsoft Windows Mobile
 [WINDOWSMOBILE], Blackberry [BLACKBERRY], Google Android [ANDROID],
 Microsoft Windows, Linux, and BSD-based operating systems.

2. Summary of Current Approaches

 This section summarizes current approaches that are used to resolve
 the multiple-interface issues described in the MIF problem statement
 [RFC6418].  These approaches can be broken down into three major
 categories:
 o  Centralized connection management
 o  Per-application connection settings
 o  Stack-level solutions to specific problems

2.1. Centralized Connection Management

 It is a common practice for mobile handset operating systems to use a
 centralized connection manager that performs network interface
 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 [RFC6418].  The information used by the connection
 manager may be programmed into an application or provisioned on a
 handset-wide basis.  When information is not available to make an
 interface selection, the connection manager will query the user to
 choose between available choices.
 Routing tables are not typically used for network interface selection
 when a connection manager is in use, as the criteria for network
 selection is not strictly IP-based but is also dependent on other
 properties of the interface (cost, type, etc.).  Furthermore,
 multiple overlapping private IPv4 address spaces are often exposed to
 a multiple-interface host, making it difficult to make interface
 selection decisions based on prefix matching.

Wasserman & Seite Informational [Page 3] RFC 6419 MIF Current Practices November 2011

2.2. Per-Application Connection Settings

 In mobile handsets, applications are often involved in choosing what
 interface and related configuration information should be used.  In
 some cases, the application selects the interface directly, and in
 other cases, the application provides more abstract information to a
 connection manager that makes the final interface choice.

2.3. Stack-Level Solutions to Specific Problems

 In most desktop operating systems, multiple-interface problems are
 dealt with in the stack and related components, based on system-
 level configuration information, without the benefit of input from
 applications or users.  These solutions tend to map well to the
 problems listed in the problem statement:
 o  DNS resolution issues
 o  Routing
 o  Address selection policy
 The configuration information for desktop systems comes from one of
 the following sources: DHCP, router advertisements, proprietary
 configuration systems, or manual configuration.  While these systems
 universally accept IP address assignment on a per-interface basis,
 they differ in what set of information can be assigned on a per-
 interface basis and what can be configured only on a per-system
 basis.
 When choosing between multiple sets of information provided, these
 systems will typically give preference to information received on the
 "primary" interface.  The mechanism for designating the "primary"
 interface differs by system.
 There is very little commonality in how desktop operating systems
 handle multiple sets of configuration information, with notable
 variations between different versions of the same operating system
 and/or within different software packages built for the same
 operating system.  Although these systems differ widely, it is not
 clear that any of them provide a completely satisfactory user
 experience in multiple-interface environments.
 The following sections discuss some of the solutions used in each of
 the areas raised in the MIF problem statement.

Wasserman & Seite Informational [Page 4] RFC 6419 MIF Current Practices November 2011

2.3.1. DNS Resolution Issues

 There is very little commonality in how desktop operating systems
 handle the DNS server list.  Some systems support per-interface DNS
 server lists, while others only support a single system-wide list.
 On hosts with per-interface DNS server lists, different mechanisms
 are used to determine which DNS server is contacted for a given
 query.  In most cases, the first DNS server listed on the "primary"
 interface is queried first, with back off to other servers if an
 answer is not received.
 Systems that support a single system-wide list differ in how they
 select which DNS server to use in cases where they receive more than
 one DNS server list to configure (e.g., from DHCP on multiple
 interfaces).  Some accept the information received on the "primary"
 interface, while others use either the first or last set DNS server
 list configured.

2.3.2. First-Hop Selection

 Routing information is also handled differently on different desktop
 operating systems.  While all systems maintain some sort of routing
 cache, to handle redirects and/or statically configured routes, most
 packets are routed based on configured default gateway information.
 Some systems do allow the configuration of different default router
 lists for different interfaces.  These systems will always choose the
 default gateway on the interface with the lowest routing metric, with
 different behavior when two or more interfaces have the same routing
 metric.
 Most systems do not allow the configuration of more than one default
 router list, choosing instead to use the first or last default router
 list configured and/or the router list configured on the "primary"
 interface.

2.3.3. Address Selection Policy

 There is somewhat more commonality in how desktop hosts handle
 address selection.  Applications typically provide the destination
 address for an outgoing packet, and the IP stack is responsible for
 picking the source address.
 IPv6 specifies a specific source address selection mechanism in
 [RFC3484], and several systems implement this mechanism with similar
 support for IPv4.  However, many systems do not provide any mechanism
 to update this default policy, and there is no standard way to do so.

Wasserman & Seite Informational [Page 5] RFC 6419 MIF Current Practices November 2011

 In some cases, the routing decision (including which interface to
 use) is made before source address selection is performed, and a
 source address is chosen from the outbound interface.  In other
 cases, source address selection is performed before, or independently
 from, outbound interface selection.

3. Current Practices in Some Operating Systems

 The material presented in this section is derived from contributions
 from people familiar with the operating systems described (see
 Section 6 a list of these individuals).  The authors and the IETF
 take no position about the operating systems described and understand
 that other operating systems also exist.  Furthermore, it should be
 understood that Section 3 describes particular behaviors that were
 believed to be current at the time this document was written: earlier
 and later versions of the operating systems described may exhibit
 different behaviors.  Please refer to the References section for
 pointers to original documentation, including further details.

3.1. Mobile Handset Operating Systems

 Cellular devices typically run a variety of applications in parallel,
 each with different requirements for IP connectivity.  A typical
 scenario is shown in Figure 1, where a cellular device is utilizing
 Wireless Local Area Network (WLAN) access for web browsing and
 General Packet Radio Service (GPRS) access for transferring
 multimedia messages (MMS).  Another typical scenario would be a real-
 time Voice over IP (VoIP) session over one network interface in
 parallel with best-effort web browsing on another network interface.
 Yet another typical scenario would be global Internet access through
 one network interface and local (e.g., corporate VPN) network access
 through another.
      Web server                                       MMS Gateway
           |                                                |
          -+--Internet----            ----Operator network--+-
                  |                          |
              +-------+                  +-------+
              |WLAN AP|                  | GGSN  |
              +-------+                  +-------+
                  |        +--------+        |
                  +--------|Cellular|--------+
                           |device  |
                           +--------+
             A Cellular Device with Two Network Interfaces
                               Figure 1

Wasserman & Seite Informational [Page 6] RFC 6419 MIF Current Practices November 2011

 Different network access technologies require different settings.
 For example, WLAN requires the Service Set Identifier (SSID), and the
 GPRS network requires the Access Point Name (APN) of the Gateway GPRS
 Support Node (GGSN), among other parameters.  It is common that
 different accesses lead to different destination networks (e.g., to
 Internet, intranet, cellular network services, etc.).

3.1.1. Nokia S60 3rd Edition, Feature Pack 2

 S60 is a software platform for mobile devices running on the Symbian
 operating system (OS).  S60 uses the concept of an Internet Access
 Point (IAP) [S60] that contains all information required for opening
 a network connection using a specific access technology.  A device
 may have several IAPs configured for different network technologies
 and settings (multiple WLAN SSIDs, GPRS APNs, dial-up numbers, and so
 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
 when the application requires network connectivity.  This is
 essential, as the wrong IAP may not be able to support the
 application or reach the desired destination.  For example, an MMS
 application must use the correct IAP in order to reach the MMS
 Gateway, which typically is not accessible from the public Internet.
 As another example, an application might need to use the IAP
 associated with its corporate VPN in order to reach internal
 corporate servers.  Binding applications to IAPs avoids several
 problems, such as choosing the correct DNS server in the presence of
 split DNS (as an application will use the DNS server list from its
 bound IAP) and overlapping private IPv4 address spaces used for
 different interfaces (as each application will use the default routes
 from its bound IAP).
 If multiple applications utilize the same IAP, the underlying network
 connection can typically be shared.  This is often the case when
 multiple Internet-using applications are running in parallel.
 The IAP for an application can be selected in multiple ways:
 o  Statically: for example, from a configuration interface, via
    client provisioning/device management system, or at build-time.
 o  Manually by the user: for example, each time an application
    starts, the user may be asked to select the IAP to use.  This may
    be needed, for example, if a user sometimes wishes to access his
    corporate intranet and other times would prefer to access the
    Internet directly.

Wasserman & Seite Informational [Page 7] RFC 6419 MIF Current Practices November 2011

 o  Automatically by the system: after the destination network has
    been selected statically or dynamically.
 The static approach is fine for certain applications, like MMS, for
 which configuration can be provisioned by the network operator and
 does not change often.  Manual selection works but may be seen as
 troublesome by the user.  An automatic selection mechanism needs to
 have some way of knowing which destination network the user, or an
 application, is trying access.
 S60 3rd Edition, Feature Pack 2 introduces the concept of Service
 Network Access Points (SNAPs) that group together IAPs that lead to
 the same destination.  This enables static or manual selection of the
 destination network for an application and leaves the problem of
 selecting the best of the available IAPs within a SNAP to the
 operating system.
 When SNAPs are used, the operating system can notify applications
 when a preferred IAP, leading to the same destination, becomes
 available (for example, when a user comes within range of his home
 WLAN access point) or when the currently used IAP is no longer
 available.  If so, applications have to reconnect via another IAP
 (for example, when a user goes out of range of his home WLAN and must
 move to the cellular network).
 S60 3.2 does not support RFC 3484 for source address selection
 mechanisms.  Applications are tightly bound to the network interface
 selected for them or by them.  For example, an application may be
 connected to an 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 bound 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.
 S60 3.2 manages with totally overlapping addresses spaces.  Each
 interface can even have the same IPv4 address configured on it
 without issues because interfaces are kept totally separate from each
 other.  This implies that interface selection has to be done at the
 application layer, as from the network-layer point of view, a device
 is not multihomed in the IP-sense.
 Please see the S60 source documentation for more details and
 screenshots [S60].

Wasserman & Seite Informational [Page 8] RFC 6419 MIF Current Practices November 2011

3.1.2. Microsoft Windows Mobile and Windows Phone 7

 Microsoft Windows Mobile leverages a connection manager
 [WINDOWSMOBILE] to handle multiple network connections.  This
 architecture centralizes and automates network connection
 establishment and management and makes it possible to automatically
 select a connection, to dial-in automatically or by user initiation,
 and to optimize connection and shared resource usage.  The connection
 manager periodically re-evaluates the validity of the connection
 selection.  The connection manager uses various attributes such as
 cost, security, bandwidth, error rate, and latency in its decision
 making.
 The connection manager selects the best possible connection for the
 application based on the destination network the application wishes
 to reach.  The selection is made between available physical and
 virtual connections (e.g., VPN, GPRS, WLAN, and wired Ethernet) that
 are known to provide connectivity to the destination network, and the
 selection is based on the costs associated with each connection.
 Different applications are bundled to use the same network connection
 when possible, but in conflict situations when a connection cannot be
 shared, higher-priority applications take precedence, and the lower-
 priority applications lose connectivity until the conflict situation
 clears.
 During operation, the connection manager opens new connections as
 needed and also disconnects unused or idle connections.
 To optimize resource use, such as battery power and bandwidth, the
 connection manager enables applications to synchronize network
 connection usage by allowing applications to register their
 requirements for periodic connectivity.  An application is notified
 when a suitable connection becomes available for its use.
 In comparison to Windows Mobile connection management, Windows Phone
 7 updates the routing functionality in the case where the terminal
 can be attached simultaneously to several interfaces.  Windows Phone
 7 selects the first hop corresponding to the interface that has a
 lower metric.  When there are multiple interfaces, the applications
 system will, by default, choose from an ordered list of available
 interfaces.  The default connection policy will prefer wired over
 wireless and WLAN over cellular.  Hence, if an application wants to
 use cellular 3G as the active interface when WLAN is available, the
 application needs to override the default connection mapping policy.
 An application-specific mapping policy can be set via a Microsoft API
 or provisioned by the Mobile Operator.  The application, in

Wasserman & Seite Informational [Page 9] RFC 6419 MIF Current Practices November 2011

 compliance with the security model, can request connection type by
 interface (WLAN, cellular), by minimum interface speed (x kbit/s, y
 Mbit/s), or by name (Access Point Name).
 In dual-stack systems, Windows Mobile and Windows Phone 7 implement
 address selection rules per [WNDS-RFC3484].  An administrator can
 configure a policy table that can override the default behavior of
 the selection algorithms.  Note 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. RIM BlackBerry

 Depending on the network configuration, applications in Research In
 Motion (RIM) BlackBerry devices [BLACKBERRY] can use direct TCP/IP
 connectivity or different application proxies to establish
 connections over the wireless network.  For instance, some wireless
 service providers provide an Internet gateway to offer direct TCP/IP
 connectivity to the Internet while some others can provide a Wireless
 Application Protocol (WAP) gateway that allows HTTP connections to
 occur over WAP.  It is also possible to use the BlackBerry Enterprise
 Server [BLACKBERRY] as a network gateway.  The BlackBerry Enterprise
 Server provides an HTTP and TCP/IP proxy 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.  An application
 connecting to the Internet can use either the BlackBerry Internet
 Service or the Internet gateway of the wireless server provider or
 direct Internet connectivity over WLAN to manage connections.  The
 problem of gateway selection is supposed to be managed independently
 by each application.  For instance, an application can be designed to
 always use the default Internet gateway, while another application
 can be designed to use a preferred proxy when available.
 A BlackBerry device [BLACKBERRY] can be attached to multiple networks
 simultaneously (wireless/wired).  In this case, multiple network
 interfaces can be associated to a single IP stack or multiple IP
 stacks.  The device, or the application, can select the network
 interface to be used in various ways.  For instance, the device can
 always map the applications to the default network interface (or the
 default access network).  When multiple IP stacks are associated to
 multiple interfaces, the application can select the source address
 corresponding to the preferred network interface.  Per-interface IP
 stacks also allow to manage overlapping address spaces.  When
 multiple network interfaces are aggregated into a single IP stack,

Wasserman & Seite Informational [Page 10] RFC 6419 MIF Current Practices November 2011

 the device associates each application to the more appropriate
 network interface.  The selection can be based on cost, type of
 service (ToS), 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

 Android is based on a Linux kernel and, in many situations, behaves
 like a Linux device as described in Section 3.2.2.  Per Linux,
 Android can manage multiple routing tables and relies 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, 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 versions prior to 2.2 simply
 prefer IPv6 connectivity over IPv4.  However, it should be noted
 that, at the time of this writing, IPv6 is available only on WiFi and
 virtual interfaces but not on the cellular interface (without IPv6 in
 IPv4 encapsulation).  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), rule 4 (prefer home
 addresses), and rule 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
 [ANDROID] and the ConnectivityManager class that applications can use
 to request the first hop to a specified destination address via a

Wasserman & Seite Informational [Page 11] RFC 6419 MIF Current Practices November 2011

 specified network interface (Third Generation Partnership Project
 (3GPP) or WLAN).  Applications also ask the connection manager for
 permission to start using a network feature.  The connection manager
 monitors changes in network connectivity and attempts to failover to
 another network if connectivity to an active network is lost.  When
 there are changes in network connectivity, applications are notified.
 Applications are also able to ask for information about all network
 interfaces, including their availability, type, and other
 information.

3.1.5. Qualcomm Brew

 This section describes how multiple-interface support is handled by
 Advanced Mobile Station Software (AMSS) that comes with Brew OS for
 all Qualcomm chipsets (e.g., Mobile Station Modem (MSM), Snapdragon,
 etc.).  AMSS is a low-level connectivity platform, on top of which
 manufacturers can build to provide the necessary connectivity to
 applications.  The interaction model between AMSS, the operating
 system, and the applications is not unique and depends on the design
 chosen by the manufacturer.  The Mobile OS can let an application
 invoke the AMSS directly (via API) or provide its own connection
 manager that will request connectivity to the AMSS based on
 applications needs.  The interaction between the OS connection
 manager and the applications is OS dependent.
 AMSS supports a concept of netpolicy that allows each application to
 specify the type of network connectivity desired.  The netpolicy
 contains parameters such as access technology, IP version type, and
 network profile.  Access technology could be a specific technology
 type such as CDMA or WLAN or could be a group of technologies, such
 as ANY_Cellular or ANY_Wireless.  IP version could be one of IPv4,
 IPv6, or Default.  The network profile identifies a type of network
 domain or service within a certain network technology, such as 3GPP
 APN or Mobile IP Home Agent.  It also specifies all the mandatory
 parameters required to connect to the domain such authentication
 credentials and other optional parameters such as Quality of Service
 (QoS) attributes.  Network profile is technology specific, and the
 set of parameters contained in the profile could vary for different
 technologies.
 Two models of network usage are supported:
 o  Applications requiring network connectivity specify an appropriate
    netpolicy in order to select the desired network.  The netpolicy
    may match one or more network interfaces.  The AMSS system
    selection module selects the best interface out of the ones that
    match the netpolicy based on various criteria such as cost, speed,
    or other provisioned rules.  The application explicitly starts the

Wasserman & Seite Informational [Page 12] RFC 6419 MIF Current Practices November 2011

    selected network interface and, as a result, the application also
    gets bound to the corresponding network interface.  All outbound
    packets from this application are always routed over this bound
    interface using the source address of the interface.
 o  Applications may rely on a separate connection manager to control
    (e.g., start/stop) the network interface.  In this model,
    applications are not necessarily bound to any one interface.  All
    outbound packets from such applications are routed on one of the
    interfaces that match its netpolicy.  The routing decision is made
    individually for each packet and selects the best interface based
    on the criteria described above and the destination address.
    Source address is always assigned to the interface used to
    transmit the packet.
 All of the routing/interface selection decisions are based on the
 netpolicy and not just on the destination address to avoid the issue
 of overlapping private IPv4 addresses.  This also allows multiple
 interfaces to be configured with the same IP address, for example, to
 handle certain tunneling scenarios.  Applications that do not specify
 a netpolicy are routed by AMSS to the best possible interface using
 the default netpolicy.  Default netpolicy could be pre-defined or
 provisioned by the administrator or operator.  Hence, the default
 interface could vary from device to device and also depends upon the
 available networks at any given time.
 AMSS allows each interface to be configured with its own set of DNS
 configuration parameters (e.g., list of DNS servers, domain names,
 etc.).  The interface selected to make a DNS resolution is the one to
 which the application making the DNS query is bound.  Applications
 can also specify a different netpolicy as part of the DNS request to
 select another interface for DNS resolution.  Regardless, all the DNS
 queries are sent only over this selected interface using the DNS
 configuration from the interface.  DNS resolution is first attempted
 with the primary server configured in the interface.  If a response
 is not received, the queries are sent to all the other servers
 configured in the interface in a sequential manner using a backoff
 mechanism.

3.1.6. Leadcore Technology Arena

 Arena, a mobile OS based on Linux, provides a connection manager,
 which is described in [MIF-ARENA] and [MIF-REQS].  The Arena
 connection manager provides a means for applications to register
 their connectivity requirement.  The connection manager can then
 choose an interface that matches the application's needs while

Wasserman & Seite Informational [Page 13] RFC 6419 MIF Current Practices November 2011

 considering other factors such as availability, cost, and stability.
 Also, the connection manager can handle multiple-interface issues
 such as connection sharing.

3.2. Desktop Operating Systems

 Multiple-interface issues also occur in desktop environments in those
 cases where a desktop host has multiple (logical or physical)
 interfaces connected to networks with different reachability
 properties, such as one interface connected to the global Internet,
 while another interface is connected to a corporate VPN.

3.2.1. Microsoft Windows

 The multiple-interface functionality currently implemented in
 Microsoft Windows operation systems is described in more detail in
 [MULTIHOMING].

3.2.1.1. First-Hop Selection

 It is possible, although not often desirable, to configure default
 routers on more than one Windows interface.  In this configuration,
 Windows will use the default route on the interface with the lowest
 routing metric (i.e., the fastest interface).  If multiple interfaces
 share the same metric, the behavior will differ based on the version
 of Windows in use.  Prior to Windows Vista, the packet would be
 routed out of the first interface that was bound to the TCP/IP stack,
 the preferred interface.  In Windows Vista, host-to-router load
 sharing [RFC4311] is used for both IPv4 and IPv6.

3.2.1.2. Outbound and Inbound Addresses

 If the source address of the outgoing packet has not been determined
 by the application, Windows will choose from the addresses assigned
 to its interfaces.  Windows implements [RFC3484] for source address
 selection in IPv6 and, in Windows Vista, for IPv4.  Prior to Windows
 Vista, IPv4 simply chose the first address on the outgoing interface.
 For incoming packets, Windows will check if the destination address
 matches one of the addresses assigned to its interfaces.  Windows has
 implemented the weak host model [RFC1122] on IPv4 in Windows 2000,
 Windows XP, and Windows Server 2003.  The strong host model became
 the default for IPv4 in Windows Vista and Windows Server 2008;
 however, the weak host model is available via per-interface
 configuration.  IPv6 has always implemented the strong host model.

Wasserman & Seite Informational [Page 14] RFC 6419 MIF Current Practices November 2011

3.2.1.3. DNS Configuration

 Windows largely relies on suffixes to solve DNS resolution issues.
 Suffixes are used for four different purposes:
 1.  DNS Suffix Search List (aka domain search list): suffix is added
     to non-FQDNs (Fully Qualified Domain Names).
 2.  Interface-specific suffix list: allows sending different DNS
     queries to different DNS servers.
 3.  Suffix to control Dynamic DNS Updates: determines which DNS
     server will receive a dynamic update for a name with a certain
     suffix.
 4.  Suffix in the Name Resolution Policy Table [NRPT]: aids in
     identifying a namespace that requires special handling (feature
     available only after Windows 7 and its server counterpart,
     Windows Server 2008 R2).
 However, this section focuses on the interface-specific suffix list
 since it is the only suffix usage in the scope of this document.
 DNS configuration information can be host-wide or interface specific.
 Host-wide DNS configuration is input via static configuration or, in
 sites that use Active Directory, Microsoft's Group Policy.
 Interface-specific DNS configuration can be input via static
 configuration or via DHCP.
 The host-wide configuration consists of a primary DNS suffix to be
 used for the local host, as well as a list of suffixes that can be
 appended to names being queried.  Before Windows Vista and Windows
 Server 2008, there was also a host-wide DNS server list that took
 precedence over per-interface DNS configuration.
 The interface-specific DNS configuration comprises an interface-
 specific suffix list and a list of DNS server IP addresses.
 Windows uses a host-wide "effective" server list for an actual query,
 where the effective server list may be different for different names.
 In the list of DNS server addresses, the first server is considered
 the "primary" server, with all other servers being secondary.
 When a DNS query is performed in Windows, the query is first sent to
 the primary DNS server on the preferred interface.  If no response is
 received in one second, the query is sent to the primary DNS servers
 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

Wasserman & Seite Informational [Page 15] RFC 6419 MIF Current Practices November 2011

 servers on the DNS server lists for all interfaces under
 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
 for a response.

3.2.2. Linux and BSD-Based Operating Systems

3.2.2.1. First-Hop Selection

 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 that 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, and 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 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-interface 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 management of complex
 situations such as address space overlapping.  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 that belongs to the same subnet as the destination
 address or the next-hop router.

Wasserman & Seite Informational [Page 16] RFC 6419 MIF Current Practices November 2011

 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 and 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
 the configuration of interface-specific information (such as an IP
 address and netmask) and a set of system-wide configuration
 information (such a DNS server list, an NTP server list, and default
 routes).  Users of these operating systems have the choice of using
 any DHCP client available for their platform with an operating system
 default.  This section discusses the behavior of several DHCP clients
 that may be used with Linux and BSD distributions.
 The Internet Systems Consortium (ISC) DHCP Client [ISCDHCP] and its
 derivative for OpenBSD [OPENBSDDHCLIENT] can be configured with
 specific instructions for each interface.  However, 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, such as the default routes
 and the DNS server list (in /etc/resolv.conf) with the most recent
 information received.  Therefore, the last configured interface
 always become the primary one.  The ISC DHCPv6 client behaves
 similarly.  However, OpenBSD provides two mechanisms that prevent the
 configuration that the user made manually from being overwritten:
 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: this 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
 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

Wasserman & Seite Informational [Page 17] RFC 6419 MIF Current Practices November 2011

 interface.  However, the -R flag can be used to instruct the client
 to not replace the DNS servers in /etc/resolv.conf.  However, this
 flag is a global flag for the DHCP server and is therefore applicable
 to all interfaces.  When dhcpd is called with the -R flag, the DNS
 servers are never replaced.
 The pump client [PUMP] also behaves similarly to the ISC client.  It
 replaces the DNS servers in /etc/resolv.conf and the default routes
 each time new DHCP information is received on any interface.
 However, the nodns and nogateway options can be specified on a per-
 interface basis, enabling the user to define which interface should
 be used to obtain the global configuration information.
 The udhcp client [UDHCP] is often used in embedded platforms based on
 busybox.  The udhcp client behaves similarly to the ISC client.  It
 rewrites default routes and the DNS server list each time new DHCP
 information is received.
 Red Hat-based distributions, such as Red Hat, Centos, and Fedora have
 a per-interface configuration option (PEERDNS) that indicates that
 the DNS server list should not be updated based on configuration
 received on that interface.
 Most configurable DHCP clients can be set to define a primary
 interface; only that interface is used for the global configuration
 data.  However, this is limited, since a mobile host might not always
 have the same set of interfaces available.  Connection managers may
 help in this situation.
 Some distributions also have a connection manager.  However, most
 connection managers serve as a GUI to the DHCP client and therefore
 do not change the functionality described above.

4. Acknowledgements

 The authors of this document would like to thank following people for
 their input and feedback: Dan Wing, Hui Deng, Jari Arkko, Julien
 Laganier, and Steinar H. Gunderson.

5. Security Considerations

 This document describes current operating system implementations and
 how they handle the issues raised in the MIF problem statement.
 While it is possible that the currently implemented mechanisms
 described in this document may affect the security of the systems
 described, this document merely reports on current practice.  It does
 not attempt to analyze the security properties (or any other
 architectural properties) of the currently implemented mechanisms.

Wasserman & Seite Informational [Page 18] RFC 6419 MIF Current Practices November 2011

6. Contributors

 The following people contributed most of the per-operating system
 information found in this document:
 o  Marc Blanchet, Viagenie
 o  Hua Chen, Leadcore Technology, Ltd.
 o  Yan Zhang, Leadcore Technology, Ltd.
 o  Shunan Fan, Huawei Technology
 o  Jian Yang, Huawei Technology
 o  Gabriel Montenegro, Microsoft Corporation
 o  Shyam Seshadri, Microsoft Corporation
 o  Dave Thaler, Microsoft Corporation
 o  Kevin Chin, Microsoft Corporation
 o  Teemu Savolainen, Nokia
 o  Tao Sun, China Mobile
 o  George Tsirtsis, Qualcomm
 o  David Freyermuth, France Telecom
 o  Aurelien Collet, Altran
 o  Giyeong Son, RIM

7. References

7.1. Normative References

 [RFC6418]     Blanchet, M. and P. Seite, "Multiple Interfaces and
               Provisioning Domains Problem Statement", RFC 6418,
               November 2011.

7.2. Informative References

 [ANDROID]     Google Inc., "Android developers: package android.net",
               <http://developer.android.com/reference/android/net/
               ConnectivityManager.html>.

Wasserman & Seite Informational [Page 19] RFC 6419 MIF Current Practices November 2011

 [ANDROID-RFC3484]
               Gunderson, S., "RFC 3484 support for Android", 2010,
               <http://gitorious.org/0xdroid/bionic/commit/
               9ab75d4cc803e91b7f1b656ffbe2ad32c52a86f9>.
 [BLACKBERRY]  Research In Motion Limited, "BlackBerry Java
               Development Environment - Fundamentals Guide: Wireless
               gateways", <http://na.blackberry.com/eng/
               deliverables/5827/Wireless_gateways_447132_11.jsp>.
 [ISCDHCP]     Internet Software Consortium, "ISC DHCP",
               <http://www.isc.org/software/dhcp>.
 [MIF-ARENA]   Zhang, Y., Sun, T., and H. Chen, "Multi-interface
               Network Connection Manager in Arena Platform", Work
               in Progress, February 2009.
 [MIF-REQS]    Yang, J., Sun, T., and S. Fan, "Multi-interface
               Connection Manager Implementation and Requirements",
               Work in Progress, March 2009.
 [MULTIHOMING] Montenegro, G., Thaler, D., and S. Seshadri, "Multiple
               Interfaces on Windows", Work in Progress, March 2009.
 [NRPT]        Davies, J., "Name Resolution Policy Table",
               February 2010, <http://technet.microsoft.com/en-
               us/magazine/ff394369.aspx>.
 [OPENBSDDHCLIENT]
               OpenBSD, "OpenBSD dhclient", <http://www.openbsd.org/>.
 [PHYSTECHDHCPC]
               Phystech, "dhcpcd",
               <http://www.phystech.com/download/dhcpcd.html>.
 [PUMP]        Red Hat, "PUMP", 2009, <http://redhat.com>.
 [RFC1122]     Braden, R., "Requirements for Internet Hosts -
               Communication Layers", STD 3, RFC 1122, October 1989.
 [RFC3484]     Draves, R., "Default Address Selection for Internet
               Protocol version 6 (IPv6)", RFC 3484, February 2003.
 [RFC4311]     Hinden, R. and D. Thaler, "IPv6 Host-to-Router Load
               Sharing", RFC 4311, November 2005.

Wasserman & Seite Informational [Page 20] RFC 6419 MIF Current Practices November 2011

 [S60]         Nokia Corporation, "S60 Platform: IP Bearer
               Management", 2007, <http://www.forum.nokia.com/info/
               sw.nokia.com/id/190358c8-7cb1-4be3-9321-f9d6788ecae5/
               S60_Platform_IP_Bearer_Management_v1_0_en.pdf.html>.
 [UDHCP]       Busybox, "uDHCP",
               <http://busybox.net/downloads/BusyBox.html>.
 [WINDOWSMOBILE]
               Microsoft Corporation, "SDK Documentation for Windows
               Mobile-Based Smartphones: Connection Manager", 2005,
               <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", April 2010, <http://msdn.microsoft.com/en-us/
               library/aa925716.aspx>.

Authors' Addresses

 Margaret Wasserman
 Painless Security, LLC
 356 Abbott Street
 North Andover, MA  01845
 USA
 Phone: +1 781 405-7464
 EMail: mrw@painless-security.com
 URI:   http://www.painless-security.com
 Pierrick Seite
 France Telecom - Orange
 4, rue du clos courtel BP 91226
 Cesson-Sevigne  35512
 France
 EMail: pierrick.seite@orange.com

Wasserman & Seite Informational [Page 21]

/data/webs/external/dokuwiki/data/pages/rfc/rfc6419.txt · Last modified: 2011/11/22 05:51 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki