Subject: Re: [multipathtcp] Interesting paper

From: Joe Touch <[email-masked]>
Date: Tue, 03 Nov 2009 13:41:06 -0800

marcelo bagnulo braun wrote:
> Interesting... the charter doesn't have IPv4 nor IPv6 in it.
> I assumed that we were chartered to work on both, don't we?

I thought all new protocols were *required* to address at least IPv6.

Joe

---

From: Mark Handley <[email-masked]>
Date: Tue, 3 Nov 2009 21:50:08 +0000

> I thought all new protocols were *required* to address at least IPv6.

We definitely intend MP-TCP to work for both v4 and v6.  More
debatable is whether we want to permit mixed v4/v6 connections (some
v4 subflows, some v6, in the same connection).  I'm unconvinced.

 - Mark

---

From: Scott Brim <[email-masked]>
Date: Tue, 03 Nov 2009 16:56:48 -0500

> v4 subflows, some v6, in the same connection).  I'm unconvinced.

That would be fun to do in the API.

---

From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 04 Nov 2009 08:50:39 +0100

> v4 subflows, some v6, in the same connection).  I'm unconvinced.
Do you expect any special difficulty on supporting this?
I mean, this would be useful for dual stack hosts.
If there is no special difficulty, i would go for that.

Regards, marcelo

---

From: Scott Brim <[email-masked]>
Date: Wed, 04 Nov 2009 05:43:43 -0500

> If there is no special difficulty, i would go for that.

IMHO the issue is in the API.

---

From: Michael Tüxen <[email-masked]>
Date: Wed, 4 Nov 2009 12:43:33 +0100

> Do you expect any special difficulty on supporting this?
At least in SCTP there is no problem in supporting it...
> _______________________________________________
> multipathtcp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/multipathtcp
>

---

From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 04 Nov 2009 13:35:25 +0100

> IMHO the issue is in the API.
ok, i am very very far from being an API expert

with that in mind

I understand that we have 2 cases: the current API (i.e. no MPTCP 
aware), there should be no problem, the usage of "locator" of another 
address family should remain transparent to the application, correct?

The MPTCP extended API. In this case i understnad we should distinguish 
whether the connection was open as an IPv6 connection or as an IPv4 
connection.
If it was open as an IPv6 connection, i think there is no problem, since 
IPv4 addresses can be represented as IPv4-mapped addresses, so the API 
allows to handle both IPv4 and IPv6 addresses in the same way (i.e. as 
IPv6 addresses). some degree of care should be taken not to form 
incompatible address pairs with one IPv4 and one IPv6 address.
If it was opened as an IPv4 connection, then i thin more thought is needed.

Regards, marcelo

---

From: Rémi Després <[email-masked]>
Date: Wed, 4 Nov 2009 18:44:37 +0100

Le 3 nov. 09 à 22:50, Mark Handley a écrit :

> We definitely intend MP-TCP to work for both v4 and v6.

Sure, as TCP is above IP, MPTCP will naturally work on both.

But isn't the real question whether the protocol will support NAT  
traversals?

If yes, it would be a pity to make the IPv6 solution more complex  
than needed just to support NAT traversals.

Can't we expect that before MPTCP is agreed on and deployed, the vast  
majority of multihomed hosts will have IPv6?

RD

---

From: William Herrin <[email-masked]>
Date: Wed, 4 Nov 2009 16:10:48 -0400

On Wed, Nov 4, 2009 at 8:35 AM, marcelo bagnulo braun
<[email-masked]> wrote:
> allows to handle both IPv4 and IPv6 addresses in the same way (i.e. as IPv6
> addresses). some degree of care should be taken not to form incompatible
> address pairs with one IPv4 and one IPv6 address.

Hi Marcelo,

We could just set up the extended API to be protocol agnostic from the
start, yes? We don't routinely tell it which protocol to use; it tells
us which protocols it has used. Which at some point in the distant
future may be IPv12 and we'd like the then-legacy apps to still behave
in a reasonable fashion.

Main difference would be passing textual representations through the
API instead of protocol-specific structures.

On Wed, Nov 4, 2009 at 1:44 PM, Rémi Després <[email-masked]> wrote:
> If yes, it would be a pity to make the IPv6 solution more complex than
> needed just to support NAT traversals.

Hi Rémi ,

If subflows are basically TCP streams joined to the larger TCP stream
then we can't expect the connection's acceptor to make new connections
to the initiator. That'll blow up with any firewall, not just NAT.
That was a hard lesson with active-mode FTP too. I would hope we don't
have to learn it again.

If we assume that only the initiator will start new subflows then
client-side NAT (the initiator's end) only really raises an
authentication-by-source-address issue. Which is pretty weak
authentication to begin with so I'd hate to see it derail
compatibility with client-side NAT.

That only leaves server-side NAT. Unless someone identifies a really
elegant solution for handling legacy server-side NAT, my view is:
detect and fail.

Include the destination address in a TCP option when you first
initiate the connection and if the server sees a different address
than you do (because it passed through a NAT that wasn't
MPTCP-compatible enough to change the option too) then MPTCP is
disabled for that connection. As for folks who want to run MPTCP in a
server-side NAT environment, that's the NAT box's problem and the
system administrator's configuration problem, not ours.

> majority of multihomed hosts will have IPv6?

No. Making any prediction about IPv6 deployment beyond "slow" would be
unwise. That most especially includes predictions about whether any
significant portion of IPv6 users will employ NAT.

Regards,
Bill Herrin

-- 
William D. Herrin ................ [email-masked]  [email-masked]
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004