Subject: Re: WG Review: Multiple InterFaces (mif)

From: Jari Arkko <[email-masked]>
Date: Sat, 18 Apr 2009 12:25:17 +0300

I wanted to bring up a comment that was raised during the IESG and IAB 
discussions about this charter by Adrian and others.

When the work started, it was clearly about multiple interfaces. Upon 
closer inspection, we have realized that the overall problem is somewhat 
larger. Problems that occur with multiple interfaces also occur even 
with one interface, when you have a number of default routers on the 
same link. The current charter text reflects this in some parts of the 
text, e.g.,

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

However, it was pointed out that the text is not consistent. Other parts 
still talk about multiple interfaces, e.g.,

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

This has created some confusion with regards to what really is in scope. 
Are hosts with multiple physical interfaces in scope (obviously yes)? 
Are hosts with multiple virtual or physical interfaces in scope (yes)? 
Are hosts with one interface but multiple connections to different 
networks in scope (I think they should be)? Are we only talking about 
multiple interfaces or connections when they are to different 
administrative domains (I do not think it really matters, even in one 
domain the parameters can be different)?

I would like to solicit suggestions on how to modify the text to be 
fully aligned. Note: we need to keep the name of the group the same, as 
it something that is already familiar to people, not to mention the fact 
that the IETF database system does not allow an acronym change very easily.

Would it be enough to change s/multiple interfaces/connections to 
multiple networks/ in the second quoted text excerpt?

Jari

---

From: Hui Deng <[email-masked]>
Date: Sat, 18 Apr 2009 19:03:08 +0800

Hi, Jari and all

It will be good to include that scenario, that scenario already exist
and haven't been covered by other working group at the moment.
Starting from changeing the working group full name looks like a feasible way.
please check comments inline started with ==>

2009/4/18 Jari Arkko <[email-masked]>:
> When the work started, it was clearly about multiple interfaces. Upon closer
> inspection, we have realized that the overall problem is somewhat larger.
> Problems that occur with multiple interfaces also occur even with one
> interface, when you have a number of default routers on the same link. The
> current charter text reflects this in some parts of the text, e.g.,
>
==> resolving the issue of multiple default routers in multiple
interfaces doesn't
really solve the issue of multiple default routers in one single interface.

> This has created some confusion with regards to what really is in scope. Are
> hosts with multiple physical interfaces in scope (obviously yes)? Are hosts
> with multiple virtual or physical interfaces in scope (yes)? Are hosts with
> one interface but multiple connections to different networks in scope (I
> think they should be)? Are we only talking about multiple interfaces or
> connections when they are to different administrative domains (I do not
> think it really matters, even in one domain the parameters can be
> different)?
==> I agree that hosts with one interface but multiple connections to
different networks in scope. This has been the scenarios of many
mobile network.
I also agree that not necessarily mention whether it is the same or
different administrative domains.

>
> I would like to solicit suggestions on how to modify the text to be fully
> aligned. Note: we need to keep the name of the group the same, as it
> something that is already familiar to people, not to mention the fact that
> the IETF database system does not allow an acronym change very easily.
>
> Would it be enough to change s/multiple interfaces/connections to multiple
> networks/ in the second quoted text excerpt?
==> changing the full name is the good way.
then charter could be modified correspondense.
"The purpose of the MIF working group is to describe the issues
of connecting to multiple networks on hosts, document existing
practice, and make recommendations about best current practice."

Thanks,

-Hui

>
> Jari
>
> _______________________________________________
> Ietf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf
>

---

From: "Giyeong Son" <[email-masked]>
Date: Mon, 20 Apr 2009 10:19:56 -0400

Hi all,

Jari seems to be using the term of "connection" in his emails as
"association between an interface and an (access) network". When I used
"connection" so far during email exchanges, I have used it as more
likely "routing or routable path for packet transmission" in an abstract
manner. I feel that different usage of the same word "connection" may
consequence confusion or misinterpretation to the audiences.

Therefore, it might be better to clarify it in terms of MIF so that
everybody can be in the same page without any confusion or
misinterpretation:-)

Giyeong

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Jari Arkko
Sent: April 18, 2009 5:25 AM
To: IETF Discussion
Cc: Adrian Farrel; mif
Subject: Re: [mif] WG Review: Multiple InterFaces (mif)

> 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 

I would like to solicit suggestions on how to modify the text to be
fully aligned. Note: we need to keep the name of the group the same, as
it something that is already familiar to people, not to mention the fact
that the IETF database system does not allow an acronym change very
easily.

Jari

_______________________________________________
mif mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mif

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

---

From: Jari Arkko <[email-masked]>
Date: Mon, 20 Apr 2009 22:51:24 +0300

> everybody can be in the same page without any confusion or

Yes -- this is indeed an issue. Let me see what I can come up with.

Jari

---

From: Jari Arkko <[email-masked]>
Date: Mon, 20 Apr 2009 23:14:23 +0300

Hui,

I'm not sure if I understood your comment about the WG name correctly. 
We cannot change it at this stage easily. So lets just keep it as is.

Please find below the full charter proposal, with the suggested changes 
folded in from you and others.

Jari

Multiple InterFaces (mif)
------------------------------------------------
Last Modified: 2009-04-20

Current Status: Proposed Working Group

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

---

From: Ted Hardie <[email-masked]>
Date: Mon, 20 Apr 2009 13:21:20 -0700

>We cannot change it at this stage easily. So lets just keep it as is.

Huh?  Why on earth is it hard?  Strings are cheap.

Not that I care much about this, but having been in many a working
group name change (hi, DRINKS folks!), I don't know what has changed
to make this hard. 

				Ted

---

From: Jari Arkko <[email-masked]>
Date: Mon, 20 Apr 2009 23:36:12 +0300

Ted,

> Huh?  Why on earth is it hard?  Strings are cheap.

On some previous WG creation exercise I was told that once the WG 
creation process is in the IETF's database system, the WG acronym cannot 
be changed, you can delete it and create a new one, but you cannot the 
acronym. Of course, I could create a new one and ask it to be brought to 
the right state... hopefully without having to re-do any real-life 
steps, like announcements going out or the topic being on the IESG 
telechat. This might work, but I'd have to investigate further to ensure 
that it actually is possible. If it was the only problem I would.

The other problem is that people may already recognize the name. And I 
don't have a nice replacement acronym in mind. Multple Interfaces is a 
very concrete description of the problem, even if its not the most 
generic one. Multiple Attachments to Networks (MAN, but too close to 
6MAN), Connections to Multiple Networks (CMN, a bit boring), etc. But 
its too late in the day here to be creative. I'm sure someone sends the 
coolest acronym in reply :-)

Bottom line: not impossible, but requires some effort.

Jari

---

From: Keith Moore <[email-masked]>
Date: Mon, 20 Apr 2009 17:11:00 -0400

It seems to me that the general problem is not multiple interfaces, but
multiple addresses per host.  It doesn't matter (much) whether those
addresses result from multiple physical interfaces, a combination of
physical and virtual network interfaces, multiple prefixes being
advertised on the network attached to any particular interface, or even
a mixture of v4 and v6.

So that might have some impact on the name, particularly if you want to
attract the breadth of interests whom this affects.  Something like
Hosts Addressed Multiply (HAM), perhaps?

Keith

p.s. and if the software can't deal with changing a wg name before it's
chartered, seems like that should result in a change request for the
software.  we really want to resist having our tools make the rules by
which we operate, rather than the other way around.

---

From: George Tsirtsis <[email-masked]>
Date: Mon, 20 Apr 2009 22:21:35 +0100

Keith,

I think this (multiple IP addresses) is one issue this WG seems to
want to deal with.
Another one is the availability of multiple paths (next hop routers)
for a given destination.

It seems indeed that whether the source addresses, and even the
paths/routes, are over different physical interfaces or not, is
somewhat secondary.

There is, however, significance in the presence of different
interfaces in a given non-router node...I do not think either of the
other two points (multiple IFs, multiple routes) should be lost
completely in the effort to widen/clarify the charter.

George
P.S.: It would be kind of funny to figure out that this WG really has
nothing to do with Multiple IFs, and yet maintain the MIF name... it
would enhance the already obscure tradition of nonsensical terms like
BOFs, RFCs etc ..not to mention other rather funny WG names :-)

---

From: Sam Hartman <[email-masked]>
Date: Mon, 20 Apr 2009 18:08:40 -0400

