<?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-jacquenet-sfc-ipv6-eh-01" ipr="trust200902">
  <front>
    <title abbrev="draft-jacquenet-ipv6-eh-sfc-00.txt">An IPv6 Extension
    Header for Service Function Chaining (SFC)</title>

    <author fullname="Christian Jacquenet" initials="C." surname="Jacquenet">
      <organization>Orange</organization>

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

    <author fullname="Mohamed Boucadair" initials="M." surname="Boucadair">
      <organization>Orange</organization>

      <address>
        <email>mohamed.boucadair@orange.com</email>
      </address>
    </author>

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

    <abstract>
      <t>This document specifies an IPv6 extension header for Service Function
      Chaining (SFC) purposes. This extension header is used by SFC data plane
      elements to make forwarding decisions in an IPv6-enabled SFC domain and
      it conveys metadata that are processed by SFC-aware nodes.</t>

      <t>This extension is intended to be used within a single administrative
      domain.</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>Service Function Chaining (SFC) can be seen as a technique that
      facilitates the dynamic enforcement of differentiated traffic forwarding
      policies within an SFC-enabled domain. SFC operation assumes the
      manipulation of some information that is typically carried by packets
      within an SFC-enabled domain. In particular, this information is meant
      to assist Service Function Forwarders (SFFs) in making forwarding
      decisions within the SFC-enabled domain.</t>

      <t>The overall SFC problem space is discussed in <xref
      target="RFC7498"></xref>, while a data plane architecture is documented
      in <xref target="RFC7665"></xref>.</t>

      <t>Several options can be used to carry SFC-specific information. Some
      of them can take advantage of various existing tools such as
      encapsulation schemes (e.g., IP-in-IP), or specific fields in an IP
      header. This document specifies an IPv6 Extension Header ( <xref
      target="RFC6564"></xref>) to carry SFC-related information.</t>

      <t>The SFC extension header is intended to be used within a single
      administrative domain.</t>

      <t>The reader should be familiar with the terms defined in <xref
      target="RFC7498"></xref> and <xref target="RFC7665"></xref>.</t>
    </section>

    <section title="Overview">
      <t>Unlike some other solutions that require the use of yet another shim
      layer to carry SFC information, the use of an IPv6 Extension Header (EH)
      in IPv6-enabled SFC domains has the advantage to get rid of any specific
      transport encapsulation scheme when forwarding packets between nodes
      that are connected to the same subnet. <xref target="fig1"></xref> shows
      the case of a packet that carries the SFC EH and which is forwarded to
      the SFC Next Hop that is connected to the same subnet.</t>

      <t><xref target="fig2"></xref> shows a packet that is encapsulated in an
      IPv6 packet that contains the SFC EH. Such encapsulation scheme can also
      be used to carry IPv4 packets within an IPv6-enabled SFC domain.</t>

      <t><figure align="center" anchor="fig1">
          <artwork align="center"><![CDATA[+--------+--------------+-------------..-+
|  IPv6  |     SFC      | IPv6           |
| Header | Ext. Header  | Payload        |
+--------+--------------+-------------..-+]]></artwork>
        </figure></t>

      <t><figure align="center" anchor="fig2">
          <artwork align="center"><![CDATA[+----------+-------------+---------+-------------..-+
|Outer IPv6|     SFC     |Inner IP | IP             |
| Header   | Ext. Header | Header  | Payload        |
+----------+-------------+---------+-------------..-+
                            
                         |--Original IP packet------|
|-----------Encapsulated IPv6 packet----------------|]]></artwork>
        </figure></t>
    </section>

    <section title="SFC IPv6 Extension Header Format">
      <t>The IPv6 Extension Header to carry SFC metadata has format shown in
      <xref target="eh"></xref>.</t>

      <t><figure align="center" anchor="eh">
          <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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Next Header  |  Hdr Ext Len  |     Flags     |   SF Index    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Service Function Chain Identifier (SFC ID)           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    (Optional) Service Function Path Identifier (SFP ID)       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   .                                                               .
   .              (Optional) Information Elements                  .
   .                                                               .
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

      <t>The description of the fields is as follows:<list style="hanging">
          <t hangText="Next Header:">8-bit selector. Identifies the type of
          header immediately following the extension header.</t>

          <t hangText="Hdr Ext Len:">8-bit unsigned integer. Length of the
          extension header in 8-octet units, excluding the first 8 octets.</t>

          <t hangText="Flags:">The Flags field comprises a set of 8
          flags:<figure>
              <artwork><![CDATA[     +-+-+-+-+-+-+-+-+
     |P|E|r|r|r|r|r|M|
     +-+-+-+-+-+-+-+-+
]]></artwork>
            </figure>where "rrrrr" are reserved bits for future assignment as
          additional flag bits. r bits MUST each be sent as zero and MUST be
          ignored on receipt.<vspace blankLines="1" />When set, the P-flag
          indicates that a Service Function Path Identifier (SFP ID) field is
          present in the SFC EH. This flag is set to 0 by default: this means
          that there is no SFP ID information carried in the SFC EH.<vspace
          blankLines="1" />When set, the E-flag indicates that a source routed
          SFP field is present in the SFC EH. This flag is set by default to
          0, meaning there is no source routed SFP field present in the SFC
          EH. <vspace blankLines="1" />When set, the M-flag indicates that an
          extended set of a 32-bit encoded Flags field is present in the SFC
          EH. The default value of the M flag is 0. This feature allows to
          extend the SFC EH with new flags while ensuring backward
          compatibility. When present, the extended flag field MUST be
          positioned right after the SFC ID field.</t>

          <t hangText="SF Index: ">8-bit unsigned integer. This field is
          decremented by 1 and used to detect SFC loops.</t>

          <t hangText="Service Function Chain Identifier (SFC ID):">8-bit
          unsigned integer. Identifies the Service Function Chain that is
          associated to the IPv6 packet.</t>

          <t
          hangText="(Optional) Service Function Path Identifier (SFP ID):">This
          field MUST be supplied only if 'P' flag is set. This field is used
          to convey an identifier of a path that is bound to a given service
          function chain. A null value of this field means that no specific
          constraint is to be applied when forwarding this packet with this
          service function chain. It is RECOMMENDED to use this field only if
          non-null identifiers are to be carried in the SFC EH. A null value
          with P-flag set leads to the same behavior as with P-flag set to
          0.</t>

          <t hangText="(Optional) Information Elements:">Conveys one or
          multiple optional data that may be supplied within an SFC-enabled
          domain. The format of an optional Information Element can either be
          associated with the definition of a new flag or encoded according to
          the following TLV format <xref target="fig3"></xref>.<figure
              anchor="fig3">
              <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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Registry ID  |    Type       |     Length    | Originator Len|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   //                      Originator ID (Variable)                //
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   //                           Data (Variable)                    //
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
            </figure>The description of the fields is as follows:<list
              style="hanging">
              <t hangText="Registry ID:">In order to foster service
              innovation, this field allows to inherit from existing code
              point registries that are likely to be useful in a SFC context.
              The following value is reserved by this specification:<list
                  style="format %d:">
                  <t>IPFIX <xref target="IPFIX"></xref>.</t>
                </list></t>

              <t hangText="Type:">Indicates the code point of the information
              element. If Registry ID is set, then the interpretation of this
              field must conform to the one defined for that specific
              registry.</t>

              <t hangText="Length:">Indicates, in octets, the length of the
              data carried in the Information Element (including the
              "Originator Len" and "Originator ID" fields).</t>

              <t hangText="Originator Len:">Indicates, in octets, the length
              of the "Originator ID" field.</t>

              <t hangText="Originator ID:">Provides the identifier of the
              entity that injected this Information Element in the SFC
              Extension Header.</t>

              <t hangText="Originator ID:">Conveys the identifier of the
              entity that injected this Information Element in the SFC header
              (e.g., a service function identifier, a classifier, etc.). This
              document does not make any assumption about the structure of the
              information carried in this field because this is
              deployment-specific. This information is used by SFC-aware
              elements to enforce policies such as: process a context
              information if and only if it was supplied by a given entity.
              This information can be used as a safeguard against misbehaving
              nodes that inject illegitimate data in the SFC EH.</t>

              <t hangText="Data (Variable):">The semantics of this field
              depend on the "Registry ID" and "Type" fields.</t>
            </list></t>
        </list></t>

      <t></t>

      <section anchor="srs" title="Source Routed SFP">
        <t>If the E-flag is set, a "Source Routed SFP" field MUST be present
        in the SFC Extension Header. This field MUST be positioned right after
        the "Service Function Path Identifier (SFP ID)" field and "Extended
        Flag bits", if P-flag or M-flag are set. It MUST be positioned right
        after the "Service Function Chain Identifier (SFC ID)" field if P-flag
        and M-flag are both set to 0.</t>

        <t><figure align="center" anchor="sr">
            <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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   //                 (Optional) Locators[1..n] (Variable)        //
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
          </figure></t>

        <t>The optional "Source Routed SFP" field is structured as a vector of
        SF locators (whereas a SF locator could be an IP address, a MAC
        address or a FQDN, for example).</t>

        <t>A SFP Source Route is said to be "strict" when the exact set of all
        the SF instances that need to be invoked along the SFP is explicitly
        and exhaustively mentioned in the field. Each locator in the list is
        encoded as follows:<figure align="center" anchor="loc">
            <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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Locator Len |           Locator (Variable)                   //       
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+       
]]></artwork>
          </figure></t>

        <t>A SFP Source Route is said to be "loose" when only a subset of the
        SF instances, that need to be invoked in the context of a given
        service function chain, is mentioned in the field. The other SFs that
        need to be invoked will be set to "ANY" in the field, meaning that SFF
        are free to forward the packet towards the next SF instance that needs
        to be invoked as per the SFC instructions and according to SFC next
        hop resolution procedure or a result of load-balancing scheme. "ANY"
        corresponds to "Locator Len" set to "0" and no "Locator" field.<list
            style="empty">
            <t>For the sake of optimization, the encoding of loose source
            routes could be improved by indicating only explicit hops (i.e.,
            Locator!=ANY). A Hop Index is also provided for each included
            locator to help identifying the node when progressing a packet
            within an SFC-enabled domain.</t>
          </list></t>

        <t>A locator in the list set to 'ANY' is an indication that the
        selection of the exact SF instance to invoke is left to the SFF or to
        some kind of SF load-balancing mechanism.</t>

        <t>The Source Routed SFP field of the SFC EH MUST NOT include a list
        of locators that are all set to "ANY".</t>
      </section>
    </section>

    <section title="Operation">
      <t></t>

      <section title="Generic Considerations">
        <t>Routers MUST NOT process the SFC EH unless they are explicitly
        configured to do so. Processing the SFC EH MUST be disabled by
        default. Typically, routers that are not within an SFC-enabled domain
        MUST NOT be configured to process the SFC EH.</t>

        <t>To minimize fragmentation issues, it is recommended to configure
        MTU sizes that allow for the SFC EH to be inserted/updated
        in-path.</t>
      </section>

      <section title="Generating the SFC Extension Header">
        <t>A classifier typically inserts the SFC EH to every incoming packet
        that matches one of the entries of the SFC classification policy table
        maintained by the classifier. The classifier is supposed to be
        configured with the set of context information that must be supplied
        for each service function. If no such instruction is provided, the
        classifier inserts by default an identifier of the service chain and
        optionally an identifier of the service function path.</t>

        <t>The classifier may also inject a source SFP as part of the SFC EH
        that will be injected in packet matching its classification
        policies.</t>

        <t>The SFC EH is inserted either following the format in <xref
        target="fig1"></xref> (if the next hop is within the same subnet as
        the classifier) or as shown in <xref target="fig2"></xref> otherwise.
        When an encapsulation is required, the destination IP address is set
        to the IPv6 address of the first hop in the chain.</t>

        <t>SFC-aware nodes that are configured to inject context information
        for a given service function chain can update the context of an SFC
        EH.</t>
      </section>

      <section title="Processing the SFC Extension Header">
        <t>Upon receipt of an IPv6 packet that carries the SFC EH, a SFF must,
        eventually decapsulate the packet, and process the metadata
        information carried in the SFC EH: typically, the SF node that embeds
        the SFF capability will use these metadata to (1) position itself in
        the forwarding path, (2) determine which SF instance(s) need to be
        invoked next and (3) make its forwarding decision according to the SFC
        instructions carried in the SFC EH and as per the matching entry of
        its SFC Forwarding Policy Table.</t>

        <t>Once the packet is processed by the corresponding SF, SF Index is
        decremented by 1.</t>

        <t>An SFC-aware node MUST discard packets with an "SF Index" equal to
        0. This event must be logged locally.<!--CJ: we may want to discuss the case of processing the SFC EH by a SFC Proxy.--></t>

        <section title="Processing Source-Routed SFP Information">
          <t>If the SFC EH carried in the incoming IPv6 packet contains
          Source-Routed SFP (<xref target="srs"></xref>), the SFF will forward
          the packet according to the instructions carried in the
          corresponding field: if this is a Strict Source Route, the SFF will
          forward the packet towards the next SF node that embeds the SF
          instance identified by the SF Locator carried in the Source-Routed
          SFP field, possibly upon completion of some SF operation, depending
          on the nature of the chain and its corresponding instructions.</t>

          <t>If the explicit route happens to be a loose source route:</t>

          <t><list style="numbers">
              <t>If the next SF instance that needs to be invoked is
              explicitly identified by its Locator, then the SFF forwards the
              packet accordingly: the next SF to be invoked can be reached
              according to the corresponding entry of its SFC Forwarding
              Policy Table.</t>

              <t>If the next SF instance that needs to be invoked is valued to
              "ANY", then the SFF forwards the packet according to the best
              matching entry of its SFC Forwarding Policy Table, as per the
              SFC ID and Hop Index carried in the SFC EH.</t>
            </list></t>

          <t>By default, packets destined outside the SFC-enabled domain MUST
          be strip any SFC EH that is carried in the packet.</t>

          <t>When a node receives an IPv6 packet with a"ICMPv6 Destination
          Unreachable Code, "Error in Source Routing Header"xxx</t>
        </section>
      </section>
    </section>

    <section anchor="IANA" title="IANA Considerations">
      <t>This document requests IANA to assign the following values from the
      register in
      http://www.iana.org/assignments/ipv6-parameters/ipv6-parameters.xhtml#extension-header:</t>

      <texttable>
        <ttcol>Protocol Number</ttcol>

        <ttcol>Description</ttcol>

        <ttcol>Reference</ttcol>

        <c>TBD</c>

        <c>SFC Extension Header</c>

        <c>[This document]</c>
      </texttable>

      <t>Also, this document requests IANA to assign a sub-registry for
      Registry ID. The following value is reserved by this specification:<list
          style="empty">
          <t>1: IPFIX</t>
        </list></t>

      <t></t>
    </section>

    <section anchor="Security" title="Security Considerations">
      <t>Security considerations discussed in <xref target="RFC7045"></xref>
      and <xref target="RFC7112"></xref> apply. Additional considerations are
      discussed in the following sub-sections.</t>

      <section title="Privacy">
        <t>Because context headers may reveal privacy information (e.g., IMSI,
        user name, user profile, location, etc.). SFC Extension Headers MUST
        NOT be exposed outside the SFC domain. Also, means to protect context
        headers from eavesdroppers SHOULD be enforced.</t>
      </section>

      <section title="Invalid Context Information">
        <t>In order to control the information that can be supplied by a
        SFC-aware node, and therefore influence the behavior of an SFC-aware
        node within the SFC-enabled domain, the Originator ID field can be
        used as a first safeguard to check that the node is entitled to supply
        such information. If so, the Originator ID field can also be used to
        check whether the supplied information can be processed as part of the
        instructions that pertain to a given service function chain.</t>

        <t>An SFC-aware node can be provided with the appropriate SFC
        instructions by the SFC control plane or by configuration.</t>
      </section>

      <section title="Forwarding Threats">
        <t>This specification is not subject to infinite forwarding loops
        because a loop can be detected by an SF Index equal to 0.</t>

        <t>Several attacks (e.g., evade access controls based on destination
        addresses, amplification attacks) have been identified in <xref
        target="RFC4942"></xref>. Such attacks can be prevented in the SFC
        context by the enforcement of adequate policies at the boundaries of
        the SFC domain. Typically, SFC border nodes of a SFC-enabled domain
        can be configured to discard any SFC EH that may be present in a
        packet that enters the domain, and strip the SFC EH when the packet is
        forwarded outside of the SFC-enabled domain, so that the information
        carried by the SFC EH is not leaked outside the domain when the packet
        exits the SFC-enabled domain.</t>

        <t>Nevertheless, a node of a SFC-enabled domain may alter the contents
        of the SFC EH, thereby possibly distorting the SFP. Misbehaving nodes
        can be detected and countermeasures applied, if adequate monitoring is
        enforced. Also, means to protect traffic against illegitimate SFs/SFFs
        that do not belong to the SFC-enabled domain must be enabled. Such
        means should typically be defined in service function discovery
        specifications.</t>
      </section>
    </section>

    <section anchor="Acknowledgements" title="Acknowledgements">
      <t>TBD</t>
    </section>
  </middle>

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

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

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

      <reference anchor="IPFIX"
                 target="http://www.iana.org/assignments/ipfix/ipfix.xhtml">
        <front>
          <title>IP Flow Information Export (IPFIX) Entities</title>

          <author fullname="IETF">
            <organization>International Organization for
            Standardization</organization>
          </author>

          <date year="1992" />
        </front>
      </reference>
    </references>

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

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

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

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