One document matched: draft-boucadair-mptcp-dhc-03.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-boucadair-mptcp-dhc-03" ipr="trust200902">
<front>
<title abbrev="DHCP for MPTCP">DHCP Options for Network-Assisted Multipath
TCP (MPTCP)</title>
<author fullname="Mohamed Boucadair" initials="M." surname="Boucadair">
<organization>France Telecom</organization>
<address>
<postal>
<street></street>
<city>Rennes</city>
<region></region>
<code>35000</code>
<country>France</country>
</postal>
<email>mohamed.boucadair@orange.com</email>
</address>
</author>
<author fullname="Christian Jacquenet" initials="C." surname="Jacquenet">
<organization>France Telecom</organization>
<address>
<postal>
<street></street>
<city>Rennes</city>
<region></region>
<country>France</country>
</postal>
<email>christian.jacquenet@orange.com</email>
</address>
</author>
<author fullname="Tirumaleswar Reddy" initials="T." surname="Reddy">
<organization abbrev="Cisco">Cisco Systems, Inc.</organization>
<address>
<postal>
<street>Cessna Business Park, Varthur Hobli</street>
<street>Sarjapur Marathalli Outer Ring Road</street>
<city>Bangalore</city>
<region>Karnataka</region>
<code>560103</code>
<country>India</country>
</postal>
<email>tireddy@cisco.com</email>
</address>
</author>
<date />
<abstract>
<t>One of the promising deployment scenarios for Multipath TCP (MPTCP)
is to enable a Customer Premises Equipment (CPE) that is connected to
multiple networks (e.g., DSL, LTE, WLAN) to optimize the usage of its
network attachments. Because of the lack of MPTCP support at the server
side, some service providers consider a network-assisted model that
relies upon the activation of a dedicated function called: MPTCP
Concentrator.</t>
<t>This document focuses on the explicit deployment scheme where the
identity of the MPTCP Concentrator(s) is explicitly configured on
connected hosts. This document specifies DHCP (IPv4 and IPv6) options to
configure hosts with Multipath TCP (MPTCP) parameters.<!--Hi Med,
My comments
1) How will this work if endpoint is MPTCP-aware but CPE is not capable of acting as MPTCP proxy ?
2)You may want to discuss how the proposed mechanism can be used with https://tools.ietf.org/html/draft-ietf-mif-mpvd-dhcp-support-01
Cheers,
-Tiru
--></t>
</abstract>
<note title="Requirements Language">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <xref
target="RFC2119">RFC 2119</xref>.</t>
</note>
</front>
<middle>
<section title="Introduction">
<t>One of the promising deployment scenarios for Multipath TCP (MPTCP,
<xref target="RFC6824"></xref>) is to enable a Customer Premises
Equipment (CPE) that is connected to multiple networks (e.g., DSL, LTE,
WLAN) to optimize the usage of such resources, see for example <xref
target="RFC4908"></xref>. This deployment scenario relies on MPTCP
proxies located on both the CPE and network sides (<xref
target="fig"></xref>). The latter plays the role of traffic
concentrator. A concentrator terminates the MPTCP sessions established
from a CPE, before redirecting traffic into a legacy TCP session.</t>
<t><figure align="center" anchor="fig"
title="“Network-Assisted” MPTCP Design">
<artwork><![CDATA[ IP Network #1
+------------+ _--------_ +------------+
| | (e.g., LTE ) | |
| CPE +======================+ |
| (MPTCP | (_ _) |Concentrator|
| Proxy) | (_______) | (MPTCP |
| | | Proxy) |------> Internet
| | | |
| | IP Network #2 | |
| | _--------_ | |
| | ( e.g., DSL ) | |
| +======================+ |
| | (_ _) | |
+-----+------+ (_______) +------------+
|
----CPE network----
|
end-nodes
]]></artwork>
</figure></t>
<t>Both implicit and explicit modes are considered to steer traffic
towards an MPTCP Concentrator. This document focuses on the explicit
mode that consists in configuring explicitly the reachability
information of the MPTCP concentrator on a host.</t>
<t>This document defines DHCPv4 <xref target="RFC2131"></xref> and
DHCPv6 <xref target="RFC3315"></xref> options that can be used to
configure hosts with MPTCP Concentrator IP addresses.</t>
<t>This specification assumes an MPTCP Concentrator is reachable through
one or multiple IP addresses. As such, a list of IP addresses can be
returned in the DHCP MPTCP option. Also, it assumes the various network
attachments provided to an MPTCP-enabled CPE are managed by the same
administrative entity.</t>
</section>
<section title="Terminology">
<t>This document makes use of the following terms:<?rfc subcompact="yes" ?></t>
<t><list style="symbols">
<t>MPTCP Concentrator (or concentrator): refers to a functional
element that is responsible for aggregating the traffic of a group
of CPEs. This element is located upstream in the network. One or
multiple concentrators can be deployed in the network side to assist
MPTCP-enabled CPEs to establish MPTCP connections via available
network attachments. <vspace blankLines="1" />On the uplink path,
the concentrator terminates the MPTCP connections <xref
target="RFC6824"></xref> received from its customer-facing
interfaces and transforms these connections into legacy TCP
connections <xref target="RFC0793"></xref> towards upstream servers.
<vspace blankLines="1" />On the downlink path, the concentrator
turns the legacy server's TCP connection into MPTCP connections
towards its customer-facing interfaces.</t>
<t>DHCP refers to both DHCPv4 <xref target="RFC2131"></xref> and
DHCPv6 <xref target="RFC3315"></xref>.</t>
<t>DHCP client denotes a node that initiates requests to obtain
configuration parameters from one or more DHCP servers.</t>
<t>DHCP server refers to a node that responds to requests from DHCP
clients.</t>
</list><?rfc subcompact="no" ?></t>
</section>
<section title="DHCPv6 MPTCP Option">
<t></t>
<section title="Format">
<t>The DHCPv6 MPTCP option can be used to configure a list of IPv6
addresses of an MPTCP Concentrator.</t>
<t>The format of this option is shown in <xref
target="dhcpv6_option"></xref>. As a reminder, this format follows the
guidelines for creating new DHCPv6 options (Section 5.1 of <xref
target="RFC7227"></xref>).</t>
<t><figure anchor="dhcpv6_option" title="DHCPv6 MPTCP option">
<artwork><![CDATA[ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_V6_MPTCP | Option-length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| ipv6-address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| ipv6-address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>The fields of the option shown in <xref
target="dhcpv6_option"></xref> are as follows:<?rfc subcompact="yes" ?></t>
<t><list style="symbols">
<t>Option-code: OPTION_V6_MPTCP (TBA, see <xref
target="iana6"></xref>)</t>
<t>Option-length: Length of the 'MPTCP Concentrator IP
Address(es)' field in octets. MUST be a multiple of 16.</t>
<t>MPTCP Concentrator IPv6 Addresses: Includes one or more IPv6
addresses <xref target="RFC4291"></xref> of the MPTCP Concentrator
to be used by the MPTCP client. <vspace blankLines="1" />Note,
IPv4-mapped IPv6 addresses (Section 2.5.5.2 of <xref
target="RFC4291"></xref>) are allowed to be included in this
option.</t>
</list></t>
<t><?rfc subcompact="no" ?>To return more than one MPTCP concentrators
to the requesting DHCPv6 client, the DHCPv6 server returns multiple
instances of OPTION_V6_MPTCP.</t>
</section>
<section title="DHCPv6 Client Behavior">
<t>Clients MAY request option OPTION_V6_MPTCP, as defined in <xref
target="RFC3315"></xref>, Sections 17.1.1, 18.1.1, 18.1.3, 18.1.4,
18.1.5, and 22.7. As a convenience to the reader, we mention here that
the client includes requested option codes in the Option Request
Option.</t>
<t>The DHCPv6 client MUST be prepared to receive multiple instances of
OPTION_V6_MPTCP; each instance is to be treated separately as it
corresponds to a given MPTCP Concentrator: there are as many
concentrators as instances of the OPTION_V6_MPTCP option.</t>
<t>If an IPv4-mapped IPv6 address is received in OPTION_V6_MPTCP, it
indicates that the MPTCP Concentrator has the corresponding IPv4
address.</t>
<t>The DHCPv6 client MUST silently discard multicast and host loopback
addresses <xref target="RFC6890"></xref> conveyed in
OPTION_V6_MPTCP.</t>
</section>
</section>
<section title="DHCPv4 MPTCP Option">
<t></t>
<section title="Format">
<t>The DHCPv4 MPTCP option can be used to configure a list of IPv4
addresses of an MPTCP Concentrator. The format of this option is
illustrated in <xref target="dhcp_mptcp"></xref>.</t>
<t><figure anchor="dhcp_mptcp" title="DHCPv4 MPTCP option">
<artwork><![CDATA[ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| List-Length | List of |
+-+-+-+-+-+-+-+-+ MPTCP |
/ Concentrator IPv4 Addresses /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---
| List-Length | List of | |
+-+-+-+-+-+-+-+-+ MPTCP | |
/ Concentrator IPv4 Addresses / |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
. ... . optional
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| List-Length | List of | |
+-+-+-+-+-+-+-+-+ MPTCP | |
/ Concentrator IPv4 Addresses / |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---
]]></artwork>
</figure></t>
<t>The fields of the option shown in <xref target="dhcp_mptcp"></xref>
are as follows:<?rfc subcompact="yes" ?><list style="symbols">
<t>Code: OPTION_V4_MPTCP (TBA, see <xref
target="iana4"></xref>);</t>
<t>Length: Length of all included data in octets. The minimum
length is 5.</t>
<t>List-Length: Length of the "List of MPTCP Concentrator IPv4
Addresses" field in octets; MUST be a multiple of 4.</t>
<t>List of MPTCP Concentrator IPv4 Addresses: Contains one or more
IPv4 addresses of the MPTCP Concentrator to be used by the MPTCP
client. The format of this field is shown in <xref
target="list"></xref>.</t>
<t>OPTION_V4_MPTCP can include multiple lists of MPTCP
Concentrator IPv4 addresses; each list is treated separately as it
corresponds to a given MPTCP Concentrator. <vspace
blankLines="1" />When several lists of MPTCP Concentrator IPv4
addresses are to be included, "List-Length" and "MPTCP
Concentrator IPv4 Addresses" fields are repeated.</t>
</list><figure anchor="list"
title="Format of the List of MPTCP Concentrator IPv4 Addresses">
<artwork><![CDATA[ 0 8 16 24 32 40 48
+-----+-----+-----+-----+-----+-----+--
| a1 | a2 | a3 | a4 | a1 | a2 | ...
+-----+-----+-----+-----+-----+-----+--
IPv4 Address 1 IPv4 Address 2 ...]]></artwork>
<postamble>This format assumes that an IPv4 address is encoded as
a1.a2.a3.a4.</postamble>
</figure></t>
<t><?rfc subcompact="no" ?>OPTION_V4_MPTCP is a
concatenation-requiring option. As such, the mechanism specified in
<xref target="RFC3396"></xref> MUST be used if OPTION_V4_MPTCP exceeds
the maximum DHCPv4 option size of 255 octets.</t>
</section>
<section title="DHCPv4 Client Behavior">
<t>To discover one or more MPTCP Concentrators, the DHCPv4 client MUST
include OPTION_V4_MPTCP in a Parameter Request List Option <xref
target="RFC2132"></xref>.</t>
<t>The DHCPv4 client MUST be prepared to receive multiple lists of
MPTCP Concentrator IPv4 addresses in the same OPTION_V4_MPTCP; each
list is to be treated as a separate MPTCP Concentrator instance.</t>
<t>The DHCPv4 client MUST silently discard multicast and host loopback
addresses <xref target="RFC6890"></xref> conveyed in
OPTION_V4_MPTCP.</t>
</section>
</section>
<section title="DHCP Server Configuration Guidelines">
<t>The DHCP server MUST NOT reply with the DHCP MPTCP Concentrator
option unless the client has explicitly requested for it.</t>
<t>DHCP servers that support the DHCP MPTCP Concentrator option can be
configured with a list of IP addresses of the MPTCP Concentrator(s). If
multiple IP addresses are configured, the DHCP server MUST be explicitly
configured whether all or some of these addresses refer to:</t>
<t><list style="numbers">
<t>the same MPTCP Concentrator: the DHCP server returns multiple
addresses in the same instance of the DHCP MPTCP Concentrator
option.</t>
<t>distinct MPTCP Concentrators : the DHCP server returns multiple
lists of MPTCP Concentrator IP addresses to the requesting DHCP
client (encoded as multiple OPTION_V6_MPTCP or in the same
OPTION_V4_MPTCP); each list refers to a distinct MPTCP
Concentrator.</t>
</list></t>
<t>Precisely how DHCP servers are configured to separate lists of IP
addresses according to which MPTCP Concentrator they refer to is out of
scope for this document. However, DHCP servers MUST NOT combine the IP
addresses of multiple MPTCP Concentrators and return them to the DHCP
client as if they were belonging to a single MPTCP Concentrator, and
DHCP servers MUST NOT separate the addresses of a single MPTCP
Concentrator and return them as if they were belonging to distinct MPTCP
Concentrators. For example, if an administrator configures the DHCP
server by providing a Fully Qualified Domain Name (FQDN) for a MPTCP
Concentrator, even if that FQDN resolves to multiple addresses, the DHCP
server MUST deliver them within a single server address block.</t>
<t>DHCPv6 servers that implement this option and that can populate the
option by resolving FQDNs will need a mechanism for indicating whether
to query A records or only AAAA records. When a query returns A records,
the IP addresses in those records are returned in the DHCPv6 response as
IPv4-mapped IPv6 addresses.</t>
<t>Since this option requires support for IPv4-mapped IPv6 addresses, a
DHCPv6 server implementation will not be complete if it does not query A
records and represent any that are returned as IPv4-mapped IPv6
addresses in DHCPv6 responses. The mechanism whereby DHCPv6
implementations provide this functionality is beyond the scope of this
document.</t>
<t>For guidelines on providing context-specific configuration
information (e.g., returning a regional-based configuration), and
information on how a DHCP server might be configured with FQDNs that get
resolved on demand, see <xref
target="I-D.ietf-dhc-topo-conf"></xref>.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>The security considerations in <xref target="RFC2131"></xref> and
<xref target="RFC3315"></xref> are to be considered.</t>
<t>MPTCP-related security considerations are discussed in <xref
target="RFC6824"></xref>.</t>
<t>Means to protect the MPTCP concentrator against Denial-of-Service
(DoS) attacks must be enabled. Such means include the enforcement of
ingress filtering policies at the boundaries of the network. In order to
prevent exhausting the resources of the concentrator by creating an
aggressive number of simultaneous subflows for each MPTCP connection,
the administrator should limit the number of allowed subflows per host
for a given connection.</t>
<t>Attacks outside the domain can be prevented if ingress filtering is
enforced. Nevertheless, attacks from within the network between a host
and a concentrator instance are yet another actual threat. Means to
ensure that illegitimate nodes cannot connect to a network should be
implemented.</t>
<t>Traffic theft is also a risk if an illegitimate concentrator is
inserted in the path. Indeed, inserting an illegitimate concentrator in
the forwarding path allows to intercept traffic and can therefore
provide access to sensitive data issued by or destined to a host. To
mitigate this threat, secure means to discover a concentrator (for
non-transparent modes) should be enabled.</t>
</section>
<section title="Privacy Considerations">
<t>Generic privacy-related considerations are discussed in <xref
target="I-D.ietf-dhc-anonymity-profile"></xref>. </t>
<t>The concentrator may have access to privacy-related information
(e.g., International Mobile Subscriber Identity (IMSI), link identifier,
subscriber credentials, etc.). The concentrator must not leak such
sensitive information outside an administrative domain.</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t></t>
<section anchor="iana6" title="DHCPv6 Option">
<t>IANA is requested to assign the following new DHCPv6 Option Code in
the registry maintained in
http://www.iana.org/assignments/dhcpv6-parameters:</t>
<texttable style="headers">
<ttcol align="right">Option Name</ttcol>
<ttcol>Value</ttcol>
<c>OPTION_V6_MPTCP</c>
<c>TBA</c>
</texttable>
</section>
<section anchor="iana4" title="DHCPv4 Option">
<t>IANA is requested to assign the following new DHCPv4 Option Code in
the registry maintained in
http://www.iana.org/assignments/bootp-dhcp-parameters/:</t>
<texttable style="headers">
<ttcol align="right">Option Name</ttcol>
<ttcol>Value</ttcol>
<ttcol>Data length</ttcol>
<ttcol>Meaning</ttcol>
<c>OPTION_V4_MPTCP</c>
<c>TBA</c>
<c>Variable; the minimum length is 5.</c>
<c>Includes one or multiple lists of MPTCP Concentrator IP
addresses; each list is treated as a separate MPTCP
Concentrator.</c>
</texttable>
<t></t>
</section>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>Many thanks to Olivier Bonaventure for the feedback on this document.
Olivier suggested to define the option as a name but that design
approach was debated several times within the dhc wg.</t>
<t>Thanks to Dan Seibel, Bernie Volz, Niall O'Reilly, and Simon Hobson
for the feedback on the dhc wg mailing list.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include='reference.RFC.6824'?>
<?rfc include="reference.RFC.2119"?>
<?rfc include='reference.RFC.3315'?>
<?rfc include='reference.RFC.2131'?>
<?rfc include='reference.RFC.4291'?>
<?rfc include='reference.RFC.2132'?>
<?rfc include='reference.RFC.6890'?>
<?rfc include='reference.RFC.3396'?>
</references>
<references title="Informative References">
<?rfc include='reference.I-D.ietf-dhc-topo-conf'?>
<?rfc include='reference.I-D.ietf-dhc-anonymity-profile'?>
<?rfc include='reference.RFC.4908'?>
<?rfc include='reference.RFC.6333'?>
<?rfc include='reference.RFC.0793'?>
<?rfc include='reference.RFC.7227'?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 03:16:13 |