>>>>> "Keith" == Keith Moore <[email-masked]> writes:

    Keith> It seems to me that the general problem is not multiple
    Keith> interfaces, but multiple addresses per host.  It doesn't
    Keith> matter (much) whether those addresses result from multiple
    Keith> physical interfaces, a combination of physical and virtual
    Keith> network interfaces, multiple prefixes being advertised on
    Keith> the network attached to any particular interface, or even a
    Keith> mixture of v4 and v6.

    Keith> So that might have some impact on the name, particularly if
    Keith> you want to attract the breadth of interests whom this
    Keith> affects.  Something like Hosts Addressed Multiply (HAM),
    Keith> perhaps?

I'd actually appreciate focus on the multiple interfaces (or multiple
network providers) problem.  I think that attacking this in full
generality is well beyond what we can manage.  I think even a focused
problem may prove challenging.

---

From: Keith Moore <[email-masked]>
Date: Mon, 20 Apr 2009 18:24:38 -0400

> problem may prove challenging.

I certainly agree that it's challenging to attack the generalized
version.  However, if you try to solve each version of this problem
separately, the result will be even more complex, less workable, and
less realistic than if you try to look at it from a broader view.
There's a strong potential for those different solutions to collide with
one another.

Or to put it another way, if you define a solution to a narrow version
of the problem, it might not actually solve anything in the real world,
and the WG's work will have been wasted.

And from the POV of the application, or the transport layer, it really
doesn't matter much _why_ the host (or peer) has multiple addresses - it
still has to deal with them.

As for whether "attacking this in full generality is well beyond what we
can manage":  Based on previous work that I have done in this area, I
suspect that this is exactly the case.   Which is why I think that it
should be reasonable for the WG to look at the problem and come back and
say "we haven't identified a good solution to this problem, and the best
practices that we can recommend are to minimize the cases where a host
or app has to deal with multiple addresses for itself or its peers".

Of course, a better result would be for the WG to say "we recommend that
 the use of multiple addresses per host be limited to these specific
cases, and avoided in other cases"... along with specific
recommendations for networks, stacks, APIs, applications, etc.  I think
that this kind of output would be the most useful that the WG could
produce.  But it won't be able to produce a reasonable output if it
looks at the problem through a narrow aperture.

(Maybe this should really be in IRTF?)

Keith

---

From: "David W. Hankins" <[email-masked]>
Date: Mon, 20 Apr 2009 15:26:34 -0700

> problem may prove challenging.

I'm not sure if this agrees or disagrees with your view;

I think the problem being skirted, and the one that needs resolution,
is any situation where a host receives configuration from two
different administrative domains it straddles, regardless of
mechanism.

A single administrative domain that wishes to present inconsistent
configuration seems like a problem that can be solved by having the
domain present itself as two (or more).

At present, and core to the problem of IPv6 casual interconnection
security, there are no mechanisms for network related configuration
to identify its source domain.  This suggests interim solutions that
attempt to divine a unique source domain, and the algorithm(s) to
digest configuration across domains, as well as long-term experiments
(?) to seek concise advertisements of a given configuration's source
domain.

-- 
David W. Hankins	"If you don't do it right the first time,
Software Engineer		     you'll just have to do it again."
Internet Systems Consortium, Inc.		-- Jack T. Hankins

---

From: Hui Deng <[email-masked]>
Date: Tue, 21 Apr 2009 18:42:33 +0800

Hi, Jari,

What I suggest is like the below:

> Connections to Multiple Networks (mif)

thanks

-Hui
2009/4/21 Jari Arkko <[email-masked]>:
> Hui,
>
> I'm not sure if I understood your comment about the WG name correctly. We
> cannot change it at this stage easily. So lets just keep it as is.
>
> 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.
>
> 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
> 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
> 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: Jari Arkko <[email-masked]>
Date: Tue, 21 Apr 2009 13:57:13 +0300

Keith,

> There's a strong potential for those different solutions to collide with

Indeed. And I want to remind everyone that this charter is only about 
_problem definition_ and _documentation of existing solutions_, not 
about development of new solutions. The scope at this stage needs to be 
large, even if we later find out that we need to or can develop a 
specific extension of, say, DHCP. At that point the group can focus on a 
narrow aspect, or perhaps even be moved to existing WGs. But we are not 
in that stage yet.

> looks at the problem through a narrow aperture.

Yes.

> (Maybe this should really be in IRTF?)

I think the proposed scope fits very nicely to IETF: we are documenting 
what the problem is and what various real-world implementations have 
done about it.

(If we later decide that the real-world techniques are lacking and want 
to develop a magical solution that solves this problem in all 
situations, then it is probably a good idea to start a research 
project... but we are not there yet.)

Jari

---

From: Hui Deng <[email-masked]>
Date: Tue, 21 Apr 2009 19:37:48 +0800

Margaret created the name of "MIF" orginally, maybe she has some other thoughts?
like "MAIN" "MAD"

-Hui

2009/4/21 Jari Arkko <[email-masked]>:
> On some previous WG creation exercise I was told that once the WG creation
> process is in the IETF's database system, the WG acronym cannot be changed,
> you can delete it and create a new one, but you cannot the acronym. Of
> course, I could create a new one and ask it to be brought to the right
> state... hopefully without having to re-do any real-life steps, like
> announcements going out or the topic being on the IESG telechat. This might
> work, but I'd have to investigate further to ensure that it actually is
> possible. If it was the only problem I would.
>
> The other problem is that people may already recognize the name. And I don't
> have a nice replacement acronym in mind. Multple Interfaces is a very
> concrete description of the problem, even if its not the most generic one.
> Multiple Attachments to Networks (MAN, but too close to 6MAN), Connections
> to Multiple Networks (CMN, a bit boring), etc. But its too late in the day
> here to be creative. I'm sure someone sends the coolest acronym in reply :-)
>

---

From: Jari Arkko <[email-masked]>
Date: Tue, 21 Apr 2009 14:40:54 +0300

