One document matched: draft-boucadair-mptcp-dhc-06.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-06" 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>Because of the lack of Multipath TCP (MPTCP) support at the server
side, some service providers now consider a network-assisted model that
relies upon the activation of a dedicated function called MPTCP
Conversion Point (MCP). Network-assisted MPTCP deployment models are
designed to facilitate the adoption of MPTCP for the establishment of
multi-path communications without making any assumption about the
support of MPTCP by the communicating peers. MCPs located in the network
are responsible for establishing multi-path communications on behalf of
endpoints, thereby taking advantage of MPTCP capabilities to achieve
different goals that include (but are not limited to) optimization of
resource usage (e.g., bandwidth aggregation), of resiliency (e.g.,
primary/backup communication paths), and traffic offload management.</t>
<t>This document focuses on the explicit deployment scheme where the
identity of the MPTCP Conversion Point(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 Conversion Points (MCPs) located on both the CPE and
network sides (<xref target="fig"></xref>). The latter plays the role of
traffic concentrator. An MCP 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[ +------------+ _--------_ +----------------+
| | ( LTE ) | |
| CPE +=======+ +===+ Backbone |
| (MCP) | (_ _) | Network |
| | (_______) |+--------------+|
| | IP Network #1 || Concentrator ||------> Internet
| | || (MCP) ||
| | |+--------------+|
| | IP Network #2 | |
| | _--------_ | |
| | ( DSL ) | |
| +=======+ +==+ |
| | (_ _) | |
+-----+------+ (_______) +----------------+
|
---- LAN ----
|
end-nodes
]]></artwork>
</figure></t>
<t>Both implicit and explicit modes are considered to steer traffic
towards an MPTCP Conversion Point (MCP). This document focuses on the
explicit mode that consists in configuring explicitly the reachability
information of the MCP 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
MCP. For example, the MCP 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 an MCP 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 an MCP for some
reason (e.g., to better accommodate dimensioning constraints, to
move the MCP to a data canter, to enable additional MCP 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 an MCP 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 MCP, or decide to relay them via a
specific MCP. Such policies can be instructed to the MCP.
Implementing such differentiating behavior if the implicit mode is
in use may be complex to achieve.</t>
<t>Multiple MCPs can be supported to service the same CPE, e.g., an
MCP can be enabled for internal services (to optimize the delivery
of some operator-specific services) while another MCP 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 an MCP selection policy table that relies upon the
destination IP prefixes to select the MCP to involve for an ongoing
MPTCP connection, for instance.</t>
<t>Because the MCP'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 MCP 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 MCP.</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 MCP IP addresses.</t>
<t>This specification assumes an MCP 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>Multipath Conversion Point (MCP): a function that terminates a
transport flow and relays all data received over it over another
transport flow. This element is located upstream in the network. One
or multiple MCPs can be deployed in the network side to assist
MPTCP-enabled devices to establish MPTCP connections via available
network attachments. <vspace blankLines="1" />On the uplink path,
the MCP 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 MCP 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 MCP.</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 'MCP IP Address(es)' field in
octets. MUST be a multiple of 16.</t>
<t>MCP IPv6 Addresses: Includes one or more IPv6 addresses <xref
target="RFC4291"></xref> of the MCP 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 MCPs 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 MCP: there are as many MCPs 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 MCP 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 MCP. 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 |
/ MCP IPv4 Addresses /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---
| List-Length | List of | |
+-+-+-+-+-+-+-+-+ MPTCP | |
/ MCP IPv4 Addresses / |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
. ... . optional
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| List-Length | List of | |
+-+-+-+-+-+-+-+-+ MPTCP | |
/ MCP 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 MCP IPv4 Addresses" field
in octets; MUST be a multiple of 4.</t>
<t>List of MCP IPv4 Addresses: Contains one or more IPv4 addresses
of the MCP 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 MCP IPv4
addresses; each list is treated separately as it corresponds to a
given MCP. <vspace blankLines="1" />When several lists of MCP IPv4
addresses are to be included, "List-Length" and "MCP IPv4
Addresses" fields are repeated.</t>
</list><figure anchor="list"
title="Format of the List of MCP 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 MCPs, 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 MCP
IPv4 addresses in the same OPTION_V4_MPTCP; each list is to be treated
as a separate MCP 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 MCP option can be configured with
a list of IP addresses of the MCP(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 MCP: the DHCP server returns multiple addresses in the
same instance of the DHCP MCP option.</t>
<t>distinct MCPs : the DHCP server returns multiple lists of MCP 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 MCP.</t>
</list></t>
<t>Precisely how DHCP servers are configured to separate lists of IP
addresses according to which MCP they refer to is out of scope for this
document. However, DHCP servers MUST NOT combine the IP addresses of
multiple MCPs and return them to the DHCP client as if they were
belonging to a single MCP, and DHCP servers MUST NOT separate the
addresses of a single MCP and return them as if they were belonging to
distinct MCPs. For example, if an administrator configures the DHCP
server by providing a Fully Qualified Domain Name (FQDN) for an MCP,
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="RFC7969"></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 MCP 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 MCP 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 an MCP 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 MCP is inserted in
the path. Indeed, inserting an illegitimate MCP 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 an MCP (for non-transparent modes) should be
enabled.</t>
</section>
<section title="Privacy Considerations">
<t>Generic privacy-related considerations are discussed in <xref
target="RFC7844"></xref>.</t>
<t>The MCP may have access to privacy-related information (e.g.,
International Mobile Subscriber Identity (IMSI), link identifier,
subscriber credentials, etc.). The MCP 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 MCP IP addresses; each list is
treated as a separate MCP.</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.RFC.7969'?>
<?rfc include='reference.RFC.7844'?>
<?rfc include='reference.RFC.0793'?>
<?rfc include='reference.RFC.7227'?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 03:15:58 |