<?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-tcpm-dhc-converter-03"
     ipr="trust200902">
  <front>
    <title abbrev="DHCP for TCP Converters">DHCP Options for 0-RTT TCP
    Converters</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="McAfee">McAfee, Inc.</organization>

      <address>
        <postal>
          <street>Embassy Golf Link Business Park</street>

          <city>Bangalore</city>

          <region>Karnataka</region>

          <code>560071</code>

          <country>India</country>
        </postal>

        <email>kondtir@gmail.com</email>
      </address>
    </author>

    <date />

    <abstract>
      <t>Because 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.</t>

      <t>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.<!----></t>
    </abstract>
  </front>

  <middle>
    <section title="Introduction">
      <t>One of the promising deployment scenarios for Multipath TCP (MPTCP,
      <xref target="RFC6824"></xref>) 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 <xref
      target="I-D.ietf-tcpm-converters"></xref>). 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 <xref
      target="I-D.nam-mptcp-deployment-considerations"></xref>.</t>

      <t><xref target="fig"></xref> shows a deployment example of the
      Converters to assist establishing MPTCP connections.</t>

      <t><figure align="center" anchor="fig"
          title="&ldquo;Network-Assisted&rdquo; MPTCP Design">
          <artwork><![CDATA[  +------------+        _--------_    +----------------+
  |            |       (    LTE   )   |                |
  |   Host     +=======+          +===+  Backbone      |
  |            |       (_        _)   |   Network      |
  |            |         (_______)    |+--------------+|
  |            |       IP Network #1  ||   Converter  ||------> Internet
  |            |                      ||              ||
  |            |                      |+--------------+|
  |            |       IP Network #2  |                |
  |            |        _--------_    |                |
  |            |       (    DSL    )  |                |
  |            +=======+           +==+                |
  |            |       (_        _)   |                |
  +------------+        (_______)     +----------------+

]]></artwork>
        </figure></t>

      <t><xref target="I-D.ietf-tcpm-converters"></xref> 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.</t>

      <t><xref target="I-D.ietf-tcpm-converters"></xref> assumes the explicit
      mode that consists in configuring explicitly the reachability
      information of the Converter(s) on a host.</t>

      <t>This document defines DHCPv4 <xref target="RFC2131"></xref> and
      DHCPv6 <xref target="RFC8415"></xref> options that can be used to
      configure hosts with Converter IP addresses.</t>

      <t>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.</t>
    </section>

    <section title="Terminology">
      <t>This document makes use of the following terms:<?rfc subcompact="yes" ?></t>

      <t><list style="symbols">
          <t>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:<list style="symbols">
              <t>Listen for client sessions;</t>

              <t>Receive from a client the address of the final target
              server;</t>

              <t>Setup a session to the final server;</t>

              <t>Relay control messages and data between the client and the
              server;</t>

              <t>Perform access controls according to local policies.<vspace
              blankLines="1" /></t>
            </list></t>

          <t>DHCP refers to both DHCPv4 <xref target="RFC2131"></xref> and
          DHCPv6 <xref target="RFC8415"></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></t>

      <t>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
      <xref target="RFC2119"></xref><xref target="RFC8174"></xref> when, and
      only when, they appear in all capitals, as shown here.<?rfc subcompact="no" ?></t>
    </section>

    <section title="DHCPv6 Converter Option">
      <t></t>

      <section title="Format">
        <t>The DHCPv6 Converter option can be used to configure a list of IPv6
        addresses of a Converter.</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 Converter 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_CONVERT         |         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_CONVERT (TBA, see <xref
            target="iana6"></xref>)</t>

            <t>Option-length: Length of the 'Converter IP Address(es)' field
            in octets. MUST be a multiple of 16.</t>

            <t>Converter IPv6 Addresses: Includes one or more IPv6 addresses
            <xref target="RFC4291"></xref> of the Converter to be used by the
            TCP 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 Converter to the
        requesting DHCPv6 client, the DHCPv6 server returns multiple instances
        of OPTION_V6_CONVERT. Some guidelines for DHCP servers are elaborated
        in <xref target="sguide"></xref>.</t>
      </section>

      <section title="DHCPv6 Client Behavior">
        <t>Clients MAY request option OPTION_V6_CONVERT, as defined in <xref
        target="RFC8415"></xref>, 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.</t>

        <t>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.</t>

        <t>If an IPv4-mapped IPv6 address is received in OPTION_V6_CONVERT, it
        indicates that the Converter 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_CONVERT.</t>
      </section>
    </section>

    <section title="DHCPv4 Converter Option">
      <t></t>

      <section title="Format">
        <t>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
        <xref target="dhcp_mptcp"></xref>.</t>

        <t><figure anchor="dhcp_mptcp" title="DHCPv4 Converter 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     |
   +-+-+-+-+-+-+-+-+               |
   / Converter IPv4 Addresses      /
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  ---
   | List-Length   |   List of     |   |
   +-+-+-+-+-+-+-+-+               |   |
   / Converter IPv4 Addresses      /   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   |
   .             ...               . Optional
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   |
   | List-Length   |   List of     |   |
   +-+-+-+-+-+-+-+-+               |   |
   / Converter 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_CONVERT (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 Converter IPv4 Addresses"
            field in octets; MUST be a multiple of 4.</t>

            <t>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 <xref target="list"></xref>.</t>

            <t>OPTION_V4_CONVERT can include multiple lists of Converter IPv4
            addresses; each list is treated separately as it corresponds to a
            given Converter. <vspace blankLines="1" />When several lists of
            Converter IPv4 addresses are to be included, "List-Length" and
            "Converter IPv4 Addresses" fields are repeated.</t>
          </list><figure anchor="list"
            title="Format of the List of Converter 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_CONVERT is a
        concatenation-requiring option. As such, the mechanism specified in
        <xref target="RFC3396"></xref> MUST be used if OPTION_V4_CONVERT
        exceeds the maximum DHCPv4 option size of 255 octets.</t>

        <t>Some guidelines for DHCP servers are elaborated in <xref
        target="sguide"></xref>.</t>
      </section>

      <section title="DHCPv4 Client Behavior">
        <t>To discover one or more Converters, the DHCPv4 client MUST include
        OPTION_V4_CONVERT in a Parameter Request List Option <xref
        target="RFC2132"></xref>.</t>

        <t>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.</t>

        <t>The DHCPv4 client MUST silently discard multicast and host loopback
        addresses <xref target="RFC6890"></xref> conveyed in
        OPTION_V4_CONVERT.</t>
      </section>
    </section>

    <section anchor="Security" title="Security Considerations">
      <t>The security considerations in <xref target="RFC2131"></xref> and
      <xref target="RFC8415"></xref> are to be considered.</t>

      <t>Generic Convert security considerations are discussed in <xref
      target="I-D.ietf-tcpm-converters"></xref>.</t>

      <t>MPTCP-related security considerations are discussed in <xref
      target="RFC6824"></xref>.</t>

      <t>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.</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 Converter 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 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.</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_CONVERT</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_CONVERT</c>

          <c>TBA</c>

          <c>Variable; the minimum length is 5.</c>

          <c>Includes one or multiple lists of Converter IP addresses; each
          list is treated as a separate Converter.</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.8415'?>

      <?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'?>

      <?rfc include='reference.RFC.8174'?>

      <?rfc include='reference.I-D.ietf-tcpm-converters'?>
    </references>

    <references title="Informative References">
      <?rfc include='reference.RFC.7969'?>

      <?rfc include='reference.I-D.nam-mptcp-deployment-considerations'?>

      <?rfc include='reference.RFC.7844'?>

      <?rfc include='reference.RFC.0793'?>

      <?rfc include='reference.RFC.7227'?>
    </references>

    <section anchor="sguide" title="DHCP Server Configuration Guidelines">
      <t>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:</t>

      <t><list style="numbers">
          <t>the same Converter: the DHCP server returns multiple addresses in
          the same instance of the DHCP Converter option.</t>

          <t>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.</t>
        </list></t>

      <t>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.</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>
  </back>
</rfc>