There has been some discussion on whether the key issue is merging 
configuration from multiple sources (the "DHCP view"), multiple 
interfaces (the "original view"), multiple default routers (the "routing 
view"), multiple addresses (the "IP layer view"), multiple 
administrative domains (the "operational view"), and so on.

I would like to make the point that there is no single, perfect answer. 
Its easy to find examples where the key issues above do not capture 
everything that we want to capture (see, e.g., George's response to 
Keith). Its really about the combination of these issues. And I think 
that is the way it should be.

The charter text that I sent out yesterday attempts to explain what the 
problem space is without prejudicing ourselves to a view from just one 
perspective (except perhaps through the group's acronym). I think the 
rest is work on the problem statement, and we should let the group write 
that.

The IESG telechat where this could be approved is two days away. Does 
someone have a big problem with the charter as written, serious enough 
to warrant a change?

Jari

---

From: Scott Brim <[email-masked]>
Date: Tue, 21 Apr 2009 07:55:35 -0400

> someone have a big problem with the charter as written, serious enough  

I think it's just about right.  It includes scenarios where an
endpoint gets information from multiple apparent sources, and does not
mention that it might be getting complex information from a single
source.  That's good.

---

From: Sam Hartman <[email-masked]>
Date: Tue, 21 Apr 2009 08:00:06 -0400

Keith, I've considered your points and continue to disagree.  I'm
mostly replying in the interest of judging consensus.

I believe that the primary use cases identified in the MIF BOF are use
cases that are not going to go away.  I think that saying "avoid
multiple addresses" is likely to be the same kind of head-in-sand
thinking that caused us to get where we are today with a number of
areas where there is a disconnect between what the market wants and
what we're willing to include in our engineering model.

Yes, the results of delivering what the market wants may be more
complicated than our conceptually pure model.  It will be less
complicated and work better than ignoring the problem and letting the
market come up with something.

So, I'd prefer to make sure that our problem analysis is narrow enough
that we're more likely to come up with an answer as useless as "don't
do that."  We may get an answer of "here are the issues to consider,
here are points on a spectrum and the problems we introduce," but I
think we can only do that if we limit the scope somewhat.

---

From: Sam Hartman <[email-masked]>
Date: Tue, 21 Apr 2009 08:05:56 -0400

>>>>> "David" == David W Hankins <[email-masked]> writes:

    David> On Mon, Apr 20, 2009 at 06:08:40PM -0400, Sam Hartman wrote:
    >> I'd actually appreciate focus on the multiple interfaces (or
    >> multiple network providers) problem.  I think that attacking
    >> this in full generality is well beyond what we can manage.  I
    >> think even a focused problem may prove challenging.

    David> I'm not sure if this agrees or disagrees with your view;

    David> I think the problem being skirted, and the one that needs
    David> resolution, is any situation where a host receives
    David> configuration from two different administrative domains it
    David> straddles, regardless of mechanism.

Well put.

    David> A single administrative domain that wishes to present
    David> inconsistent configuration seems like a problem that can be
    David> solved by having the domain present itself as two (or
    David> more).

This is the sort of thing I'd like to see out of scope for the MIF
working group.  I'd also like to see source address selection within a
domain including cases like choosing between ULAs and global prefixes
within a domain, route selection within a domain, etc all ruled out of
scope.

---

From: Keith Moore <[email-masked]>
Date: Tue, 21 Apr 2009 09:19:33 -0400

> different administrative domains it straddles, regardless of

While I certainly admit that this is part of the problem, I don't know
why this is _the_ distinguished problem that needs resolution.  I can
certainly identify several others.

> domain present itself as two (or more).

How does this actually solve the problem?  To me it seems like it
glosses over it.  It certainly doesn't make the application writer's
task any easier.

> (?) to seek concise advertisements of a given configuration's source

Certainly agree that network configuration information received from one
 domain should not be applied to another domain.  And a host should not
be expected, as an architectural matter, to be bound by the
configuration information received from one of its interfaces, except
with respect to traffic sent over that interface.

But I thought this was obvious, so maybe I don't see what you're getting at.

Keith

---

From: Keith Moore <[email-masked]>
Date: Tue, 21 Apr 2009 09:25:27 -0400

> what we're willing to include in our engineering model.

Please note that there is a subtle but important difference between
saying "avoid multiple interfaces" and "don't do that under any
circumstances".  Maybe "avoid" is too strong a word and I should have
used "discourage".  I agree that the problems presented by multiple
addresses per host are unlikely to go away.  They are being driven by
several independent factors.

At the same time it needs to be made clear that adding addresses to a
host does come with a cost, and (e.g.) network admins who wish to solve
problems by adding prefixes to their networks (whether this be for
multihoming or interconnection with private networks or whatever) need
to consider the impact that this will have on applications.

I still don't think that we need to consider this problem from only one
angle.  If we do that we will get a solution that only makes sense from
one angle.

Keith

---

From: Jari Arkko <[email-masked]>
Date: Tue, 21 Apr 2009 16:45:02 +0300

Sam,

> We may get an answer of "here are the issues to consider,
> think we can only do that if we limit the scope somewhat

Point taken. But can you bring that to a concrete level by stating if 
something needs to change or be removed from the scope as defined by the 
charter? I'm including the latest charter proposal below for your 
convenience.

Please remember that this charter and initial scope of the WG involves 
description of the problem and existing solutions; I do agree that if 
and when we ever get to developing a new solution, significant scope 
reduction seems likely.

Jari

Chair(s):
TBD

Internet Area Advisor:
TBD

Mailing Lists:

Milestones:

May 2009 WG chartered

---

From: Keith Moore <[email-masked]>
Date: Tue, 21 Apr 2009 10:15:14 -0400

> someone have a big problem with the charter as written, serious enough

1. I really think that the emphasis on "attachment to multiple networks"
is too narrow, as this is far from the only source of the problem.  As
long as the WG is just trying to understand the problem and identify
existing solutions, it seems appropriate to broaden the scope to
consider the more general problem of multiple addresses per host.

2. I also think that, when considering the effect on applications, it
needs to be explicitly pointed out that p2p and distributed apps need to
be considered separately from client-server apps that many people regard
as representative.

More generally I think that various kinds of effects need to be
considered (i.e. not just the effects on applications) and it would be
very helpful if the charter could lists some examples of these as
illustrations of the breadth of scope.  That would minimize the
potential for the WG to start off with many participants thinking "_the_
problem is X" when the actual problem is much broader.... and hopefully
get the WG in the mode where it tries to enumerate the various problems
and impacts rather than to try to nail down _which_ problem it is and
ignore the others.

3. I am a bit concerned by the charter's mentioning of BCP documents as
a possible output from the WG.  I thought I had seen language in the
charter text saying that the group should write a BCP, but either I was
mistaken or that language has since been removed.  But there's still a
BCP mentioned as a deliverable in the milestones.  My concern is that
the WG will take this as license to try to define best current practice,
which I think is somewhat of a conflict of interest with trying to
identify the problem - especially given the broad scope.

Keith

---

From: Keith Moore <[email-masked]>
Date: Tue, 21 Apr 2009 10:20:55 -0400

Giyeong Son wrote:
> I think that there are many working groups, standard bodies and
> technologies who focuses on multiple addresses per host. So, I'd  also
> like MIF to concentrate on simultaneous connections to multiple networks
> (or simultaneous use of multiple connections with multiple networks). I
> believe that most of cases for simultaneous connections to multiple
> networks require multiple addresses. However, it does not need to be the
> main focus, but MIF NEEDS it. So, I would like to say that multiple
> addresses per host needs to be addressed for simultaneous use of
> multiple connections. Therefore, I think working on MIF problem should
> be more than just focusing on multiple addresses.

I think it's interesting that you appear to consider "multiple addresses
per host" a narrower problem than "multiple network connections per
host", whereas I consider the latter to be a subset of the former.

I suppose that makes a good illustration of why I really want the WG to
explore this issue from multiple points-of-view.

Keith

---

From: Melinda Shore <[email-masked]>
Date: Tue, 21 Apr 2009 10:55:11 -0400

> host", whereas I consider the latter to be a subset of the former.

Yeah - I do, too.

To expand on this a little, I think it's useful to
frame this in terms of policy (which seems to be the
direction it's already headed) and identify which
policies are attributes of which entities.  There are
policies that apply to the network device (routing,
for example), policies which apply to an interface
(filtering and maybe QoS), and policies which apply to
a network.  I don't think the distinctions are always
all that clean but I do think it's a useful exercise
to try to get some clarity around what belongs to whom.
If nothing else it might help sort out what's a tractable
problem and what isn't.

Melinda

---

From: Thomas Narten <[email-masked]>
Date: Tue, 21 Apr 2009 11:39:10 -0400

Overall, I think the charter is good enough and we should ship it.

A few minor comments.

> tunnels), or even through multiple default routers being on the same 

Nit: this last point isn't really accurate. Having two routers on a
network doesn't mean one is attached to "multiple networks". The
"multiple" is at least one hop away in this case...

> For instance, current laptops and smartphones typically have 

> on different interfaces.

Specifically, issues arise (only) when the information is in some
sense contradictory, forcing the host to make decisions about which
object to use under various circumstances. This is the root cause of
all the problems being discussed.

> At best, decisions about these matters have an 

> make recommendations about best current practice.

Charter does seem to say here that BCP documents will be an
output. That goes beyond just describing the problem.

Personally, I'm skeptical that there is much in this space being done
today that would qualify as a BCP recommendation.

But that is something that we can figure out definitively when the WG
tries to produce such a document and we see what they are actually
recommending. So, as long as it is clear that one possible outcome is
that no BCP is possible at the current time, I'm OK with going
forward.

Thomas

---

From: Hui Deng <[email-masked]>
Date: Wed, 22 Apr 2009 00:10:45 +0800

Are you saying multiple addresses on one interface of the host?

thanks

-Hui

---

From: "Giyeong Son" <[email-masked]>
Date: Tue, 21 Apr 2009 09:37:33 -0400

Giyeong 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Sam Hartman
Sent: April 20, 2009 6:09 PM
To: Keith Moore
Cc: Ted Hardie; Adrian Farrel; mif; IETF Discussion
Subject: Re: [mif] WG Review: Multiple InterFaces (mif)

---

From: "Giyeong Son" <[email-masked]>
Date: Tue, 21 Apr 2009 10:28:55 -0400

No, I am also interested in "multiple network connections per host", but
my main interesting topic is *simultaneous* if multiple networks (or
multiple interfaces) are available. Sorry for this confusion.

Giyeong 

-----Original Message-----
From: Keith Moore [mailto:[email-masked]] 
Sent: April 21, 2009 10:21 AM
To: Giyeong Son
Cc: Sam Hartman; Ted Hardie; Adrian Farrel; mif; IETF Discussion
Subject: Re: [mif] WG Review: Multiple InterFaces (mif)

> like MIF to concentrate on simultaneous connections to multiple 
> networks (or simultaneous use of multiple connections with multiple 
> networks). I believe that most of cases for simultaneous connections 
> to multiple networks require multiple addresses. However, it does not 
> need to be the main focus, but MIF NEEDS it. So, I would like to say 
> that multiple addresses per host needs to be addressed for 
> simultaneous use of multiple connections. Therefore, I think working 
> on MIF problem should be more than just focusing on multiple
addresses.

Keith

---

From: Keith Moore <[email-masked]>
Date: Tue, 21 Apr 2009 14:53:39 -0400

> If nothing else it might help sort out what's a tractable

Policies are certainly an interesting set of questions raised by these
circumstances.  But they do not stand on their own, they interact with
other concerns.  I don't see any benefit in fragmenting the discussion
so that policies are discussed separately from, say, application level
issues, or network administration issues, or host administration issues
(note that the latter two are not the same), etc.  To the contrary, I
don't think a policy discussion can be realistic unless it's held in
light of those other concerns.

And I don't know why you think that the discussion is "already headed"
toward policy when the group isn't even chartered yet.  Certainly the
discussion on the IETF list isn't "already headed" that way.

Keith

---

From: Melinda Shore <[email-masked]>
Date: Tue, 21 Apr 2009 15:04:36 -0400

> discussion on the IETF list isn't "already headed" that way.

You can call it "foo" for all I care, but much of what's
been discussed so far is policy.  From the proposed
charter:

"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."

That's all policy.

Melinda

---

From: Keith Moore <[email-masked]>
Date: Tue, 21 Apr 2009 15:13:24 -0400

I'm saying there is a set of problems that exist if there are multiple
addresses associated with a host for any reason.  This could be multiple
addresses on a single interface (including aliases and multiple v6
prefixes advertised on the network segment), multiple addresses because
there are multiple active interfaces, multiple addresses because the
host supports both v4 and v6, multiple addresses because the host has
some sort of tunnel endpoint (which might be IPvX in IPvY, or an IPsec
tunnel, or mobileIP), multiple addresses because the host is behind a
NAT (any kind of NAT, including a v4/v6 NAT), and so on.

And among those problem areas are: address selection (which differs
depending on the needs of the app, and the configuration of the network
to which the host is attached), referrals, sorting out policy conflicts,
sorting out non-policy related configuration, security, etc.

Keith

---

From: Keith Moore <[email-masked]>
Date: Tue, 21 Apr 2009 15:14:21 -0400

> effects such as security impacts, or even lead to communication not

you're arguing that the charter should stay as it is because the charter
says what it says?  sounds circular to me.

Keith

---

From: Sam Hartman <[email-masked]>
Date: Tue, 21 Apr 2009 15:14:46 -0400

Keith, Melinda, I believe you are talking about an issue that is distinct from what was discussed in the BOF.
My personal preference is to see work on what was discussed in the BOF.

However to respond to Jari, I do not have have concerns with the charter as written.

---

From: Dean Willis <[email-masked]>
Date: Tue, 21 Apr 2009 16:48:18 -0500

> effects such as security impacts, or even lead to communication not

My shaman once said "For God, everything is just a question of  
policy."  But, we need to reduce this problem to a more mortal scope,  
and  I'm not quite certain that the proposed charter text accomplishes  
this goal.

There's a tremendous amount of complexity inherent in the problem. I  
suspect as worded that it is roughly isomorphic to the peering  
problem, with all the business-driven policy consideration that entails.

Consider that peering policy is often driven by things that are well  
beyond the scope of protocol.  Its potential range of expression is  
unlimited; in fact driven by a natural-language contract and heuristic  
operations on underspecified constraints derived from that natural- 
language contract.

The only alternative I can see here is to try and reduce the range of  
expression. One such approach might be to develop a policy language  
having the property of an algebra, so that policies can be written and  
interpreted in a defined manner, and so that the combinations and  
interactions of multiple policies can be evaluated and applied  
predictably in automata and simulation.

This requires a substantial body of precursor work:  What things  
should the language be able to express? What combinatorial operations  
are required? What are the relative priorities of linguistic  
statements? What sorts of fundamental things should the policy  
describe (we have things like route selection, prefix manipulation,  
addressing, access rules, name services, name defaults, and so on to  
consider as options).

Even with this sort of model, I am not confident at our ability to  
achieve success, at least without even more substantive reductions in  
the scope of the effort.

Can we narrow it down some more?

--
Dean Willis

---

From: Melinda Shore <[email-masked]>
Date: Tue, 21 Apr 2009 18:09:06 -0400

Dean Willis wrote:
> operations on underspecified constraints derived from that 
> natural-language contract.

Good heavens - I was not proposing, nor would I
propose, that what's needed here is the development
of a policy language.  If the word "policy" is
making people uncomfortable perhaps it would be
better to drop it in favor of "properties."

Melinda

---

From: "Tony Hain" <[email-masked]>
Date: Tue, 21 Apr 2009 16:19:17 -0700

At the end of the day it doesn't matter what you call it, the fundamental
problem is that the widespread assumptions about a single-interface /
single-address are not realistic in today's Internet, and there are
independent policy realms influencing each end system. The available tool
set is built on a single-interface / single-policy-realm model, so it
routinely fails. Any effort that does not recognize that there needs to be a
way to describe the policy attributes is going to create a short-sighted
mess.

Keith is also right, in that aspects of the problem from the application
perspective still fail even when there are multiple choices from the same
administrative entity. That said, there should be a way to describe the
local policy attributes to sort between choices from a common
administration. 

The bottom line is that we need to stop the fantasy that there are -any-
global attributes. This alone is the source of most of the confusion, and if
removed it would be fairly obvious to most people how to sort between the
choices. The IPv6 address selection effort is suffering from the same
'merged global attribute' mindset, and needs to be able to describe policy
attributes to each source of addresses, then a hierarchy for sorting through
them. 

I do object to having the charter spend any more time on IPv4 than to simply
document current practice as a reference. It is long past time for the IETF
to stop wasting cycles on a dead end, and this should be one place where we
say 'it just doesn't work in IPv4, so move to IPv6 if you need multiple
interfaces'. Other than that I think it is fine.

Tony

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Melinda Shore
> Sent: Tuesday, April 21, 2009 3:09 PM
> To: Dean Willis
> Cc: IETF Discussion

---

From: Christian Vogt <[email-masked]>
Date: Tue, 21 Apr 2009 22:19:46 -0700

Folks -

It seems that folks are considering two related, yet still orthogonal
topics for inclusion in the MIF charter:

- Conflicts between configuration parameters.

- Issues with address selection.

(These two topics also span "issues with multiple network connections",
which has been brought up as well.)

The first topic talks about a problem of the network stack:  How are
conflicting parameters for host or interface configuration reconciled
with each other, or, if not reconcilable, which parameters win?  This
issue may come up if configuration parameters are received from multiple
sources, such as from any set of default routers, DHCP servers, and
manual configuration.  Hosts with multiple interfaces are more likely to
be confronted with this issue, but the issue may also come up for hosts
with a single interface.

The second topic talks about a problem of applications:  When initiating
a connection, which pair of source and destination address (and
consequently which pair of interfaces) should be used?  Again, this
issue may come up independently of whether a host has one or multiple
interfaces -- though the presence of multiple interfaces makes the issue
more difficult to tackle and, since it determines which interface pair
is used, also more important.

Both topics need work; the arguments that have been put forth clearly
show this.  And we have to make a decision whether to tackle either or
both of these topics in the MIF working group.  Personally, I feel that
the workload of both topics will be manageable for a single working
group.  Though, if we decide to tackle both, then the working group
charter would have to explicitly list these topics as two separate ones.
This would require some, but not much, rewriting of the charter.

In any case, the working group acronym could actually stay as is.  If
the working group will tackle both topics, we could re-use the acronym
for "Multiply Interface Addressing and Configuration".  If only one of
the topics will be tackled, then we could just remove from this the
words "and Configuration" or "Addressing and", respectively.

- Christian

---

From: Lars Eggert <[email-masked]>
Date: Wed, 22 Apr 2009 10:15:10 -0300

Hi,

> - Issues with address selection.

I agree that both of these are important and should be worked on (and  
with the rest of your email, basically).

The first one is what I thought MIF would be focusing on, as an INT WG  
is IMO the right venue for this.

The second one is also important, but much more tricky, because it  
ties in with transports and applications (as Keith and others have  
pointed out already). Topics that cross area boundaries are always a  
bit difficult to charter. I'm at this point not fully convinced that  
simply throwing this in with topic #1 into one WG is going to work.

Lars

---

From: Lars Eggert <[email-masked]>
Date: Wed, 22 Apr 2009 10:42:05 -0300

> what we're willing to include in our engineering model.

Agree with Sam. If you want a host to have a more reliable  
connectivity to the network than any one of its interfaces can give  
it, or if you want to aggregate capacity of multiple network  
connections, you have no choice but to assign it multiple interfaces  
in today's Internet. Nokia alone has probably shipped over a billion  
devices by now that have at least WLAN + 3G, and there are obviously  
many other vendors. Any IETF activity that enables better use of those  
interfaces simultaneously is consequently very interesting.

Lars

---

From: Ralph Droms <[email-masked]>
Date: Wed, 22 Apr 2009 10:19:51 -0400

I agree with Christian that there are two orthogonal issues.  Comments  
in line...

- Ralph

> be confronted with this issue, but the issue may also come up for  

Yes...this topic arises whenever there are multiple sources of  
"information", and those sources of information may be delivered over  
a single "interface".

I think the topic is modified by the existence of multiple  
"administrative domains".  We could hand-wave away the topic of  
conflicting information from multiple sources in a single admin domain  
as "misconfiguration".  Information from multiple admin domains might  
be conflicting, or might be appropriate only for traffic related to  
the admin domain.  Roughly speaking, there is a vague description of  
the related problem of per-interface and host-wide information  
supplied through DHCP.

> is used, also more important.

In some circumstances, the order of selection might be reversed: pick  
an interface (WiFi versus wired Ethernet) and then choose addresses.

Hm.  Perhaps that would be better expressed as "order of preference";  
some destination might not be reachable through one interface, even if  
that interface might be preferred for other reasons.

---

From: Jari Arkko <[email-masked]>
Date: Wed, 22 Apr 2009 18:44:55 +0300

Lars,

> simply throwing this in with topic #1 into one WG is going to work.

First, a minor point: I think everyone is mindful about the fact that 
address selection is a problem that affects apps, transports, and IP 
layer. However, I'll note that address selection has been an Internet 
area topic for some time (RFC 3484, 6MAN work, etc).

But my main point is that the MIF charter covers -- on purpose -- a 
relatively large problem area. We need to describe the problem as 
experienced by real-life implementations without constraining ourselves 
too much at this stage. Once we finally understand the problem fully, 
then it is a time to start narrowing down the scope to something 
implementable. However, we are not there yet. The WG needs to complete 
its problem definition task first. When it does, it may be that we no 
longer need a specific WG and the rest can be handled in, say, DHC -- if 
the chosen scope is just parameters conflicts, for instance.

I would also echo what Margaret said about this discussion being 
excellent input for the problem definition work. From my point of view 
I'd like to get the group chartered so that they can do that work, as 
opposed to us writing the full problem definition into the charter. The 
latter would consume quite a bit of IETF discussion list and AD cycles :-)

