Subject: [mif] Preferring IPv4 interface over IPv6 interface? A problem to be covered?

From: <[email-masked]>
Date: Sat, 7 Aug 2010 15:26:25 +0200

Mif,

Currently hosts generally prefer IPv6 over IPv4 communications. However, a multi-homed host may have IPv6 available only on a less preferred interface. For example, host's destination may be reachable over both IPv4 and IPv6, but the host has an IPv6-only cellular (maybe less preferred) and IPv4-only local WLAN interfaces (maybe more preferred).

Do you think in such a case a MIF host should actually prefer IPv4 communications instead of IPv6? Current single homed hosts would probably have chosen to use WLAN for all communications anyway.

Do you think this preference should be part of a distributed policy, or something the host just should make its own mind about?

Best regards,

Teemu

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 08 Aug 2010 09:57:49 +1200

Teemu,

Shouldn't the decision about that be part of the RFC 3484 update
discussion over in 6man?

Or should we logically separate the question of 'preferred interface'
from the question of 'preferred address prefix'? Then it can be a local
policy issue whether you give priority to the interface choice or to the
prefix choice. (Or to measured performance.)

Regards
   Brian

On 2010-08-08 01:26, [email-masked] wrote:
> ------------------------------------------------------------------------
> 
> _______________________________________________
> mif mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mif

---

From: Ted Lemon <[email-masked]>
Date: Sat, 7 Aug 2010 18:36:47 -0400

On Aug 7, 2010, at 5:57 PM, Brian E Carpenter wrote:
> Then it can be a local

It can't be a matter of local policy, because there is no mechanism for announcing that policy.   It should not be the case that IPv4 is preferred over IPv6, or that IPv6 is preferred over IPv4; rather, all options should be tried, and the option that works best should be taken.

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 08 Aug 2010 10:57:54 +1200

On 2010-08-08 10:36, Ted Lemon wrote:
> It can't be a matter of local policy, because there is no mechanism for announcing that policy.

There's very likely to be a defined mechanism for announcing local
RFC3484(bis) policy. There's nothing to prevent such a mechanism also
defining interface preferences.

> It should not be the case that IPv4 is preferred over IPv6, or that IPv6 is preferred over IPv4; rather, all options should be tried, and the option that works best should be taken.

That's a matter of opinion. There might well be a management decision to
have a policy, or there might be a cost-based policy. All other things
being equal, a REAP-like process to choose the best performance would
be OK too. I don't think it's for the IETF to decide which approach
suits the world best.

    Brian

---

From: Ted Lemon <[email-masked]>
Date: Sat, 7 Aug 2010 23:02:18 -0400

On Aug 7, 2010, at 6:57 PM, Brian E Carpenter wrote:
> There's nothing to prevent such a mechanism also

Yes, there is.   Presumably, if there is some difference between the interfaces, it will be because each interface is connected to a network managed by a different entity.   Thus, there is no reasonable basis for assuming that what either entity defines as a policy is in fact valid for the node.

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 08 Aug 2010 16:56:56 +1200

> Yes, there is.   Presumably, if there is some difference between the interfaces, it will be because each interface is connected to a network managed by a different entity.   Thus, there is no reaso…

That could well be, in which case the host's own policy should predominate.
I guess my point is that we don't know the deployment scenario, so we need
mechanisms that can be applied in a wide range of scenarios, not just yours
or mine.

   Brian

---

From: Scott W Brim <[email-masked]>
Date: Sun, 8 Aug 2010 08:26:06 -0400

I see three different factors:

The multihomed device may need to blend policy from multiple networks.  We
do want to support cases within a single administration but an endpoint must
be able to handle connectivity to arbitrary unexpected networks as well.
MIF covers this well.

Modulo policy the device needs to test actual connectivity. The "happy
eyeballs" approach seems most effective.

Connectivity doesn't mean actual goodput, and the only way to test the
usefulness of a path, which changes over time,  is with real data. Of the
possibilities I would recommend SCTP CMT (or perhaps multipath TCP). It will
soon be turned on by default in FreeBSD.

If we know we have the second and third, that allows us to look at the first
with a different prrspective.

I'm away from any decent Internet access but I'll join in a more thorough
discussion in a few days.

Scott

On Aug 7, 2010 9:26 AM, <[email-masked]> wrote:

 Mif,

Currently hosts generally prefer IPv6 over IPv4 communications. However, a
multi-homed host may have IPv6 available only on a less preferred interface.
For example, host’s destination may be reachable over both IPv4 and IPv6,
but the host has an IPv6-only cellular (maybe less preferred) and IPv4-only
local WLAN interfaces (maybe more preferred).

Do you think in such a case a MIF host should actually prefer IPv4
communications instead of IPv6? Current single homed hosts would probably
have chosen to use WLAN for all communications anyway.

Do you think this preference should be part of a distributed policy, or
something the host just should make its own mind about?

Best regards,

Teemu

---

From: Rémi Després <[email-masked]>
Date: Mon, 9 Aug 2010 10:59:35 +0200

Hi, Teemu and Brian,

> Shouldn't the decision about that be part of the RFC 3484 update

Concerning the choice between IPv4 and IPv6 depending on which prefixes are available, this 6man discussion is IMHO the right place.

> from the question of 'preferred address prefix'?

In my understanding, we should, to keep the problem manageable.
 
> prefix choice.

Unless I miss something, recommending to first choose the interface, and then a source-destination couple available at this interface, can be recommended as a basic requirement.
It apparently works in typical scenarios, and anything else would in my understanding be far more complex. 

> (Or to measured performance.)

Later maybe, but for a start, let's "Keep It Simple, Stupid".

>> Do you think in such a case a MIF host should actually prefer IPv4 communications instead of IPv6? Current single homed hosts would probably have chosen to use WLAN for all communications anyway.

At least when both source and destination can be public IPv4, using them independently of any IPv6 availability seems to me the right choice.

If the IPv4 source can only be private IPv4 while both source and destination can be public IPv6, choosing IPv6 could be recommended because it should preserves e2e transparency.

I said should because of danger that some deployments would have NAT64s with Network-Specific Prefixes;  
The end result would be that hosts could no longer distinguish really e2e transparent native addresses from addresses that are IPv4-embeded IPv6 addresses (a terrible danger for IPv6 IMHO).

>> Do you think this preference should be part of a distributed policy, or something the host just should make its own mind about?

Choice 2, at least to start with.

Regards,
RD

---

From: <[email-masked]>
Date: Mon, 9 Aug 2010 15:51:15 +0200

Hi,

> -----Original Message-----
> From: ext Rémi Després [mailto:[email-masked]]
> Sent: 09. elokuuta 2010 12:00
> To: Savolainen Teemu (Nokia-MS/Tampere); Brian Carpenter
> Cc: Bajko Gabor (Nokia-CIC/MtView); [email-masked]
> Subject: Re: [mif] Preferring IPv4 interface over IPv6 interface? A
> problem to be covered?
> 
> Concerning the choice between IPv4 and IPv6 depending on which prefixes
> are available, this 6man discussion is IMHO the right place.

Agree.

> In my understanding, we should, to keep the problem manageable.

There is a current practice to deal with problems as has been described (stick to use one of the available interface). We shall improve, and for that we must walk into the land current implementations have not dared to go:)

> Unless I miss something, recommending to first choose the interface,
> and then a source-destination couple available at this interface, can
> be recommended as a basic requirement.

If I understood your point correctly, that is the current practice. The host chooses an interface and then does its best with it, while...

> understanding be far more complex.

.. in MIF we want to improve that and allow all interfaces to be used when doing source-destination selection. Possibly added with weighting addresses of some interface higher than of others (i.e. having preferred interface but not limiting to it).

> Later maybe, but for a start, let's "Keep It Simple, Stupid".

The current practice is simple, we want something smart now:)

> If the IPv4 source can only be private IPv4 while both source and
> destination can be public IPv6, choosing IPv6 could be recommended
> because it should preserves e2e transparency.

This hits my point. What I'm saying is that in some scenarios host should prefer private NAT44444'ed IPv4 address over native IPv6, if the application does not really care (uses e.g. connectbyname-like calls), and the physical interface providing IPv4 is preferred over the physical interface providing IPv6.
 
> The end result would be that hosts could no longer distinguish really
> e2e transparent native addresses from addresses that are IPv4-embeded
> IPv6 addresses (a terrible danger for IPv6 IMHO).

The NSP can be detected by the host OS or even by application itself, as was discussed in behave WG. It requires some effort, though...

Best regards,

Teemu

---

