[mif] MIF charter discussion

[Hui Deng <[e-mail]>]

Hello all

We plan to do charter update fully since it will need

Thanks Dmitry for editing the detail updates.

feel free to post your comments, thanks a lot

Best regards,

DENG Hui

--------------------------------------------------------------------------------------------

 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. After completing 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.

2. A set of requirements for changes to protocols, used to 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. 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, i.e., specific details about mapping to
operating system primitives or programming languages will be left out.
In addition to the new API, the behavior of existing APIs may be changed to
improve the behavior of unmodified applications.

4. Guidelines to applications on MIF API usage, 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.

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.