Jari

---

From: "Giyeong Son" <[email-masked]>
Date: Wed, 22 Apr 2009 09:49:32 -0400

I agree with Lars.

Giyeong 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Lars Eggert
Sent: April 22, 2009 9:42 AM
To: Sam Hartman
Cc: Ted Hardie; Adrian Farrel; mif; Keith Moore; IETF Discussion
Subject: Re: [mif] WG Review: Multiple InterFaces (mif)

> what we're willing to include in our engineering model.

Agree with Sam. If you want a host to have a more reliable connectivity
to the network than any one of its interfaces can give it, or if you
want to aggregate capacity of multiple network connections, you have no
choice but to assign it multiple interfaces in today's Internet. Nokia
alone has probably shipped over a billion devices by now that have at
least WLAN + 3G, and there are obviously many other vendors. Any IETF
activity that enables better use of those interfaces simultaneously is
consequently very interesting.

Lars

---

From: Marc Blanchet <[email-masked]>
Date: Wed, 22 Apr 2009 09:53:23 -0600

Jari Arkko a écrit :
> its problem definition task first.

fully agree. I was going to write about the same thing!

Marc.

 When it does, it may be that we no

-- 
=========
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: Margaret Wasserman <[email-masked]>
Date: Wed, 22 Apr 2009 09:45:41 -0400

