One document matched: draft-jacquenet-sfc-ipv6-eh-00.xml
<?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-00" 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>France Telecom</organization>
<address>
<email>christian.jacquenet@orange.com</email>
</address>
</author>
<author fullname="Mohamed Boucadair" initials="M." surname="Boucadair">
<organization>France Telecom</organization>
<address>
<email>mohamed.boucadair@orange.com</email>
</address>
</author>
<date day="" month="" year="2015" />
<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="I-D.ietf-sfc-architecture"></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 proposed 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="I-D.ietf-sfc-architecture"></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>(to be completed)</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.I-D.ietf-sfc-architecture'?>
<?rfc include='reference.RFC.4942'?>
<?rfc include='reference.RFC.7498'?>
<?rfc include='reference.RFC.7112'?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 15:58:03 |