DHCP Options for 0-RTT TCP
ConvertersOrangeRennes35000Francemohamed.boucadair@orange.comOrangeRennesFrancechristian.jacquenet@orange.comMcAfee, Inc.Embassy Golf Link Business ParkBangaloreKarnataka560071Indiakondtir@gmail.comBecause of the lack of important TCP extensions, e.g., Multipath TCP
support at the server side, some service providers now consider a
network-assisted model that relies upon the activation of a dedicated
function called Transport Converters. For example, network-assisted
Multipath TCP deployment models are designed to facilitate the adoption
of Multipath TCP for the establishment of multi-path communications
without making any assumption about the support of Multipath TCP by the
remote servers. Transport Converters located in the network are
responsible for establishing multi-path communications on behalf of
endpoints, thereby taking advantage of Multipath TCP 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.This document focuses on the explicit deployment scheme where the
identity of the Transport Converters is explicitly configured on
connected hosts. This document specifies DHCP (IPv4 and IPv6) options to
configure hosts with Converters parameters.One of the promising deployment scenarios for Multipath TCP (MPTCP,
) is to enable a host or a Customer
Premises Equipment (CPE) connected to multiple networks (e.g., DSL, LTE,
WLAN) to optimize the usage of such resources. A deployment scenario
relies on MPTCP Conversion Points (called, Transport Converters ). A Converter terminates the
extended TCP (e.g., MPTCP, TCPinc) sessions established from a host,
before redirecting traffic into a legacy TCP session. Further
Network-Assisted MPTCP deployment and operational considerations are
discussed in . shows a deployment example of the
Converters to assist establishing MPTCP connections. specifies the
Converter as a function that is installed by a network operator to aid
the deployment of TCP extensions and to provide the benefits of such
extensions to clients. A Transport Converter supports one or more TCP
extensions. assumes the explicit
mode that consists in configuring explicitly the reachability
information of the Converter(s) on a host.This document defines DHCPv4 and
DHCPv6 options that can be used to
configure hosts with Converter IP addresses.This specification assumes a Converter is reachable through one or
multiple IP addresses. As such, a list of IP addresses can be returned
in the DHCP Converter option. Also, it assumes the various network
attachments provided to an MPTCP-enabled host are managed by the same
administrative entity.This document makes use of the following terms:Converter: 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 Converters can
be deployed in the network side. The Converter achieves the
following:Listen for client sessions;Receive from a client the address of the final target
server;Setup a session to the final server;Relay control messages and data between the client and the
server;Perform access controls according to local policies.DHCP refers to both DHCPv4 and
DHCPv6 .DHCP client denotes a node that initiates requests to obtain
configuration parameters from one or more DHCP servers.DHCP server refers to a node that responds to requests from DHCP
clients.The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP 14
when, and
only when, they appear in all capitals, as shown here.The DHCPv6 Converter option can be used to configure a list of IPv6
addresses of a Converter.The format of this option is shown in . As a reminder, this format follows the
guidelines for creating new DHCPv6 options (Section 5.1 of ).The fields of the option shown in are as follows:Option-code: OPTION_V6_CONVERT (TBA, see )Option-length: Length of the 'Converter IP Address(es)' field
in octets. MUST be a multiple of 16.Converter IPv6 Addresses: Includes one or more IPv6 addresses
of the Converter to be used by the
TCP client. Note, IPv4-mapped IPv6
addresses (Section 2.5.5.2 of ) are
allowed to be included in this option.To return more than one Converter to the
requesting DHCPv6 client, the DHCPv6 server returns multiple instances
of OPTION_V6_CONVERT. Some guidelines for DHCP servers are elaborated
in .Clients MAY request option OPTION_V6_CONVERT, as defined in , Sections 18.2.1, 18.2.2, 18.2.4, 18.2.5,
18.2.6, and 21.7. As a convenience to the reader, we mention here that
the client includes requested option codes in the Option Request
Option.The DHCPv6 client MUST be prepared to receive multiple instances of
OPTION_V6_CONVERT; each instance is to be treated separately as it
corresponds to a given Converter: there are as many Converters as
instances of the OPTION_V6_CONVERT option.If an IPv4-mapped IPv6 address is received in OPTION_V6_CONVERT, it
indicates that the Converter has the corresponding IPv4 address.The DHCPv6 client MUST silently discard multicast and host loopback
addresses conveyed in
OPTION_V6_CONVERT.The DHCPv4 Converter option can be used to configure a list of IPv4
addresses of a Converter. The format of this option is illustrated in
.The fields of the option shown in
are as follows:Code: OPTION_V4_CONVERT (TBA, see );Length: Length of all included data in octets. The minimum
length is 5.List-Length: Length of the "List of Converter IPv4 Addresses"
field in octets; MUST be a multiple of 4.List of Converter IPv4 Addresses: Contains one or more IPv4
addresses of the Converter to be used by the TCP client. The
format of this field is shown in .OPTION_V4_CONVERT can include multiple lists of Converter IPv4
addresses; each list is treated separately as it corresponds to a
given Converter. When several lists of
Converter IPv4 addresses are to be included, "List-Length" and
"Converter IPv4 Addresses" fields are repeated.OPTION_V4_CONVERT is a
concatenation-requiring option. As such, the mechanism specified in
MUST be used if OPTION_V4_CONVERT
exceeds the maximum DHCPv4 option size of 255 octets.Some guidelines for DHCP servers are elaborated in .To discover one or more Converters, the DHCPv4 client MUST include
OPTION_V4_CONVERT in a Parameter Request List Option .The DHCPv4 client MUST be prepared to receive multiple lists of
Converter IPv4 addresses in the same OPTION_V4_CONVERT; each list is
to be treated as a separate Converter instance.The DHCPv4 client MUST silently discard multicast and host loopback
addresses conveyed in
OPTION_V4_CONVERT.The security considerations in and
are to be considered.Generic Convert security considerations are discussed in .MPTCP-related security considerations are discussed in .Means to protect the Converter 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 Converter 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.Attacks outside the domain can be prevented if ingress filtering is
enforced. Nevertheless, attacks from within the network between a host
and a Converter instance are yet another actual threat. Means to ensure
that illegitimate nodes cannot connect to a network should be
implemented.Traffic theft is also a risk if an illegitimate Converter is inserted
in the path. Indeed, inserting an illegitimate Converter 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 Converter should be enabled.IANA is requested to assign the following new DHCPv6 Option Code in
the registry maintained in
http://www.iana.org/assignments/dhcpv6-parameters:Option NameValueOPTION_V6_CONVERTTBAIANA is requested to assign the following new DHCPv4 Option Code in
the registry maintained in
http://www.iana.org/assignments/bootp-dhcp-parameters/:Option NameValueData lengthMeaningOPTION_V4_CONVERTTBAVariable; the minimum length is 5.Includes one or multiple lists of Converter IP addresses; each
list is treated as a separate Converter.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.Thanks to Dan Seibel, Bernie Volz, Niall O'Reilly, Simon Hobson, and
Ted Lemon for the feedback on the dhc wg mailing list.DHCP servers that support the DHCP Converter option can be configured
with a list of IP addresses of the Converter(s). If multiple IP
addresses are configured, the DHCP server MUST be explicitly configured
whether all or some of these addresses refer to:the same Converter: the DHCP server returns multiple addresses in
the same instance of the DHCP Converter option.distinct Converters : the DHCP server returns multiple lists of
Converter IP addresses to the requesting DHCP client (encoded as
multiple OPTION_V6_CONVERT or in the same OPTION_V4_CONVERT); each
list refers to a distinct Converter.Precisely how DHCP servers are configured to separate lists of IP
addresses according to which Converter they refer to is out of scope for
this document. However, DHCP servers MUST NOT combine the IP addresses
of multiple Converters and return them to the DHCP client as if they
were belonging to a single Converter, and DHCP servers MUST NOT separate
the addresses of a single Converter and return them as if they were
belonging to distinct Converters. For example, if an administrator
configures the DHCP server by providing a Fully Qualified Domain Name
(FQDN) for a Converter, even if that FQDN resolves to multiple
addresses, the DHCP server MUST deliver them within a single server
address block.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.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.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 .