<?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="exp" docName="draft-boucadair-hops-capability-discovery-00"
     ipr="trust200902">
  <front>
    <title abbrev="Retrieving the Capabilities of Middleboxes">Discovering the
    Capabilities of Flow-Aware Service Functions (a.k.a. Middleboxes): A
    PCP-based Approach</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>

          <code></code>

          <country>France</country>
        </postal>

        <email>christian.jacquenet@orange.com</email>
      </address>
    </author>

    <date day="" month="" year="2015" />

    <abstract>
      <t>This document specifies a solution to discover the capabilities of a
      flow-aware service function. The solution relies upon the use of the
      Port Control Protocol (PCP).</t>

      <t>This solution allows for applications to anticipate connectivity
      failures and to proceed with countermeasures (e.g., create a mapping for
      incoming connections, discover a mapping lifetime, discover an external
      IP address, avoid injecting some options in the outgoing packets, etc.).
      The propsoed approach allows, for example, to discover whether an
      upstream flow-aware service function is MPTCP-friendly (that is, it does
      not strip MPTCP signals) or SCTP-compliant, whether it embeds a firewall
      function, etc. or a combination thereof.</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 anchor="introduction" title="Introduction">
      <t>Advanced service functions (e.g., Performance Enhancement Proxies
      (<xref target="RFC3135"></xref>), NATs <xref
      target="RFC3022"></xref><xref target="RFC6333"></xref><xref
      target="RFC6146"></xref>, firewalls <xref
      target="I-D.ietf-opsawg-firewalls"></xref>, etc.) are required to
      achieve various objectives such as IP address sharing, firewalling, to
      avoid covert channels, to detect and protect against DDoS attacks,
      etc.</t>

      <t>Removing those functions is not an option because they are used to
      address constraints that are often typical of the current yet protean
      Internet situation (global IPv4 address depletion comes to mind, but
      also the plethora of services with different QoS/security/robustness
      requirements, etc.), and this is even exacerbated by
      environment-specific designs (e.g., the nature and the number of service
      functions that need to be invoked at the Gi interface of a mobile
      infrastructure).</t>

      <t>Moreover, these sophisticated service functions are located in the
      network but also in service platforms, or other structures like Content
      Delivery Networks. Some of these service functions can be controlled by
      hosts (e.g., NAT) to avoid connectivity complications (<xref
      target="RFC6269"></xref>) while others are hidden to customers.</t>

      <t>This document proposes a solution that can be used by hosts to
      discover the capabilities of flow-aware service functions that are
      visible to them but it can also be used by an administrator responsible
      for the management of such (hidden) service functions, e.g., to inform
      an SFC controller (<xref target="I-D.ww-sfc-control-plane"></xref>)
      about the nature and the status of these service functions. Obviously,
      exposing this information to hosts/applications is
      deployment-specific.</t>

      <t>Customer-facing flow-aware service functions can announce their
      capabilities to hosts. This information can be used by a host to select
      a service function instance (e.g., include the external address of that
      service function in a referral will involve that service function in the
      communication path). For example, a host that discovers that the
      Residential Gateway it is connected to does not support Stream Control
      Transmission Protocol (SCTP, <xref target="RFC4960"></xref>), won't even
      try to use SCTP as a transport protocol; TCP/SCTP happy eyeball
      proposals are useless in such case.</t>

      <t>This document extends the <xref target="RFC6887">base PCP </xref>
      with a new option, called CAPABILITY (<xref
      target="capability_ie"></xref>), to discover the capabilities of one or
      several service functions typically embedded in middleboxes. Retrieving
      the capabilities of these middleboxes is meant to facilitate fault
      management (e.g., provide a hint about why some applications fail, help
      select the required actions to instruct the middlebox to handle incoming
      connections, etc.). This option, when received from a PCP server, is
      used by a host (and the PCP client) to better adapt the traffic it may
      send according to the perceived network conditions as exposed in the PCP
      option (including tweaking PCP requests to instruct mappings).</t>

      <t>This specification can also be used to help the introduction of new
      transport protocols. For example, CPE devices managed by a service
      provider can include this feature. Also, a service provider that
      Introduces additional service nodes that support new features (e.g.,
      SCTP-aware CGN) in the network can select the set of CPEs that will be
      serviced by these nodes. It can do so by setting the SCTP bit when
      sending the capability information to the selected CPEs. Additional
      sample use cases are discussed in <xref target="usage"></xref>.</t>
    </section>

    <section anchor="capability_ie" title="PCP CAPABILITY Option">
      <t>The CAPABILITY option (Code: TBA, <xref target="capability"></xref>)
      is used by a flow-aware service function to explicitly inform a host
      about the capabilities that pertain to the said flow-aware service
      function, especially as far as IP forwarding operations are
      concerned.</t>

      <t>One single CAPABILITY option is conveyed in the same PCP message even
      if several functions are co-located in the same device (e.g., NAT44 and
      NAT64, NAT44 and port set assignment capability, etc.).</t>

      <t><figure anchor="capability" title="Capability option">
          <artwork><![CDATA[    0                   1                   2                   3
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | CAPABILITY    |  Reserved     |            Length=16          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |A|                           Capability                        |
   +-+                                                             |
   :                                                               :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      This Option:

      Option Name: PCP Capabilities option (CAPABILITY)
      Number: TBA (IANA)
      Purpose: Retrieve the capabilities of a PCP-controlled device 
      Valid for Opcodes: ANNOUNCE, MAP, PEER
      Length: 16
      May appear in: both request and response
      Maximum occurrences: 1
]]></artwork>
        </figure></t>

      <t>When set, the A bit indicates the PCP server supports authentication
      (<xref target="I-D.ietf-pcp-authentication"></xref>). If this bit is
      unset, it indicates that plain PCP is supported.</t>

      <t>The Capability Field is encoded in 127 bits. Each bit in the
      Capability bit mask is used to represent a PCP-controlled device
      capability. Whenever a bit of the Capability Field is set, this means
      that the corresponding capability is enabled/supported. Several bits can
      be set simultaneously if several functions are co-located. The default
      value for each capability bit is '0'. The meaning associated with the
      following Capability bits is (other values can be added to the
      list):</t>

      <t><list style="empty">
          <t>Bit #: Description<?rfc subcompact="yes" ?></t>

          <t>1: NAT44 <xref target="RFC3022"></xref></t>

          <t>2: Stateless NAT64 <xref target="RFC6145"></xref>.</t>

          <t>4: Stateful NAT64 <xref target="RFC6146"></xref>.</t>

          <t>5 : Dual-Stack Lite (DS-Lite) AFTR <xref
          target="RFC6333"></xref></t>

          <t>6: Dual-Stack Extra Lite <xref target="RFC6619"></xref></t>

          <t>8: A+P Port Range Router (PRR) <xref target="RFC6346"></xref></t>

          <t>9: Supports PORT_SET option <xref
          target="I-D.ietf-pcp-port-set"></xref>.</t>

          <t>16: IPv4 firewall.</t>

          <t>32: IPv6 Firewall <xref target="RFC6092"></xref>.</t>

          <t>64: IPv6-to-IPv6 Network Prefix Translation (NPTv6) <xref
          target="RFC6296"></xref>.</t>

          <t>119: TCP <xref target="RFC0793"></xref>.</t>

          <t>120: User Datagram Protocol (UDP) <xref
          target="RFC0768"></xref>.</t>

          <t>121: UDP-Lite compliant <xref target="RFC3828"></xref></t>

          <t>122: Datagram Congestion Control Protocol (DCCP) <xref
          target="RFC4340"></xref></t>

          <t>123: SCTP <xref target="RFC4960"></xref></t>

          <t>124: Multipath TCP (MPTCP) <xref target="RFC6824"></xref>.</t>

          <t>125: DSCP re-marking function.</t>

          <t>126: FLOWDATA-aware function (<xref
          target="I-D.wing-pcp-flowdata"></xref>).</t>

          <t>127: ILNP Translator <xref target="RFC6740"></xref>.</t>
        </list><?rfc subcompact="no" ?></t>
    </section>

    <section title="PCP Client &amp; Host Behavior">
      <t>The PCP client includes a CAPABILITY option in a MAP or ANNOUNCE
      request to learn the capabilities of an upstream PCP-controlled device.
      When conveyed in a PCP request, the Capability field MUST be set to 0.
      The CAPABILITY option can be inserted in a MAP request that is used to
      learn the external IP address, as detailed in Section 11.6 of <xref
      target="RFC6887"></xref>.</t>

      <t>The PCP client MUST be prepared to receive multiple CAPABILITY
      options (e.g., if several PCP servers are deployed and each of them is
      configured with a distinct set of capabilities). The PCP client MUST
      associate each received set of capabilities and suffix with the PCP
      server from which the information was retrieved.</t>

      <t>Upon receipt of an unsolicited PCP ANNOUNCE message, the PCP client
      replaces the former set of capabilities as received from the same PCP
      server with the new set of capabilities, as indicated in the CAPABILITY
      option.</t>

      <t>Based on the received capabilities, the host/application/PCP client
      may decide to tune its requests (e.g., <xref target="usage"></xref>).
      For example, a PCP client can use the returned information to decide
      whether all PCP servers need to be contacted in parallel or only a
      subset of them , or which service function to solicit in order to
      establish some sessions (e.g., SCTP).</t>
    </section>

    <section title="PCP Server Behavior">
      <t>Activating this feature on the PCP server is subject to
      administrative authorization procedures.</t>

      <t>The PCP server that controls a flow-aware service function SHOULD be
      configured to provide requesting PCP clients with the supported
      capabilities whose corresponding bit in the CAPABILITY option will
      therefore be set. When enabled, the CAPABILITY option conveys the set of
      capabilities supported by the PCP-controlled device.</t>

      <t>If the PCP server is configured to honor the CAPABILITY option but
      has no means to determine the set of capabilities supported by the local
      device, the PCP server MUST NOT include any CAPABILITY option in its PCP
      messages.</t>

      <t>The PCP server MAY be configured to include a CAPABILITY option in
      all MAP responses, even if the CAPABILITY option is not listed in the
      associated request. The PCP server MAY be configured to include a
      CAPABILITY option in its ANNOUNCE messages.</t>

      <t>In the event of any change of the capabilities supported by the
      PCP-controlled device (e.g., the activation of a new service function),
      the PCP server SHOULD issue an unsolicited PCP ANNOUNCE message to
      inform the PCP client about the updated set of capabilities.</t>

      <t>Upon receipt of a PCP request from a PCP client that requires the PCP
      server to proceed with an operation that is beyond its capabilities, the
      PCP server MAY return an error code together with the CAPABILITY
      option.</t>

      <t>When a new PCP server joins the network, it MAY then send an ANNOUNCE
      Opcode with its capabilities (i.e., CAPABILITY option).</t>
    </section>

    <section anchor="usage" title="Sample Use Cases">
      <t>Below is provided a non-exhaustive list of use cases to illustrate
      the benefits of the proposed solution:<list style="symbols">
          <t>A middlebox may be configured to strip MPTCP options or to let
          them pass without any modification. Explicitly advertising such
          capability to the hosts will avoid extra delays to establish
          successful TCP sessions. In reference to <xref
          target="mptcp"></xref>, the host won't use MPTCP because the
          firewall it is connected to does not support MPTCP. This information
          is useful for the application since it can use the TCP option space
          more efficiently, so as to insert options that couldn't be inserted
          if MPTCP options were included.<figure anchor="mptcp"
              title="MPTCP Example">
              <artwork><![CDATA[                                        __________
+-----------+   +-----------------+    /          \   +-----------+
|   HOST    |___|MPTCP-disabled FW|____| Internet |___|   Server  |    
+-----------+   +-----------------+    \__________/   +-----------+               
        ]]></artwork>
            </figure></t>

          <t>A host that supports both TCP and SCTP can decide which transport
          to use when establishing transport sessions. For example, an
          application that is designed to be transported over TCP or SCTP can
          avoid sending SCTP packets if an upstream device in the path
          announces that it is not compliant with SCTP. SCTP can be used if
          that upstream device announces it supports SCTP. Furthermore, if
          that upstream device is also a NAT, appropriate (SCTP) explicit
          dynamic mappings can be instantiated by the application so that
          incoming connections can be forwarded appropriately. <xref
          target="sctp"></xref> shows an example of two NAT devices; one of
          them supports SCTP. Owing to the CAPABILITY option, SCTP sessions
          can be forced by the host to cross the SCTP-enabled NAT by including
          for instance the external IP address (@IP_Ext2) in a
          referral).<figure align="center" anchor="sctp" title="SCTP Example">
              <artwork><![CDATA[                               ______________________                      
                              /                       \
                              |                        |
                              |                     +--------+
                              |                     | SCTP-  |@IP_Ext1
                              |                     |disabled|-----+
                              |                     |  NAT   |  
                +------+      |      Network        +--------+
                | Host |______|                        |
                +------+      |                     +-------+
                              |                     | SCTP- |@IP_Ext2
                              |                     |Enabled|-------
                              |                     |  NAT  |  
                              |                     +-------+
                              \_________________________/
                                                          
]]></artwork>
            </figure></t>

          <t>In an IPv6 network that runs NPTv6 <xref target="RFC6296"></xref>
          functions, firewalls controlled by a PCP server are embedded in
          different devices: the PCP client learns about the available PCP
          servers by means of DHCP <xref target="RFC7291"></xref> or any other
          PCP server discovery technique. The PCP client learns about the PCP
          server capabilities by using the CAPABILITY option. The PCP client
          sends MAP PCP request to a PCP-controlled NPTv6 device with Internal
          Port=0 and Protocol=0 (which means 'all ports for all protocols') to
          find the external IP address. This PCP request has to be sent only
          once since NPTv6 is stateless and provides a 1:1 relationship
          between addresses that belong to the "inside" and "outside"
          prefixes, respectively. The PCP client will send PCP requests only
          to the PCP server that controls the NPTv6 device before the Assigned
          Lifetime of the MAP response expires or when the host that embeds
          the PCP client acquires a new IPv6 address that belongs to the
          "inside" prefix. However, the PCP client will send MAP/PEER requests
          to the PCP server that controls the firewall device to create/delete
          dynamic outbound mappings, or use PCP instead of its default
          application keep-alives to maintain the firewall-maintained states
          alive.<figure anchor="figure1"
              title="NPTv6 and Firewall not collocated with PCP server Capability">
              <artwork><![CDATA[     PCP           
    Client                              __________
+-----------+   +------+   +------+    /          \   +-----------+
|Application|___| NPTv6|___| FW   |____| Internet |___|Application|    
|  Client   |   |      |   |      |    |          |   |   Server  | 
+-----------+   +------+   +------+    \__________/   +-----------+               
        ]]></artwork>
            </figure></t>

          <t>In a network that embeds NAT64 <xref target="RFC6146"></xref>
          devices, the PCP-controlled firewall service functions are embedded
          in different devices: The IPv6-only PCP client can send the PREFIX64
          PCP option <xref target="RFC7225"></xref> only to the PCP-controlled
          NAT64 device to learn the Prefix64(s) used to build IPv4-embedded
          IPv6 addresses.</t>

          <t>Multiple PCP-controlled devices: See <xref
          target="figure2"></xref> the example of a network deploying several
          techniques to connect with the IPv4 Internet, to provide IPv6-only
          connectivity, etc. The discovered capabilities can be used to
          trigger the selection of the appropriate PCP server <xref
          target="RFC7488"></xref>.<figure anchor="figure2"
              title="Multiple PCP-controlled devices">
              <artwork><![CDATA[                                     +-----+ 
                               ______|NPTv6|___________                      
                              /      +-----+           \
                              |                        |
                              |                     +-----+
+-----------+   +------+      |                     | PRR |
|Application|___| IPv6 |______|        Network      +-----+
|PCP  Client|   |  FW  |      |                        |
+-----------+   +------+      |                     +------+
                              |                     | NAT64|
+-----------+   +-------+     |                     |   +  |
|PCP client |___|A+P NAT|_____|                     |  FW  |  
+-----------+   +-------+     |      +-----+        +------+
                              \______|NPTv6|___________/
                                     +-----+    
]]></artwork>
            </figure></t>

          <t>In a IPv6 network that supports a PCP-controlled ILNP translator
          <xref target="RFC6740"></xref>, the PCP-controlled firewall service
          functions are embedded in different devices. The PCP client needs to
          send PCP requests only to the PCP-controlled ILNP translator to find
          Global Locators associated with Internal Locators.</t>

          <t>When the PCP-controlled device is a Port Range Router (PRR, see
          Section 3.2 of <xref target="RFC6346"></xref>), the PCP client
          should use the PORT_SET <xref target="I-D.ietf-pcp-port-set"></xref>
          option.</t>
        </list></t>
    </section>

    <section anchor="security" title="Security Considerations">
      <t>PCP-related security considerations are discussed in <xref
      target="RFC6887"></xref>.</t>

      <t>An attacker may generate a PCP message with a fake CAPABILITY option
      to switch off some features that would have been used by a host. Means
      to authenticate the PCP server SHOULD be supported.</t>
    </section>

    <section anchor="iana" title="IANA Considerations">
      <t>The following PCP option Code is to be allocated in the
      optional-to-process range (the registry is maintained in
      http://www.iana.org/assignments/pcp-parameters/pcp-parameters.xml#options):<list
          style="empty">
          <t>CAPABILITY</t>
        </list>A sub-registry is required to track the set of capabilities of
      PCP-controlled devices.</t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <?rfc include="reference.RFC.2119"?>

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

    <references title="Informative References">
      <?rfc include='reference.I-D.ietf-pcp-port-set'?>

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

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

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

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

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

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

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

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

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

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

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

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

      <?rfc include='reference.I-D.ietf-opsawg-firewalls'?>

      <?rfc include='reference.I-D.ietf-pcp-authentication'?>

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

      <?rfc include='reference.I-D.wing-pcp-flowdata'?>

      <?rfc include='reference.I-D.ww-sfc-control-plane'?>

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

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

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

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

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

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

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

    <!--
-->
  </back>
</rfc>
