Subject: [mif] charter, take 3

From: Jari Arkko <[email-masked]>
Date: Thu, 02 Apr 2009 21:49:23 +0200

Third version, incorporating feedback from Thierry, Danny, and Giyeong.

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

Multiple InterFaces (MIF)

Last Modified: 2009-04-02

Chair(s):
TBD

Internet Area Director(s):
Ralph Droms <[email-masked]>
Jari Arkko <[email-masked]>

Internet Area Advisor:
TBD

Mailing Lists:
General Discussion: [email-masked]
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 connect 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 connected 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 multiple interfaces. 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 
surrounding the use of multiple interfaces 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

---

From: "Yong-Geun Hong" <[email-masked]>
Date: Fri, 3 Apr 2009 10:30:04 +0900

Thanks your charter update.

Updated charter looks good to me.

Best regards.

Yong-Geun. 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Jari
> Arkko
> Sent: Friday, April 03, 2009 4:49 AM
> To: mif
> Subject: [mif] charter, take 3
> 
> _______________________________________________
> mif mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mif

---

From: Hui Deng <[email-masked]>
Date: Fri, 3 Apr 2009 16:40:29 +0800

I support the work of this chater.

-Hui

2009/4/3 Jari Arkko <[email-masked]>:
> Many hosts have the ability to connect 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 connected 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 multiple interfaces. 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 surrounding
> the use of multiple interfaces 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
> 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

---

From: Scott Brim <[email-masked]>
Date: Fri, 3 Apr 2009 09:54:30 -0400

The charter describes interactions as information is acquired.  What
about as information is used?  For example, a DNS lookup result ends
up losing its original context, and being decoupled from the interface
on which it was acquired, so it may be used on the wrong interface.
Do you think the charter covers this kind of issue already?  If not,
should it?

Scott

---

From: Marc Blanchet <[email-masked]>
Date: Fri, 03 Apr 2009 11:28:13 -0400

> Do you think the charter covers this kind of issue already?  If not,

well, it is (or should be if not complete) in the problem statement
draft currently.

Marc.

-- 
=========
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

---

From: Jari Arkko <[email-masked]>
Date: Fri, 03 Apr 2009 18:38:39 +0200

Scott,

> Do you think the charter covers this kind of issue already?  If not,

I believe it should be covered in the work. Can you suggest some 
specific wording change to the charter, if you think it is needed? But 
we need to leave room for the problem definition draft to say something, 
too :-)

Jari

---

From: Scott Brim <[email-masked]>
Date: Fri, 3 Apr 2009 12:51:42 -0400

> we need to leave room for the problem definition draft to say something,  

In looking at the charter to see where to include it, I have come to
believe that it is already included, although subtly.  I don't think
any change is necessary.  Thanks for listening.

Scott

---

From: Jari Arkko <[email-masked]>
Date: Fri, 03 Apr 2009 20:33:38 +0200

Ok, thanks.

Jari

---

From: <[email-masked]>
Date: Mon, 6 Apr 2009 14:21:24 +0200

Hi,

Also I support the work of this charter.

I hope we gather around this topic in Stockholm,

	Teemu 

>From: [email-masked] [mailto:[email-masked]] On 
>Behalf Of ext Jari Arkko
>Sent: 02 April, 2009 22:49
>To: mif
>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 
>A host connected 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 multiple interfaces. 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.
>
>surrounding the use of multiple interfaces 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
>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
>