Tech-invite3GPPspaceIETF RFCsSIP
in Index   Prev   Next

RFC 8300

Network Service Header (NSH)

Pages: 40
Proposed Standard
Part 2 of 2 – Pages 22 to 40
First   Prev   None

Top   ToC   RFC8300 - Page 22   prevText

7. Policy Enforcement with NSH

7.1. NSH Metadata and Policy Enforcement

As described in Section 2, NSH provides the ability to carry metadata along a service path. This metadata may be derived from several sources. Common examples include: Network nodes/devices: Information provided by network nodes can indicate network-centric information (such as VPN Routing and Forwarding (VRF) or tenant) that may be used by Service Functions or conveyed to another network node post service path egress. External (to the network) systems: External systems, such as orchestration systems, often contain information that is valuable for Service Function policy decisions. In most cases, this information cannot be deduced by network nodes. For example, a cloud orchestration platform placing workloads "knows" what application is being instantiated and can communicate this information to all NSH nodes via metadata carried in the Context Header(s). Service Functions: A Classifier co-resident with Service Functions often performs very detailed and valuable classification. Regardless of the source, metadata reflects the "result" of classification. The granularity of classification may vary. For example, a network switch, acting as a Classifier, might only be able to classify based on a 2-tuple, or based on a 5-tuple, while a Service Function may be able to inspect application information. Regardless of granularity, the classification information can be represented in the NSH.
Top   ToC   RFC8300 - Page 23
   Once the data is added to the NSH, it is carried along the service
   path.  NSH-aware SFs receive the metadata, and can use that metadata
   for local decisions and policy enforcement.  Figures 9 and 10
   highlight the relationship between metadata and policy.

                +-------+        +-------+        +-------+
                |  SFF  )------->(  SFF  |------->|  SFF  |
                +---+---+        +---+---+        +---+---+
                    ^                |                |
                  ,-|-.            ,-|-.            ,-|-.
                 /     \          /     \          /     \
                ( Class )        (  SF1  )        (  SF2  )
                 \ ify /          \     /          \     /
                  `---'            `---'            `---'
                 5-tuple:        Permit             Inspect
                 Tenant A        Tenant A           AppY

                       Figure 9: Metadata and Policy

               +-----+           +-----+            +-----+
               | SFF |---------> | SFF |----------> | SFF |
               +--+--+           +--+--+            +--+--+
                  ^                 |                  |
                ,-+-.             ,-+-.              ,-+-.
               /     \           /     \            /     \
              ( Class )         (  SF1  )          (  SF2  )
               \ ify /           \     /            \     /
                `-+-'             `---'              `---'
                  |              Permit            Deny AppZ
              +---+---+          employees
              |       |

                  Figure 10: External Metadata and Policy

   In both of the examples above, the Service Functions perform policy
   decisions based on the result of the initial classification: the SFs
   did not need to perform re-classification; instead, they rely on an
   antecedent classification for local policy enforcement.

   Depending on the information carried in the metadata, data privacy
   impact needs to be considered.  For example, if the metadata conveys
   tenant information, that information may need to be authenticated
Top   ToC   RFC8300 - Page 24
   and/or encrypted between the originator and the intended recipients
   (which may include intended SFs only); one approach to an optional
   capability to do this is explored in [NSH-ENCRYPT].  The NSH itself
   does not provide privacy functions, rather it relies on the transport
   encapsulation/overlay.  An operator can select the appropriate set of
   transport encapsulation protocols to ensure confidentiality (and
   other security) considerations are met.  Metadata privacy and
   security considerations are a matter for the documents that define
   metadata format.

7.2. Updating/Augmenting Metadata

Post-initial metadata imposition (typically, performed during initial service path determination), the metadata may be augmented or updated: 1. Metadata Augmentation: Information may be added to the NSH's existing metadata, as depicted in Figure 11. For example, if the initial classification returns the tenant information, a secondary classification (perhaps co-resident with deep packet inspection (DPI) or server load balancing (SLB)) may augment the tenant classification with application information, and impose that new information in NSH metadata. The tenant classification is still valid and present, but additional information has been added to it. 2. Metadata Update: Subsequent Classifiers may update the initial classification if it is determined to be incorrect or not descriptive enough. For example, the initial Classifier adds metadata that describes the traffic as "Internet", but a security Service Function determines that the traffic is really "attack". Figure 12 illustrates an example of updating metadata.
Top   ToC   RFC8300 - Page 25
               +-----+           +-----+            +-----+
               | SFF |---------> | SFF |----------> | SFF |
               +--+--+           +--+--+            +--+--+
                  ^                 |                  |
                ,---.             ,---.              ,---.
               /     \           /     \            /     \
              ( Class )         (  SF1  )          (  SF2  )
               \     /           \     /            \     /
                `-+-'             `---'              `---'
                  |              Inspect           Deny
              +---+---+          employees         employee+
              |       |          Class=AppZ        appZ

                     Figure 11: Metadata Augmentation

                +-----+           +-----+            +-----+
                | SFF |---------> | SFF |----------> | SFF |
                +--+--+           +--+--+            +--+--+
                   ^                 |                  |
                 ,---.             ,---.              ,---.
                /     \           /     \            /     \
               ( Class )         (  SF1  )          (  SF2  )
                \     /           \     /            \     /
                 `---'             `---'              `---'
              5-tuple:            Inspect             Deny
              Tenant A            Tenant A            attack
                                   --> attack

                        Figure 12: Metadata Update

7.3. Service Path Identifier and Metadata

Metadata information may influence the service path selection since the Service Path Identifier values can represent the result of classification. A given SPI can be defined based on classification results (including metadata classification). The imposition of the SPI and SI results in the packet being placed on the newly specified SFP at the position indicated by the imposed SPI and SI. This relationship provides the ability to create a dynamic service plane based on complex classification, without requiring each node to be capable of such classification or requiring a coupling to the network topology. This yields Service Graph functionality as
Top   ToC   RFC8300 - Page 26
   described in Section 6.4.  Figure 13 illustrates an example of this

               +-----+           +-----+            +-----+
               | SFF |---------> | SFF |------+---> | SFF |
               +--+--+           +--+--+      |     +--+--+
                  |                 |         |        |
                ,---.             ,---.       |      ,---.
               /     \           / SF1 \      |     /     \
              (  SCL  )         (   +   )     |    (  SF2  )
               \     /           \SCL2 /      |     \     /
                `---'             `---'    +-----+   `---'
             5-tuple:            Inspect   | SFF |    Original
             Tenant A            Tenant A  +--+--+    next SF
                                  --> DoS     |
                                           /     \
                                          (  SF10 )
                                           \     /

             SCL = Service Classifier

                      Figure 13: Path ID and Metadata

   Specific algorithms for mapping metadata to an SPI are outside the
   scope of this document.

8. Security Considerations

NSH security must be considered in the contexts of the SFC architecture and operators' environments. One important characteristic of NSH is that it is not an end-to-end protocol. As opposed to a protocol that "starts" on a host and "ends" on a server or another host, NSH is typically imposed by a network device on ingress to the SFC domain and removed at the egress of the SFC domain. As such, and as with any other network-centric protocols (e.g., IP Tunneling, Traffic Engineering, MPLS, or Provider- Provisioned Virtual Private Networks), there is an underlying trust in the network devices responsible for imposing, removing, and acting on NSH information. The following sections detail an analysis and present a set of requirements and recommendations in those two areas.
Top   ToC   RFC8300 - Page 27

8.1. NSH Security Considerations from Operators' Environments

Trusted Devices All Classifiers, SFFs and SFs (hereinafter referred to as "SFC devices") within an operator's environment are assumed to have been selected, vetted, and actively maintained; therefore, they are trusted by that operator. This assumption differs from the oft held view that devices are untrusted, often referred to as the "zero-trust model". Operators SHOULD regularly monitor (i.e., continuously audit) these devices to help ensure compliant behavior. This trust, therefore, extends into NSH operations: SFC devices are not, themselves, considered to be attack vectors. This assumption, and the resultant conclusion is reasonable since this is the very basis of an operator posture; the operator depends on this reality to function. If these devices are not trusted, and indeed are compromised, almost the entirety of the operator's standard-based IP and MPLS protocol suites are vulnerable; therefore, the operation of the entire network is compromised. Although there are well-documented monitoring-based methods for detecting compromise (such as included continuous monitoring and audit and log review), these may not be sufficient to contain damage by a completely compromised element. Methods and best practices to secure devices are also widely documented and outside the scope of this document. Single Domain Boundary As per [RFC7665], NSH is designed for use within a single administrative domain. This scoping provides two important characteristics: i) Clear NSH boundaries NSH egress devices MUST strip the NSH headers before they send the users' packets or frames out of the NSH domain. Means to prevent leaking privacy-related information outside an administrative domain are natively supported by the NSH given that the last SFF of a service path will systematically remove the NSH encapsulation before forwarding a packet exiting the service path. The second step in such prevention is to filter the transport encapsulation protocol used by NSH at the domain edge. The transport encapsulation protocol MUST be filtered and MUST NOT leave the domain edge.
Top   ToC   RFC8300 - Page 28
      Depending upon the transport encapsulation protocol used for NSH,
      this can be done either by completely blocking the transport
      encapsulation (e.g., if MPLS is the chosen NSH transport
      encapsulation protocol, it is therefore never allowed to leave the
      domain) or by examining the carried protocol with the transport
      encapsulation (e.g., if VXLAN-gpe is used as the NSH transport
      encapsulation protocol, all domain edges need to filter based on
      the carried protocol in the VXLAN-gpe.)

      The other consequence of this bounding is that ingress packets
      MUST also be filtered to prevent attackers from sending in NSH
      packets with service path identification and metadata of their own
      selection.  The same filters as described above for both the NSH
      at SFC devices and for the transport encapsulation protocol as
      general edge protections MUST be applied on ingress.

      In summary, packets originating outside the SFC-enabled domain
      MUST be dropped if they contain an NSH.  Similarly, packets
      exiting the SFC-enabled domain MUST be dropped if they contain an

      ii) Mitigation of external threats

      As per the trusted SFC device points raised above, given that NSH
      is scoped within an operator's domain, that operator can ensure
      that the environment and its transitive properties comply with
      that operator's required security posture.  Continuous audits for
      assurance are recommended with this reliance on a fully trusted
      environment.  The term "continuous audits" describes a method
      (automated or manual) of checking security-control compliance on a
      regular basis, at some set period of time.