I don't see any compelling reason to change the name of this group at 
this point... 

We obviously could change the name if we wanted to, but it would 
significant cost -- setting up a new mailing list, getting everyone 
subscribed there, renaming all of the drafts (and thus losing the edit 
trail), changing entries in the secretariat database, etc.  Personally, 
I haven't seen a justification for changing the name that would be worth 
the effort.  The name we have chosen is fairly general, I agree, but it 
is the purpose of the charter to actually scope the work, not just the 
WG name.

Margaret

Jari Arkko wrote:
> creation process is in the IETF's database system, the WG acronym 
> cannot be changed, you can delete it and create a new one, but you 
> cannot the acronym. Of course, I could create a new one and ask it to 
> be brought to the right state... hopefully without having to re-do any 
> real-life steps, like announcements going out or the topic being on 
> the IESG telechat. This might work, but I'd have to investigate 
> further to ensure that it actually is possible. If it was the only 
> problem I would.
>
> its too late in the day here to be creative. I'm sure someone sends 
> the coolest acronym in reply :-)
>

---

From: Margaret Wasserman <[email-masked]>
Date: Wed, 22 Apr 2009 09:52:18 -0400

> advertised on the network attached to any particular interface, or even
Not quite right, IMO.  I think that the problem stems from having 
multiple _prefixes_ per host, because IP hosts don't generally have a 
way to associate configuration information with a particular prefix, nor 
do they have good ways of telling which prefix is most appropriate for 
reaching a certain destination.  Hosts that implement all of the IETF 
protocols (and nothing that tries to do better) currently use 
longest-match, but that doesn't always work well in the "real world".
> Hosts Addressed Multiply (HAM), perhaps
As I indicated in my previous message, I don't see the point of changing 
the name, especially not to reflect a concept that this is a multiple 
addresses problem when I don't think that is actual the case.  One of 
the things that this group can/should do is try to figure out where the 
problem lies.  We know that some multi-interface hosts work just fine -- 
where all of their interfaces are under a signal administrative control 
and/or connect to all of the services that a host wants to use.  But, 
there are other cases (corporate VPN, WLAN/cell devices, etc.) where our 
current standards don't work well.  Figuring out exactly where things 
break down is part of this effort.

Margaret

---

From: Margaret Wasserman <[email-masked]>
Date: Wed, 22 Apr 2009 09:56:44 -0400

> BOFs, RFCs etc ..not to mention other rather funny WG names :-)
I agree with you.  If, for example, the outcome of is that we should 
charger a WG to develop specific standards and/or BCPs for hosts with 
multiple addresses, we should charter that effort under a new name.  Or 
if it were about multiple prefixes, or multiple access networks, or 
multiple administrative domains...  But, at this point, I think that the 
only thing we're sure that we have consensus about is that we run into 
trouble in many cases where hosts have multiple interfaces.

Margaret

---

From: Margaret Wasserman <[email-masked]>
Date: Wed, 22 Apr 2009 09:58:59 -0400

>> Connections to Multiple Networks (mif)

Personally, I think that this sort of disconnect between WG name and 
acronym would create long-lived confusion about the name of the group.  
While I don't favor changing the name at this point (because I don't 
think we know what to change it to), if we do change the name we should 
change the acronym, too, in my opinion.

Margaret

---

From: Margaret Wasserman <[email-masked]>
Date: Wed, 22 Apr 2009 10:05:29 -0400

> Multiple InterFaces (mif)
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
> A host attached to multiple networks has to make decisions about 
> 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.
>
> 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.
>
> 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.
>
> 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: Margaret Wasserman <[email-masked]>
Date: Wed, 22 Apr 2009 10:13:22 -0400

