Re: [mif] WG Review: Multiple InterFaces (mif)

> Multiple InterFaces (mif)
> ------------------------------------------------
> Last Modified: 2009-04-20
I like this version of the charter very much.  I think it does a good 
job of capturing the area that we need to discuss within MIF.  I am 
hopeful that we can get our charter approved ASAP, so that we can begin 
working on the July milestone of producing a problem statement draft 
that is acceptable to the WG.  I think that much of the recent 
discussion about the charter will be great intput for the problem 
statement work.
Margaret
> Current Status: Proposed Working Group
>
> Chair(s):
> TBD
>
> Internet Area Director(s):
> Ralph Droms <rdroms(_at_)cisco(_dot_)com>
> Jari Arkko <jari(_dot_)arkko(_at_)piuha(_dot_)net>
>
> Internet Area Advisor:
> TBD
>
> Mailing Lists:
> General Discussion: mif(_at_)ietf(_dot_)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 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 multiple 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, document existing practice, 
> and make recommendations about best current practice. 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), 
> 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. The working group shall address both IPv4 and IPv6 
> as well as stateless and stateful configuration.
> Network discovery and selection on lower layers as defined by RFC 5113 
> is out of scope. Also, the group shall not develop new protocol or 
> policy mechanisms; recommendations and gap analysis from the group are 
> solely based on existing solutions. The 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.
> Once the group has completed its work items, the IETF can make an 
> informed decision about rechartering the working group to define new 
> mechanisms or asking other, specialized working groups (such as DHC or 
> 6MAN) to deal with specific issues.
> Milestones:
>
> May 2009 WG chartered
> July 2009 Initial draft on problem statement adopted by the WG
> September 2009 Initial draft on existing practices adopted by the WG
> Jan 2010 Initial best current practices draft adopted by the WG
> March 2010 Problem statement draft submitted to the IESG for 
> publication as an Informational RFC
> July 2010 Existing practices draft submitted to the IESG for 
> publication as an Informational RFC
> September 2010 Best current practices draft submitted to the IESG for 
> publication as a BCP
> October 2010 Recharter or close
>
> _______________________________________________
> mif mailing list
> mif(_at_)ietf(_dot_)org
> https://www.ietf.org/mailman/listinfo/mif
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf