Hi Vlad, Please see inline.
Cheers, Med De : Vladimir Olteanu [mailto:vladimir.olte...@cs.pub.ro] Envoyé : vendredi 7 juillet 2017 09:19 À : BOUCADAIR Mohamed IMT/OLN; David Schinazi Cc : Int-area@ietf.org; multipathtcp Objet : Re: [Int-area] SOCKS 6 Draft Hi Mohamed, I'm replying specifically to the parts quoted below. SOCKS is used by explicit proxies; anything related to transparent proxies is beyond its scope. [Med] The definition we had so far is that "explicit proxy" means that the client is aware about the presence of the proxy and such packets are sent explicitly to that proxy. An explicit proxy can therefore behave either as transparent or non-transparent. I understand, that the current design assumes non-transparent mode. It does not preclude the deployment of anything transparent. In other words, I merely propose it as an alternative to MP_CONVERT. Discussing PCP, IPv6 source address preservation, UPnP etc. makes no sense in this context. [Med] I disagree. The support of incoming connections is one of the requirements of the MPTCP WG: "A session can be initiated from either end". This is why I'm wondering how this typical flow can be achieved with SOCKS. H<=====CPE<----------proxy<===RM +----------+ Cheers, Vlad On 7/6/2017 3:56 PM, mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com> wrote: De : Vladimir Olteanu [mailto:vladimir.olte...@cs.pub.ro] Envoyé : mercredi 5 juillet 2017 18:39 À : BOUCADAIR Mohamed IMT/OLN; David Schinazi Cc : Int-area@ietf.org<mailto:Int-area@ietf.org>; multipathtcp Objet : Re: [Int-area] SOCKS 6 Draft <SNIP> On 7/5/2017 9:00 AM, mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com> wrote: <SNIP> De : Vladimir Olteanu [mailto:vladimir.olte...@cs.pub.ro] Envoyé : mercredi 5 juillet 2017 01:35 À : BOUCADAIR Mohamed IMT/OLN; David Schinazi Cc : Int-area@ietf.org<mailto:Int-area@ietf.org>; multipathtcp Objet : Re: [Int-area] SOCKS 6 Draft <SNIP> Can you please let me know if the proposal supports the following features: * Support incoming connections (Proxy<---Remote Host): That is the proxy intercept a TCP connection that it transforms into an MPTCP one. Yes. See section 7.2. The client makes a request and then has to keep the connection to the proxy open. When the proxy accepts a connection from a remote host, it informs the client of the remote host's address and starts relaying data. SOCKS 5 has the exact same feature. You are limited to one incoming connection per request, though. [Med] In the plain mode, there is no such limitation because we are leveraging on PCP (RFC6887). * If such feature is supported, how a host located behind a CPE (Host----CPE-----Proxy----Remote Host) can instruct dynamically the CPE so that it can forward appropriately incoming connections? It does not have to. The connection on the host-proxy leg is initiated by the client. [Med] I'm not sure to understand your answer here. Let's consider that your host is using UPnP IGD to talk with the CPE to accept incoming connections + those connections are eligible to the MPTCP service. How the solution would work? <SNIP> * IPv6 source address/prefix preservation I'm not sure what you mean by that. [Med] Please see slide 18 of https://www.ietf.org/proceedings/98/slides/slides-98-mptcp-sessa-network-assisted-mptcp-03.pdf
_______________________________________________ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