> and  I'm not quite certain that the proposed charter text accomplishes 
I agree with you that this is a complex problem.  The purpose of the 
_WG_ (not the charter) is to try to reduce this problem to a more mortal 
scope.  The actual work in the current charter is _not_ to develop a 
solution to this problem, it is to define the problem(s) clearly, and to 
document how current implementations (some of which do some interesting 
things that aren't reflected in any IETF standard) are dealing with this 
problem in the real world.  If/when we fully understand the problem and 
the current status of implementations, we'll be in a better situation to 
start discussing how to solve it.

Margaret

---

From: Margaret Wasserman <[email-masked]>
Date: Wed, 22 Apr 2009 10:18:18 -0400

> is used, also more important.
This topic, address selection, is not currently handled by 
applications.  In many cases, it is handled entirely by the stack 
(through ordering of the destination ddresses in DNS replies and source 
address selection in the IP stack), and in other cases the application 
chooses a destination address with the stack choosing a source address.  
There are certain cases (sometimes in solutions to the problems that we 
are discussing here) where applications do choose both the destination 
and sourece address, but they are not common.

Margaret

---

From: Margaret Wasserman <[email-masked]>
Date: Wed, 22 Apr 2009 10:29:07 -0400

Hi Lars,

> simply throwing this in with topic #1 into one WG is going to work.

I disagree with your conclusion for two reasons:

(1) As I pointed out in my previous message to Christian, address 
selection is not (today) a transport-layer or application-layer function 
in most cases.  Given that this is currently an Internet-layer function, 
I think it makes sense to analyze the issues with address selection (as 
part of the whole address/interface/router selection process)  in an 
Internet Area group.  If we find that one of the problems we have is 
that the Internet layer doesn't have the right information to make these 
decisions, then possibly some follow-on work might need to be chartered 
elsewhere.

(2) There is no way that these decisions can be made solely at the 
transport or application layer, because source (and to a lesser degree 
destination) address selection is tightly tied to the first-hop 
forwarding decision.  The outbound interface, source address and default 
router all have to be selected in a coordinate process, to avoid sending 
traffic that will be discarded on the outbound path, due to router filters.

So, while agree that address selection affects transport layers and 
applications, and that it might be necessary for transport layers and 
applications to have better ways of influencing it, I do not believe 
that address selection is a transport layer or applications layer 
function today, nor do I think it can be done solely at those layers in 
the future.

Margaret

---

From: Hui Deng <[email-masked]>
Date: Thu, 23 Apr 2009 00:52:40 +0800

If you are saying multiple address for multiple interface, that's fine.
but if you are talking multiple address for single interface, could you help to
point out any IPv4 scenario except VPN,

MIF is targeting at least half billion of subscribers who have this
real problem,
The problems you raised here is valuable to resolve, but MIF at the early stage
may only solve some simple and easy to solve work,

thanks

-Hui

---

From: Ted Hardie <[email-masked]>
Date: Wed, 22 Apr 2009 10:21:10 -0700

>decisions, then possibly some follow-on work might need to be chartered

So this may be simply one of those cases where address selection
does not fit your model, but at what layer would you describe the ICE
spec as working?  Clearly, one aim in ICE is to provide a signalling-path
mechanism for flow endpoint selection, which certainly relates to the question
of address/interface selection.

There is an old saw that my work is a cross-layer optimization; yours is
a layer violation, and that guy's is a hideous hack.  However we have arrived
here, it seems at least reasonable to say that we currently have this
work muddled across a variety of layers.  If we can focus it and solve it
at a single layer, the architecture gets easier and the protocol smog
clear a bit.  But I seem to be hearing that tackling the big problem is
ocean-boiling; what I am not clear on is whether the end result of piece work
shifts the pain or actually reduces the smog.

Perhaps it is just me; this is not stuff I am following in any depth.  But the
impression I'm getting from following the thread is that there is some
disagreement about how to structure the work to make sure it really
does reduce pain, rather than just shift it around.

			regards,
				Ted
				Ted

---

From: "Spencer Dawkins" <[email-masked]>
Date: Wed, 22 Apr 2009 12:42:42 -0500

If anyone is looking for a theme for a t-shirt at any upcoming IETF, this 
one would be awesome...

:-)

Spencer

> a layer violation, and that guy's is a hideous hack.

---

From: Scott Brim <[email-masked]>
Date: Wed, 22 Apr 2009 16:52:08 -0400

> function today, nor do I think it can be done solely at those layers in  

The first problem (configuration conflicts) is best dealt with before
the second problem (address selection) even arises.  First I
initialize my interface, and then I use it.  They impinge on each
other but they are not tightly bound to each other -- they do not have
to be worked on in the same Working Group.  

I suggest chartering MIF to focus on problem #1, let it make progress,
and in the meantime figure out how to organize work on problem #2 in
parallel.

Scott

---

From: Scott Brim <[email-masked]>
Date: Wed, 22 Apr 2009 16:55:01 -0400

> of address/interface selection.

As I understand it, the ICE client is not deciding on what address to
use on its packets, it is _discovering_ what address it is using and
then communicating that to its peers as payload (not providing it as
fodder for a forwarding function).

Scott

---

From: Ted Hardie <[email-masked]>
Date: Wed, 22 Apr 2009 14:10:06 -0700

>fodder for a forwarding function).

I think if you go back and review the "Gathering Candidates"
section of http://tools.ietf.org/html/draft-ietf-mmusic-ice-19,
you'll see that the Host Candidate portion covers this area:

  The first step is to gather host candidates.  Host candidates are
   obtained by binding to ports (typically ephemeral) on a IP address
   attached to an interface (physical or virtual, including VPN
   interfaces) on the host.

Those candidates become part of the overall candidate list (and
it gets much, much more complicated than this small snippet would
indicate), and the SDP exchange is then a signalling-path mechanism
for working out the best flow pairing. 

				regards,
					Ted

---

From: Christian Huitema <[email-masked]>
Date: Wed, 22 Apr 2009 15:18:35 -0700

> traffic that will be discarded on the outbound path, due to router

Actually, applications can to do that today, using the socket API, if the stack implements the "strong host" model. The application just needs to bind the socket to a specific IP address. Doing that ensures that packets sourced by the application will use the specified address, will go out through the interface corresponding to that address, and will use the default gateway associated with that interface.

-- Christian Huitema

---

From: Christian Vogt <[email-masked]>
Date: Wed, 22 Apr 2009 16:03:39 -0700

On Apr 22, 2009, Margaret Wasserman wrote:

> applications.
> In many cases, it is handled entirely by the stack (through ordering  
> of
> the destination ddresses in DNS replies and source address selection  
> in
> the IP stack), and in other cases the application chooses a  
> destination
> address with the stack choosing a source address.  There are certain
> cases (sometimes in solutions to the problems that we are discussing
> here) where applications do choose both the destination and sourece
> address, but they are not common.

Margaret -

 From a system perspective, you are certainly right:  Applications
typically do get help from the operating system in selecting their
addresses.  From an OSI layering perspective, though, address selection
still is performed at application layer.  In fact, if an application
wants to do a complete job, especially a peer-to-peer application, it
needs to select both source and destination address itself, possibly
after running STUN, TURN, or ICE.

My main point, though, was that we are talking about two orthogonal
issues -- conflicting configuration and address selection.  This holds
independently of the fact that an application may let the operating
system accomplish part or all of address selection.

Whether we take this to mean that both issues should be tackled in the
same working group is a different story.  I personally don't see the
orthogonality of the two issues as a reason not to tackle both issues in
the same working group.  We just ought to be aware that the issues are
separate, and the charter should describe them as such.  This said,
there might be work-load- or work-scope-specific reasons that suggest
splitting the work into separate working groups, like those brought up
by Lars, Sam, and Scott.  Those arguments should be discussed as well.

- Christian

---

From: Scott Brim <[email-masked]>
Date: Wed, 22 Apr 2009 19:07:16 -0400

Excerpts from Christian Vogt on Wed, Apr 22, 2009 04:03:39PM -0700:
> issues -- conflicting configuration and address selection.  This
> holds independently of the fact that an application may let the
> operating system accomplish part or all of address selection.
>
> Whether we take this to mean that both issues should be tackled in
> the same working group is a different story.  I personally don't see
> the orthogonality of the two issues as a reason not to tackle both
> issues in the same working group.  We just ought to be aware that
> the issues are separate, and the charter should describe them as
> such.  This said, there might be work-load- or work-scope-specific
> reasons that suggest splitting the work into separate working
> groups, like those brought up by Lars, Sam, and Scott.  Those
> arguments should be discussed as well.

Exactly.  Thanks.

---

From: Christian Vogt <[email-masked]>
Date: Wed, 22 Apr 2009 16:26:28 -0700

On Apr 22, 2009, Margaret Wasserman wrote:

> forwarding decision.  [...]

Margaret -

FWIW:  The fact that address selection determines the first hop does not
mean that address selection could not be performed at the application
layer.  In fact, applications can select their addresses.  This just  
some-
times does not work well, which is what we should analyze and document.

- Christian

---

From: Ralph Droms <[email-masked]>
Date: Thu, 23 Apr 2009 00:08:23 -0400