8.2. NSH Security Considerations from the SFC Architecture

The SFC architecture defines functional roles (e.g., SFF), as well as protocol elements (e.g., Metadata). This section considers each role and element in the context of threats posed in the areas of integrity and confidentiality. As with routing, the distributed computation model assumes a distributed trust model. An important consideration is that NSH contains mandatory-to-mute fields, and further, the SFC architecture describes cases where other fields in NSH change, all on a possible SFP hop-by-hop basis. This means that any cryptographic solution requires complex key distribution and life-cycle operations.
Top   ToC   RFC8300 - Page 29

8.2.1. Integrity

SFC devices SFC devices MAY perform various forms of verification on received NSH packets such as only accepting NSH packets from expected devices, checking that NSH SPI and SI values received from expected devices conform to expected values and so on. Implementation of these additional checks are a local matter and, thus, out of scope of this document. NSH Base and Service Path Headers Attackers who can modify packets within the operator's network may be able to modify the SFP, path position, and/or the metadata associated with a packet. One specific concern is an attack in which a malicious modification of the SPI/SI results in an alteration of the path to avoid security devices. The options discussed in this section help thwart that attack, and so does the use of the optional "Proof of Transit" method [PROOF-OF-TRANSIT]. As stated above, SFC devices are trusted; in the case where an SFC device is compromised, NSH integrity protection would be subject to forging (in many cases) as well. NSH itself does not mandate protocol-specific integrity protection. However, if an operator deems protection is required, several options are viable: 1. SFF/SF NSH verification Although, strictly speaking, not integrity protection, some of the techniques mentioned above, such as checking expected NSH values are received from expected SFC device(s), can provide a form of verification without incurring the burden of a full- fledged integrity-protection deployment. 2. Transport Security NSH is always encapsulated by an outer transport encapsulation as detailed in Section 4 of this specification, and as depicted in Figure 1. If an operator deems cryptographic integrity protection necessary due to their risk analysis, then an outer transport encapsulation that provides such protection [RFC6071], such as IPsec, MUST be used.
Top   ToC   RFC8300 - Page 30
          Although the threat model and recommendations of Section 5 of
          BCP 72 [RFC3552] would normally require cryptographic data
          origin authentication for the header, this document does not
          mandate such mechanisms in order to reflect the operational
          and technical realities of deployment.

          Given that NSH is transport independent, as mentioned above, a
          secure transport, such as IPsec can be used for carry NSH.
          IPsec can be used either alone or in conjunction with other
          transport encapsulation protocols, in turn, encapsulating NSH.

          Operators MUST ensure the selected transport encapsulation
          protocol can be supported by the transport encapsulation/
          underlay of all relevant network segments as well as SFFs,
          SFs, and SFC Proxies in the service path.

          If connectivity between SFC-enabled devices traverses the
          public Internet, then such connectivity MUST be secured at the
          transport encapsulation layer.  IPsec is an example of such a

      3.  NSH Variable Header-Based Integrity

          Lastly, NSH MD Type 2 provides, via variable-length headers,
          the ability to append cryptographic integrity protection to
          the NSH packet.  The implementation of such a scheme is
          outside the scope of this document.

   NSH metadata

      As with the Base and Service Path Headers, if an operator deems
      cryptographic integrity protection needed, then an existing,
      standard transport protocol MUST be used since the integrity
      protection applies to entire encapsulated NSH packets.  As
      mentioned above, a risk assessment that deems data-plane traffic
      subject to tampering will apply not only to NSH but to the
      transport information; therefore, the use of a secure transport is
      likely needed already to protect the entire stack.

      If an MD Type 2 variable header integrity scheme is in place, then
      the integrity of the metadata can be ensured via that mechanism as