From: Rémi Després <[email-masked]>
Date: Mon, 9 Aug 2010 17:47:57 +0200

Thanks Teemu for your comments.
Continued discussion below.

> This hits my point. What I'm saying is that in some scenarios host should prefer private NAT44444'ed IPv4 address over native IPv6, if the application does not really care (uses e.g. connectbyname-…

Connect by name is indeed a promising approach (BTW, I support Christian Vogt's proposal of a name oriented socket interface).

If the best interface is chosen first (e.g. Wifi vs 3G+) the remaining preference could be, for outgoing connections:
- SRC&DST public v4
- SRC&DST public v6
- DST public v4, SRC private v4
- DST public v6, SRC private v6
- DST private v4, SRC private v4 
- DST private v6, SRC private v6

This would only solve a subset of the mif general problem, but, if agreed, would at least be a guidance on what to do on a single dual-stack interface.
Besides, inbound connections received on some interface would use this interface for outgoing traffic.

Scenarios where this isn't sufficient need IMHO to be identified to usefully discuss more sophisticated mechanisms.

> The NSP can be detected by the host OS or even by application itself, as was discussed in behave WG. It requires some effort, though...

That's where I see a danger.
As long as there isn't a clean and safe conclusion to this discussion, the danger remains to badly destroy the guarantee of e2e transparency for SRC&DST public IPv6 addresses.

IPv6-only client hosts and IPv6-only applications SHOULD only communicate with IPv6-enabled peers.
It shouldn't be possible that dual-stack hosts that use public IPv6 addresses, SRC&DST, reach IPv4 servers (via NAT64s) without knowing that e2e transparency won't be available.

Said differently, all hosts that may need connectivity with some servers that don't have IPv6 enabled  SHOULD remain DUAL-STACK. 
They may get their IPv4 addresses, public or private, across tunnels over IPv6, but in no case their public IPv6 traffic should be permitted to traverse NAT64s as long as their IPv6-capable applications have no way to know it.

Cheers,
RD

---

From: Scott Brim <[email-masked]>
Date: Wed, 11 Aug 2010 17:12:02 -0400

On 08/09/2010 09:51 EDT, [email-masked] wrote:
> This hits my point. What I'm saying is that in some scenarios host
> should prefer private NAT44444'ed IPv4 address over native IPv6, if
> the application does not really care (uses e.g. connectbyname-like
> calls), and the physical interface providing IPv4 is preferred over
> the physical interface providing IPv6.

(Back from vacation ...) My concern with much of this discussion is that
it seems to treat the problem as if the answer has to be figured out a
priori and then set as policy for a particular configuration, not taking
actual performance into account.  Networks are fluid, but hosts can
observe their environment and adapt as the environment changes.  A
behavior choice at one moment may not be the correct one in a few seconds.

Scott

---

From: <[email-masked]>
Date: Wed, 11 Aug 2010 23:29:40 +0200

Hi guys,

This is a very interesting discussion, but it seems to me that it is a 6man discussion and that we digress from the MIF problem statement. If I browse the emails, it seems that _for MIF_ the question is (quoting Teemu):

Should we add the case where destination is dual-stack reachable but with different characteristics (e.g. Costs) for different AFs. 

It is true that it is slightly different from the problem statement's routing section which focuses on the selection of the path to reach a single IP address. However I think this use-case is specific to V4/V6 cohabitation and is out of MIF scope. MIF could tackle with a use-case where a server could be reachable via two IP addresses. However, I do not see this use-case realistic. Other opinion?

BR,
Pierrick

> -----Message d'origine-----
> De : [email-masked] [mailto:[email-masked]] De la part de Rémi
> Després
> Envoyé : lundi 9 août 2010 17:48
> À : [email-masked]
> Cc : Gabor Bajko; [email-masked]
> Objet : Re: [mif] Preferring IPv4 interface over IPv6 interface? A
> problemto be covered?
> 
> > There is a current practice to deal with problems as has been described
> (stick to use one of the available interface). We shall improve, and for
> that we must walk into the land current implementations have not dared to
> go:)
> >
> >>> Then it can be a local
> > If I understood your point correctly, that is the current practice. The
> host chooses an interface and then does its best with it, while...
> >
> > .. in MIF we want to improve that and allow all interfaces to be used
> when doing source-destination selection. Possibly added with weighting
> addresses of some interface higher than of others (i.e. having preferred
> interface but not limiting to it).
> >
> should prefer private NAT44444'ed IPv4 address over native IPv6, if the
> application does not really care (uses e.g. connectbyname-like calls), and
> the physical interface providing IPv4 is preferred over the physical
> interface providing IPv6.
> 
> Connect by name is indeed a promising approach (BTW, I support Christian
> Vogt's proposal of a name oriented socket interface).
> 
> If the best interface is chosen first (e.g. Wifi vs 3G+) the remaining
> preference could be, for outgoing connections:
> - SRC&DST public v4
> - SRC&DST public v6
> This would only solve a subset of the mif general problem, but, if agreed,
> would at least be a guidance on what to do on a single dual-stack
> interface.
> Scenarios where this isn't sufficient need IMHO to be identified to
> usefully discuss more sophisticated mechanisms.
> 
> 
> > The NSP can be detected by the host OS or even by application itself, as
> was discussed in behave WG. It requires some effort, though...
> 
> As long as there isn't a clean and safe conclusion to this discussion, the
> danger remains to badly destroy the guarantee of e2e transparency for
> SRC&DST public IPv6 addresses.
> 
> It shouldn't be possible that dual-stack hosts that use public IPv6
> addresses, SRC&DST, reach IPv4 servers (via NAT64s) without knowing that
> e2e transparency won't be available.
> 
> Said differently, all hosts that may need connectivity with some servers
> that don't have IPv6 enabled  SHOULD remain DUAL-STACK.
> They may get their IPv4 addresses, public or private, across tunnels over
> IPv6, but in no case their public IPv6 traffic should be permitted to
> traverse NAT64s as long as their IPv6-capable applications have no way to
> know it.
> 
> Cheers,
> RD
> 
> 
> 
> 
> >
> > Best regards,
> >
> > Teemu
> 
>

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 12 Aug 2010 09:38:38 +1200

> behavior choice at one moment may not be the correct one in a few seconds.

I completelly agree. As RFC3484 experience shows, a default policy and no
run-time flexibility clearly create bad user experience. I can't guess how
many times I've switched the network.dns.disableIPv6 flag in Firefox
around as I've travelled with my laptop. I would much prefer my computer
to make this decision automatically based on performance.

    Brian

    Brian

---

From: Yuri Ismailov <[email-masked]>
Date: Thu, 12 Aug 2010 14:27:50 +0200

Hi all,
The discussion is interesting but isn't it obvious that an application
chooses an interface first and then preferred address family.
It is not possible to choose IPv6 GPRS for 128K coded stream. It will
not work.

/yuri

---

From: Ted Lemon <[email-masked]>
Date: Thu, 12 Aug 2010 10:18:40 -0400

> It is not possible to choose IPv6 GPRS for 128K coded stream. It will

I think that the naive application does not choose an interface at all--it leaves that decision up to the operating system.   And my personal belief is that "choosing an interface" is actually the wrong choice, as is "choosing an address family."   My preferred solution is to see what gets me to a connected state with the desired endpoint first, and use that.

This is why I pushed back so hard on the problem statements in the meeting--the minute you start talking about the problem in terms of how to choose the right interface, you're already restricting the set of possible solutions, and you've already excluded what I consider to be the correct solution.

---

From: Yuri Ismailov <[email-masked]>
Date: Thu, 12 Aug 2010 16:45:55 +0200

On 08/12/10 16:18, Ted Lemon wrote:
> My preferred solution is to see what gets me to a connected state with the desired endpoint first

And how this is different from the choice of interface which gets you
connected and an application will most probably work?

/yuri

---

From: Ted Lemon <[email-masked]>
Date: Thu, 12 Aug 2010 11:11:35 -0400

> connected and an application will most probably work?

What I'm saying is that you choose *all* interfaces, try each one, and use the one that successfully connects first.   If one interface is more expensive than the other, you might give the cheaper one a head start.   But you don't *choose* an interface.   You just take the socket that successfully connected, and ditch the others.

---

From: Zhen Cao <[email-masked]>
Date: Thu, 12 Aug 2010 23:20:02 +0800

> This is a very interesting discussion, but it seems to me that it is a 6man discussion and that we digress from the MIF problem statement. If I browse the emails, it seems that _for MIF_ the questi…

I'd more like to take this as a mif discussion than a 6man discussion,
considering the policy and source address selection becomes much more
complex in mif context, and 6man targets a specific scenario.

---

From: Rémi Després <[email-masked]>
Date: Thu, 12 Aug 2010 18:34:00 +0200

Hi Teemu,
Comments in line.

Le 7 août 2010 à 15:26, <[email-masked]> <[email-masked]> a écrit :

> Mif,
>  
> Currently hosts generally prefer IPv6 over IPv4 communications. However, a multi-homed host may have IPv6 available only on a less preferred interface. For example, host’s destination may be reachable over both IPv4 and IPv6, but the host has an IPv6-only cellular (maybe less preferred) and IPv4-only local WLAN interfaces (maybe more preferred).
>  

If an interface that gives access to the Internet is considered the best, the simplest approach is IMHO to use it, with the best address family available at this interface.

The choice of the AF should depend not only on v4 vs v6, but also on  private vs public address spaces in each family, and in the case of public v4 on full vs restricted port sets, and possibly on the upper layer protocol (e.g. IPv4, private or public, for the mail, public IPv6 for IPsec). 

> Do you think this preference should be part of a distributed policy, or something the host just should make its own mind about?

It can be both:
1. The host default choice should be applicable if no distributed policy is received
2. The distributed policy, if any, may supersede or be superseded by the host choice, depending on what the host is ready to accept. 

Specifying host default choices would IMHO be a good way to start.

Regards,
RD

---

From: Scott Brim <[email-masked]>
Date: Thu, 12 Aug 2010 13:07:07 -0400

On 08/12/2010 11:11 EDT, Ted Lemon wrote:
> What I'm saying is that you choose *all* interfaces, try each one,
> and use the one that successfully connects first.   If one interface
> is more expensive than the other, you might give the cheaper one a
> head start.   But you don't *choose* an interface.   You just take
> the socket that successfully connected, and ditch the others.

or you try a subset, where the subset is defined by other policies (e.g.
"when your battery is low, don't fire up a lot of extra radios").

---

From: Ted Lemon <[email-masked]>
Date: Thu, 12 Aug 2010 13:26:25 -0400

> "when your battery is low, don't fire up a lot of extra radios").

Sure, but if you're choosing between two radios, how do you choose?   This is such a tiny corner case that I don't think it's worth exploring: most devices nowadays aren't that tight on battery life, and I care more about getting my bits than I do about what happens when my battery dies.   That's why I have a charger in the car and another in my backpack...

However, I will admit that I might change my tune if there were more data on this.   Right now at least on the iPhone, I think it only tries one radio at a time, so I don't really have any data on how big an impact trying both would have.

---

From: Yuri Ismailov <[email-masked]>
Date: Fri, 13 Aug 2010 08:51:40 +0200

On 08/12/10 17:11, Ted Lemon wrote:
> hat I'm saying is that you choose *all* interfaces, try each one, and use the one that successfully connects first.

Hmmm... IMHO it would not be too nice to try each. You just get an info
about all interfaces and evaluate only those, which let you get
connected based on the status of interface, existence of the default
route for the interfaces and DNS availability for that interface. What
I'm saying is that the knowledge about interfaces is there when you
start making a choice. The reason for choice is that there may be more
than one, which gets you connected.

/yuri

---

From: Ted Lemon <[email-masked]>
Date: Fri, 13 Aug 2010 08:27:31 -0400

On Aug 13, 2010, at 2:51 AM, Yuri Ismailov wrote:
> Hmmm... IMHO it would not be too nice to try each.

Why not?

> than one, which gets you connected.

Why is that a problem?   Suppose you connect with every combination you try.   Why is that bad?   Just drop all but the first connection, or if you have a pricing scheme where one interface is cheaper than another, allow a period of time to pass before giving up on the cheaper interface--if your connection on that interface takes 500ms longer to complete the handshake, use it anyway.   But if you still don't have an answer after 500ms (or whatever timeout you set), use the connection that answered.

In the ssh client I'm working on for my iPad, I really want to get all the way through to a finished, authenticated connection before I make the decision, because it's possible that I'll get an MiTM attack on one link, and no MiTM attack on the other.   In that case, even if the MiTM-free connection takes longer, that's still the one I want.   If I dropped the good connection before authenticating, then even though I detected the MiTM attack on the other link, it would still prevent me from using ssh.

But in the case of an unauthenticated web page, all you really care about is that you get a connection as quickly as possible.   Web servers are armored against DoS attacks, because they have to be.   The load presented by an extra three connections, for example, from every single device that legitimately uses them, will be much less than the load presented by DoS attacks (SYN flooding) they are designed to weather. The web server doesn't have to do any work until you tell it what page to look up, and that happens *after* you've completed the connection process.  Dropped connections prior to that point are cheap.

So I think there's no logical basis for the assertion that it's not nice to try every possible means of connection all at once.

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 14 Aug 2010 09:01:14 +1200

On 2010-08-14 00:27, Ted Lemon wrote:
...
> So I think there's no logical basis for the assertion that it's not nice to try every possible means of connection all at once.

Actually this is susceptible to more than theorising, since we have shim6/REAP as
a worked example. It turns out that there is some advantage to trying several
address pairs in parallel, compared to one after another, in terms of the
total time to recover connectivity after a failure, and no significant
penalty in traffic load.

H. Naderi and B. Carpenter, A Performance Study on REAchability Protocol in Large
Scale IPv6 Networks , Second International Conference on Computer and Network
Technology (ICCNT 2010), Bangkok, (April 2010) 28-32.

    Brian

---

From: <[email-masked]>
Date: Sat, 14 Aug 2010 08:19:31 +0200

Hi Yuri,

That is current practice: either OS or application chooses interface that is used, and only after that address families available in that interface are chosen from. This works fine if you are happy to use only one interface at the time for an application (current devices pretty much do this), or willing to configure/provision application specific settings to the host (if it is possible on a given host).

I don't think in MIF we would be forbidding application specific configuration or denying applications limiting interfaces they use. They could do that e.g. by binding their connections to source addresses of the preferred interfaces, or by some other means (like requesting "Connection Manager" to open WLAN connection).

Teemu

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> ext Yuri Ismailov
> Sent: 12. elokuuta 2010 15:28
> To: [email-masked]

---

From: <[email-masked]>
Date: Sat, 14 Aug 2010 08:21:38 +0200

Hi Rémi,

> communications instead of IPv6? Current single homed hosts would
> probably have chosen to use WLAN for all communications anyway.
> 
> If an interface that gives access to the Internet is considered the
> best, the simplest approach is IMHO to use it, with the best address
> family available at this interface.

In this case both (all) interfaces would give access to Internet, just different kind. I.e. in this case I was not talking about interfaces leading to different domains.
 
> The choice of the AF should depend not only on v4 vs v6, but also on
> private vs public address spaces in each family, and in the case of
> public v4 on full vs restricted port sets, and possibly on the upper
> layer protocol (e.g. IPv4, private or public, for the mail, public IPv6
> for IPsec).

Yes, but sometimes the used physical interface may be higher priority than any of the above.

Teemu

---

From: Rémi Després <[email-masked]>
Date: Sat, 14 Aug 2010 08:59:40 +0200

> Yes, but sometimes the used physical interface may be higher priority than any of the above.

It seems we agree.
(I meant choosing an AF among those available *at the previously chosen physical interface*).

RD

---

From: <[email-masked]>
Date: Tue, 17 Aug 2010 06:06:45 +0200

Yuri is right. When I have a choice of interfaces and I know beforehand that I could connect using either one, I want to make a wise choice based on the characteristics of the interfaces, before connecting. Trying them one by one consumes the battery and takes time (which translates to bad user experience).

The possibility of choosing between v4 and v6 on a given interface may not be possible, as some 3G carriers seem to prefer transitioning to v6-only, while wifi hotspots are, and will probably remain for a long time, v4-only (and yes, there is a way to discover the characteristics of the interface before attaching/associating to it). Ie, choosing the interface implicitly means choosing the IP version.

Thus, a device has to balance between preferring v6 or preferring a possibly lower cost v4 (interface).

- gabor

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Ted Lemon
Sent: Friday, August 13, 2010 5:28 AM
To: Yuri Ismailov
Cc: [email-masked]
Subject: Re: [mif] Preferring IPv4 interface over IPv6 interface? A problem to be covered?

Why not?

---

From: Ted Lemon <[email-masked]>
Date: Tue, 17 Aug 2010 00:26:19 -0400

On Aug 17, 2010, at 12:06 AM, <[email-masked]> <[email-masked]> wrote:
> When I have a choice of interfaces and I know beforehand that I could connect using either one, I want to make a wise choice based on the characteristics of the interfaces, before connecting.

How could you know beforehand?   That's the problem.   The mere fact that you have an IP address configured on that interface does not mean that you will succeed when you try to use it to connect.

---

From: <[email-masked]>
Date: Tue, 17 Aug 2010 06:29:29 +0200

I use L2 procedures beforehand to discover if the IP version is supported or not. If it is, then I'll be able to use it after connecting.

- gabor

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 17 Aug 2010 16:30:36 +1200

Gabor,

I have a little experience with a device that can do both GPRS and WiFi,
and happens to contain IPv6 code. When I try to link to a URL, it
will ask me to select an "access point" and I have to choose (for example)
"Easy WLAN" or "xxx GPRS". In a random situation, I have no idea which one
will work. If I choose "Easy WLAN" it fires up the WiFi radio, and then
I can find out if I can get service, and even whether that service is
v4 or v6 or dual stack. If this fails, I try again, manually, with GPRS,
firing up a second radio.

1. I can see no way to set a default preference between WiFi
and GPRS. The choice is entirely experimental.

2. I am quite certain that a simple connection manager in the device
could fire up both radios, test automatically for the best connectivity,
and close down the other radio, for less battery drain than the manual
process, which is very slow and also lights up the screen, another
drain on the battery.

I really don't see how a priori preferences can solve the problem,
except as a tie-breaker when everything else is equal.

Regards
   Brian Carpenter

---

From: Ted Lemon <[email-masked]>
Date: Tue, 17 Aug 2010 00:35:14 -0400

> I use L2 procedures beforehand to discover if the IP version is supported or not. If it is, then I'll be able to use it after connecting.

Nono, I mean how can you know which interface will work?   What if you have an IPv4 address on both interfaces, and your destination is IPv4, but you only have IPv4 transit to the Internet on one interface.   Or for that matter, you need to connect to a firewalled host, and only have IP connectivity to the network it's on on one interface.   How do you tell?

---

From: <[email-masked]>
Date: Tue, 17 Aug 2010 06:56:07 +0200

This is why and where we need to make improvements. Fire up both interfaces wouldn't really solve the problem as the device still needs to decide which interface it wants to test first for connectivity. And once it has connectivity on the first interface, there's no reason to try the second one. Ie, the question is which interface to fire up first and test.

As to Ted's question, a test is always needed, but which interface to fire up, IP configure and test first. And if from connectivity pov would not matter which interface it is used, there are other aspects to choose one iface over the other.

- gabor

-----Original Message-----
From: ext Brian E Carpenter [mailto:[email-masked]] 
Sent: Monday, August 16, 2010 9:31 PM
To: Bajko Gabor (Nokia-CIC/MtView)
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [mif] Preferring IPv4 interface over IPv6 interface? A problem to be covered?

Gabor,

Regards
   Brian Carpenter

---

From: Ted Lemon <[email-masked]>
Date: Tue, 17 Aug 2010 10:39:52 -0400

> As to Ted's question, a test is always needed, but which interface to fire up, IP configure and test first. And if from connectivity pov would not matter which interface it is used, there are other…

You're assuming a solution: that you try one interface first, and then the second.   This means that if you guess wrong, your user experiences a minimum 90-second delay while your code figures out that it guessed wrong, because that's how long it takes for the connection to time out.   You have to try in parallel if you want the user to have a good experience in this case.   This is why I object so strongly to stating the problem as "how to pick which interface to use."

As Brian said, any heuristic that you follow other than firing up both radios is going to wind up costing more battery.   My solution when this happened to me during IETF was to quit out of the app I was using, go into the preferences app, *disable* the wifi, and then go back into my app and try again.   Added bonus: now all my www traffic, which was not being blocked by the WiFi firewall, nevertheless had to go over the 3G connection.

So not only did this solution not save me power, and not only did it require me to be knowledgeable about networking (something that no sane application writer ever assumes), it cost me a lot of extra 3G usage, which was being billed by the megabyte.

It's certainly true that if you happen to guess right, you save some power.   But the amount of power you waste by guessing wrong *once* is probably an order or two of magnitude more, and the UI problems you create are really substantial.

If, as Brian proposes, you use your preference for WiFi over 3G as a tie-breaker, then you get the cost advantages of preferring WiFi, without ever presenting a user interface to the user where they have to engage in network management, and without ever making the user wait for a connection that will never complete.