Christian - I think address selection is part but not all of the  
problem.

I would be happy to see a summary of current practice in dealing with  
simultaneous attachment to multiple networks.  How does an iPhone  
decide between its WiFi and dell interfaces?  How does an RG that can  
reach multiple next hop routers on its WAN interface select which  
router to forward to?  How does a laptop choose between its WiFi and  
wired interfaces?

- Ralph

On Apr 22, 2009, at 7:03 PM 4/22/09, Christian Vogt wrote:

>> In many cases, it is handled entirely by the stack (through  
>> ordering of
>> the destination ddresses in DNS replies and source address  
>> selection in

---

From: Jari Arkko <[email-masked]>
Date: Thu, 23 Apr 2009 17:57:59 +0300

Thomas,

> Overall, I think the charter is good enough and we should ship it.

Thanks and thanks for your review.

I have made a small revision of the text to accommodate your comments.

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

Multiple InterFaces (mif)
------------------------------------------------
Last Modified: 2009-04-23

Chair(s):
TBD

Internet Area Advisor:
TBD

Mailing Lists:

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.

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.

Milestones:

May 2009 WG chartered

---

From: Jari Arkko <[email-masked]>
Date: Thu, 23 Apr 2009 18:07:23 +0300

Marc Blanchet wrote:
> 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.
>
>   

That would also work for me.

Jari

---

From: Jari Arkko <[email-masked]>
Date: Thu, 23 Apr 2009 18:19:55 +0300

Let me try again, with an informational document as suggested by Marc:

Multiple InterFaces (mif)
------------------------------------------------
Last Modified: 2009-04-23 18:20

Chair(s):
TBD

Internet Area Advisor:
TBD

Mailing Lists:

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. The working group shall address both IPv4 and IPv6 as 
well as stateless and stateful configuration.

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
December 2009 Initial draft on analysis of 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
September 2010 Analysis draft submitted to the IESG for publication as 
an Informational RFC
October 2010 Recharter or close

---

From: Scott Brim <[email-masked]>
Date: Thu, 23 Apr 2009 12:48:02 -0400

> Let me try again, with an informational document as suggested by

Fine with me.  As the work evolves, we can always change our minds
and make it a BCP after all.

---

From: "Tony Hain" <[email-masked]>
Date: Wed, 22 Apr 2009 14:37:18 -0700

Ted Hardie wrote:
...
> does reduce pain, rather than just shift it around.

It is not just you. The basic tenant here is a hand-wave that some magic set
of engineering choices will resolve a collection of policy conflicts.
Fortunately there is enough sanity to recognize that we don't even have a
consistent view of the problem space, so the intent as I understand it is to
document what we know. That step is not going to either reduce pain or move
it, but the follow-on will result in moving it because the network admin's
perspective of what is 'right' is in direct conflict with the perspective of
the sys admin, and neither of them care about the end user trying to get
something done. Resolving this requires a real signaling and negotiation
infrastructure, and the IETF has refused to replace RSVP as an endpoint
signaling path, so the entire effort can only lead to shifting the pain.

Tony

---

From: Hui Deng <[email-masked]>
Date: Thu, 23 Apr 2009 21:30:00 +0800

For what I know at the moment service provider deployment experience,
ICE like solution has been deployed by a dedicate close network, this
is not interact with MIF space we talked here, mif are resolve general issue
with host connections, in that scenario, application is isolated.

thanks.

-Hui.

---

From: Hui Deng <[email-masked]>
Date: Thu, 23 Apr 2009 22:02:38 +0800

This type of implementation is not transparent to application, kind of
binding everything together, what mif is trying to do is to avoid it.

thanks

-Hui

---

From: Hui Deng <[email-masked]>
Date: Thu, 23 Apr 2009 22:44:21 +0800

Hi, Marc,

Normally, host vendors normally really do not like to open this interface,
but anyhow it is more solution oriented, let's discuss it after.

-Hui

2009/4/23 Marc Blanchet <[email-masked]>:
> Christian's suggestion is one way. not sure it is complete.
>
> but I don't agree with you (Deng): i.e. I think this suggestion is in
> scope of MIF wg. Maybe the outcome of the wg is a best practice document
> that tells application developers how to write "good" applications in
> context of MIF, where one practice is what Christian wrote, for example.
>
> Marc.
>
> Hui Deng a écrit :

---

From: Hui Deng <[email-masked]>
Date: Thu, 23 Apr 2009 22:46:47 +0800

Agree.

-Hui

2009/4/23 Giyeong Son <[email-masked]>:
> I think we may need to understand what are the real problems that
> people/organizations (i.e. carriers, ISPs and vendors and users) have
> been currently struggling with in terms of simultaneous use of multiple
> networks.
>
> I think, Ralph seems to have clearly brought applicable practical use
> cases and/or criteria. So, with the use cases it might be worth to
> clarify if MIF will address and provide some recommendation for (at
> least) BCP which can answer to those use cases. If MIF does not
> (instead, only addresses partially, such as conflicting configurations
> and/or others), there may need other working group for focusing on BCP
> for the end-to-end practice of simultaneous use of multiple
> networks/interfaces. I believe that there is no working groups currently
> where can provide this kind of recommendation. They may be also willing
> to address partially from their perspective, similar with MIF if MIF
> want to tackle the problem partially.
>
> I think that we already know that simultaneous use of multiple networks
> is very crucial issue in various aspects by various organizations. Most
> of current carriers/ISPs/mobile device (including laptop) manufactures
> seems to be willing to hear about efficient, reliable and best common
> practice to handle the problem.
>
> Giyeong
>
>
> Ralph Droms
> Sent: April 23, 2009 12:08 AM
> To: Christian Vogt
> Cc: mif; Margaret Wasserman; Sam Hartman; Scott Brim; David W. Hankins;
> Keith Moore; Hui Deng; IETF Discussion
> simultaneous attachment to multiple networks.  How does an iPhone decide
> between its WiFi and dell interfaces?  How does an RG that can reach
> multiple next hop routers on its WAN interface select which router to
> forward to?  How does a laptop choose between its WiFi and wired
> interfaces?
>
> - Ralph
>
>>> of the destination ddresses in DNS replies and source address
>>> selection in the IP stack), and in other cases the application
>>> chooses a destination address with the stack choosing a source
>>> address.  There are certain cases (sometimes in solutions to the
>>> problems that we are discussing
>> addresses.  From an OSI layering perspective, though, address
>> selection still is performed at application layer.  In fact, if an
>> application wants to do a complete job, especially a peer-to-peer
>> application, it needs to select both source and destination address
>> itself, possibly after running STUN, TURN, or ICE.
>>
>> orthogonality of the two issues as a reason not to tackle both issues
>> in the same working group.  We just ought to be aware that the issues
>> are separate, and the charter should describe them as such.  This
>> said, there might be work-load- or work-scope-specific reasons that
>> suggest splitting the work into separate working groups, like those
>> brought up by Lars, Sam, and Scott.  Those arguments should be
>> discussed as well.
>>
>> - Christian
>>
>>
>>

---

From: "Giyeong Son" <[email-masked]>
Date: Thu, 23 Apr 2009 10:33:46 -0400

Giyeong

-----Original Message-----

- Ralph

---

From: Marc Blanchet <[email-masked]>
Date: Thu, 23 Apr 2009 05:04:06 -0600

Ralph Droms a écrit :
> Christian - I think address selection is part but not all of the problem.
> 

that is the purpose of draft-mrw-mif-current-practices... Some answers
are already there.

Marc.

>>> This topic, address selection, is not currently handled by applications.
>>> In many cases, it is handled entirely by the stack (through ordering of
>>> the destination ddresses in DNS replies and source address selection in
>>> the IP stack), and in other cases the application chooses a destination

---

From: Marc Blanchet <[email-masked]>
Date: Thu, 23 Apr 2009 08:32:41 -0600

Marc.

---

From: Marc Blanchet <[email-masked]>
Date: Thu, 23 Apr 2009 08:50:59 -0600

> been currently struggling with in terms of simultaneous use of multiple

there is a first cut in draft-blanchet-mif-problem-statement.

Please provide text/comments to it.

Marc.

---

From: Marc Blanchet <[email-masked]>
Date: Thu, 23 Apr 2009 09:05:59 -0600

Jari,

Marc.

---

From: Christian Vogt <[email-masked]>
Date: Thu, 23 Apr 2009 10:09:28 -0700

On Apr 22, 2009, Ralph Droms wrote:

> decide

Absolutely.  Nowadays, though, interface and next-hop selection, which
you mention, are tied to address selection.  This is why I summarized
everything under address selection.  Nevertheless, I agree that this
tying between interface, next-hop, and address selection is part of the
issue we should analyze and document.

- Christian

---

From: Christian Vogt <[email-masked]>
Date: Thu, 23 Apr 2009 11:42:29 -0700

On Apr 23, 2009, Hui Deng wrote:

> is not interact with MIF space we talked here, mif are resolve general
> issue with host connections, in that scenario, application is  
> isolated.

Hui -

If the to-be MIF working group is to tackle the issue of address  
selection,
then doing so thoroughly would require to also look into NAT  
traversal, and
this includes ICE.  ICE specifies address selection rules for a large  
group
of applications.

- Christian

---

From: Jari Arkko <[email-masked]>
Date: Thu, 23 Apr 2009 23:20:21 +0300

We discussed this topic in today's IESG call and approved the working 
group with the charter I send earlier (copied below).

A couple of additional notes: I think this discussion has been extremely 
useful, and a good starting point for writing the problem definition. I 
certainly have learned much more about this than what I knew after the 
BOF. Lets continue the discussion.

We clearly need to work more on understanding the full scope of the 
problem, including the application and transport points of view. We'd 
love  to have more people in the group who have worked on application 
layer address selection tools; please join.

Jari

----

Chair(s):
Margaret Wasserman <[email-masked]>
Hui Deng <[email-masked]>

Internet Area Advisor:

Mailing Lists:

Milestones:

May 2009 WG chartered

---

From: Hui Deng <[email-masked]>
Date: Fri, 24 Apr 2009 23:40:34 +0800

Hi, Ted,

Excuse me for late reply, thanks for the discussion.

The reason why I said before is that currently there are limtied ISP
providing ICE support for open applications, anyhow, P2P made a smart
way to reach it.

For what I know application which need ICE like IMS is normally go to
independent APN.
That could be guaranteed since it is kind of application binding APN.

Today most mobile application binding with APN(kind of interface like)
or could be on-demand select for user. I guess Marc raised similar
consideration which allow application to call such interface API, then
it can run depending on different connection's characteristic.

Please kind help to provide your text regarding this application
scenario, it will be helpful for MIF PS could include those.
I will re-read the spec which you recommend and to know the potential needs.

thanks again

-Hui

2009/4/24 Ted Hardie <[email-masked]>:
> At 6:30 AM -0700 4/23/09, Hui Deng wrote:
> Forgive me, Hui, but it is not clear to me whether you think the application
> is isolated in situations where ICE is in use, or whether it is isolated in the
> work for which MIF might be chartered.
>
> If your point is that not all applications have a signalling-path mechanism
> for trading candidates using SDP, that is certainly true.  What is truly scary
> is that this makes applications which can use ICE better off than the common
> case, despite ICE's complexity.  I hope, after reading the full ICE spec and
> recognizing that there are *still* cases where it does not work to establish
> connectivity, you will see the scope of the problem.
>
> Interfaces/network attachments may have different reachability characteristics
> (e.g. be part of different address realms or otherwise have substantially
> different access to parts of the network).  There are classes of application
> which will want to make interface choices based on those characteristics.
>
> There are many other characteristics which may play into interface choices
> (do I already have a data channel on interface X, and need to acquire it on
> interface y?), and I do not want to minimize those, power savings being
> a big deal in my day job choices for this type of thing.  But the
> applications' needs here can't be subordinate to those, or the whole point
> of the link--you know, traffic across it--is lost.
>
> Just my personal opinion, despite the mention of a day job,
>                                regards,
>                                        Ted
>
>

---

From: Hui Deng <[email-masked]>
Date: Fri, 24 Apr 2009 23:43:12 +0800

Christian,

I agree with what you said here, MIF should tackle this thoroughly.

I just wondering whether any ISP provider ICE service for open applications?
maybe my limited knowledge.

Regards,

-Hui

2009/4/24 Christian Vogt <[email-masked]>:
>> issue with host connections, in that scenario, application is isolated.
>
>
> Hui -
>
> If the to-be MIF working group is to tackle the issue of address selection,
> then doing so thoroughly would require to also look into NAT traversal, and
> this includes ICE.  ICE specifies address selection rules for a large group
> of applications.
>
> - Christian
>
>
>

---

From: "Rémi Denis-Courmont" <[email-masked]>
Date: Fri, 24 Apr 2009 19:03:36 +0300

> same link. The current charter text reflects this in some parts of the

I don't quite agree here.

Multiple interfaces will typically have some differing properties, such as:
 - bandwidth,
 - latency,
 - charging,
 - power consumption,
 - reliability,
 - address transparency (e.g. what kind of NAT if any)
 - filtering policy,
 - IP protocol versions availability,
 - set of reachable hosts (the Internet, the home, the office...),
 - recursive DNS servers,
 - DNS namespace,
 - address filtering rules.

A host may have multiple default gateways on the same "interface". However, 
those gateways should be usable interchangeably. All of those gateways should 
have the same "values" for the properties above. Otherwise, I would argue the 
network is broken and/or the host is misconfigured. In other words, it can 
pick any of its live gateways outbound, and may receive packets from any of 
those gateways in the other direction. If I'm not mistaken, the IETF IPv6 
wireless network is an example of this.

But I think /that/ form of multi-homing has been solved for a long time by Ip 
stack implementors. What was discussed at the MIF BoF were quite different 
scenarios.

-- 
Rémi Denis-Courmont
Nokia Devices R&D, Maemo Software, Helsinki

---

From: Ted Hardie <[email-masked]>
Date: Thu, 23 Apr 2009 10:15:50 -0700

---

From: Christian Huitema <[email-masked]>
Date: Sat, 25 Apr 2009 12:32:35 -0700

> A host may have multiple default gateways on the same "interface".
> However, those gateways should be usable interchangeably. All of those gateways
> should have the same "values" for the properties above. Otherwise, I would
> argue the network is broken and/or the host is misconfigured. In other words, it
> can pick any of its live gateways outbound, and may receive packets from any
> of those gateways in the other direction. If I'm not mistaken, the IETF
> IPv6 wireless network is an example of this.

There are obvious examples where multiple gateways make sense. For example, a home network could have routers attached to different broadband providers, with different bandwidth and different connectivity characteristics. Rémi, you may believe that this is a configuration error, but it is only an error because our protocols do not handle that configuration very well. I would expect MIF to address the problem and suggest fixes...

-- Christian Huitema

---

From: "Rémi Denis-Courmont" <[email-masked]>
Date: Mon, 27 Apr 2009 10:25:36 +0300

On Saturday 25 April 2009 22:32:35 ext Christian Huitema wrote:
> > However, those gateways should be usable interchangeably. All of those
> > gateways should have the same "values" for the properties above.
> > Otherwise, I would argue the network is broken and/or the host is
> > misconfigured. In other words, it can pick any of its live gateways
> > outbound, and may receive packets from any of those gateways in the other
> > direction. If I'm not mistaken, the IETF IPv6 wireless network is an
> > example of this.
>
> There are obvious examples where multiple gateways make sense. For example,
> a home network could have routers attached to different broadband
> providers, with different bandwidth and different connectivity
> characteristics. Rémi, you may believe that this is a configuration error,
> but it is only an error because our protocols do not handle that
> configuration very well.

It is a configuration error. If only because existing devices on the network 
assume that those gateways work the way I said, interchangeably.

> I would expect MIF to address the problem and
> suggest fixes...

I doubt MIF can solve backward compatibility.

---

From: Markku Savela <[email-masked]>
Date: Mon, 27 Apr 2009 12:42:27 +0300

> From: "=?iso-8859-1?q?R=E9mi?= Denis-Courmont" <[email-masked]>

> > There are obvious examples where multiple gateways make sense. For
> > example, a home network could have routers attached to different
> > broadband providers, with different bandwidth and different
> > connectivity characteristics.

Exactly the configuration I've currently at home. To make it work on
Linux, I need to use few ip table rules to direct packets correctly.

> It is a configuration error. If only because existing devices on the
> network assume that those gateways work the way I said,
> interchangeably.

It just shows some lack of vision, which should be fixed.. Hopefully
MIF can do it.

> I doubt MIF can solve backward compatibility.

Hmm.. wouldn't give up backward compatibility without trying. And if
not 100%, maybe good enough level can be reached...