Top   ToC   RFC8300 - Page 31

8.2.2. Confidentiality

SFC devices SFC devices can "see" (and need to use) NSH information. NSH Base and Service Path Headers SPI and other base / service path information does not typically require confidentiality; however, if an operator does deem confidentiality to be required, then, as with integrity, an existing transport encapsulation that provides encryption MUST be utilized. NSH metadata An attacker with access to the traffic in an operator's network can potentially observe the metadata NSH carries with packets, potentially discovering privacy-sensitive information. Much of the metadata carried by NSH is not sensitive. It often reflects information that can be derived from the underlying packet or frame. Direct protection of such information is not necessary, as the risks are simply those of carrying the underlying packet or frame. Implementers and operators MUST be aware that metadata can have privacy implications, and those implications are sometimes hard to predict. Therefore, attached metadata should be limited to that necessary for correct operation of the SFP. Further, [RFC8165] defines metadata considerations that operators can take into account when using NSH. Protecting NSH metadata information between SFC components can be done using transport encapsulation protocols with suitable security capabilities, along the lines discussed above. If a security analysis deems these protections necessary, then security features in the transport encapsulation protocol (such as IPsec) MUST be used. One useful element of providing privacy protection for sensitive metadata is described under the "SFC Encapsulation" area of the Security Considerations of [RFC7665]. Operators can and should use indirect identification for metadata deemed to be sensitive (such as personally identifying information), significantly mitigating the risk of a privacy violation. In particular, subscriber-identifying information should be handled carefully, and, in general, SHOULD be obfuscated.
Top   ToC   RFC8300 - Page 32
      For those situations where obfuscation is either inapplicable or
      judged to be insufficient, an operator can also encrypt the
      metadata.  An approach to an optional capability to do this was
      explored in [NSH-ENCRYPT].  For other situations where greater
      assurance is desired, optional mechanisms such as
      [PROOF-OF-TRANSIT] can be used.

