[secdir] [new-work] WG Review: Multiple Interfaces (mif)

[The IESG <[e-mail]>]

The Multiple Interfaces (mif) working group in the Internet Area of the
IETF is undergoing rechartering. The IESG has not made any determination
yet. The following draft charter was submitted, and is provided for
informational purposes only. Please send your comments to the IESG
mailing list (iesg at ietf.org) by 2013-12-16.

Multiple Interfaces (mif)
------------------------------------------------
Current Status: Active WG

Chairs:
  Margaret Wasserman <[e-mail]>
  Hui Deng <[e-mail]>

Assigned Area Director:
  Ted Lemon <[e-mail]>

Mailing list
  Address: [e-mail]
  To Subscribe: https://www.ietf.org/mailman/listinfo/mif
  Archive: http://www.ietf.org/mail-archive/web/mif

Charter:

Nodes attached to multiple networks may encounter problems due to
conflict of network configuration information and/or simultaneous use of
the multiple available networks. 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.
 
The MIF problem statement document [RFC6418] enumerates the problems 
into 3 categories:
1. Lack of consistent and distinctive management of configuration
elements, associated with different networks.
2. Inappropriate mixed use of configuration elements, associated with
different networks, in the course of a particular network activity /
connection.
3. Use of a particular network, not consistent with the intent of the
scenario / involved parties, leading to connectivity failure and / or
other undesired consequences.
 
The purpose of the MIF working group is to describe the architecture
detailing how devices attach to and operate in multiple networks. The
group shall also analyze how applications can be influenced by these
existing mechanisms. The WG shall employ and refer to existing IETF work
in this area, including, for instance, strong/weak models (RFC 1122),
default address selection (RFC 6724), 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. Having completed some of its
initial goals the group is also developing the following:
 
1. An incrementally deployable architecture, defining a consistent
approach and recommended practices for handling sets of network
configuration objects by hosts, attached to multiple networks, which
enable hosts to improve network connectivity for the host's applications
and users.   Each of these sets of network configuration objects is
referred to collectively as a provisioning domain (PVD).

2. A set of requirements for changes  to or the uses of protocols, that
provide network configuration  information, to enable improved handling
of multiple sets of network configuration in networks and hosts. For
example, requirements for DHCPv6 options, Neighbor Discovery options 
etc. to communicate association of the configuration information with
particular networks.

3. In cooperation with other working groups, uses of existing protocols
in accordance with the requirements produced under item 2. Any changes 
of function of protocols are out of scope.

4. A MIF API: While no changes are required for applications to run on
multiple interface hosts, a new API could provide additional services to
applications running on hosts attached to multiple networks. For
instance, these services could assist advanced applications in having
greater control over first-hop, source address and/or DNS resolver,
interface and other network configuration element selection. This API
will be defined as an abstract interface specification.   That is,
specific details about mapping to operating system primitives or
programming languages will be left out, and the API will not be 
specified in terms of familiar APIs (e.g., "BSD sockets API").   In 
addition to the new API, the behavior of existing APIs may be changed to 
improve the behavior of unmodified applications.

5. Guidelines to applications, to provide an improved connectivity
experience when the host is attached to multiple networks or there is a
change in the set of networks the host is attached to, e.g., via MIF API
usage.

6.  The MIF working group will document either as part of the MIF API
specification, as part of the MIF architecture document, or in a 
separate document, the issues and requirements for a high-level MIF user 
interface that would allow the user to exert control over how individual
applications or application roles make use of different provisioning
domains and network interfaces.

7. A specification for the format, generation and usage of PVD IDs.

Network discovery and selection on lower layers as defined by RFC 5113 
is out of scope. With the exception of identifying requirements for
additional DHCPv6 and/or ND options, as well as requirements for 
possible related changes in these protocols, the group shall not assume 
any software beyond basic IP protocol support on its peers or in network
hosts. 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.

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
_______________________________________________
new-work mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/new-work