The Multiple Interfaces (mif) working group in the Internet Area of the IETF has been rechartered. For additional information, please contact the Area Directors or the working group Chairs. Multiple Interfaces (mif) --------------------------------------------- Status: Active Working Group Last updated: 2010-11-18 Chairs: Margaret Wasserman <mrw@lilacglade.org> Hui Deng <denghui02@hotmail.com> Internet Area Directors: 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. 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 Nov 2011 Submit MIF API extension solution to IESG for publication as an Informational RFC _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