9. IANA Considerations

9.1. NSH Parameters

IANA has created a new "Network Service Header (NSH) Parameters" registry. The following subsections detail new registries within the "Network Service Header (NSH) Parameters" registry.

9.1.1. NSH Base Header Bits

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 [RFC8126]. Bit 2 - O (OAM) bit Bit 3 - Unassigned Bits 16-19 - Unassigned

9.1.2. NSH Version

IANA has set up the "NSH Version" registry. New values are assigned via Standards Action [RFC8126]. +-------------+---------------------------------+-----------+ | Version | Description | Reference | +-------------+---------------------------------+-----------+ | Version 00b | Protocol as defined by RFC 8300 | RFC 8300 | | Version 01b | Reserved | RFC 8300 | | Version 10b | Unassigned | | | Version 11b | Unassigned | | +-------------+---------------------------------+-----------+ Table 5: NSH Version
Top   ToC   RFC8300 - Page 33

9.1.3. NSH MD Types

IANA has set up the "NSH MD Types" registry, which contains 4-bit values. MD Type values 0x0, 0x1, 0x2, and 0xF are specified in this document; see Table 6. Registry entries are assigned via the "IETF Review" policy defined in RFC 8126 [RFC8126]. +-----------+-----------------+-----------+ | MD Type | Description | Reference | +-----------+-----------------+-----------+ | 0x0 | Reserved | RFC 8300 | | | | | | 0x1 | NSH MD Type 1 | RFC 8300 | | | | | | 0x2 | NSH MD Type 2 | RFC 8300 | | | | | | 0x3 - 0xE | Unassigned | | | | | | | 0xF | Experimentation | RFC 8300 | +-----------+-----------------+-----------+ Table 6: MD Type Values

