[Search] [pdf|bibtex] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01                                                         
Network Working Group                                       C. Jacquenet
Internet-Draft                                              M. Boucadair
Intended status: Standards Track                                  Orange
Expires: July 10, 2016                                   January 7, 2016


      An IPv6 Extension Header for Service Function Chaining (SFC)
                     draft-jacquenet-sfc-ipv6-eh-01

Abstract

   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.

   This extension is intended to be used within a single administrative
   domain.

Requirements Language

   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 RFC 2119 [RFC2119].

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on July 10, 2016.

Copyright Notice

   Copyright (c) 2016 IETF Trust and the persons identified as the
   document authors.  All rights reserved.





Jacquenet & Boucadair     Expires July 10, 2016                 [Page 1]


Internet-Draft     draft-jacquenet-ipv6-eh-sfc-00.txt       January 2016


   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Overview  . . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  SFC IPv6 Extension Header Format  . . . . . . . . . . . . . .   3
     3.1.  Source Routed SFP . . . . . . . . . . . . . . . . . . . .   6
   4.  Operation . . . . . . . . . . . . . . . . . . . . . . . . . .   7
     4.1.  Generic Considerations  . . . . . . . . . . . . . . . . .   7
     4.2.  Generating the SFC Extension Header . . . . . . . . . . .   8
     4.3.  Processing the SFC Extension Header . . . . . . . . . . .   8
       4.3.1.  Processing Source-Routed SFP Information  . . . . . .   8
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
     6.1.  Privacy . . . . . . . . . . . . . . . . . . . . . . . . .  10
     6.2.  Invalid Context Information . . . . . . . . . . . . . . .  10
     6.3.  Forwarding Threats  . . . . . . . . . . . . . . . . . . .  10
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  11
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  11
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .  11
     8.2.  Informative References  . . . . . . . . . . . . . . . . .  11
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  12

1.  Introduction

   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.

   The overall SFC problem space is discussed in [RFC7498], while a data
   plane architecture is documented in [RFC7665].

   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



Jacquenet & Boucadair     Expires July 10, 2016                 [Page 2]


Internet-Draft     draft-jacquenet-ipv6-eh-sfc-00.txt       January 2016


   header.  This document specifies an IPv6 Extension Header (
   [RFC6564]) to carry SFC-related information.

   The SFC extension header is intended to be used within a single
   administrative domain.

   The reader should be familiar with the terms defined in [RFC7498] and
   [RFC7665].

2.  Overview

   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.  Figure 1 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.

   Figure 2 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.

                +--------+--------------+-------------..-+
                |  IPv6  |     SFC      | IPv6           |
                | Header | Ext. Header  | Payload        |
                +--------+--------------+-------------..-+

                                 Figure 1

           +----------+-------------+---------+-------------..-+
           |Outer IPv6|     SFC     |Inner IP | IP             |
           | Header   | Ext. Header | Header  | Payload        |
           +----------+-------------+---------+-------------..-+

                                    |--Original IP packet------|
           |-----------Encapsulated IPv6 packet----------------|

                                 Figure 2

3.  SFC IPv6 Extension Header Format

   The IPv6 Extension Header to carry SFC metadata has format shown in
   Figure 3.







Jacquenet & Boucadair     Expires July 10, 2016                 [Page 3]


Internet-Draft     draft-jacquenet-ipv6-eh-sfc-00.txt       January 2016


       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                  .
      .                                                               .
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                                 Figure 3

   The description of the fields is as follows:

   Next Header:  8-bit selector.  Identifies the type of header
      immediately following the extension header.

   Hdr Ext Len:  8-bit unsigned integer.  Length of the extension header
      in 8-octet units, excluding the first 8 octets.

   Flags:  The Flags field comprises a set of 8 flags:

        +-+-+-+-+-+-+-+-+
        |P|E|r|r|r|r|r|M|
        +-+-+-+-+-+-+-+-+

      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.

      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.

      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.

      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



Jacquenet & Boucadair     Expires July 10, 2016                 [Page 4]


Internet-Draft     draft-jacquenet-ipv6-eh-sfc-00.txt       January 2016


      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.

   SF Index:   8-bit unsigned integer.  This field is decremented by 1
      and used to detect SFC loops.

   Service Function Chain Identifier (SFC ID):  8-bit unsigned integer.
      Identifies the Service Function Chain that is associated to the
      IPv6 packet.

   (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.

   (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 Figure 4.

        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)                    //
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                                 Figure 4

      The description of the fields is as follows:

      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:

         1:  IPFIX [IPFIX].



Jacquenet & Boucadair     Expires July 10, 2016                 [Page 5]


Internet-Draft     draft-jacquenet-ipv6-eh-sfc-00.txt       January 2016


      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.

      Length:  Indicates, in octets, the length of the data carried in
         the Information Element (including the "Originator Len" and
         "Originator ID" fields).

      Originator Len:  Indicates, in octets, the length of the
         "Originator ID" field.

      Originator ID:  Provides the identifier of the entity that
         injected this Information Element in the SFC Extension Header.

      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.

      Data (Variable):  The semantics of this field depend on the
         "Registry ID" and "Type" fields.

3.1.  Source Routed SFP

   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.

        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)        //
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                                 Figure 5

   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).



Jacquenet & Boucadair     Expires July 10, 2016                 [Page 6]


