Re: [mif] Updated charter

[Hui Deng <[e-mail]>]

It seems my browser gmail has some issue on this, redo , double space line
hope it works this time,
sorry,

-Hui

Charter for 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) Handling sets of network configuration objects by nodes, attached to
multiple networks: a solution could include a set of requirements for
changes to protocols used to provide configuration information. For
example:
- requirements for DHCPv6 options, Neighbor Discovery options etc. to
communicate association of the objects with particular
provisioning domains
- best practices for nodes how to group the configuration objects
into sets and use them for network connectivity
- APIs to expose the sets to the applications which require that
information

2) 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 provisioning
domains. For instance, these services could assist advanced
applications in having greater control over first-hop, source address
and/or DNS selection, interface selection, and PVD 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.

Nov 2013
Architecture draft adopted as the working group document

Dec 2013
Working group last call for MIF API document



2013/10/10 Hui Deng <[e-mail]>

> excuse me for adding some space lines between paragraphs
> thanks for your comments,
>
> -Hui
>
>
> Charter for 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) Handling sets of network configuration objects by nodes, attached to
> multiple networks: a solution could include a set of requirements for
> changes to protocols used to provide configuration information. For
> example:
> - requirements for DHCPv6 options, Neighbor Discovery options etc. to
> communicate association of the objects with particular
> provisioning domains
> - best practices for nodes how to group the configuration objects
> into sets and use them for network connectivity
> - APIs to expose the sets to the applications which require that
> information
> 2) 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 provisioning
> domains. For instance, these services could assist advanced
> applications in having greater control over first-hop, source address
> and/or DNS selection, interface selection, and PVD 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.
>
>  Nov 2013
> Architecture draft adopted as the working group document
>
> Dec 2013
> Working group last call for MIF API document
>
>
>>
>