9.1.4. NSH MD Class

IANA has set up the "NSH MD Class" registry, which contains 16-bit values. New allocations are to be made according to the following policies: 0x0000 to 0x01ff: IETF Review 0x0200 to 0xfff5: Expert Review IANA has assigned the values as follows: +------------------+------------------------+------------+ | Value | Meaning | Reference | +------------------+------------------------+------------+ | 0x0000 | IETF Base NSH MD Class | RFC 8300 | | | | | | 0xfff6 to 0xfffe | Experimental | RFC 8300 | | | | | | 0xffff | Reserved | RFC 8300 | +------------------+------------------------+------------+ Table 7: NSH MD Class A registry for Types for the MD Class of 0x0000 is defined in Section 9.1.5.
Top   ToC   RFC8300 - Page 34
   Designated Experts evaluating new allocation requests from the
   "Expert Review" range should principally consider whether a new MD
   class is needed compared to adding MD Types to an existing class.
   The Designated Experts should also encourage the existence of an
   associated and publicly visible registry of MD Types although this
   registry need not be maintained by IANA.

   When evaluating a request for an allocation, the Expert should verify
   that the allocation plan includes considerations to handle privacy
   and security issues associated with the anticipated individual MD
   Types allocated within this class.  These plans should consider, when
   appropriate, alternatives such as indirection, encryption, and
   limited-deployment scenarios.  Information that can't be directly
   derived from viewing the packet contents should be examined for
   privacy and security implications.

9.1.5. NSH IETF-Assigned Optional Variable-Length Metadata Types

The Type values within the IETF Base NSH MD Class, i.e., when the MD Class is set to 0x0000 (see Section 9.1.4), are the Types owned by the IETF. Per this document, IANA has created a registry for the Type values for the IETF Base NSH MD Class called the "NSH IETF- Assigned Optional Variable-Length Metadata Types" 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.
Top   ToC   RFC8300 - Page 35

9.1.6. NSH Next Protocol

