Jari Arkko a écrit : > > This revision includes the removal of the BCP document. I am hoping that > also helps in other problems people had with this charter, as it becomes > even clearer that the WG will not develop solutions, its really only > about describing the problem and existing practices. Unrelated to your > comments, I also added a statement about app & transport aspects. Jari, I think by removing the BCP document, we are diminishing too much the scope of the wg. IETF does not have a good track record for PS-only wg... what about an informational document (instead of BCP) that would describe some possible ways to manage MIF without a new protocol? This would be an outcome after getting all the existing practices and have a discussion what are the best ways to solve (maybe scope limited/specific use cases) MIF issues without a new protocol. That work would be a good segway to protocol work, since we would know what the best we can do within what we have, and what needs to be done for new protocol work. Marc. > > Jari > > Multiple InterFaces (mif) > ------------------------------------------------ > Last Modified: 2009-04-23 > > Current Status: Proposed Working Group > > Chair(s): > TBD > > Internet Area Director(s): > Ralph Droms <rdroms@xxxxxxxxx> > Jari Arkko <jari.arkko@xxxxxxxxx> > > Internet Area Advisor: > TBD > > Mailing Lists: > General Discussion: mif@xxxxxxxx > 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 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. 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 > 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 > October 2010 Recharter or close > _______________________________________________ > mif mailing list > mif@xxxxxxxx > https://www.ietf.org/mailman/listinfo/mif -- ========= IPv6 book: Migrating to IPv6, Wiley. http://www.ipv6book.ca Stun/Turn server for VoIP NAT-FW traversal: http://numb.viagenie.ca DTN news service: http://reeves.viagenie.ca _______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf