Multiple Interfaces (mif)
-------------------------

 Charter
 Last Modified: 2010-11-23

 Current Status: Active Working Group

 Chair(s):
     Margaret Wasserman  <mrw@lilacglade.org>
     Hui Deng  <denghui02@hotmail.com>

 Internet Area Director(s):
     Ralph Droms  <rdroms.ietf@gmail.com>
     Jari Arkko  <jari.arkko@piuha.net>

 Internet Area Advisor:
     Jari Arkko  <jari.arkko@piuha.net>

 Mailing Lists: 
     General Discussion:mif@ietf.org
     To Subscribe:      https://www.ietf.org/mailman/listinfo/mif
     Archive:           http://www.ietf.org/mail-archive/web/mif

Description of Working Group:

Many hosts have the ability to attach to multiple networks
simultaneously. This can happen over multiple physical network
interfaces, a combination of physical and virtual interfaces (VPNs or
tunnels), or even indirectly through multiple default routers being on
the same link. For instance, current laptops and smartphones typically
have multiple access network interfaces.

A host attached to multiple networks has to make decisions about default
router selection, address selection, DNS server selection, choice of
interface for packet transmission, and the treatment of configuration
information received from the various networks. Some configuration
objects are global to the node, some are local to the interface, and
some are related to a particular prefix. Various issues arise when
contradictory configuration objects that are global to the node are
received on different interfaces. At best, decisions about these matters
have an efficiency effect. At worst, they have more significant effects
such as security impacts, or even lead to communication not being
possible at all.

A number of operating systems have implemented various techniques to
deal with attachments to multiple networks. Some devices employ only one
interface at a time and some allow per-host configuration of preferences
between the interfaces but still use just one at a time. Other systems
allow per-application preferences or implement sophisticated policy
managers that can be configured by users or controlled externally.

The purpose of the MIF working group is to describe the issues of
attaching to multiple networks on hosts and document existing practice.
The group shall also analyze the impacts and effectiveness of these
existing mechanisms. The WG shall employ and refer to existing IETF work
in this area, including, for instance, strong/weak models (RFC 1122),
address selection (RFC 3484), ICE and other mechanisms higher layers can
use for address selection, DHCP mechanisms, Router Advertisement
mechanisms, and DNS recommendations. The focus of the working group
should be on documenting the system level effects to host IP stacks and
identification of gaps between the existing IETF recommendations and
existing practice. After completing some of its initial goals in 2010 the
group is also developing three specific extensions:

1) DNS server selection solution: a specification for describing a way
for a network to communicate to nodes information required to perform
advanced DNS server selection at name resolution request granularity
in scenarios involving multiple namespaces. The specification shall
describe the information to be delivered for nodes and the protocol to
be used for delivery.

2) DHCPv6 routing configuration: DHCPv6 routing configuration: a
specification of DHCPv6 options allowing to provision client nodes
with small amount of static routing information (e.g. regarding
first-hop selection). This is an additional mechanism to the one
already defined in RFC 4191 to enable per-host configuration in a
managed network environment. The development of dynamic routing
capabilities or ability to send more than a few specific routes are
explicitly outside the scope of work in this working group, and
require the use of either existing or new routing protocols.

3) MIF API: While no changes are needed for applications to run on
multiple interface hosts, a new API could provide additional services
to applications running on hosts attached to multiple provisioning
domains. For instance, these services could assist advanced
applications in having greater control over first-hop, source address
and/or DNS selection issues. This API will be defined as an abstract
interface specification, i.e., specific details about mapping to
operating system primitives or programming language will be left out.

Network discovery and selection on lower layers as defined by RFC 5113
is out of scope. With the exception of support for additional DHCP
options in DHCP servers, group shall not assume any software beyond
basic IP protocol support on its peers or in network nodes. No work
will be done to enable traffic flows to move from one interface to
another. The group recognizes existing work on mechanisms that require
peer or network support for moving traffic flows such as RFC 5206, RFC
4980 and the use of multiple care-of addresses in Mobile IPv6. This
group does not work on or impact such mechanisms.

Future work in this area requires rechartering the working group or
asking other, specialized working groups (such as DHC or 6MAN) to deal
with specific issues.

 Goals and Milestones:

   Done         WG chartered 

   Done         Initial draft on problem statement adopted by the WG 

   Done         Initial draft on existing practices adopted by the WG 

   Done         Initial draft on analysis of existing practices adopted by the 
                WG 

   Done         Problem statement draft submitted to the IESG for publication 
                as an Informational RFC 

   Done         Existing practices draft submitted to the IESG for publication 
                as an Informational RFC 

   Dec 2010       Initial WG draft on DHCPv6 option for routing configuration 

   Jan 2011       Analysis draft submitted to the IESG for publication as an 
                Informational RFC 

   Jan 2011       Initial WG draft on advanced DNS server selection solution 

   Jan 2011       Initial WG draft on MIF API extension 

   Mar 2011       Submit MIF API extension solution to IESG for publication as an 
                Informational RFC 

   Jun 2011       Submit DHCPv6 routing configuration option to IESG for 
                publication as a Proposed Standard RFC 

   Nov 2011       Submit advanced DNS server selection solution to IESG for 
                publication as a Proposed Standard RFC 


 Internet-Drafts:

Posted Revised         I-D Title   <Filename>
------ ------- --------------------------------------------
Oct 2009 Mar 2011   <draft-ietf-mif-problem-statement-10.txt>
                Multiple Interfaces and Provisioning Domains Problem Statement 

Oct 2009 Feb 2011   <draft-ietf-mif-current-practices-08.txt>
                Current Practices for Multiple Interface Hosts 

Jan 2011 Mar 2011   <draft-ietf-mif-dhcpv6-route-option-01.txt>
                DHCPv6 Route Option 

Jan 2011 Mar 2011   <draft-ietf-mif-dns-server-selection-01.txt>
                Improved DNS Server Selection for Multi-Homed Nodes 

 Request For Comments:

  None to date.