<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.6.22 (Ruby 3.0.2) -->
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-lh-spring-srv6-sfc-csid-00" category="std" consensus="true" submissionType="IETF" xml:lang="en" version="3">
  <!-- xml2rfc v2v3 conversion 3.16.0 -->
  <front>
    <title>Compressed SID (C-SID) for SRv6 SFC</title>
    <seriesInfo name="Internet-Draft" value="draft-lh-spring-srv6-sfc-csid-00"/>
    <author initials="C." surname="Li" fullname="Cheng Li" role="editor">
      <organization>Huawei</organization>
      <address>
        <postal>
          <country>China</country>
        </postal>
        <email>c.l@huawei.com</email>
      </address>
    </author>
    <author initials="H." surname="Huang" fullname="Hongyi Huang" role="editor">
      <organization>Huawei</organization>
      <address>
        <postal>
          <country>China</country>
        </postal>
        <email>hongyi.huang@huawei.com</email>
      </address>
    </author>
    <date year="2023" month="February" day="08"/>
    <area>Routing Area</area>
    <workgroup>SPRING Working Group</workgroup>
    <keyword>Service programming</keyword>
    <keyword>Compression</keyword>
    <abstract>
      <t>In SRv6, an SRv6 SID is a 128-bit value. When too many 128-bit SRv6 SIDs are included in an SRH, the introduced overhead will affect the transmission efficiency of payload. In order to address this problem, Compressed SID(C-SID) is proposed. This document defines new behaviors for service segments with REPLACE-C-SID and NEXT-C-SID flavors to enable compressed SRv6 service programming.</t>
    </abstract>
  </front>
  <middle>
    <section anchor="introduction">
      <name>Introduction</name>
      <t>Segment Routing <xref target="RFC8402"/> is a source routing paradigm to support steering packets through a programmed path at the ingress node. Currently, two data planes are defined for Segment Routing: MPLS and IPv6. When IPv6 data plane is used in Segment Routing, it is called SRv6 <xref target="RFC8754"/> . <xref target="RFC8754"/> defines a new extension header in IPv6, called Segment Routing Header (SRH), to support SRv6. To support SRv6 network programming, <xref target="RFC8986"/> defines a framework to build a network program with topological and service segments carried in a Segment Routing header (SRH) <xref target="RFC8754"/>.</t>
      <t>A Service Function Chain (SFC) <xref target="RFC7665"/> defines an ordered set of abstract service functions and ordering constraints that must be applied to packets and/or frames and/or flows.</t>
      <t>A service function chain can be implemented by SRv6 by using a sequence of SRv6 SIDs including service segments defined in <xref target="I-D.ietf-spring-sr-service-programming"/>.</t>
      <t>However, when too many 128-bit SRv6 SIDs are included in an SRH, the overhead of the SRH will affect the transmission efficiency of the payload. <xref target="I-D.srcompdt-spring-compression-requirement"/> points out the problem of long SRv6 SID lists reduce payload efficiency. To mitigate such overhead, <xref target="I-D.ietf-spring-srv6-srh-compression"/> defines new flavors for basic SR endpoint behaviors defined in <xref target="RFC8986"/>. Using the new flavored behavior SID, a 128-bit SRv6 SID can be compressed to be an 32-bit or 16-bit Compressed SID (C-SID), which reduces a lot of size of the SRv6 header.</t>
      <t>To enable SRv6 SID lists compression for service function chaining (SFC), this document defines new behaviors of service segments with flavors defined in <xref target="I-D.ietf-spring-srv6-srh-compression"/>.</t>
      <section anchor="requirements-language">
        <name>Requirements Language</name>
        <t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they
