| Network Working Group | C. Jacquenet |
| Internet-Draft | M. Boucadair |
| Intended status: Standards Track | France Telecom |
| Expires: January 4, 2016 | July 3, 2015 |
An IPv6 Extension Header for Service Function Chaining (SFC)
draft-jacquenet-sfc-ipv6-eh-00
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.
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].
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 January 4, 2016.
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
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.
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 [I-D.ietf-sfc-architecture].
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 ( [RFC6564]) to carry SFC-related information.
The proposed extension header is intended to be used within a single administrative domain.
The reader should be familiar with the terms defined in [RFC7498] and [I-D.ietf-sfc-architecture].
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
The IPv6 Extension Header to carry SFC metadata has format shown in Figure 3.
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
+-+-+-+-+-+-+-+-+
|P|E|r|r|r|r|r|M|
+-+-+-+-+-+-+-+-+
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:
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).
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 "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:
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.
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".
(to be completed)
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.
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.
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.
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 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:
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
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:
Security considerations discussed in [RFC7045] and [RFC7112] apply. Additional considerations are discussed in the following sub-sections.
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.
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.
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.
TBD
| [IPFIX] | International Organization for Standardization, "IP Flow Information Export (IPFIX) Entities", 1992. |
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. |
| [RFC6564] | Krishnan, S., Woodyatt, J., Kline, E., Hoagland, J. and M. Bhatia, "A Uniform Format for IPv6 Extension Headers", RFC 6564, April 2012. |
| [RFC7045] | Carpenter, B. and S. Jiang, "Transmission and Processing of IPv6 Extension Headers", RFC 7045, December 2013. |
| [I-D.ietf-sfc-architecture] | Halpern, J. and C. Pignataro, "Service Function Chaining (SFC) Architecture", Internet-Draft draft-ietf-sfc-architecture-09, June 2015. |
| [RFC4942] | Davies, E., Krishnan, S. and P. Savola, "IPv6 Transition/Co-existence Security Considerations", RFC 4942, September 2007. |
| [RFC7112] | Gont, F., Manral, V. and R. Bonica, "Implications of Oversized IPv6 Header Chains", RFC 7112, January 2014. |
| [RFC7498] | Quinn, P. and T. Nadeau, "Problem Statement for Service Function Chaining", RFC 7498, April 2015. |