Re: [multipathtcp] potential MPTCP proxy charter item

Olivier Bonaventure <> Sun, 06 November 2016 21:07 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F0F3812969C for <>; Sun, 6 Nov 2016 13:07:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.321
X-Spam-Status: No, score=-4.321 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id pZoSoZDotKZO for <>; Sun, 6 Nov 2016 13:06:58 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 63BE012968F for <>; Sun, 6 Nov 2016 13:06:58 -0800 (PST)
Received: from [] (unknown []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: by (Postfix) with ESMTPSA id 3E26667DB5A; Sun, 6 Nov 2016 22:06:50 +0100 (CET)
DKIM-Filter: OpenDKIM Filter v2.9.2 3E26667DB5A
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;; s=selucl; t=1478466410; bh=yUgn2wArZVTzty/TbRF1g6hfmgEl8dCyeoRvJSehKX0=; h=Reply-To:Subject:References:To:Cc:From:Date:In-Reply-To; b=raD2EUoxVrM4sjAyfP6QTlKw04KNYeR64CVHBEIm2rglIBezc6F0CG+9BwtvglJ4B bBeoIUoPRnZsVUiFIDU90yeFjeF7PUnQpuv53CifuKG89TTzAttAMaf82ExMbvwKKc v2ltcEdxgKdb9jAOT+tEgKAEr9JgF0dSiAF0qB6w=
X-Virus-Status: Clean
X-Virus-Scanned: clamav-milter 0.99 at smtp-2
References: <> <> <> <> <787AE7BB302AE849A7480A190F8B933009D9577B@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <22907_1476946228_58086934_22907_5464_1_a7bca8d2-7656-4ff0-9f01-cf307f017148@OPEXCLILM42.corporate.adroot.infra.ftgroup> <> <> <b8bfd5c6-21eb-4c4f-879a-851c3a71792a@OPEXCLILM31.corporate.adroot.infra.ftgroup> <> <787AE7BB302AE849A7480A190F8B933009D9CA84@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <> <787AE7BB302AE849A7480A190F8B933009DAAA88@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <>
To: Alan Ford <>,
From: Olivier Bonaventure <>
Message-ID: <>
Date: Sun, 06 Nov 2016 22:06:49 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.4.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Sgsi-Spamcheck: SASL authenticated,
X-SGSI-MailScanner-ID: 3E26667DB5A.A32D6
X-SGSI-MailScanner: Found to be clean
X-SGSI-Spam-Status: No
Archived-At: <>
Cc: "" <>
Subject: Re: [multipathtcp] potential MPTCP proxy charter item
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Multi-path extensions for TCP <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 06 Nov 2016 21:07:01 -0000


>> [Med] The scenario is about an MPTCP-capable host located behind a
>> CPE(MCP). This is typically an iPhone connected behind a CPE. We want
>> that MPTCP communications issued from this host are forwarded as such
>> to their destination without soliciting the downstream MCP.
> OK I understand this scenario now, it is special for implicit mode,
> since if the CPE was acting in explicit mode, it would address the
> packets to the MCP.
> What are the benefits of using implicit mode in this scenario? This is
> so you can target it to an MCP without knowing the target address. Are
> there any other reasons why this would be used rather than explicit
> mode? And what sort of deployment would this scenario exist in?

The implicit mode was suggested by network operators. The MCP resides on 
the path between the CPE and the destination server. The main benefit of 
the implicit mode is that the MCP does not need to perform any address 
translation. Given all the complications with NAT, this is a huge 
benefit, in particular in IPv6 deployments. In IPv4 deployments, the CPE 
can use a single address and there is no need for a pool of IPv4 
addresses on the MCP.

In implicit mode, the MCP needs to distinguish between an MP_CAPABLE 
generated by the endhost and an MP_CAPABLE added by the CPE.