appear in all capitals, as shown here.</t>
      </section>
      <section anchor="terminology">
        <name>Terminology</name>
        <t>This document leverages the terms defined in <xref target="RFC8402"/>, <xref target="RFC8754"/>, <xref target="RFC8986"/>, <xref target="I-D.ietf-spring-srv6-srh-compression"/> and <xref target="I-D.ietf-spring-sr-service-programming"/>. The reader is assumed to be familiar with this terminology. This document does not introduce any new terms.</t>
      </section>
    </section>
    <section anchor="proxy_behaviors">
      <name>SR Proxy Behaviors</name>
      <t><xref target="I-D.ietf-spring-sr-service-programming"/> defines several SRv6 endpoint behaviors for service proxy segments. A service proxy segment ID is represented as an 128-bit value just like other SIDs defined in <xref target="RFC8986"/>. This section defines some new behaviors of those service proxy segments by combining the existing service proxy segment behaviors with C-SID flavors, such as REPLACE-C-SID flavor and NEXT-C-SID flavor.</t>
      <t>The main difference between behaviors are the forwarding instructions. Therefore, when C-SID compression mechanism applies to SR Proxy behaviors, the pseudo code of the new behaviors can be generated by updating the forwarding instructions of C-SID to SR proxy forwarding instructions. The following sections define the details of the pseudo code of new behaviors.</t>
      <section anchor="static-sr-proxy">
        <name>Static SR Proxy</name>
        <section anchor="static-proxy-for-inner-type-ethernet">
          <name>Static Proxy for Inner Type Ethernet</name>
          <section anchor="replace-c-sid-flavor">
            <name>REPLACE-C-SID Flavor</name>
            <t>When processing an IPv6 packet that matches a FIB entry locally instantiated as an SRv6 static proxy SID with the REPLACE-C-SID flavor for Ethernet traffic, the procedure described in <xref section="4.2.1" sectionFormat="of" target="I-D.ietf-spring-srv6-srh-compression"/> is executed except for line S23 replaced as follows.</t>
            <artwork><![CDATA[
S1.   If (Upper-layer header type != 143 (Ethernet)) {
S2.     Resubmit the packet to the IPv6 module for transmission to
           the new destination.
S3.   }
S4.   Perform IPv6 decapsulation.
S5.   Submit the frame to the Ethernet module for transmission via
         interface IFACE-OUT.
]]></artwork>
            <t>The upper-layer header processing is unchanged as per <xref section="6.1.2.1" sectionFormat="of" target="I-D.ietf-spring-sr-service-programming"/>.</t>
            <t>When processing an Ethernet frame received on the interface IFACE-IN and with a destination MAC address that is neither a broadcast address nor matches the address of IFACE-IN, as per <xref section="6.1.2.1" sectionFormat="of" target="I-D.ietf-spring-sr-service-programming"/>.</t>
          </section>
          <section anchor="next-c-sid-flavor">
            <name>NEXT-C-SID Flavor</name>
            <t>When processing an IPv6 packet that matches a FIB entry locally instantiated as an SRv6 static proxy SID with the NEXT-C-SID flavor for Ethernet traffic, the procedure described in <xref section="4.1.1" sectionFormat="of" target="I-D.ietf-spring-srv6-srh-compression"/> is executed except for line S08 of that and line S15 of <xref section="4.1" sectionFormat="of" target="RFC8986"/> that are both replaced as follows.</t>
            <artwork><![CDATA[
S1.   If (Upper-layer header type != 143 (Ethernet)) {
S2.     Resubmit the packet to the IPv6 module for transmission to
           the new destination.
S3.   }
S4.   Perform IPv6 decapsulation.
S5.   Submit the frame to the Ethernet module for transmission via
         interface IFACE-OUT.
]]></artwork>
            <t>The upper-layer header processing is unchanged as per <xref section="6.1.2.1" sectionFormat="of" target="I-D.ietf-spring-sr-service-programming"/>.</t>
            <t>When processing an Ethernet frame received on the interface IFACE-IN and with a destination MAC address that is neither a broadcast address nor matches the address of IFACE-IN, as per <xref section="6.1.2.1" sectionFormat="of" target="I-D.ietf-spring-sr-service-programming"/>.</t>
          </section>
        </section>
        <section anchor="static-proxy-for-inner-type-ipv4">
          <name>Static Proxy for Inner Type IPv4</name>
          <section anchor="replace-c-sid-flavor-1">
            <name>REPLACE-C-SID Flavor</name>
            <t>When processing an IPv6 packet that matches a FIB entry locally instantiated as an SRv6 static proxy SID with the REPLACE-C-SID flavor for IPv4 traffic, the procedure described in <xref section="4.2.1" sectionFormat="of" target="I-D.ietf-spring-srv6-srh-compression"/> is executed except for line S23 replaced as follows.</t>
            <artwork><![CDATA[
S1.   If (Upper-layer header type != 4 (IPv4)) {
S2.     Resubmit the packet to the IPv6 module for transmission to
           the new destination.
S3.   }
S4.   Perform IPv6 decapsulation.
S5.   Submit the packet to the IPv4 module for transmission on
         interface IFACE-OUT via NH-ADDR.
]]></artwork>
            <t>The upper-layer header processing is unchanged as per <xref section="6.1.2.2" sectionFormat="of" target="I-D.ietf-spring-sr-service-programming"/>.</t>
            <t>When processing an IPv4 packet received on the interface IFACE-IN and with a destination address that does not match any address of IFACE-IN, as per <xref section="6.1.2.2" sectionFormat="of" target="I-D.ietf-spring-sr-service-programming"/>.</t>
          </section>
          <section anchor="next-c-sid-flavor-1">
            <name>NEXT-C-SID Flavor</name>
            <t>When processing an IPv6 packet that matches a FIB entry locally instantiated as an SRv6 static proxy SID with the NEXT-C-SID flavor for IPv4 traffic, the procedure described in <xref section="4.1.1" sectionFormat="of" target="I-D.ietf-spring-srv6-srh-compression"/> is executed except for line S08 of that and line S15 of <xref section="4.1" sectionFormat="of" target="RFC8986"/> that are both replaced as follows.</t>
            <artwork><![CDATA[
S1.   If (Upper-layer header type != 4 (IPv4)) {
S2.     Resubmit the packet to the IPv6 module for transmission to
           the new destination.
S3.   }
S4.   Perform IPv6 decapsulation.
S5.   Submit the packet to the IPv4 module for transmission on
         interface IFACE-OUT via NH-ADDR.
]]></artwork>
            <t>The upper-layer header processing is unchanged as per <xref section="6.1.2.2" sectionFormat="of" target="I-D.ietf-spring-sr-service-programming"/>.</t>
            <t>When processing an IPv4 packet received on the interface IFACE-IN and with a destination address that does not match any address of IFACE-IN, as per <xref section="6.1.2.2" sectionFormat="of" target="I-D.ietf-spring-sr-service-programming"/>.</t>
          </section>
        </section>
        <section anchor="static-proxy-for-inner-type-ipv6">
          <name>Static Proxy for Inner Type IPv6</name>
          <section anchor="replace-c-sid-flavor-2">
            <name>REPLACE-C-SID Flavor</name>
            <t>When processing an IPv6 packet that matches a FIB entry locally instantiated as an SRv6 static proxy SID with the REPLACE-C-SID flavor for IPv6 traffic, the procedure described in <xref section="4.2.1" sectionFormat="of" target="I-D.ietf-spring-srv6-srh-compression"/> is executed except for line S23 replaced as follows.</t>
            <artwork><![CDATA[
S1.   If (Upper-layer header type != 41 (IPv6)) {
S2.     Resubmit the packet to the IPv6 module for transmission to
           the new destination.
S3.   }
S4.   Perform IPv6 decapsulation.
S5.   Submit the packet to the IPv6 module for transmission on
         interface IFACE-OUT via NH-ADDR.
]]></artwork>
            <t>The upper-layer header processing is unchanged as per <xref section="6.1.2.3" sectionFormat="of" target="I-D.ietf-spring-sr-service-programming"/>.</t>
            <t>When processing an IPv6 packet received on the interface IFACE-IN and with a destination address that does not match any address of IFACE-IN, as per <xref section="6.1.2.3" sectionFormat="of" target="I-D.ietf-spring-sr-service-programming"/>.</t>
          </section>
          <section anchor="next-c-sid-flavor-2">
            <name>NEXT-C-SID Flavor</name>
            <t>When processing an IPv6 packet that matches a FIB entry locally instantiated as an SRv6 static proxy SID with the NEXT-C-SID flavor for IPv6 traffic, the procedure described in <xref section="4.1.1" sectionFormat="of" target="I-D.ietf-spring-srv6-srh-compression"/> is executed except for line S08 of that and line S15 of <xref section="4.1" sectionFormat="of" target="RFC8986"/> that are both replaced as follows.</t>
            <artwork><![CDATA[
S1.   If (Upper-layer header type != 41 (IPv6)) {
S2.     Resubmit the packet to the IPv6 module for transmission to
           the new destination.
S3.   }
S4.   Perform IPv6 decapsulation.
S5.   Submit the packet to the IPv6 module for transmission on
         interface IFACE-OUT via NH-ADDR.
]]></artwork>
            <t>The upper-layer header processing is unchanged as per <xref section="6.1.2.3" sectionFormat="of" target="I-D.ietf-spring-sr-service-programming"/>.</t>
            <t>When processing an IPv6 packet received on the interface IFACE-IN and with a destination address that does not match any address of IFACE-IN, as per <xref section="6.1.2.3" sectionFormat="of" target="I-D.ietf-spring-sr-service-programming"/>.</t>
          </section>
        </section>
      </section>
      <section anchor="dynamic-sr-proxy">
        <name>Dynamic SR Proxy</name>
        <section anchor="dynamic-proxy-for-inner-type-ethernet">
          <name>Dynamic Proxy for Inner Type Ethernet</name>
          <section anchor="replace-c-sid-flavor-3">
            <name>REPLACE-C-SID Flavor</name>
            <t>When processing an IPv6 packet that matches a FIB entry locally instantiated as an SRv6 dynamic proxy SID with the REPLACE-C-SID flavor for Ethernet traffic, the procedure described in <xref section="4.2.1" sectionFormat="of" target="I-D.ietf-spring-srv6-srh-compression"/> is executed except for line S23 replaced as follows.</t>
            <artwork><![CDATA[
S1.   If (Upper-layer header type != 143 (Ethernet)) {
S2.     Resubmit the packet to the IPv6 module for transmission to
           the new destination.
S3.   }
S4.   Copy the IPv6 encapsulation in a CACHE entry associated with
            the interface IFACE-IN.
S5.   Perform IPv6 decapsulation.
S6.   Submit the frame to the Ethernet module for transmission via
         interface IFACE-OUT.
]]></artwork>
            <t>The upper-layer header processing is unchanged as per <xref section="6.2.2" sectionFormat="of" target="I-D.ietf-spring-sr-service-programming"/>.</t>
            <t>When processing an Ethernet frame received on the interface IFACE-IN and with a destination MAC address that is neither a broadcast address nor matches the address of IFACE-IN, as per <xref section="6.2.2" sectionFormat="of" target="I-D.ietf-spring-sr-service-programming"/>.</t>
          </section>
          <section anchor="next-c-sid-flavor-3">
            <name>NEXT-C-SID Flavor</name>
            <t>When processing an IPv6 packet that matches a FIB entry locally instantiated as an SRv6 dynamic proxy SID with the NEXT-C-SID flavor for Ethernet traffic, the procedure described in <xref section="4.1.1" sectionFormat="of" target="I-D.ietf-spring-srv6-srh-compression"/> is executed except for line S08 of that and line S15 of <xref section="4.1" sectionFormat="of" target="RFC8986"/> that are both replaced as follows.</t>
            <artwork><![CDATA[
S1.   If (Upper-layer header type != 143 (Ethernet)) {
S2.     Resubmit the packet to the IPv6 module for transmission to
           the new destination.
S3.   }
S4.   Copy the IPv6 encapsulation in a CACHE entry associated with
            the interface IFACE-IN.
S5.   Perform IPv6 decapsulation.
S6.   Submit the frame to the Ethernet module for transmission via
         interface IFACE-OUT.
]]></artwork>
            <t>The upper-layer header processing is unchanged as per <xref section="6.2.2" sectionFormat="of" target="I-D.ietf-spring-sr-service-programming"/>.</t>
            <t>When processing an Ethernet frame received on the interface IFACE-IN and with a destination MAC address that is neither a broadcast address nor matches the address of IFACE-IN, as per <xref section="6.2.2" sectionFormat="of" target="I-D.ietf-spring-sr-service-programming"/>.</t>
          </section>
        </section>
        <section anchor="dynamic-proxy-for-inner-type-ipv4">
          <name>Dynamic Proxy for Inner Type IPv4</name>
          <section anchor="replace-c-sid-flavor-4">
            <name>REPLACE-C-SID Flavor</name>
            <t>When processing an IPv6 packet that matches a FIB entry locally instantiated as an SRv6 dynamic proxy SID with the REPLACE-C-SID flavor for IPv4 traffic, the procedure described in <xref section="4.2.1" sectionFormat="of" target="I-D.ietf-spring-srv6-srh-compression"/> is executed except for line S23 replaced as follows.</t>
            <artwork><![CDATA[
S1.   If (Upper-layer header type != 4 (IPv4)) {
S2.     Resubmit the packet to the IPv6 module for transmission to
           the new destination.
S3.   }
S4.   Copy the IPv6 encapsulation in a CACHE entry associated with
            the interface IFACE-IN.
S5.   Perform IPv6 decapsulation.
S6.   Submit the frame to the IPv4 module for transmission via
         interface IFACE-OUT via NH-ADDR.
]]></artwork>
            <t>The upper-layer header processing is unchanged as per <xref section="6.2.2" sectionFormat="of" target="I-D.ietf-spring-sr-service-programming"/>.</t>
            <t>When processing an IPv4 packet received on the interface IFACE-IN and with a destination address that does not match any address of IFACE-IN, as per <xref section="6.2.2" sectionFormat="of" target="I-D.ietf-spring-sr-service-programming"/>.</t>
          </section>
          <section anchor="next-c-sid-flavor-4">
            <name>NEXT-C-SID Flavor</name>
            <t>When processing an IPv6 packet that matches a FIB entry locally instantiated as an SRv6 dynamic proxy SID with the NEXT-C-SID flavor for IPv4 traffic, the procedure described in <xref section="4.1.1" sectionFormat="of" target="I-D.ietf-spring-srv6-srh-compression"/> is executed except for line S08 of that and line S15 of <xref section="4.1" sectionFormat="of" target="RFC8986"/> that are both replaced as follows.</t>
            <artwork><![CDATA[
S1. If (Upper-layer header type != 4 (IPv4)) {
S2.   Resubmit the packet to the IPv6 module for transmission to
        the new destination.
S3. }
S4. Copy the IPv6 encapsulation in a CACHE entry associated with
        the interface IFACE-IN.
S5. Perform IPv6 decapsulation.
S6. Submit the frame to the IPv4 module for transmission via
      interface IFACE-OUT via NH-ADDR.
]]></artwork>
            <t>The upper-layer header processing is unchanged as per <xref section="6.2.2" sectionFormat="of" target="I-D.ietf-spring-sr-service-programming"/>.</t>
            <t>When processing an IPv4 packet received on the interface IFACE-IN and with a destination address that does not match any address of IFACE-IN, as per <xref section="6.2.2" sectionFormat="of" target="I-D.ietf-spring-sr-service-programming"/>.</t>
          </section>
        </section>
        <section anchor="dynamic-proxy-for-inner-type-ipv6">
          <name>Dynamic Proxy for Inner Type IPv6</name>
          <section anchor="replace-c-sid-flavor-5">
            <name>REPLACE-C-SID Flavor</name>
            <t>When processing an IPv6 packet that matches a FIB entry locally instantiated as an SRv6 dynamic proxy SID with the REPLACE-C-SID flavor for IPv6 traffic, the procedure described in <xref section="4.2.1" sectionFormat="of" target="I-D.ietf-spring-srv6-srh-compression"/> is executed except for line S23 replaced as follows.</t>
            <artwork><![CDATA[
S1. If (Upper-layer header type != 41 (IPv6)) {
S2.   Resubmit the packet to the IPv6 module for transmission to
        the new destination.
S3. }
S4. Copy the IPv6 encapsulation in a CACHE entry associated with
        the interface IFACE-IN.
S5. Perform IPv6 decapsulation.
S6. Submit the frame to the IPv6 module for transmission via
      interface IFACE-OUT via NH-ADDR.
]]></artwork>
            <t>The upper-layer header processing is unchanged as per <xref section="6.2.2" sectionFormat="of" target="I-D.ietf-spring-sr-service-programming"/>.</t>
            <t>When processing an IPv6 packet received on the interface IFACE-IN and with a destination address that does not match any address of IFACE-IN, as per <xref section="6.2.2" sectionFormat="of" target="I-D.ietf-spring-sr-service-programming"/>.</t>
          </section>
          <section anchor="next-c-sid-flavor-5">
            <name>NEXT-C-SID Flavor</name>
            <t>When processing an IPv6 packet that matches a FIB entry locally instantiated as an SRv6 dynamic proxy SID with the NEXT-C-SID flavor for IPv6 traffic, the procedure described in <xref section="4.1.1" sectionFormat="of" target="I-D.ietf-spring-srv6-srh-compression"/> is executed except for line S08 of that and line S15 of <xref section="4.1" sectionFormat="of" target="RFC8986"/> that are both replaced as follows.</t>
            <artwork><![CDATA[
S1. If (Upper-layer header type != 41 (IPv6)) {
S2.   Resubmit the packet to the IPv6 module for transmission to
        the new destination.
S3. }
S4. Copy the IPv6 encapsulation in a CACHE entry associated with
        the interface IFACE-IN.
S5. Perform IPv6 decapsulation.
S6. Submit the frame to the IPv6 module for transmission via
      interface IFACE-OUT via NH-ADDR.
]]></artwork>
            <t>The upper-layer header processing is unchanged as per <xref section="6.2.2" sectionFormat="of" target="I-D.ietf-spring-sr-service-programming"/>.</t>
            <t>When processing an IPv6 packet received on the interface IFACE-IN and with a destination address that does not match any address of IFACE-IN, as per <xref section="6.2.2" sectionFormat="of" target="I-D.ietf-spring-sr-service-programming"/>.</t>
          </section>
        </section>
      </section>
      <section anchor="shared-memory-sr-proxy">
        <name>Shared Memory SR Proxy</name>
        <t>This document does not define new flavors for shared proxy behavior as it is just an SR endpoint behavior.</t>
      </section>
      <section anchor="mas_proxy">
        <name>Masquerading SR Proxy</name>
        <t>As per <xref target="I-D.ietf-spring-sr-service-programming"/>, when forwarding packets to SR-unaware SFs, masquerading SR proxy sets the destination address of the IPv6 header as segment list[0] which is the original final destination address. When receiving the traffic returning from the service, de-masquerading sets the destination address as segment list[Segment Left].</t>
        <t>To be consistent with the behavior of masquerading proxy, it's required that any segment list containing one or more masquerading proxy C-SID <bcp14>MUST NOT</bcp14> apply any compression encoding to the last segment (segment list[0]).</t>
        <t>Note: The service receiving an IPv6 packet from the proxy uses the destination address (copied from last segment) as final destination and could apply certain actions based on that. In order to process and forward packets correctly, it is required that the last segment not be compressed.</t>
        <t>To be consistent with the behavior of masquerading proxy, when processing an IPv6 packet matching a FIB entry locally instantiated as an SRv6 masquerading C-SID, it's required that the updated destination address <bcp14>MUST</bcp14> be cached in the proxy by adding a dynamic caching mechanism similar to the one described in <xref section="6.2" sectionFormat="of" target="I-D.ietf-spring-sr-service-programming"/> in case that segment list[Segment Left] is a compressed SID.</t>
        <t>When processing an IPv6 packet received on the interface IFACE-IN and with a destination address that does not match any address of IFACE-IN, the destination address <bcp14>MUST</bcp14> be recovered from CACHE in case that segment list[Segment Left] could be a C-SID container.</t>
        <section anchor="srv6-masquerading-proxy-pseudocode">
          <name>SRv6 Masquerading Proxy Pseudocode</name>
          <section anchor="replace-c-sid-flavor-6">
            <name>REPLACE-C-SID Flavor</name>
            <t>When processing an IPv6 packet that matches a FIB entry locally instantiated as an SRv6 masquerading proxy SID with the REPLACE-C-SID flavor, the procedure described in Figure 23 from <xref section="4.2.1" sectionFormat="of" target="I-D.ietf-spring-srv6-srh-compression"/> is executed except for line S23 replaced as follows.</t>
            <artwork><![CDATA[
S1. Copy the IPv6 Destination Address in a CACHE entry associated 
      with the interface IFACE-IN.
S2. Copy Segment List[0] from the SRH to the Destination Address
      of the IPv6 header.
S3. Submit the packet to the IPv6 module for transmission on
      interface IFACE-OUT via NH-ADDR.
]]></artwork>
            <t><strong>De-masquerading</strong>: When processing an IPv6 packet received on the interface IFACE-IN and with a destination address that does not match any address of IFACE-IN, the procedure described in Figure 24 from <xref section="6.4.1" sectionFormat="of" target="I-D.ietf-spring-sr-service-programming"/> is executed except for line S10 that is replaced as follows.</t>
            <artwork><![CDATA[
S01. Retrieve the CACHE entry associated with IFACE-IN.
S02. If the CACHE entry is not empty {
S03.    Destination Address of the IPv6 header is set to CACHE.
S04. }
]]></artwork>
          </section>
          <section anchor="next-c-sid-flavor-6">
            <name>NEXT-C-SID Flavor</name>
            <t>When processing an IPv6 packet that matches a FIB entry locally instantiated as an SRv6 masquerading proxy SID with the NEXT-C-SID flavor, the procedure described in <xref section="4.1.1" sectionFormat="of" target="I-D.ietf-spring-srv6-srh-compression"/> is executed except for line S08 of that and line S15 of <xref section="4.1" sectionFormat="of" target="RFC8986"/> that are both replaced as follows.</t>
            <artwork><![CDATA[
S1. Copy the IPv6 Destination Address in a CACHE entry associated 
      with the interface IFACE-IN.
S2. Copy Segment List[0] from the SRH to the Destination Address
      of the IPv6 header.
S3. Submit the packet to the IPv6 module for transmission on
      interface IFACE-OUT via NH-ADDR.
]]></artwork>
            <t><strong>De-masquerading</strong>: When processing an IPv6 packet received on the interface IFACE-IN and with a destination address that does not match any address of IFACE-IN, the procedure described in <xref section="6.4.1" sectionFormat="of" target="I-D.ietf-spring-sr-service-programming"/> is executed except for line S10 that is replaced as follows.</t>
            <artwork><![CDATA[
S01. Retrieve the CACHE entry associated with IFACE-IN.
S02. If the CACHE entry is not empty {
S03.    Destination Address of the IPv6 header is set to CACHE.
S04. }
]]></artwork>
          </section>
        </section>
        <section anchor="destination-nat-flavor">
          <name>Destination NAT Flavor</name>
          <section anchor="replace-c-sid-flavor-7">
            <name>REPLACE-C-SID Flavor</name>
            <t>The Destination NAT flavor of the SRv6 masquerading proxy with the REPLACE-C-SID is executed except for line S09.1 and S10 in <xref section="6.4.2" sectionFormat="of" target="I-D.ietf-spring-sr-service-programming"/> replaced as follows.</t>
            <artwork><![CDATA[
S1. Copy the Destination Address of the IPv6 header to the
      Segment List[0] entry of the SRH.
S2. Retrieve the CACHE entry associated with IFACE-IN.
S3. If the CACHE entry is not empty {
S4.    Destination Address of the IPv6 header is set to CACHE.
S5. }
]]></artwork>
          </section>
          <section anchor="next-c-sid-flavor-7">
            <name>NEXT-C-SID Flavor</name>
            <t>The Destination NAT flavor of the SRv6 masquerading proxy with the NEXT-C-SID is executed except for line S09.1 and S10 in <xref section="6.4.2" sectionFormat="of" target="I-D.ietf-spring-sr-service-programming"/> replaced as follows.</t>
            <artwork><![CDATA[
S1. Copy the Destination Address of the IPv6 header to the
      Segment List[0] entry of the SRH.
S2. Retrieve the CACHE entry associated with IFACE-IN.
S3. If the CACHE entry is not empty {
S4.    Destination Address of the IPv6 header is set to CACHE.
S5. }
]]></artwork>
          </section>
        </section>
        <section anchor="cache-flavor">
          <name>Cache Flavor</name>
          <t>The caching flavor of the SRv6 masquerading proxy with C-SID is enabled as per <xref section="6.4.3" sectionFormat="of" target="I-D.ietf-spring-sr-service-programming"/> without any modification.</t>
        </section>
      </section>
    </section>
    <section anchor="security-considerations">
      <name>Security Considerations</name>
      <t>The security requirements and mechanisms described in <xref target="RFC8402"/> and <xref target="RFC8754"/> also apply to this document.</t>
      <t>This document does not introduce any new security considerations.</t>
    </section>
    <section anchor="iana-considerations">
      <name>IANA Considerations</name>
      <t>TBD</t>
    </section>
  </middle>
  <back>
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <reference anchor="RFC2119">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <author fullname="S. Bradner" initials="S." surname="Bradner">
              <organization/>
            </author>
            <date month="March" year="1997"/>
            <abstract>
              <t>In many standards track documents several words are used to signify the requirements in the specification.  These words are often capitalized. This document defines these words as they should be interpreted in IETF documents.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="2119"/>
          <seriesInfo name="DOI" value="10.17487/RFC2119"/>
        </reference>
        <reference anchor="RFC8174">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <author fullname="B. Leiba" initials="B." surname="Leiba">
              <organization/>
            </author>
            <date month="May" year="2017"/>
            <abstract>
              <t>RFC 2119 specifies common key words that may be used in protocol  specifications.  This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the  defined special meanings.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="8174"/>
          <seriesInfo name="DOI" value="10.17487/RFC8174"/>
        </reference>
        <reference anchor="RFC8402">
          <front>
            <title>Segment Routing Architecture</title>
            <author fullname="C. Filsfils" initials="C." role="editor" surname="Filsfils">
              <organization/>
            </author>
            <author fullname="S. Previdi" initials="S." role="editor" surname="Previdi">
              <organization/>
            </author>
            <author fullname="L. Ginsberg" initials="L." surname="Ginsberg">
              <organization/>
            </author>
            <author fullname="B. Decraene" initials="B." surname="Decraene">
              <organization/>
            </author>
            <author fullname="S. Litkowski" initials="S." surname="Litkowski">
              <organization/>
            </author>
            <author fullname="R. Shakir" initials="R." surname="Shakir">
              <organization/>
            </author>
            <date month="July" year="2018"/>
            <abstract>
              <t>Segment Routing (SR) leverages the source routing paradigm.  A node steers a packet through an ordered list of instructions, called "segments".  A segment can represent any instruction, topological or service based.  A segment can have a semantic local to an SR node or global within an SR domain.  SR provides a mechanism that allows a flow to be restricted to a specific topological path, while maintaining per-flow state only at the ingress node(s) to the SR domain.</t>
              <t>SR can be directly applied to the MPLS architecture with no change to the forwarding plane.  A segment is encoded as an MPLS label.  An ordered list of segments is encoded as a stack of labels.  The segment to process is on the top of the stack.  Upon completion of a segment, the related label is popped from the stack.</t>
              <t>SR can be applied to the IPv6 architecture, with a new type of routing header.  A segment is encoded as an IPv6 address.  An ordered list of segments is encoded as an ordered list of IPv6 addresses in the routing header.  The active segment is indicated by the Destination Address (DA) of the packet.  The next active segment is indicated by a pointer in the new routing header.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8402"/>
          <seriesInfo name="DOI" value="10.17487/RFC8402"/>
        </reference>
        <reference anchor="RFC8754">
          <front>
            <title>IPv6 Segment Routing Header (SRH)</title>
            <author fullname="C. Filsfils" initials="C." role="editor" surname="Filsfils">
              <organization/>
            </author>
            <author fullname="D. Dukes" initials="D." role="editor" surname="Dukes">
              <organization/>
            </author>
            <author fullname="S. Previdi" initials="S." surname="Previdi">
              <organization/>
            </author>
            <author fullname="J. Leddy" initials="J." surname="Leddy">
              <organization/>
            </author>
            <author fullname="S. Matsushima" initials="S." surname="Matsushima">
              <organization/>
            </author>
            <author fullname="D. Voyer" initials="D." surname="Voyer">
              <organization/>
            </author>
            <date month="March" year="2020"/>
            <abstract>
              <t>Segment Routing can be applied to the IPv6 data plane using a new type of Routing Extension Header called the Segment Routing Header (SRH). This document describes the SRH and how it is used by nodes that are Segment Routing (SR) capable.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8754"/>
          <seriesInfo name="DOI" value="10.17487/RFC8754"/>
        </reference>
        <reference anchor="RFC8986">
          <front>
            <title>Segment Routing over IPv6 (SRv6) Network Programming</title>
            <author fullname="C. Filsfils" initials="C." role="editor" surname="Filsfils">
              <organization/>
            </author>
            <author fullname="P. Camarillo" initials="P." role="editor" surname="Camarillo">
              <organization/>
            </author>
            <author fullname="J. Leddy" initials="J." surname="Leddy">
              <organization/>
            </author>
            <author fullname="D. Voyer" initials="D." surname="Voyer">
              <organization/>
            </author>
            <author fullname="S. Matsushima" initials="S." surname="Matsushima">
              <organization/>
            </author>
            <author fullname="Z. Li" initials="Z." surname="Li">
              <organization/>
            </author>
            <date month="February" year="2021"/>
            <abstract>
              <t>The Segment Routing over IPv6 (SRv6) Network Programming framework enables a network operator or an application to specify a packet processing program by encoding a sequence of instructions in the IPv6 packet header.</t>
              <t>Each instruction is implemented on one or several nodes in the network and identified by an SRv6 Segment Identifier in the packet.</t>
              <t>This document defines the SRv6 Network Programming concept and specifies the base set of SRv6 behaviors that enables the creation of interoperable overlays with underlay optimization.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8986"/>
          <seriesInfo name="DOI" value="10.17487/RFC8986"/>
        </reference>
        <reference anchor="I-D.ietf-spring-srv6-srh-compression">
          <front>
            <title>Compressed SRv6 Segment List Encoding in SRH</title>
            <author fullname="Weiqiang Cheng" initials="W." surname="Cheng">
              <organization>China Mobile</organization>
            </author>
            <author fullname="Clarence Filsfils" initials="C." surname="Filsfils">
              <organization>Cisco Systems</organization>
            </author>
            <author fullname="Zhenbin Li" initials="Z." surname="Li">
              <organization>Huawei Technologies</organization>
            </author>
            <author fullname="Bruno Decraene" initials="B." surname="Decraene">
              <organization>Orange</organization>
            </author>
            <author fullname="Francois Clad" initials="F." surname="Clad">
              <organization>Cisco Systems</organization>
            </author>
            <date day="11" month="January" year="2023"/>
            <abstract>
              <t>   This document specifies new flavors for the SR endpoint behaviors
   defined in RFC 8986, which enable a compressed SRv6 Segment-List
   encoding in the Segment Routing Header (SRH).

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-spring-srv6-srh-compression-03"/>
        </reference>
        <reference anchor="I-D.ietf-spring-sr-service-programming">
          <front>
            <title>Service Programming with Segment Routing</title>
            <author fullname="Francois Clad" initials="F." surname="Clad">
              <organization>Cisco Systems, Inc.</organization>
            </author>
            <author fullname="Xiaohu Xu" initials="X." surname="Xu">
              <organization>Alibaba</organization>
            </author>
            <author fullname="Clarence Filsfils" initials="C." surname="Filsfils">
              <organization>Cisco Systems, Inc.</organization>
            </author>
            <author fullname="Daniel Bernier" initials="D." surname="Bernier">
              <organization>Bell Canada</organization>
            </author>
            <author fullname="Cheng Li" initials="C." surname="Li">
              <organization>Huawei</organization>
            </author>
            <author fullname="Bruno Decraene" initials="B." surname="Decraene">
              <organization>Orange</organization>
            </author>
            <author fullname="Shaowen Ma" initials="S." surname="Ma">
              <organization>Mellanox</organization>
            </author>
            <author fullname="Chaitanya Yadlapalli" initials="C." surname="Yadlapalli">
              <organization>AT&amp;T</organization>
            </author>
            <author fullname="Wim Henderickx" initials="W." surname="Henderickx">
              <organization>Nokia</organization>
            </author>
            <author fullname="Stefano Salsano" initials="S." surname="Salsano">
              <organization>Universita di Roma "Tor Vergata"</organization>
            </author>
            <date day="9" month="June" year="2022"/>
            <abstract>
              <t>   This document defines data plane functionality required to implement
   service segments and achieve service programming in SR-enabled MPLS
   and IPv6 networks, as described in the Segment Routing architecture.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-spring-sr-service-programming-06"/>
        </reference>
      </references>
      <references>
        <name>Informative References</name>
        <reference anchor="RFC7665">
          <front>
            <title>Service Function Chaining (SFC) Architecture</title>
            <author fullname="J. Halpern" initials="J." role="editor" surname="Halpern">
              <organization/>
            </author>
            <author fullname="C. Pignataro" initials="C." role="editor" surname="Pignataro">
              <organization/>
            </author>
            <date month="October" year="2015"/>
            <abstract>
              <t>This document describes an architecture for the specification, creation, and ongoing maintenance of Service Function Chains (SFCs) in a network.  It includes architectural concepts, principles, and components used in the construction of composite services through deployment of SFCs, with a focus on those to be standardized in the IETF.  This document does not propose solutions, protocols, or extensions to existing protocols.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7665"/>
          <seriesInfo name="DOI" value="10.17487/RFC7665"/>
        </reference>
        <reference anchor="I-D.srcompdt-spring-compression-requirement">
          <front>
            <title>Compressed SRv6 SID List Requirements</title>
            <author fullname="Weiqiang Cheng" initials="W." surname="Cheng">
              <organization>China Mobile</organization>
            </author>
            <author fullname="Chongfeng Xie" initials="C." surname="Xie">
              <organization>China Telecom</organization>
            </author>
            <author fullname="Ron Bonica" initials="R." surname="Bonica">
              <organization>Juniper</organization>
            </author>
            <author fullname="Darren Dukes" initials="D." surname="Dukes">
              <organization>Cisco Systems</organization>
            </author>
            <author fullname="Cheng Li" initials="C." surname="Li">
              <organization>Huawei</organization>
            </author>
            <author fullname="Shaofu Peng" initials="S." surname="Peng">
              <organization>ZTE</organization>
            </author>
            <author fullname="Wim Henderickx" initials="W." surname="Henderickx">
              <organization>Nokia</organization>
            </author>
            <date day="11" month="July" year="2021"/>
            <abstract>
              <t>   This document specifies requirements for solutions to compress SRv6
   SID lists.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-srcompdt-spring-compression-requirement-07"/>
        </reference>
      </references>
    </references>
    <section numbered="false" anchor="Acknowledgements">
      <name>Acknowledgements</name>
      <t>TBD.</t>
    </section>
  </back>
  <!-- ##markdown-source:
H4sIAAAAAAAAA+1c627bOBb+r6fgpD82LWxv7LqeNthZrOskkwBJmo1TzA4G
xYCWaJtbSfSQUlJvkD7LPss+2Z5zSMmSb4mTTHOpB8VYong51+8cUjmqVque
SXgc/M5DFYttluhUeHKk6cokja2td1sNz+fJNjNJ4Jm0F0ljpIqT8Qi6H+ye
7XlcC77NTlWayHjA2nDnXQy2Wffk9OD4Z/aL0p+x/Wet0pHnBcqPeQRDA837
STUcVs1Iw/Oq0eetqun7Vd/IoLq15ameUaFIhNn20lHA6cJLZBLC4I6KRloY
IwLWPdhhm50q/LxkfaVZ9/S8xbp7Hc8LeQxkiNj7fLHtMVZlXaHPpS/YSKuB
5lEEy1J7Nhuw5XkvGK61zRpbjUZ1C/+xapXamDSsL8MQFpUx42miIp5In4fh
mPXG7EsUNnTfZ7LPYpWwgTyHpT3oNlR626vCSjI2QHqNHUq4sVLoDAXIhhqU
Bmr3U34h8M5XaZzoMfaQMYcGrZBxEchEabgVEZfhNvNr4T+GNKbmq2iyyn4N
p4Kp85X2VTwYS9t629WGNEdtiHMUl/VipVEW5wIFfbrXadTr79zl2/qPzeyy
udXILn98k7e+e9vCy4PqTk2KpF82CD2s+hP1zO9XNVax1YJiwVZk3J8i68dW
6002hdE4b5Bk0xRWqWrxRyq1iEScwDxeFQyA90yiuZ943kFMNlZhPHbGBhYI
psFZvfG22pMJO+dhKmrsF9AtS5RiEY/H+cNsCAzQYFKxH6aBsyicb7/CkiG2
J1oFqQ9P1LnQQ8EDdgG2x3i/L/yE+gA9sXHuyES/L30pYn/MVJ+N+DhUPKgx
IFbpQGigg/EgQAZhLFALouqFIqpMuVLmSbbHSEFzjZ3hAHDcFAXCAtGXsTAs
FhesJ4b8XCptyPWcGuB3gD0NUJwM2enuyWG7s1ulmYHJgB3v/uvM3fZDfo7D
gTwRc6CI+QV6UFRm1mlrViWRDIJQoMceOGkl5MFdu3yOSJeXzvaurqyejEo1
zKjd8xHXPJCDCIkw6WikdAJgJ4S2D/3PIkGhQffBEEZnhACBIw788cRpbEDS
jVUAuu+kWgMN4RjUeaEQPmAgAJKwarcyDCxglcndZkcnh12S08HJecuZEV4W
ZkE+UmPNZmp8hYGRwWPEpUyGVgLgciCBWukuUyYndYoviYjJnNDgwGqkXbmS
zzYl2n3bbRPs9mWlKD9cFgyn3ABrgDD056IuK44cAIESOX14LqgzzNpLZRgQ
jaXx1r4SMNNQDRCISWozVuhzraVzsRkOhgUO2G9OMJ/Awtp5uNhLY7IsAEcO
c2xCcHlpqUY8KVLtnE0gEQn6YYYaOVF9N5chUqk3UuFDC3SUMVkaWFQEwRe8
i/HRKETaQQiZJcLAv4LZkIAmd6G6MET19ErMJ6p9IA7mk9EoJFyDOSFmkVbg
NzVIBXgGAB9giEDaJ0BlQQp7zMg2M2RY4fLyZsh8dQV07qsLAbhWYRd3AMkc
GYFavIcHq4AkPs6B0lJ/w6AAOh8pUhZYkZ3HwilOC4nUYBIYQmmgG5hE6uer
FeggH4lkIgeYYJjUH+ZcVeZKdDYmFgwQfThDVISWHjfSB1oAWwMiuADYJc3l
HlhjH8kUkKfJbGgsbiAyVSnEupxRZ2AF+EbHFaiw1w3qCoPrLbqan76hMUgQ
gBUWgkCoyIuM/I+Y6BjWs04LZnSWh40pgRfkUwpNZa9ATsmdKzYoXhPjkJS5
IS6T+TXeME93wIT34gU7nRiXYYeQXqV8AKHtDDj+LMYMUC8wbOPoY/dso2J/
2fEHuj7d/efHg9PdHbzu7rcPD/MLz/Xo7n/4eLgzuZqM7Hw4Oto93rGDoZWV
mryNo/avGxVCqo0PJ2cHH47bhxvIXFlY6KJW12BhQgNviC7ceIEwvpY9K5D3
nZP//bfeBMH84BJEMFx7gyki3CAU2NVUDCm1vQWdjz1AQcEpGkEYAksbyYSH
BvoaZobqAsOVFiDJV7+hZD5ts7/1/FG9+XfXgAyXGjOZlRpJZrMtM4OtEOc0
zVkml2apfUrSZXrbv5buM7kXGslgzoQGMMXAN0YzKeojRGQF8zEWAKHjHG+n
dKhSzAVKkXgF8EGFrYD9DG1au/QCnNyYNMrBos8jGUpQtY3syFYyYXQmE1Xo
ooARebbMMIig0xLX5FsIfydafRmz97kjX74YYcvvuWtfed7NWcjRwZCgQ4s9
cyC2CDy0YA4bNdae/4TZvYQWKGAbpjklFqW9Bfs3pgeh/AywCDrWNlQuQnQS
mhEW93LaVSRm4Q32qkYsoBnzBNB8z8Immpb4AlhbTAvKrExmJm2WEv6KjXXA
W3l7YB/P3yXULB5GmM4EEkK8plSlB0mhEHFhOQIk6Anyv+CaEheJ+ZXdIBgy
QS3gqXD5h12lGDMiAQEiliZyGRjtUHJLypeyecjIiDRQMD7Iw1RZsi42DkQM
9uJSLzrTyCS5gFKczdJmV7fyXcYWPAwhFbRKcZNYldM6gUhgI2/y7KdMeIlo
F5i6CZ5x5KxjW954kpEDGzDgjJ2NR4LtokFCok49X0ypd48U6Xm0pwFufBQ3
Zp5uh2NzXJcC88QfUhqwd/Ae3CvRY0gI7HEL8s3jRPKJg9jNoiXMygkXdDgi
5psZkp7Ri5kipmWVLJ+DvXdKW7VCELu87Do/atYatToK7YYoCS4ovgg/RYLF
F1+MElo9RM10G6/R40PuW26sDlEDX79+9br1GmPsoM82P0IY1NWQj0HWbt+C
x3Dsh59YvfmabWasvITtiddt4DAGmQUd2rk01clX0R2JPALgDMkCy7lyojw2
+S+zaZAGGC1HEdS87mtc4srrNvH3RGg8b3FbVQFR2qRh1vMN9uhOCKHdS0ZH
roJFtJxLPiGGkow+yIod7KFGP3w8q5GgCB3SWRkV7Ay3zTF69sBKGvoWdNqq
1RdrdeFWZo4t5wxZNrXwhTzHo5w4O9wpcXBwTIBHtsqLImZH7U7h2IbTxj4W
kjCfs56GzYTPIRRkfWKQXOY3uFLWjhy5pSr3xbf17wJKO+f+9r49Eynu5tj1
+3PsrbcWaoFl1LBtrL/BxtKK2DA5BbH9gcQeRPcFyLCGhicADd8tNlyXJIAh
NJ9KgoC0Pu3koMk2kYkn4PszhDQXEqLipX6PwMCO96vtnZ3Te8WAxt3TA+LL
sXp7/y/5fr4VJqegbfAq/r0qUwtC/6OJ/bfy2ScR99dOv3b6h3P664J66wkF
9dYTD+p1cvDWU3TwxYQ8lIO/vhcHbz0uB1+VqacQ1lf32mcW1tduv3b7+3V7
8PmdccyjmWP+rPXxnfMHjrL1Qf8DgEBHjcaTaUVcQAH7N1addmd/12mSG6N8
qz9UUXGpBS6SIclSrGk9jUPDe9k5PLkTw8d/nrAEP77Hlwlr9HmE6LOGn28G
P9dnOw/2wuI2mc76jcXzRpilR6TXocufspd6hiekt0ORx53FPP/XIivjyj2g
ykJIsYByL3CyDEquA5I7wsjNMGQNIt8wFXmY1yy3TEUe93uW1Y9bv2/EWMzf
qojxeADjEZ3fPsOjk+f60oatQeThQWSNIveWdrDukGOl55GIlB4XXgUtKLpy
ZSXTNafGzjIqFcogkbYsnSqXCEtmK6YcHUfc/JEKrMmnQlqXBV2+iLj5naa9
8rx2xvRNeXSVPoXambyyH0trqmnML9Ddu3umAhIvU5DVNSX2IGqeylxFDdmB
s0GsTnSlUFiU+tvWJ1fgKu00SssBTBOyPv1/zqyu+N8aVFYr5KAUWpNUUy1W
X6uIHjnOKzBXtcTDUtKn6cxK5A9FP/mEMIdltlTaGxt4jo9yyM8VDPyXViSR
4bcI/oLVbFTcGmQgPC6th/MmrhhXxSgWQAct5kznaqGykk4qzRrTfMXSLYA6
RWMc3oR4ppgtuDmlkZfI37HCD76cTQRYkPiUb+eitgSlRiyW66avRli7T2OK
VLykMDKrdAAFX6X4pQNizBca5cK4q+PqcZOBCk/Kn/ZwYERTOBPP7dtXGtih
T1FYFyyrY0ZE6NulQu7aXQzgYjlWErZR+wopSGkdsom5hpZQaAho9Dz9kB0h
WxySoMDWNWeK7RHYWsKyjAf7YcukNtDISIZcZ5aG1rsgo2mthsiMvthghGVk
sXfa75n4pXL6RxegFvlHJn8gB795kHmKzUtuKgDrMPidgbyKk9CEPg9Af7GI
FlMKKTaenFDtI5Y+LttM/1lZ9Bxwu3ZDvTR53pMDbIP9LgnxobbT5axzp6D1
ttP6stzTpX65FOamng23Sm4HLrbm0IyfAXEeOYcAt8ZsvLbJ8x3/fulmWeur
VzvlAP3q1TZ7fE57jak1p02tVWuuVim03NjqW/lrwiVGtwVWdyoSLcW5rXFe
sq8pmtFWg/Zt0yOklY6IRskYd2tb9GporiXPSfmo0J5MhubEZZq4IbN7lW+9
Vb8OZGb2689pe77GpO8Jk9YgdEMQotcLhXmO22c5Di15p3A2Zbg4zJ3xFT/M
NAdxFqQ0yzHhHagQLQfFP6Pd1TLpG2LDDWVrHc851rS3W+VNPkZmgeE2dvH6
RmbRvJtVvCkaxdzAdA9aL8y6VvnjUjnr4Ma3pOxsi7uCkie6pQ+xzT1iba72
N+k0MX5ZDyMBhDfZl747WKYPOoENaQny6OB5RICf1MHzEcuByR7q4hfV0LDy
bbuZDh2Tz4Pab1lNPo/JQ6PcaQyZQeEgtLbwYHT2a1Q5UX6J4hp9u7R93J7l
5P2O/cZpDwItMd32P8fqAuQ7cCxdvphuuvIut1mcRj3cS/+00QfixcYVTVbz
/g8l8Ju56lkAAA==

-->

</rfc>