IANA has set up the "NSH Next Protocol" registry, which contains 8-bit values. Next Protocol values 0, 1, 2, 3, 4, and 5 are defined in this document (see Table 8). New values are assigned via "Expert Review" as per [RFC8126]. +---------------+--------------+-----------+ | Next Protocol | Description | Reference | +---------------+--------------+-----------+ | 0x00 | Unassigned | | | | | | | 0x01 | IPv4 | RFC 8300 | | | | | | 0x02 | IPv6 | RFC 8300 | | | | | | 0x03 | Ethernet | RFC 8300 | | | | | | 0x04 | NSH | RFC 8300 | | | | | | 0x05 | MPLS | RFC 8300 | | | | | | 0x06 - 0xFD | Unassigned | | | | | | | 0xFE | Experiment 1 | RFC 8300 | | | | | | 0xFF | Experiment 2 | RFC 8300 | +---------------+--------------+-----------+ Table 8: NSH Base Header Next Protocol Values Expert Review requests MUST include a single codepoint per request. Designated Experts evaluating new allocation requests from this registry should consider the potential scarcity of codepoints for an 8-bit value, and check both for duplications and availability of documentation. If the actual assignment of the Next Protocol field allocation reaches half of the range (that is, when there are 128 unassigned values), IANA needs to alert the IESG. At that point, a new more strict allocation policy SHOULD be considered.

10. NSH-Related Codepoints

10.1. NSH Ethertype

An IEEE Ethertype, 0x894F, has been allocated for NSH.
Top   ToC   RFC8300 - Page 36

11. References

