draft-ietf-sfc-nsh-24.txt   draft-ietf-sfc-nsh-25.txt 
Service Function Chaining P. Quinn, Ed. Service Function Chaining P. Quinn, Ed.
Internet-Draft Cisco Internet-Draft Cisco
Intended status: Standards Track U. Elzur, Ed. Intended status: Standards Track U. Elzur, Ed.
Expires: March 28, 2018 Intel Expires: April 1, 2018 Intel
C. Pignataro, Ed. C. Pignataro, Ed.
Cisco Cisco
September 24, 2017 September 28, 2017
Network Service Header (NSH) Network Service Header (NSH)
draft-ietf-sfc-nsh-24 draft-ietf-sfc-nsh-25
Abstract Abstract
This document describes a Network Service Header (NSH) imposed on This document describes a Network Service Header (NSH) imposed on
packets or frames to realize service function paths. The NSH also packets or frames to realize service function paths. The NSH also
provides a mechanism for metadata exchange along the instantiated provides a mechanism for metadata exchange along the instantiated
service paths. The NSH is the SFC encapsulation required to support service paths. The NSH is the SFC encapsulation required to support
the Service Function Chaining (SFC) architecture (defined in the Service Function Chaining (SFC) architecture (defined in
RFC7665). RFC7665).
skipping to change at page 1, line 38 skipping to change at page 1, line 38
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 28, 2018. This Internet-Draft will expire on April 1, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
1.2. Definition of Terms . . . . . . . . . . . . . . . . . . . 4 1.2. Applicability . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Problem Space . . . . . . . . . . . . . . . . . . . . . . 6 1.3. Definition of Terms . . . . . . . . . . . . . . . . . . . 5
1.4. NSH-based Service Chaining . . . . . . . . . . . . . . . 6 1.4. Problem Space . . . . . . . . . . . . . . . . . . . . . . 6
1.5. NSH-based Service Chaining . . . . . . . . . . . . . . . 6
2. Network Service Header . . . . . . . . . . . . . . . . . . . 7 2. Network Service Header . . . . . . . . . . . . . . . . . . . 7
2.1. Network Service Header Format . . . . . . . . . . . . . . 7 2.1. Network Service Header Format . . . . . . . . . . . . . . 7
2.2. NSH Base Header . . . . . . . . . . . . . . . . . . . . . 7 2.2. NSH Base Header . . . . . . . . . . . . . . . . . . . . . 8
2.3. Service Path Header . . . . . . . . . . . . . . . . . . . 10 2.3. Service Path Header . . . . . . . . . . . . . . . . . . . 11
2.4. NSH MD Type 1 . . . . . . . . . . . . . . . . . . . . . . 11 2.4. NSH MD Type 1 . . . . . . . . . . . . . . . . . . . . . . 12
2.5. NSH MD Type 2 . . . . . . . . . . . . . . . . . . . . . . 12 2.5. NSH MD Type 2 . . . . . . . . . . . . . . . . . . . . . . 12
2.5.1. Optional Variable Length Metadata . . . . . . . . . . 13 2.5.1. Optional Variable Length Metadata . . . . . . . . . . 13
3. NSH Actions . . . . . . . . . . . . . . . . . . . . . . . . . 14 3. NSH Actions . . . . . . . . . . . . . . . . . . . . . . . . . 14
4. NSH Transport Encapsulation . . . . . . . . . . . . . . . . . 16 4. NSH Transport Encapsulation . . . . . . . . . . . . . . . . . 16
5. Fragmentation Considerations . . . . . . . . . . . . . . . . 17 5. Fragmentation Considerations . . . . . . . . . . . . . . . . 17
6. Service Path Forwarding with NSH . . . . . . . . . . . . . . 17 6. Service Path Forwarding with NSH . . . . . . . . . . . . . . 17
6.1. SFFs and Overlay Selection . . . . . . . . . . . . . . . 17 6.1. SFFs and Overlay Selection . . . . . . . . . . . . . . . 17
6.2. Mapping the NSH to Network Topology . . . . . . . . . . . 20 6.2. Mapping the NSH to Network Topology . . . . . . . . . . . 21
6.3. Service Plane Visibility . . . . . . . . . . . . . . . . 21 6.3. Service Plane Visibility . . . . . . . . . . . . . . . . 21
6.4. Service Graphs . . . . . . . . . . . . . . . . . . . . . 21 6.4. Service Graphs . . . . . . . . . . . . . . . . . . . . . 22
7. Policy Enforcement with NSH . . . . . . . . . . . . . . . . . 21 7. Policy Enforcement with NSH . . . . . . . . . . . . . . . . . 22
7.1. NSH Metadata and Policy Enforcement . . . . . . . . . . . 21 7.1. NSH Metadata and Policy Enforcement . . . . . . . . . . . 22
7.2. Updating/Augmenting Metadata . . . . . . . . . . . . . . 23 7.2. Updating/Augmenting Metadata . . . . . . . . . . . . . . 24
7.3. Service Path Identifier and Metadata . . . . . . . . . . 25 7.3. Service Path Identifier and Metadata . . . . . . . . . . 25
8. Security Considerations . . . . . . . . . . . . . . . . . . . 25 8. Security Considerations . . . . . . . . . . . . . . . . . . . 26
8.1. Transport Encapsulation Protocol Security . . . . . . . . 26 8.1. Transport Encapsulation Protocol Security . . . . . . . . 27
8.2. Boundary Protection . . . . . . . . . . . . . . . . . . . 26 8.2. Boundary Protection . . . . . . . . . . . . . . . . . . . 27
8.3. Metadata Considerations . . . . . . . . . . . . . . . . . 27 8.3. Metadata Considerations . . . . . . . . . . . . . . . . . 28
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 28 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 29
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 30
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31
11.1. NSH EtherType . . . . . . . . . . . . . . . . . . . . . 30 11.1. Network Service Header (NSH) Parameters . . . . . . . . 31
11.2. Network Service Header (NSH) Parameters . . . . . . . . 30 11.1.1. NSH Base Header Bits . . . . . . . . . . . . . . . . 31
11.2.1. NSH Base Header Bits . . . . . . . . . . . . . . . . 30 11.1.2. NSH Version . . . . . . . . . . . . . . . . . . . . 31
11.2.2. NSH Version . . . . . . . . . . . . . . . . . . . . 30 11.1.3. MD Type Registry . . . . . . . . . . . . . . . . . . 31
11.2.3. MD Type Registry . . . . . . . . . . . . . . . . . . 31 11.1.4. MD Class Registry . . . . . . . . . . . . . . . . . 32
11.2.4. MD Class Registry . . . . . . . . . . . . . . . . . 31 11.1.5. New IETF Assigned Optional Variable Length Metadata
11.2.5. NSH Base Header Next Protocol . . . . . . . . . . . 32
11.2.6. New IETF Assigned Optional Variable Length Metadata
Type Registry . . . . . . . . . . . . . . . . . . . 33 Type Registry . . . . . . . . . . . . . . . . . . . 33
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 33 11.1.6. NSH Base Header Next Protocol . . . . . . . . . . . 33
12.1. Normative References . . . . . . . . . . . . . . . . . . 33 12. NSH-Related Codepoints . . . . . . . . . . . . . . . . . . . 34
12.2. Informative References . . . . . . . . . . . . . . . . . 33 12.1. NSH EtherType . . . . . . . . . . . . . . . . . . . . . 34
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 34
13.1. Normative References . . . . . . . . . . . . . . . . . . 34
13.2. Informative References . . . . . . . . . . . . . . . . . 35
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37
1. Introduction 1. Introduction
Service functions are widely deployed and essential in many networks. Service functions are widely deployed and essential in many networks.
These service functions provide a range of features such as security, These service functions provide a range of features such as security,
WAN acceleration, and server load balancing. Service functions may WAN acceleration, and server load balancing. Service functions may
be instantiated at different points in the network infrastructure be instantiated at different points in the network infrastructure
such as the wide area network, data center, and so forth. such as the wide area network, data center, and so forth.
Prior to development of the SFC architecture [RFC7665] and the Prior to development of the SFC architecture [RFC7665] and the
skipping to change at page 4, line 23 skipping to change at page 4, line 23
Figure 1: Network Service Header Encapsulation Figure 1: Network Service Header Encapsulation
The NSH is composed of the following elements: The NSH is composed of the following elements:
1. Service Function Path identification. 1. Service Function Path identification.
2. Indication of location within a Service Function Path. 2. Indication of location within a Service Function Path.
3. Optional, per packet metadata (fixed length or variable). 3. Optional, per packet metadata (fixed length or variable).
[RFC7665] provides an overview of a service chaining architecture
that clearly defines the roles of the various elements and the scope
of a service function chaining encapsulation. Figure 3 of [RFC7665]
depicts the SFC architectural components after classification. The
NSH is the SFC encapsulation referenced in [RFC7665].
1.1. 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].
1.2. Applicability
The NSH is designed to be easy to implement across a range of The NSH is designed to be easy to implement across a range of
devices, both physical and virtual, including hardware platforms. devices, both physical and virtual, including hardware platforms.
The intended scope of the NSH is for use within a single provider's The intended scope of the NSH is for use within a single provider's
operational domain. This deployment scope is deliberately operational domain. This deployment scope is deliberately
constrained, as explained also in [RFC7665], and limited to a single constrained, as explained also in [RFC7665], and limited to a single
network administrative domain. In this context, a "domain" is a set network administrative domain. In this context, a "domain" is a set
of network entities within a single administration. For example, a of network entities within a single administration. For example, a
network administrative domain can include a single data center, or an network administrative domain can include a single data center, or an
overlay domain using virtual connections and tunnels. A corollary is overlay domain using virtual connections and tunnels. A corollary is
that a network administrative domain has a well defined perimeter. that a network administrative domain has a well defined perimeter.
An NSH-aware control plane is outside the scope of this document. An NSH-aware control plane is outside the scope of this document.
[RFC7665] provides an overview of a service chaining architecture 1.3. Definition of Terms
that clearly defines the roles of the various elements and the scope
of a service function chaining encapsulation. The NSH is the SFC
encapsulation referenced in [RFC7665].
1.1. 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].
1.2. Definition of Terms
Byte: All references to "bytes" in this document refer to 8-bit Byte: All references to "bytes" in this document refer to 8-bit
bytes, or octets. bytes, or octets.
Classification: Defined in [RFC7665]. Classification: Defined in [RFC7665].
Classifier: Defined in [RFC7665]. Classifier: Defined in [RFC7665].
Metadata: Defined in [RFC7665]. The metadata, or context Metadata: Defined in [RFC7665]. The metadata, or context
information shared between classifiers and SFs, and among SFs, is information shared between classifiers and SFs, and among SFs, is
skipping to change at page 6, line 5 skipping to change at page 6, line 11
Service Function Forwarder (SFF): Defined in [RFC7665]. Service Function Forwarder (SFF): Defined in [RFC7665].
Service Function Path (SFP): Defined in [RFC7665]. Service Function Path (SFP): Defined in [RFC7665].
Service Plane: The collection of SFFs and associated SFs creates a Service Plane: The collection of SFFs and associated SFs creates a
service-plane overlay in which all SFs and SFC Proxies reside service-plane overlay in which all SFs and SFC Proxies reside
[RFC7665]. [RFC7665].
SFC Proxy: Defined in [RFC7665]. SFC Proxy: Defined in [RFC7665].
1.3. Problem Space 1.4. Problem Space
The NSH addresses several limitations associated with service The NSH addresses several limitations associated with service
function deployments. [RFC7498] provides a comprehensive review of function deployments. [RFC7498] provides a comprehensive review of
those issues. those issues.
1.4. NSH-based Service Chaining 1.5. NSH-based Service Chaining
The NSH creates a dedicated service plane; more specifically, the NSH The NSH creates a dedicated service plane; more specifically, the NSH
enables: enables:
1. Topological Independence: Service forwarding occurs within the 1. Topological Independence: Service forwarding occurs within the
service plane, so the underlying network topology does not service plane, so the underlying network topology does not
require modification. The NSH provides an identifier used to require modification. The NSH provides an identifier used to
select the network overlay for network forwarding. select the network overlay for network forwarding.
2. Service Chaining: The NSH enables service chaining per [RFC7665]. 2. Service Chaining: The NSH enables service chaining per [RFC7665].
skipping to change at page 8, line 17 skipping to change at page 8, line 21
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ver|O|U| TTL | Length |U|U|U|U|MD Type| Next Protocol | |Ver|O|U| TTL | Length |U|U|U|U|MD Type| Next Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: NSH Base Header Figure 3: NSH Base Header
Base Header Field Descriptions: Base Header Field Descriptions:
Version: The version field is used to ensure backward compatibility Version: The version field is used to ensure backward compatibility
going forward with future NSH specification updates. It MUST be set going forward with future NSH specification updates. It MUST be set
to 0x0 by the sender, in this first revision of the NSH. Given the to 0x0 by the sender, in this first revision of the NSH. If a packet
widespread implementation of existing hardware that uses the first presumed to carry an NSH header is received at an SFF, and the SFF
nibble after an MPLS label stack for equal-cost multipath (ECMP) does not understnad the version of the protocol as indicated in the
decision processing, this document reserves version 01b. This value base header, the packet MUST be discarded, and the event SHOULD be
MUST NOT be used in future versions of the protocol. Please see logged. Given the widespread implementation of existing hardware
[RFC7325] for further discussion of MPLS-related forwarding that uses the first nibble after an MPLS label stack for equal-cost
requirements. multipath (ECMP) decision processing, this document reserves version
01b. This value MUST NOT be used in future versions of the protocol.
Please see [RFC7325] for further discussion of MPLS-related
forwarding requirements.
O bit: Setting this bit indicates an Operations, Administration, and O bit: Setting this bit indicates an Operations, Administration, and
Maintenance (OAM) packet. The actual format and processing of SFC Maintenance (OAM) packet. The actual format and processing of SFC
OAM packets is outside the scope of this specification (see for OAM packets is outside the scope of this specification (see for
example [I-D.ietf-sfc-oam-framework] for one approach). example [I-D.ietf-sfc-oam-framework] for one approach).
The O bit MUST be set for OAM packets and MUST NOT be set for non-OAM The O bit MUST be set for OAM packets and MUST NOT be set for non-OAM
packets. The O bit MUST NOT be modified along the SFP. packets. The O bit MUST NOT be modified along the SFP.
SF/SFF/SFC Proxy/Classifier implementations that do not support SFC SF/SFF/SFC Proxy/Classifier implementations that do not support SFC
skipping to change at page 9, line 8 skipping to change at page 9, line 16
for service plane loop detection. The initial TTL value SHOULD be for service plane loop detection. The initial TTL value SHOULD be
configurable via the control plane; the configured initial value can configurable via the control plane; the configured initial value can
be specific to one or more SFPs. If no initial value is explicitly be specific to one or more SFPs. If no initial value is explicitly
provided, the default initial TTL value of 63 MUST be used. Each SFF provided, the default initial TTL value of 63 MUST be used. Each SFF
involved in forwarding an NSH packet MUST decrement the TTL value by involved in forwarding an NSH packet MUST decrement the TTL value by
1 prior to NSH forwarding lookup. Decrementing by 1 from an incoming 1 prior to NSH forwarding lookup. Decrementing by 1 from an incoming
value of 0 shall result in a TTL value of 63. The packet MUST NOT be value of 0 shall result in a TTL value of 63. The packet MUST NOT be
forwarded if TTL is, after decrement, 0. forwarded if TTL is, after decrement, 0.
This TTL field is the primary loop prevention This TTL mechanism This TTL field is the primary loop prevention This TTL mechanism
represents a robust complement to the Service Index, as the TTL is represents a robust complement to the Service Index (see
decrement by each SFF. The handling of incoming 0 TTL allows for Section 2.3), as the TTL is decrement by each SFF. The handling of
better, although not perfect, interoperation with pre-standard incoming 0 TTL allows for better, although not perfect,
implementations that do not support this TTL field. interoperation with pre-standard implementations that do not support
this TTL field.
Unassigned bits: All other flag fields, marked U, are unassigned and Unassigned bits: All other flag fields, marked U, are unassigned and
available for future use, see Section 11.2.1. Unassigned bits MUST available for future use, see Section 11.1.1. Unassigned bits MUST
be set to zero upon origination, and MUST be ignored and preserved be set to zero upon origination, and MUST be ignored and preserved
unmodified by other NSH supporting elements. At reception, all unmodified by other NSH supporting elements. At reception, all
elements MUST NOT modify their actions based on these unknown bits. elements MUST NOT modify their actions based on these unknown bits.
Length: The total length, in 4-byte words, of the NSH including the Length: The total length, in 4-byte words, of the NSH including the
Base Header, the Service Path Header, the Fixed Length Context Header Base Header, the Service Path Header, the Fixed Length Context Header
or Variable Length Context Header(s). The length MUST be 0x6 for MD or Variable Length Context Header(s). The length MUST be 0x6 for MD
Type equal to 0x1, and MUST be 0x2 or greater for MD Type equal to Type equal to 0x1, and MUST be 0x2 or greater for MD Type equal to
0x2. The length of the NSH header MUST be an integer multiple of 4 0x2. The length of the NSH header MUST be an integer multiple of 4
bytes, thus variable length metadata is always padded out to a bytes, thus variable length metadata is always padded out to a
multiple of 4 bytes. multiple of 4 bytes.
Metadata (MD) Type: Indicates the format of the NSH beyond the Metadata (MD) Type: Indicates the format of the NSH beyond the
mandatory Base Header and the Service Path Header. MD Type defines mandatory Base Header and the Service Path Header. MD Type defines
the format of the metadata being carried. Please see the IANA the format of the metadata being carried. Please see the IANA
Considerations Section 11.2.3. Considerations Section 11.1.3.
This document specifies the following four MD Type values: This document specifies the following four MD Type values:
0x0 - This is a reserved value. Implementations SHOULD silently 0x0 - This is a reserved value. Implementations SHOULD silently
discard packets with MD Type 0x0. discard packets with MD Type 0x0.
0x1 - This indicates that the format of the header includes a fixed 0x1 - This indicates that the format of the header includes a fixed
length Context Header (see Figure 5 below). length Context Header (see Figure 5 below).
0x2 - This does not mandate any headers beyond the Base Header and 0x2 - This does not mandate any headers beyond the Base Header and
Service Path Header, but may contain optional variable length Context Service Path Header, but may contain optional variable length Context
Header(s). The semantics of the variable length Context Header(s) Header(s). With MD Type 0x2, a Length of 0x2 implies there are no
are not defined in this document. The format of the optional Context Headers. The semantics of the variable length Context
variable length Context Headers is provided in Section 2.5.1. Header(s) are not defined in this document. The format of the
optional variable length Context Headers is provided in
Section 2.5.1.
0xF - This value is reserved for experimentation and testing, as per 0xF - This value is reserved for experimentation and testing, as per
[RFC3692]. Implementations not explicitly configured to be part of [RFC3692]. Implementations not explicitly configured to be part of
an experiment SHOULD silently discard packets with MD Type 0xF. an experiment SHOULD silently discard packets with MD Type 0xF.
The format of the Base Header and the Service Path Header is The format of the Base Header and the Service Path Header is
invariant, and not affected by MD Type. invariant, and not affected by MD Type.
The NSH MD Type 1 and MD Type 2 are described in detail in Sections The NSH MD Type 1 and MD Type 2 are described in detail in Sections
2.4 and 2.5, respectively. NSH implementations MUST support MD types 2.4 and 2.5, respectively. NSH implementations MUST support MD types
0x1 and 0x2 (where the length is 0x2). NSH implementations SHOULD 0x1 and 0x2 (where the length is 0x2). NSH implementations SHOULD
support MD Type 0x2 with length greater than 0x2. There exists, support MD Type 0x2 with length greater than 0x2. Devices that do
however, a middle ground, wherein a device will support MD Type 0x1 not support MD Type 0x2 with length greater than 0x2 MUST ignore any
(as per the MUST) metadata, yet be deployed in a network with MD Type optional context headers and process the packet without them; the
0x2 metadata packets. In that case, the MD Type 0x1 node, MUST base header length field can be used to determine the original
utilize the base header length field to determine the original payload offset if access to the original packet/frame is required.
payload offset if it requires access to the original packet/frame.
This specification does not disallow the MD Type value from changing This specification does not disallow the MD Type value from changing
along an SFP; however, the specification of the necessary mechanism along an SFP; however, the specification of the necessary mechanism
to allow the MD Type to change along an SFP are outside the scope of to allow the MD Type to change along an SFP are outside the scope of
this document and would need to be defined for that functionality to this document and would need to be defined for that functionality to
be available. Packets with MD Type values not supported by an be available. Packets with MD Type values not supported by an
implementation MUST be silently dropped. implementation MUST be silently dropped.
Next Protocol: indicates the protocol type of the encapsulated data. Next Protocol: indicates the protocol type of the encapsulated data.
The NSH does not alter the inner payload, and the semantics on the The NSH does not alter the inner payload, and the semantics on the
inner protocol remain unchanged due to NSH service function chaining. inner protocol remain unchanged due to NSH service function chaining.
Please see the IANA Considerations section below, Section 11.2.5. Please see the IANA Considerations section below, Section 11.1.6.
This document defines the following Next Protocol values: This document defines the following Next Protocol values:
0x1: IPv4 0x1: IPv4
0x2: IPv6 0x2: IPv6
0x3: Ethernet 0x3: Ethernet
0x4: NSH 0x4: NSH
0x5: MPLS 0x5: MPLS
0xFE: Experiment 1 0xFE: Experiment 1
0xFF: Experiment 2 0xFF: Experiment 2
Packets with Next Protocol values not supported SHOULD be silently The functionality of hierarchical NSH using a Next Protocol value of
dropped by default, although an implementation MAY provide a 0x4 NSH is outside the scope of this specification. Packets with
configuration parameter to forward them. Additionally, an Next Protocol values not supported SHOULD be silently dropped by
implementation not explicitly configured for a specific experiment default, although an implementation MAY provide a configuration
[RFC3692] SHOULD silently drop packets with Next Protocol values 0xFE parameter to forward them. Additionally, an implementation not
and 0xFF. explicitly configured for a specific experiment [RFC3692] SHOULD
silently drop packets with Next Protocol values 0xFE and 0xFF.
2.3. Service Path Header 2.3. Service Path Header
Figure 4 shows the format of the Service Path Header: Figure 4 shows the format of the Service Path Header:
0 1 2 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Path Identifier (SPI) | Service Index | | Service Path Identifier (SPI) | Service Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 12, line 24 skipping to change at page 12, line 31
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: NSH MD Type=0x1 Figure 5: NSH MD Type=0x1
This specification does not make any assumptions about the content of This specification does not make any assumptions about the content of
the 16 byte Context Header that must be present when the MD Type the 16 byte Context Header that must be present when the MD Type
field is set to 1, and does not describe the structure or meaning of field is set to 1, and does not describe the structure or meaning of
the included metadata. the included metadata.
An SFC-aware SF MUST receive the data semantics first in order to An SFC-aware SF or SFC Proxy MUST receive the data semantics first in
process the data placed in the mandatory context field. The data order to process the data placed in the mandatory context field. The
semantics include both the allocation schema and the meaning of the data semantics include both the allocation schema and the meaning of
included data. How an SFC-aware SF gets the data semantics is the included data. How an SFC-aware SF or SFC Proxy gets the data
outside the scope of this specification. semantics is outside the scope of this specification.
An SF or SFC Proxy that does not know the format or semantics of the An SF or SFC Proxy that does not know the format or semantics of the
Context Header for an NSH with MD Type 1 MUST discard any packet with Context Header for an NSH with MD Type 1 MUST discard any packet with
such an NSH (i.e., MUST NOT ignore the metadata that it cannot such an NSH (i.e., MUST NOT ignore the metadata that it cannot
process), and MUST log the event at least once per the SPI for which process), and MUST log the event at least once per the SPI for which
the event occurs (subject to thresholding). the event occurs (subject to thresholding).
[I-D.guichard-sfc-nsh-dc-allocation] and [I-D.guichard-sfc-nsh-dc-allocation] and
[I-D.napper-sfc-nsh-broadband-allocation] provide specific examples [I-D.napper-sfc-nsh-broadband-allocation] provide specific examples
of how metadata can be allocated. of how metadata can be allocated.
skipping to change at page 13, line 36 skipping to change at page 13, line 41
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Metadata Class | Type |U| Length | | Metadata Class | Type |U| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Variable Metadata | | Variable Metadata |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: Variable Context Headers Figure 7: Variable Context Headers
Metadata Class (MD Class): Defines the scope of the 'Type' field to Metadata Class (MD Class): Defines the scope of the 'Type' field to
provide a hierarchical namespace. The IANA Considerations provide a hierarchical namespace. The IANA Considerations
Section 11.2.4 defines how the MD Class values can be allocated to Section 11.1.4 defines how the MD Class values can be allocated to
standards bodies, vendors, and others. standards bodies, vendors, and others.
Type: Indicates the explicit type of metadata being carried. The Type: Indicates the explicit type of metadata being carried. The
definition of the Type is the responsibility of the MD Class owner. definition of the Type is the responsibility of the MD Class owner.
Unassigned bit: One unassigned bit is available for future use. This Unassigned bit: One unassigned bit is available for future use. This
bit MUST NOT be set, and MUST be ignored on receipt. bit MUST NOT be set, and MUST be ignored on receipt.
Length: Indicates the length of the variable metadata, in bytes. In Length: Indicates the length of the variable metadata, in bytes. In
case the metadata length is not an integer number of 4-byte words, case the metadata length is not an integer number of 4-byte words,
skipping to change at page 14, line 32 skipping to change at page 14, line 38
If multiple mandatory-to-process context headers are required for a If multiple mandatory-to-process context headers are required for a
given SFP, the control plane MAY instruct the SFC-aware SF with the given SFP, the control plane MAY instruct the SFC-aware SF with the
order to consume these Context Headers. If no instructions are order to consume these Context Headers. If no instructions are
provided and the SFC-aware SF will make use of or modify the specific provided and the SFC-aware SF will make use of or modify the specific
context header, then the SFC-aware SF MUST process these Context context header, then the SFC-aware SF MUST process these Context
Headers in the order they appear in an NSH packet. Headers in the order they appear in an NSH packet.
If multiple instances of the same metadata are included in an NSH If multiple instances of the same metadata are included in an NSH
packet, but the definition of that context header does not allow for packet, but the definition of that context header does not allow for
it, the SFC-aware SF MUST process the first instance and ignore it, the SFC-aware SF MUST process the first instance and ignore
subsequent instances. subsequent instances. The SFC-aware SF MAY log or increase a counter
for this event.
3. NSH Actions 3. NSH Actions
NSH-aware nodes, which include service classifiers, SFFs, SFs and SFC NSH-aware nodes, which include service classifiers, SFFs, SFs and SFC
proxies, may alter the contents of the NSH headers. These nodes have proxies, may alter the contents of the NSH headers. These nodes have
several possible NSH-related actions: several possible NSH-related actions:
1. Insert or remove the NSH: These actions can occur respectively at 1. Insert or remove the NSH: These actions can occur respectively at
the start and end of a service path. Packets are classified, and the start and end of a service path. Packets are classified, and
if determined to require servicing, an NSH will be imposed. A if determined to require servicing, an NSH will be imposed. A
skipping to change at page 15, line 9 skipping to change at page 15, line 16
encapsulated packet. It is therefore the last node operating on encapsulated packet. It is therefore the last node operating on
the service header. the service header.
Multiple logical classifiers may exist within a given service Multiple logical classifiers may exist within a given service
path. Non-initial classifiers may re-classify data and that re- path. Non-initial classifiers may re-classify data and that re-
classification MAY result in the selection of a different Service classification MAY result in the selection of a different Service
Function Path. When the logical classifier performs re- Function Path. When the logical classifier performs re-
classification that results in a change of service path, it MUST classification that results in a change of service path, it MUST
replace the existing NSH with a new NSH with the Base Header and replace the existing NSH with a new NSH with the Base Header and
Service Path Header reflecting the new service path information Service Path Header reflecting the new service path information
and MUST set the initial SI. The O bit, as well as unassigned and MUST set the initial SI. The O bit, the TTL field, as well
flags, MUST be copied transparently from the old NSH to a new as unassigned flags, MUST be copied transparently from the old
NSH. Metadata MAY be preserved in the new NSH. NSH to a new NSH. Metadata MAY be preserved in the new NSH.
2. Select service path: The Service Path Header provides service 2. Select service path: The Service Path Header provides service
path information and is used by SFFs to determine correct service path information and is used by SFFs to determine correct service
path selection. SFFs MUST use the Service Path Header for path selection. SFFs MUST use the Service Path Header for
selecting the next SF or SFF in the service path. selecting the next SF or SFF in the service path.
3. Update the NSH: SFs MUST decrement the service index by one. If 3. Update the NSH: SFs MUST decrement the service index by one. If
an SFF receives a packet with an SPI and SI that do not an SFF receives a packet with an SPI and SI that do not
correspond to a valid next hop in a valid Service Function Path, correspond to a valid next hop in a valid Service Function Path,
that packet MUST be dropped by the SFF. that packet MUST be dropped by the SFF.
skipping to change at page 17, line 24 skipping to change at page 17, line 24
single provider's operational domain, that approach is sufficient. single provider's operational domain, that approach is sufficient.
However, although explicitly outside the scope of this specification, However, although explicitly outside the scope of this specification,
there might be cases where the underlay MTU is not large enough to there might be cases where the underlay MTU is not large enough to
carry the NSH traffic. Since the NSH does not provide fragmentation carry the NSH traffic. Since the NSH does not provide fragmentation
support at the service plane, the transport encapsulation protocol support at the service plane, the transport encapsulation protocol
ought to provide the requisite fragmentation handling. For instance, ought to provide the requisite fragmentation handling. For instance,
Section 9 of [I-D.ietf-rtgwg-dt-encap] provides exemplary approaches Section 9 of [I-D.ietf-rtgwg-dt-encap] provides exemplary approaches
and guidance for those scenarios. and guidance for those scenarios.
When the transport encapsulation protocol supports fragmentation, and
fragmentation procedures needs to be used, such fragmentation is part
of the transport encapsulation logic. If, as it is common,
fragmentation is performed by the endpoints of the transport
encapsulation, then fragmentation procedures are performed at the
sending NSH entity as part of the transport encapsulation, and
reassembly procedures are performed at the receiving NSH entity
during transport de-encapsulation handling logic. In no case would
such fragmentation result in duplication of the NSH header.
For example, when the NSH is encapsulated in IP, IP-level For example, when the NSH is encapsulated in IP, IP-level
fragmentation coupled with Path MTU Discovery (PMTUD) is used. When, fragmentation coupled with Path MTU Discovery (PMTUD) (e.g.,
on the other hand, the underlay does not support fragmentation [RFC8201]) is used. Since PMTUD relies on ICMP messages, an operator
procedures, an error message SHOULD be logged when dropping a packet should ensure ICMP packets are not blocked. When, on the other hand,
too big. Lastly, NSH-specific fragmentation and reassembly methods the underlay does not support fragmentation procedures, an error
may be defined as well, but these methods are outside the scope of message SHOULD be logged when dropping a packet too big. Lastly,
this document, and subject for future work. NSH-specific fragmentation and reassembly methods may be defined as
well, but these methods are outside the scope of this document, and
subject for future work.
6. Service Path Forwarding with NSH 6. Service Path Forwarding with NSH
6.1. SFFs and Overlay Selection 6.1. SFFs and Overlay Selection
As described above, the NSH contains a Service Path Identifier (SPI) As described above, the NSH contains a Service Path Identifier (SPI)
and a Service Index (SI). The SPI is, as per its name, an and a Service Index (SI). The SPI is, as per its name, an
identifier. The SPI alone cannot be used to forward packets along a identifier. The SPI alone cannot be used to forward packets along a
service path. Rather the SPI provides a level of indirection between service path. Rather the SPI provides a level of indirection between
the service path/topology and the network transport encapsulation. the service path/topology and the network transport encapsulation.
skipping to change at page 20, line 24 skipping to change at page 20, line 47
| | | | | | | | | |
| 30 | 7 | 192.0.2.10 | 10 | | 30 | 7 | 192.0.2.10 | 10 |
| | | | | | | | | |
| | | 198.51.100.1 | 5 | | | | 198.51.100.1 | 5 |
+------+-----+--------------+---------+ +------+-----+--------------+---------+
(encapsulation type omitted for formatting) (encapsulation type omitted for formatting)
Table 4: NSH Weighted Service Path Table 4: NSH Weighted Service Path
The information contained in Tables 1-4 may be received from the
control plane, but the exact mechanism is outside the scope of this
document.
6.2. Mapping the NSH to Network Topology 6.2. Mapping the NSH to Network Topology
As described above, the mapping of SPI to network topology may result As described above, the mapping of SPI to network topology may result
in a single path, or it might result in a more complex topology. in a single path, or it might result in a more complex topology.
Furthermore, the SPI to overlay mapping occurs at each SFF Furthermore, the SPI to overlay mapping occurs at each SFF
independently. Any combination of topology selection is possible. independently. Any combination of topology selection is possible.
Please note, there is no requirement to create a new overlay topology Please note, there is no requirement to create a new overlay topology
if a suitable one already exists. NSH packets can use any (new or if a suitable one already exists. NSH packets can use any (new or
existing) overlay provided the requisite connectivity requirements existing) overlay provided the requisite connectivity requirements
are satisfied. are satisfied.
skipping to change at page 25, line 49 skipping to change at page 26, line 35
DoS DoS
"Scrubber" "Scrubber"
Figure 13: Path ID and Metadata Figure 13: Path ID and Metadata
Specific algorithms for mapping metadata to an SPI are outside the Specific algorithms for mapping metadata to an SPI are outside the
scope of this document. scope of this document.
8. Security Considerations 8. Security Considerations
NSH is designed for use within operator environments. As such, it NSH is designed for use within a single operator environment. As
does not include any mandatory security mechanisms. As with many such, it does not include any mandatory security mechanisms. As with
other protocols, without enhancements, the NSH encapsulation can be many other protocols, by itself and without extensions, the NSH
spoofed and is subject to snooping and modification in transit. encapsulation can be spoofed and is subject to snooping and
modification in transit. However, the deployment scope (as defined
However, the deployment scope (as defined in [RFC7665]) of the NSH in [RFC7665]) of the NSH encapsulation is limited to a single network
encapsulation is limited to a single network administrative domain as administrative domain as a controlled environment, with trusted
a controlled environment, with trusted devices (e.g., a data center) devices (e.g., a data center) hence mitigating the risk of
hence mitigating the risk of unauthorized manipulation of the unauthorized manipulation of the encapsulation headers or metadata.
encapsulation headers or metadata. This controlled environment is an This controlled environment is an important assumption for NSH.
important assumption for NSH. There is one additional important There is one additional important assumption: All of the service
assumption: All of the service functions used by an operator in functions used by an operator in service chains are assumed to be
service chains are assumed to be selected and vetted by the operator. selected and vetted by the operator.
An attacker with access to the traffic in an operators network can An attacker with access to the traffic in an operators network can
potentially observe the metadata NSH carries with packets, potentially observe the metadata NSH carries with packets,
potentially discovering privacy sensitive information. Similarly, potentially discovering privacy sensitive information. Similarly,
attackers who can modify packets within the operators network may be attackers who can modify packets within the operators network may be
able to modify the service function path, path position, and / or the able to modify the service function path, path position, and / or the
metadata associated with a packet. If an attacker can compromise SFC metadata associated with a packet. If an attacker can compromise SFC
Classifiers, Service Function Forwarders, or Service Functions, then Classifiers, Service Function Forwarders, or Service Functions, then
they can inspect any or the NSH information. they can inspect any of the NSH information.
8.1. Transport Encapsulation Protocol Security 8.1. Transport Encapsulation Protocol Security
NSH is always encapsulated in a transport encapsulation protocol NSH is always encapsulated in a transport encapsulation protocol
between SFC components (as detailed in Section 4 of this between SFC components (as detailed in Section 4 of this
specification). In selecting the transport encapsulation protocol to specification). In selecting the transport encapsulation protocol to
use in a partciular deployment, operators SHOULD evaluate the degree use in a particular deployment, operators SHOULD evaluate the degree
of protection from e.g., intermediate observation and modification of protection from e.g., intermediate observation and modification
that is needed. Operators SHOULD then select a transport that is needed. Operators SHOULD then select a transport
encapsulation protocol such as one that supports [RFC6071] to provide encapsulation protocol such as one that supports [RFC6071] to provide
the needed protection (e.g., authenticity, confidentiality) for the the needed protection (e.g., authenticity, confidentiality) for the
traffic between SFC components. Operators MUST ensure the selected traffic between SFC components. Operators MUST ensure the selected
transport encapsulation protocol can be supported by the transport transport encapsulation protocol can be supported by the transport
encapsulation/underlay of all relevant network segments as well as encapsulation/underlay of all relevant network segments as well as
SFFs, SFs and SFC proxies in the service path. SFFs, SFs and SFC proxies in the service path.
One example where transport encapsulation protocol security is highly One example where transport encapsulation protocol security is highly
applicable is when an operator is using the public Internet to applicable is when an operator is using the public Internet to
provide communication between two parts of their own administrative provide communication between two parts of their own administrative
domain. domain.
Further, existing best practices, such as [BCP38] SHOULD be deployed [I-D.ietf-rtgwg-dt-encap] provides additional transport encapsulation
at the network layer to ensure that traffic entering the service path considerations.
is indeed "valid". [I-D.ietf-rtgwg-dt-encap] provides additional
transport encapsulation considerations.
8.2. Boundary Protection 8.2. Boundary Protection
Given the potential sensitivity of NSH information, it is important Given the potential sensitivity of NSH information, it is important
that operators ensure that NSH encapsulated packets do not leave the that operators ensure that NSH encapsulated packets do not leave the
operator domain. The first step in such is that NSH Egress devices operator domain. The first step in such is that NSH egress devices
MUST strip the NSH headers before they send the users packets or MUST strip the NSH headers before they send the users packets or
frames out of the NSH domain. Means to prevent leaking privacy- frames out of the NSH domain. Means to prevent leaking privacy-
related information outside an administrative domain are natively related information outside an administrative domain are natively
supported by the NSH given that the last SFF of a service path will supported by the NSH given that the last SFF of a service path will
systematically remove the NSH encapsulation before forwarding a systematically remove the NSH encapsulation before forwarding a
packet exiting the service path. packet exiting the service path.
The second step in such prevention is to filter the transport The second step in such prevention is to filter the transport
encapsulation protocol used by NSH at the doamin edge. Depending encapsulation protocol used by NSH at the doamin edge. Depending
upon the transport encapsulation protocol used for NSH, this can upon the transport encapsulation protocol used for NSH, this can
either be done by completely blocking the transport encapsulation either be done by completely blocking the transport encapsulation
(for example if MPLS is the chosen NSH transport encapsulation (for example if MPLS is the chosen NSH transport encapsulation
protocol, and is never allowed to leave the domain) or by examing the protocol, and is never allowed to leave the domain) or by examing the
carried protocol with the transport encapsulation (for example if carried protocol with the transport encapsulation (for example if
VxLAN-gpe is used as the NSH transport encapsulation protocol, all VxLAN-gpe is used as the NSH transport encapsulation protocol, all
domain edges MUST filter based on the carried protocol in the VxLAN- domain edges need to filter based on the carried protocol in the
gpe.) VxLAN-gpe.)
The other consequence of this sensitivity is that ingress packets The other consequence of this sensitivity is that ingress packets
MUST also be filtered to prevent attackers from sending in NSH MUST also be filtered to prevent attackers from sending in NSH
packets with service path identification and metadata of their own packets with service path identification and metadata of their own
selection. The same filters as described above for both the NSH selection. The same filters as described above for both the NSH
devices and for the general edge protections MUST be applied on devices and for the general edge protections MUST be applied on
ingress. ingress.
In summary, packets originating outside the SFC-enabled domain must In summary, packets originating outside the SFC-enabled domain must
be dropped if they contain an NSH. Similarly, packets exiting the be dropped if they contain an NSH. Similarly, packets exiting the
skipping to change at page 30, line 26 skipping to change at page 31, line 11
The editors also acknowledge comprehensive reviews and respective The editors also acknowledge comprehensive reviews and respective
suggestions by Med Boucadair, Adrian Farrel, Juergen Schoenwaelder, suggestions by Med Boucadair, Adrian Farrel, Juergen Schoenwaelder,
and Acee Lindem. and Acee Lindem.
Lastly, David Dolson has provides significant review, feedback and Lastly, David Dolson has provides significant review, feedback and
suggestions throughout the evolution of this document. His suggestions throughout the evolution of this document. His
contributions are very much appreciated. contributions are very much appreciated.
11. IANA Considerations 11. IANA Considerations
11.1. NSH EtherType 11.1. Network Service Header (NSH) Parameters
An IEEE EtherType, 0x894F, has been allocated for NSH.
11.2. Network Service Header (NSH) Parameters
IANA is requested to create a new "Network Service Header (NSH) IANA is requested to create a new "Network Service Header (NSH)
Parameters" registry. The following sub-sections request new Parameters" registry. The following sub-sections request new
registries within the "Network Service Header (NSH) Parameters " registries within the "Network Service Header (NSH) Parameters "
registry. registry.
11.2.1. NSH Base Header Bits 11.1.1. NSH Base Header Bits
There are five unassigned bits (U bits) in the NSH Base Header, and There are five unassigned bits (U bits) in the NSH Base Header, and
one assigned bit (O bit). New bits are assigned via Standards Action one assigned bit (O bit). New bits are assigned via Standards Action
[RFC8126]. [RFC8126].
Bit 2 - O (OAM) bit Bit 2 - O (OAM) bit
Bit 3 - Unassigned Bit 3 - Unassigned
Bits 16-19 - Unassigned Bits 16-19 - Unassigned
11.2.2. NSH Version 11.1.2. NSH Version
IANA is requested to setup a registry of "NSH Version". New values IANA is requested to setup a registry of "NSH Version". New values
are assigned via Standards Action [RFC8126]. are assigned via Standards Action [RFC8126].
Version 00b: Protocol as defined by this document. Version 00b: Protocol as defined by this document.
Version 01b: Reserved. This document. Version 01b: Reserved. This document.
Version 10b: Unassigned. Version 10b: Unassigned.
Version 11b: Unassigned. Version 11b: Unassigned.
11.2.3. MD Type Registry 11.1.3. MD Type Registry
IANA is requested to set up a registry of "MD Types". These are IANA is requested to set up a registry of "MD Types". These are
4-bit values. MD Type values 0x0, 0x1, 0x2, and 0xF are specified in 4-bit values. MD Type values 0x0, 0x1, 0x2, and 0xF are specified in
this document, see Table 5. Registry entries are assigned by using this document, see Table 5. Registry entries are assigned by using
the "IETF Review" policy defined in RFC 8126 [RFC8126]. the "IETF Review" policy defined in RFC 8126 [RFC8126].
+----------+-----------------+---------------+ +----------+-----------------+---------------+
| MD Type | Description | Reference | | MD Type | Description | Reference |
+----------+-----------------+---------------+ +----------+-----------------+---------------+
| 0x0 | Reserved | This document | | 0x0 | Reserved | This document |
skipping to change at page 31, line 32 skipping to change at page 32, line 21
| | | | | | | |
| 0x2 | NSH MD Type 2 | This document | | 0x2 | NSH MD Type 2 | This document |
| | | | | | | |
| 0x3..0xE | Unassigned | | | 0x3..0xE | Unassigned | |
| | | | | | | |
| 0xF | Experimentation | This document | | 0xF | Experimentation | This document |
+----------+-----------------+---------------+ +----------+-----------------+---------------+
Table 5: MD Type Values Table 5: MD Type Values
11.2.4. MD Class Registry 11.1.4. MD Class Registry
IANA is requested to set up a registry of "MD Class". These are IANA is requested to set up a registry of "MD Class". These are
16-bit values. New allocations are to be made according to the 16-bit values. New allocations are to be made according to the
following policies: following policies:
0x0000 to 0x01ff: IETF Review 0x0000 to 0x01ff: IETF Review
0x0200 to 0xfff5: Expert Review 0x0200 to 0xfff5: Expert Review
0xfff6 to 0xfffe: Experimental 0xfff6 to 0xfffe: Experimental
0xffff: Reserved 0xffff: Reserved
IANA is requested to assign the values as per Table 6:: IANA is requested to assign the values as per Table 6::
+-----------+-----------------------------+------------+ +-----------+-----------------------------+------------+
| MD Class | Meaning | Reference | | MD Class | Meaning | Reference |
+-----------+-----------------------------+------------+ +-----------+-----------------------------+------------+
| 0x0000 | IETF Base NSH MD Class | This.I-D | | 0x0000 | IETF Base NSH MD Class | This.I-D |
+-----------+-----------------------------+------------+ +-----------+-----------------------------+------------+
Table 6: MD Class Value Table 6: MD Class Value
A registry for Types for the MD Class of 0x0000 is defined in
Section 11.1.5.
Designated Experts evaluating new allocation requests from the Designated Experts evaluating new allocation requests from the
"Expert Review" range should principally consider whether a new MD "Expert Review" range should principally consider whether a new MD
class is needed compared to adding MD types to an existing class. class is needed compared to adding MD types to an existing class.
The Designated Experts should also encourage the existence of an The Designated Experts should also encourage the existence of an
associated and publicly visible registry of MD types although this associated and publicly visible registry of MD types although this
registry need not be maintained by IANA. registry need not be maintained by IANA.
When evaluating a request for an allocation, the Expert should verify When evaluating a request for an allocation, the Expert should verify
that the allocation plan includes considerations to handle privacy that the allocation plan includes considerations to handle privacy
and security issues associated with the anticipated individual MD and security issues associated with the anticipated individual MD
Types allocated within this class. These plans should consider, when Types allocated within this class. These plans should consider, when
appropriate, alternatives such as indirection, encryption, and appropriate, alternatives such as indirection, encryption, and
limited deployment scenarios. Information that can't be directly limited deployment scenarios. Information that can't be directly
derived from viewing the packet contents should be examined for derived from viewing the packet contents should be examined for
privacy and security implications. privacy and security implications.
11.2.5. NSH Base Header Next Protocol 11.1.5. New IETF Assigned Optional Variable Length Metadata Type
Registry
The Type values within the IETF Base NSH MD Class, i.e., when the MD
Class is set to 0x0000 (see Section 11.1.4), are the Types owned by
the IETF. This document requests IANA to create a registry for the
Type values for the IETF Base NSH MD Class called the "IETF Assigned
Optional Variable Length Metadata Type Registry", as specified in
Section 2.5.1.
The type values are assigned via Standards Action [RFC8126].
No initial values are assigned at the creation of the registry.
11.1.6. NSH Base Header Next Protocol
IANA is requested to set up a registry of "Next Protocol". These are IANA is requested to set up a registry of "Next Protocol". These are
8-bit values. Next Protocol values 0, 1, 2, 3, 4 and 5 are defined 8-bit values. Next Protocol values 0, 1, 2, 3, 4 and 5 are defined
in this document (see Table 7. New values are assigned via "Expert in this document (see Table 7. New values are assigned via "Expert
Reviews" as per [RFC8126]. Reviews" as per [RFC8126].
+---------------+--------------+---------------+ +---------------+--------------+---------------+
| Next Protocol | Description | Reference | | Next Protocol | Description | Reference |
+---------------+--------------+---------------+ +---------------+--------------+---------------+
| 0x0 | Unassigned | | | 0x0 | Unassigned | |
skipping to change at page 33, line 14 skipping to change at page 34, line 38
Expert Review requests MUST include a single code point per request. Expert Review requests MUST include a single code point per request.
Designated Experts evaluating new allocation requests from this Designated Experts evaluating new allocation requests from this
registry should consider the potential scarcity of code points for an registry should consider the potential scarcity of code points for an
8-bit value, and check both for duplications as well as availability 8-bit value, and check both for duplications as well as availability
of documentation. If the actual assignment of the Next Protocol of documentation. If the actual assignment of the Next Protocol
field allocation reaches half of the range, that is when there are field allocation reaches half of the range, that is when there are
128 unassigned values, IANA needs to alert the IESG. At this point, 128 unassigned values, IANA needs to alert the IESG. At this point,
a new more strict allocation policy SHOULD be considered. a new more strict allocation policy SHOULD be considered.
11.2.6. New IETF Assigned Optional Variable Length Metadata Type 12. NSH-Related Codepoints
Registry
This document requests IANA to create a registry for the type values
owned by the IETF (i.e., MD Class set to 0x0000) called the "IETF
Assigned Optional Variable Length Metadata Type Registry", as
specified in Section 2.5.1.
The type values are assigned via Standards Action [RFC8126]. 12.1. NSH EtherType
No initial values are assigned at the creation of the registry. An IEEE EtherType, 0x894F, has been allocated for NSH.
12. References 13. References
12.1. Normative References 13.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function
Chaining (SFC) Architecture", RFC 7665, Chaining (SFC) Architecture", RFC 7665,
DOI 10.17487/RFC7665, October 2015, DOI 10.17487/RFC7665, October 2015,
<https://www.rfc-editor.org/info/rfc7665>. <https://www.rfc-editor.org/info/rfc7665>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26, Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017, RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>. <https://www.rfc-editor.org/info/rfc8126>.
12.2. Informative References 13.2. Informative References
[BCP38] Ferguson, P. and D. Senie, "Network Ingress Filtering:
Defeating Denial of Service Attacks which employ IP Source
Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827,
May 2000, <http://www.rfc-editor.org/info/rfc2827>.
[I-D.brockners-proof-of-transit] [I-D.brockners-proof-of-transit]
Brockners, F., Bhandari, S., Dara, S., Pignataro, C., Brockners, F., Bhandari, S., Dara, S., Pignataro, C.,
Leddy, J., Youell, S., Mozes, D., and T. Mizrahi, "Proof Leddy, J., Youell, S., Mozes, D., and T. Mizrahi, "Proof
of Transit", draft-brockners-proof-of-transit-03 (work in of Transit", draft-brockners-proof-of-transit-03 (work in
progress), March 2017. progress), March 2017.
[I-D.guichard-sfc-nsh-dc-allocation] [I-D.guichard-sfc-nsh-dc-allocation]
Guichard, J., Smith, M., Kumar, S., Majee, S., Agarwal, Guichard, J., Smith, M., Kumar, S., Majee, S., Agarwal,
P., Glavin, K., Laribi, Y., and T. Mizrahi, "Network P., Glavin, K., Laribi, Y., and T. Mizrahi, "Network
skipping to change at page 35, line 35 skipping to change at page 36, line 46
[RFC7498] Quinn, P., Ed. and T. Nadeau, Ed., "Problem Statement for [RFC7498] Quinn, P., Ed. and T. Nadeau, Ed., "Problem Statement for
Service Function Chaining", RFC 7498, Service Function Chaining", RFC 7498,
DOI 10.17487/RFC7498, April 2015, DOI 10.17487/RFC7498, April 2015,
<https://www.rfc-editor.org/info/rfc7498>. <https://www.rfc-editor.org/info/rfc7498>.
[RFC7676] Pignataro, C., Bonica, R., and S. Krishnan, "IPv6 Support [RFC7676] Pignataro, C., Bonica, R., and S. Krishnan, "IPv6 Support
for Generic Routing Encapsulation (GRE)", RFC 7676, for Generic Routing Encapsulation (GRE)", RFC 7676,
DOI 10.17487/RFC7676, October 2015, DOI 10.17487/RFC7676, October 2015,
<https://www.rfc-editor.org/info/rfc7676>. <https://www.rfc-editor.org/info/rfc7676>.
[RFC8201] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed.,
"Path MTU Discovery for IP version 6", STD 87, RFC 8201,
DOI 10.17487/RFC8201, July 2017,
<https://www.rfc-editor.org/info/rfc8201>.
Authors' Addresses Authors' Addresses
Paul Quinn (editor) Paul Quinn (editor)
Cisco Systems, Inc. Cisco Systems, Inc.
Email: paulq@cisco.com Email: paulq@cisco.com
Uri Elzur (editor) Uri Elzur (editor)
Intel Intel
 End of changes. 50 change blocks. 
143 lines changed or deleted 175 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/