Internet-Draft     draft-jacquenet-ipv6-eh-sfc-00.txt       January 2016


   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:

      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)                   //
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                                 Figure 6

   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.

      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.

   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.

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

4.  Operation

4.1.  Generic Considerations

   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.

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






Jacquenet & Boucadair     Expires July 10, 2016                 [Page 7]


Internet-Draft     draft-jacquenet-ipv6-eh-sfc-00.txt       January 2016


4.2.  Generating the SFC Extension Header

   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.

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

   The SFC EH is inserted either following the format in Figure 1 (if
   the next hop is within the same subnet as the classifier) or as shown
   in Figure 2 otherwise.  When an encapsulation is required, the
   destination IP address is set to the IPv6 address of the first hop in
   the chain.

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

4.3.  Processing the SFC Extension Header

   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.

   Once the packet is processed by the corresponding SF, SF Index is
   decremented by 1.

   An SFC-aware node MUST discard packets with an "SF Index" equal to 0.
   This event must be logged locally.

4.3.1.  Processing Source-Routed SFP Information

   If the SFC EH carried in the incoming IPv6 packet contains Source-
   Routed SFP (Section 3.1), 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




Jacquenet & Boucadair     Expires July 10, 2016                 [Page 8]


Internet-Draft     draft-jacquenet-ipv6-eh-sfc-00.txt       January 2016


   some SF operation, depending on the nature of the chain and its
   corresponding instructions.

   If the explicit route happens to be a loose source route:

   1.  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.

   2.  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.

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

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

5.  IANA Considerations

   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:

       +-----------------+----------------------+-----------------+
       | Protocol Number | Description          | Reference       |
       +-----------------+----------------------+-----------------+
       | TBD             | SFC Extension Header | [This document] |
       +-----------------+----------------------+-----------------+

   Also, this document requests IANA to assign a sub-registry for
   Registry ID.  The following value is reserved by this specification:

      1: IPFIX

6.  Security Considerations

   Security considerations discussed in [RFC7045] and [RFC7112] apply.
   Additional considerations are discussed in the following sub-
   sections.








Jacquenet & Boucadair     Expires July 10, 2016                 [Page 9]


Internet-Draft     draft-jacquenet-ipv6-eh-sfc-00.txt       January 2016


6.1.  Privacy

   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.

6.2.  Invalid Context Information

   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.

   An SFC-aware node can be provided with the appropriate SFC
   instructions by the SFC control plane or by configuration.

6.3.  Forwarding Threats

   This specification is not subject to infinite forwarding loops
   because a loop can be detected by an SF Index equal to 0.

   Several attacks (e.g., evade access controls based on destination
   addresses, amplification attacks) have been identified in [RFC4942].
   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.

   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.








Jacquenet & Boucadair     Expires July 10, 2016                [Page 10]


Internet-Draft     draft-jacquenet-ipv6-eh-sfc-00.txt       January 2016


7.  Acknowledgements

   TBD

8.  References

8.1.  Normative References

   [IPFIX]    International Organization for Standardization, "IP Flow
              Information Export (IPFIX) Entities", 1992,
              <http://www.iana.org/assignments/ipfix/ipfix.xhtml>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

   [RFC6564]  Krishnan, S., Woodyatt, J., Kline, E., Hoagland, J., and
              M. Bhatia, "A Uniform Format for IPv6 Extension Headers",
              RFC 6564, DOI 10.17487/RFC6564, April 2012,
              <http://www.rfc-editor.org/info/rfc6564>.

   [RFC7045]  Carpenter, B. and S. Jiang, "Transmission and Processing
              of IPv6 Extension Headers", RFC 7045,
              DOI 10.17487/RFC7045, December 2013,
              <http://www.rfc-editor.org/info/rfc7045>.

8.2.  Informative References

   [RFC4942]  Davies, E., Krishnan, S., and P. Savola, "IPv6 Transition/
              Co-existence Security Considerations", RFC 4942,
              DOI 10.17487/RFC4942, September 2007,
              <http://www.rfc-editor.org/info/rfc4942>.

   [RFC7112]  Gont, F., Manral, V., and R. Bonica, "Implications of
              Oversized IPv6 Header Chains", RFC 7112,
              DOI 10.17487/RFC7112, January 2014,
              <http://www.rfc-editor.org/info/rfc7112>.

   [RFC7498]  Quinn, P., Ed. and T. Nadeau, Ed., "Problem Statement for
              Service Function Chaining", RFC 7498,
              DOI 10.17487/RFC7498, April 2015,
              <http://www.rfc-editor.org/info/rfc7498>.

   [RFC7665]  Halpern, J., Ed. and C. Pignataro, Ed., "Service Function
              Chaining (SFC) Architecture", RFC 7665,
              DOI 10.17487/RFC7665, October 2015,
              <http://www.rfc-editor.org/info/rfc7665>.



Jacquenet & Boucadair     Expires July 10, 2016                [Page 11]


Internet-Draft     draft-jacquenet-ipv6-eh-sfc-00.txt       January 2016


Authors' Addresses

   Christian Jacquenet
   Orange

   Email: christian.jacquenet@orange.com


   Mohamed Boucadair
   Orange

   Email: mohamed.boucadair@orange.com







































Jacquenet & Boucadair     Expires July 10, 2016                [Page 12]