11.1. Normative References

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <>. [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function Chaining (SFC) Architecture", RFC 7665, DOI 10.17487/RFC7665, October 2015, <>. [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <>. [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <>.

11.2. Informative References

[NSH-BROADBAND-ALLOCATION] Napper, J., Kumar, S., Muley, P., Henderickx, W., and M. Boucadair, "NSH Context Header Allocation -- Broadband", Work in Progress, draft-napper-sfc-nsh-broadband- allocation-04, November 2017. [NSH-DC-ALLOCATION] Guichard, J., Smith, M., Kumar, S., Majee, S., Agarwal, P., Glavin, K., Laribi, Y., and T. Mizrahi, "Network Service Header (NSH) MD Type 1: Context Header Allocation (Data Center)", Work in Progress, draft-guichard-sfc-nsh-dc-allocation-07, August 2017. [NSH-ENCRYPT] Reddy, T., Patil, P., Fluhrer, S., and P. Quinn, "Authenticated and encrypted NSH service chains", Work in Progress, draft-reddy-sfc-nsh-encrypt-00, April 2015.
Top   ToC   RFC8300 - Page 37
              Brockners, F., Bhandari, S., Dara, S., Pignataro, C.,
              Leddy, J., Youell, S., Mozes, D., and T. Mizrahi, "Proof
              of Transit", Work in Progress, draft-brockners-proof-
              of-transit-04, October 2017.

   [RFC2784]  Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.
              Traina, "Generic Routing Encapsulation (GRE)", RFC 2784,
              DOI 10.17487/RFC2784, March 2000,

   [RFC3552]  Rescorla, E. and B. Korver, "Guidelines for Writing RFC
              Text on Security Considerations", BCP 72, RFC 3552,
              DOI 10.17487/RFC3552, July 2003,

   [RFC3692]  Narten, T., "Assigning Experimental and Testing Numbers
              Considered Useful", BCP 82, RFC 3692,
              DOI 10.17487/RFC3692, January 2004,

   [RFC6071]  Frankel, S. and S. Krishnan, "IP Security (IPsec) and
              Internet Key Exchange (IKE) Document Roadmap", RFC 6071,
              DOI 10.17487/RFC6071, February 2011,

   [RFC6291]  Andersson, L., van Helvoort, H., Bonica, R., Romascanu,
              D., and S. Mansfield, "Guidelines for the Use of the "OAM"
              Acronym in the IETF", BCP 161, RFC 6291,
              DOI 10.17487/RFC6291, June 2011,

   [RFC7325]  Villamizar, C., Ed., Kompella, K., Amante, S., Malis, A.,
              and C. Pignataro, "MPLS Forwarding Compliance and
              Performance Requirements", RFC 7325, DOI 10.17487/RFC7325,
              August 2014, <>.

   [RFC7498]  Quinn, P., Ed. and T. Nadeau, Ed., "Problem Statement for
              Service Function Chaining", RFC 7498,
              DOI 10.17487/RFC7498, April 2015,

   [RFC7676]  Pignataro, C., Bonica, R., and S. Krishnan, "IPv6 Support
              for Generic Routing Encapsulation (GRE)", RFC 7676,
              DOI 10.17487/RFC7676, October 2015,
Top   ToC   RFC8300 - Page 38
   [RFC8165]  Hardie, T., "Design Considerations for Metadata
              Insertion", RFC 8165, DOI 10.17487/RFC8165, May 2017,

   [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,

              Nordmark, E., Tian, A., Gross, J., Hudson, J., Kreeger,
              L., Garg, P., Thaler, P., and T. Herbert, "Encapsulation
              Considerations", Work in Progress,
              draft-ietf-rtgwg-dt-encap-02, October 2016.

              Boucadair, M., "Service Function Chaining (SFC) Control
              Plane Components & Requirements", Work in Progress,
              draft-ietf-sfc-control-plane-08, October 2016.

              Aldrin, S., Pignataro, C., Kumar, N., Akiya, N., Krishnan,
              R., and A. Ghanwani, "Service Function Chaining (SFC)
              Operation, Administration and Maintenance (OAM)
              Framework", Work in Progress,
              draft-ietf-sfc-oam-framework-03, September 2017.

              Maino, F., Kreeger, L., and U. Elzur, "Generic Protocol
              Extension for VXLAN", Work in Progress,
              draft-ietf-nvo3-vxlan-gpe-05, October 2017.


The authors would like to thank Sunil Vallamkonda, Nagaraj Bagepalli, Abhijit Patra, Peter Bosch, Darrel Lewis, Pritesh Kothari, Tal Mizrahi, and Ken Gray for their detailed reviews, comments, and contributions. A special thank you goes to David Ward and Tom Edsall for their guidance and feedback. Additionally, the authors would like to thank Larry Kreeger for his invaluable ideas and contributions, which are reflected throughout this document. Loa Andersson provided a thorough review and valuable comments; we thank him for that.
Top   ToC   RFC8300 - Page 39
   Reinaldo Penno deserves a particular thank you for his architecture
   and implementation work that helped guide the protocol concepts and

   The editors also acknowledge comprehensive reviews and respective
   useful suggestions by Med Boucadair, Adrian Farrel, Juergen
   Schoenwaelder, Acee Lindem, and Kathleen Moriarty.

   Lastly, David Dolson has provided significant review, feedback, and
   suggestions throughout the evolution of this document.  His
   contributions are very much appreciated.


This WG document originated as draft-quinn-sfc-nsh; the following are its coauthors and contributors along with their respective affiliations at the time of WG adoption. The editors of this document would like to thank and recognize them and their contributions. These coauthors and contributors provided invaluable concepts and content for this document's creation. o Jim Guichard, Cisco Systems, Inc. o Surendra Kumar, Cisco Systems, Inc. o Michael Smith, Cisco Systems, Inc. o Wim Henderickx, Alcatel-Lucent o Tom Nadeau, Brocade o Puneet Agarwal o Rajeev Manur, Broadcom o Abhishek Chauhan, Citrix o Joel Halpern, Ericsson o Sumandra Majee, F5 o David Melman, Marvell o Pankaj Garg, Microsoft o Brad McConnell, Rackspace o Chris Wright, Red Hat, Inc. o Kevin Glavin, Riverbed o Hong (Cathy) Zhang, Huawei US R&D o Louis Fourie, Huawei US R&D o Ron Parker, Affirmed Networks o Myo Zarny, Goldman Sachs o Andrew Dolganow, Alcatel-Lucent o Rex Fernando, Cisco Systems, Inc. o Praveen Muley, Alcatel-Lucent o Navindra Yadav, Cisco Systems, Inc.
Top   ToC   RFC8300 - Page 40

Authors' Addresses

Paul Quinn (editor) Cisco Systems, Inc. Email: Uri Elzur (editor) Intel Email: Carlos Pignataro (editor) Cisco Systems, Inc. Email: