One document matched: draft-boucadair-mptcp-dhc-05.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-05" 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>Orange</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>Orange</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.<!----></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. 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. Concretely, the
explicit mode has several advantages, e.g.,: </t>
<t><list style="symbols">
<t>It does not impose any specific constraint on the location of the
concentrator. For example, the concentrator can be located in any
access network, located upstream in the core network, or located in
a data canter facility. </t>
<t>Tasks required for activating the explicit mode are minimal. In
particular, this mode does not require any specific routing and/or
forwarding policies for handling outbound packets other than
ensuring that a concentrator is reachable from a CPE, and vice versa
(which is straightforward IP routing policy operation). </t>
<t>The engineering effort to change the location of a concentrator
for some reason (e.g., to better accommodate dimensioning
constraints, to move the concentrator to a data canter, to enable
additional concentrator instances closer to the customer premises,
etc.) is minimal</t>
<t>An operator can easily enforce strategies for differentiating the
treatment of MPTCP connections that are directly initiated by an
MPTCP-enabled host connected to a concentrator if the explicit mode
is enabled. Typically, an operator may decide to offload MPTCP
connections originated by an MPTCP-enabled terminal from being
forwarded through a specific concentrator, or decide to relay them
via a specific concentrator. Such policies can be instructed to the
concentrator. Implementing such differentiating behavior if the
implicit mode is in use may be complex to achieve. </t>
<t>Multiple concentrators can be supported to service the same CPE,
e.g., a concentrator can be enabled for internal services (to
optimize the delivery of some operator-specific services) while
another concentrator may be solicited for external services (e.g.,
access to the Internet). The explicit mode allows the deployment of
such scenario owing to the provisioning of a concentrator selection
policy table that relies upon the destination IP prefixes to select
the concentrator to involve for an ongoing MPTCP connection, for
instance. </t>
<t>Because the concentrator's reachability information is explicitly
configured on the CPE, means to guarantee successful inbound
connections can be enabled in the CPE to dynamically discover the
external IP address that has been assigned for communicating with
remote servers, instruct the concentrator to maintain active
bindings so that incoming packets can be successfully redirected
towards the appropriate CPE, etc. </t>
<t>Troubleshooting and root cause analysis may be facilitated in the
explicit mode since faulty key nodes that may have caused a service
degradation are known. Because of the loose adherence to the traffic
forwarding and routing polices, troubleshooting a service
degradation that is specific to multi-access serviced customers
should first investigate the behavior of the involved concentrator.
</t>
</list></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>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, Simon Hobson, and
Ted Lemon 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.0793'?>
<?rfc include='reference.RFC.7227'?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 03:15:52 |