<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc text-list-sybols="o-*+"?>
<?rfc toc="yes"?>
<?rfc tocdepth="4"?>
<rfc category="info" docName="draft-abdo-hostid-tcpopt-implementation-03" ipr="trust200902"
     submissionType="IETF">
  <front>
    <title abbrev="Report of NAT Reveal TCP Options">HOST_ID TCP Options:
    Implementation &amp; Preliminary Test Results</title>

    <author fullname="Elie Abdo" initials="E." surname="Abdo">
      <organization>France Telecom</organization>

      <address>
        <postal>
          <street></street>

          <city>Issy-les-Moulineaux</city>

          <country></country>
        </postal>

        <email>elie.abdo@orange.com</email>
      </address>
    </author>

    <author fullname="Mohamed Boucadair" initials="M." surname="Boucadair">
      <organization>France Telecom</organization>

      <address>
        <email>mohamed.boucadair@orange.com</email>
      </address>
    </author>

    <author fullname="Jaqueline Queiroz" initials="J." surname="Queiroz">
      <organization>France Telecom</organization>

      <address>
        <postal>
          <street></street>

          <city>Issy-les-Moulineaux</city>

          <country></country>
        </postal>

        <email>jaqueline.queiroz@orange.com</email>
      </address>
    </author>

    <date day="16" month="July" year="2012" />

    <keyword>TCP Option, HOST_ID, Shared Address</keyword>

    <abstract>
      <t>This memo documents the implementation of the HOST_ID TCP Options. It
      also discusses the preliminary results of the tests that have been
      conducted to assess the technical feasibility of the approach as well as
      its scalability. Several HOST_ID TCP options have been implemented and
      tested.</t>
    </abstract>
  </front>

  <middle>
    <section title="Introduction">
      <t>To ensure IPv4 service continuity, service providers will need to
      deploy IPv4 address sharing techniques. Several issues are likely to be
      encountered (refer to <xref target="RFC6269"></xref> for a detailed
      survey of the issues) and they may affect the delivery of services that
      depends on the enforcement of policies based upon the source IPv4
      address.</t>

      <t>Some of these issues may be mitigated owing to the activation of
      advanced features. Among the solutions analyzed in <xref
      target="I-D.boucadair-intarea-nat-reveal-analysis"></xref>, the use of a
      new TCP option to convey a HOST_ID seems to be a promising solution.</t>

      <t>This memo documents some implementation and experimentation efforts
      that have been conducted to assess the viability of using HOST_ID TCP
      options at large scale. In particular, this document provides
      experimentation results related to the support of the HOST_ID TCP
      Options, the behavior of legacy TCP servers when receiving the HOST_ID
      TCP options. This draft also discusses the impact of using a HOST_ID TCP
      options on the time it takes to establish a connection; it also tries to
      evaluate the impact of the new TCP options on the performance of the
      CGN. Finally it presents the enforcement policies that could be applied
      by remote servers based upon the HOST_ID options contents.</t>
    </section>

    <section title="Objectives">
      <t>The implementation of several HOST_ID TCP options is primarily meant
      to:<?rfc subcompact="yes" ?></t>

      <t><list style="symbols">
          <t>Assess the validity of the HOST_ID TCP option approach</t>

          <t>Evaluate the impact on the TCP stack to support the HOST_ID TCP
          options</t>

          <t>Improve filtering and logging capabilities based upon the
          contents of the HOST_ID TCP option. This means the enforcement of
          various policies based upon the content of the HOST_ID TCP option at
          the server side: Log, Deny, Accept, etc.</t>

          <t>Assess the behavior of legacy TCP servers when receiving a
          HOST_ID TCP option</t>

          <t>Assess the success ratio of TCP communications when a HOST_ID TCP
          option is received</t>

          <t>Assess the impact of injecting a HOST_ID TCP option on the time
          it takes to establish a connection</t>

          <t>Assess the performance impact on the CGN device that has been
          configured to inject the HOST_ID option</t>
        </list><?rfc subcompact="no" ?></t>
    </section>

    <section title="NAT Reveal TCP Options: Overview">
      <t>The original idea of defining a TCP option is documented in <xref
      target="I-D.wing-nat-reveal-option"></xref> and denoted as
      HOST_ID_WING.</t>

      <t>An additional TCP option is also considered and denoted as
      HOST_ID_BOUCADAIR. The main motivation is to cover also the
      load-balancer use case and provide richer functionality as Forwarded-For
      HTTP header than HOST_ID_WING can provide.</t>

      <t>The following sub-sections provide an overview of these HOST_ID TCP
      options.</t>

      <section anchor="wing" title="HOST_ID_WING TCP Option">
        <t>HOST_ID_WING is defined in <xref
        target="I-D.wing-nat-reveal-option"></xref>. <xref
        target="wing_option"></xref> shows the format of this option.</t>

        <t><figure align="center" anchor="wing_option"
            title="Format of HOST_ID_WING TCP Option">
            <artwork>+--------+--------+-----------------------+
|Kind=TBD|Length=4|    HOST_ID Data       |
+--------+--------+-----------------------+
</artwork>
          </figure></t>

        <t>This option must be sent only upon the initial connection request,
        i.e., in SYN packets as shown in <xref
        target="wing_example"></xref></t>

        <t><figure align="center" anchor="wing_example"
            title="HOST_ID_WING TCP Option: Flow example">
            <artwork>+------------+        +------------+                 +------------+
| TCP CLIENT |        |     CGN    |                 | TCP SERVER |
+------------+        +------------+                 +------------+ 
      |                     |                              |
      |---TCP SYN----------&gt;|                              |
      |                     |---TCP SYN, HOST_ID=12345----&gt;|
      |                     |                              |</artwork>
          </figure></t>

        <t></t>
      </section>

      <section anchor="boucadair" title="HOST_ID_BOUCADAIR TCP Option">
        <t>As mentioned above, the HOST_ID_BOUCADAIR TCP Option is inspired
        from HOST_ID_WING and XFF.</t>

        <t>The HOST_ID_BOUCADAIR option is a 10-byte long TCP option, where
        KIND, Length and lifetime-Origin fields fill one byte each, and
        HOST_ID data is 7-byte long as shown in <xref
        target="boucadair_option"></xref></t>

        <t><figure align="center" anchor="boucadair_option"
            title="Format of HOST_ID_BOUCADAIR TCP option">
            <artwork>+--------+---------+---+---+--------..-------+
|Kind=TBD|Length=10| L | O |  HOST_ID_data   | HOST_ID
+--------+---------+---+---+--------..-------+ 
</artwork>
          </figure></t>

        <t><?rfc subcompact="yes" ?><list style="symbols">
            <t>L: Indicates the validity lifetime of the enclosed data (in the
            spirit of <xref target="RFC6250"></xref>). The following values
            are supported:<list style="empty">
                <t>0: Permanent;</t>

                <t>&gt;0:Dynamic; this value indicates the validity time.</t>
              </list></t>

            <t>Origin: Indicates the origin of the data conveyed in the data
            field. The following values are supported:<list style="empty">
                <t>0: Internal Port</t>

                <t>1: Internal IPv4 address</t>

                <t>2: Internal Port: Internal IPv4 address</t>

                <t>3: IPv6 Prefix</t>

                <t>&gt;3: No particular semantic</t>
              </list></t>

            <t>HOST_ID_data depends on the content of the Origin field;
            padding is required.</t>
          </list></t>

        <t><?rfc subcompact="no" ?></t>

        <t>Two modes are described below: the SYN mode (<xref
        target="syn_mode"></xref>) and the ACK mode. (<xref
        target="ack_mode"></xref>).</t>

        <t>If the ACK mode is used (<xref target="ack_mode"></xref>), <xref
        target="host_enabled"></xref> shows the HOST_ID_ENABLED option
        (2-bytes long) to be included in the SYN.</t>

        <t><figure align="center" anchor="host_enabled"
            title="Format of HOST_ID_ENABLED">
            <artwork>+--------+---------+
|Kind=TBD|Length=2 |   HOST_ID_ENABLED
+--------+---------+
</artwork>
          </figure></t>

        <t></t>

        <section anchor="syn_mode" title="SYN Mode">
          <t>This mode is similar to the mode described in <xref
          target="wing"></xref>. In this mode, HOST_ID_BOUCADAIR is sent in
          SYN packets.</t>

          <t><figure align="center" anchor="boucadair_syn"
              title="HOST_ID_BOUCADAIR: SYN Mode">
              <artwork>+------------+      +------------+                     +------------+
| TCP CLIENT |      |     CGN    |                     | TCP SERVER |
+------------+      +------------+                     +------------+ 
      |                   |                                    |
      |---TCP SYN--------&gt;|                                    |
      |                   |--TCP SYN, HOST_ID=2001:db8::/5482-&gt;|
      |                   |                                    |
</artwork>
            </figure></t>

          <t></t>
        </section>

        <section anchor="ack_mode" title="ACK Mode">
          <t>The ACK Mode is as follows (see <xref
          target="ackmode"></xref>):<?rfc subcompact="yes" ?><list
              style="symbols">
              <t>Send HOST_ID_ENABLED (<xref target="host_enabled"></xref>) in
              SYN</t>

              <t>If the remote TCP server supports that option, it must return
              it in SYNACK</t>

              <t>Then the TCP Client sends an ACK in which the CGN injects
              HOST_ID_BOUCADAIR (<xref target="boucadair_option"></xref>)
              <?rfc subcompact="no" ?></t>
            </list></t>

          <t><figure align="center" anchor="ackmode"
              title="HOST_ID_BOUCADAIR: ACK Mode">
              <artwork>+------------+        +------------+                 +------------+
| TCP CLIENT |        |     CGN    |                 | TCP SERVER |
+------------+        +------------+                 +------------+ 
      |                     |                               |
      |---TCP SYN----------&gt;|                               |
      |                     |--TCP SYN, HOSTID_ENABLED=OK--&gt;|
      |                     |&lt;-TCP SYNACK,HOSTID_ENABLED=OK-|
      |&lt;--TCP SYNACK--------|                               |
      |---TCP ACK----------&gt;|                               |
      |                     |--TCP ACK, HOST_ID=2001:db8::-&gt;|
      |                     |                               |
</artwork>
            </figure></t>

          <t></t>
        </section>
      </section>
    </section>

    <section anchor="linux" title="Overview of the Linux Kernel Modifications">
      <t>The objective of this phase is to support HOST_ID_WING,
      HOST_ID_BOUCADAIR and HOST_ID_ENABLED in the SYN mode.</t>

      <t>In order to support the injection of the HOST_ID TCP options
      presented in Section 3, some modifications were applied to the Linux
      Kernel (more precisely to the TCP stack part of the Kernel). The header
      file tcp.h, file where are defined the TCP variables and functions, is
      updated to define the new HOST_ID options' KINDs (option numbers) and
      Lengths.</t>

      <t>Major modifications have been made in the "tcp_output.c" file. This
      file is responsible for building and transmitting all TCP packets. For
      each HOST_ID TCP option, the required modifications to increase the
      header size and to inject KIND, Length and the corresponding HOST_ID
      data are implemented for the TCP SYN packets.</t>

      <t>As we have three different HOST_ID options and as HOST_ID_BOUCADAIR
      can convey different information the configuration of the HOST_ID
      options have to be simple with minimal complexity. Since the
      manipulation of HOST_ID options impacts the Kernel TCP drivers, a
      suitable solution is to define new sysctl variables (system control
      variables) that allow the modification of Kernel parameters at runtime,
      without having to reboot the machine so that it takes into account a new
      configuration.</t>

      <t>Once modifications have taken place, the Kernel must be recompiled so
      that the new TCP options are taken into account.</t>

      <t>Kernel modifications and recompilation have been done and tested
      successfully on Fedora and Debian Linux distributions, on different
      kernel versions.</t>

      <t>The following configuration options are supported:<?rfc subcompact="yes" ?><list
          style="symbols">
          <t>Enable/Disable injecting the TCP Option</t>

          <t>Support HOST_ID WING, HOST_ID BOUCADAIR and HOST_ID_ENABLED</t>

          <t>When the HOST_ID TCP option is supported, the information to be
          injected is configurable:<list style="symbols">
              <t>Source IPv6 address or the first 56 bits of the address</t>

              <t>Source IPv4 address</t>

              <t>Source port number</t>

              <t>Source IPv4 address and Source port</t>

              <t>IPv6 address or the first 56 bits of the B4 when DS-Lite is
              activated</t>
            </list></t>
        </list></t>

      <t><?rfc subcompact="no" ?></t>
    </section>

    <section title="Testbed Setup &amp; Configuration">
      <t>The setup of three testbed configurations have been considered:<?rfc subcompact="yes" ?><list
          style="numbers">
          <t>HOST_ID TCP option is injected by the host itself. No CGN is
          present in the forwarding path (<xref
          target="first_config"></xref>)</t>

          <t>HOST_ID TCP option is injected by hosts deployed behind a HTTP
          proxy. No CGN is present in the forwarding path (<xref
          target="second_config"></xref>)</t>

          <t>HOST_ID TCP option is injected by the DS-Lite AFTR element (<xref
          target="third_config"></xref>).</t>
        </list></t>

      <t><?rfc subcompact="no" ?></t>

      <t><figure align="center" anchor="first_config"
          title="Testbed setup: No Proxy and no CGN">
          <artwork>+-----------+    
|  HOST_1   |----+
| NO-Option |    |
+-----------+    |      +--------------------+        +------------+
                 |      |                    |--------|  server 1  |        
+-----------+    |      |                    |        +------------+
|  HOST_2   |----|------|      INTERNET      |              :::
| (HOST_ID) |    |      |                    |        +------------+     
+-----------+    |      |                    |--------|  server n  |
                 |      +--------------------+        +------------+
+-----------+    |
|  Local    |----+
|  Server   |       
+-----------+       </artwork>
        </figure></t>

      <t></t>

      <t><figure align="center" anchor="second_config"
          title="Testbed setup: HTTP Proxy">
          <artwork>+-----------+    
|  HOST_1   |----+
| NO-Option |    |
+-----------+    |        +--------------------+      +------------+
                 |        |                    |------|  server 1  |        
+-----------+  +-----+    |                    |      +------------+
|  HOST_2   |--|PROXY|----|      INTERNET      |            ::
| (HOST_ID) |  +-----+  | |                    |      +------------+     
+-----------+           | |                    |------|  server n  |
                        | +--------------------+      +------------+
+-----------+           |
|  Local    |-----------+
|  Server   |       
+-----------+       </artwork>
        </figure></t>

      <t><figure align="center" anchor="third_config"
          title="DS-Lite CGN Environment">
          <artwork>                                        +----...----+   +----------+
+----+   |           |                  |           |---| server 1 |
|HOST|---|  +----+   |   +------+   |   |           |   +----------+
+----+   |--| B4 |---|---| AFTR |---|---| INTERNET  |        ::
            +----+   |   +------+   |   |           |   +----------+
                     |                  |           |---| server n |
                                        +----...----+   +----------+</artwork>
        </figure></t>

      <t><xref target="first_config"></xref> and <xref
      target="second_config"></xref> are used to assess the behavior of the
      top 100,000 sites when a HOST_ID option is enabled and to evaluate the
      impact of the option on both the session establishment delay and the
      success ratio.</t>

      <t>On the other hand, the configuration shown in <xref
      target="third_config"></xref> will be used to evaluate the impact on the
      CGN performances when HOST_ID TCP option is injected by the CGN.</t>

      <section title="Automated TCP Traffic Generator">
        <t>A Python-encoded robot has been used as the traffic generator. The
        robot automates the retrieval of HTTP pages identified by URLs, and
        returns different connection information. The retrieval of pages is
        based upon Pycurl, a Python interface of libcurl. Libcurl is an URL
        transfer library that supports different protocols (e.g., HTTP,
        FTP).</t>

        <t>The robot consists of two programs:<?rfc subcompact="yes" ?></t>

        <t><list style="numbers">
            <t>The first one takes an URL as a input parameter, performs the
            DNS lookup and then tries to connect to the corresponding machine.
            It returns either different time values and connection status or
            an error message with the source of the error in case of
            connection failure (e.g., DNS error). The TCP connection
            establishment time is calculated as the difference between the
            CONNECT_TIME and NAMELOOKUP_TIME where: <list style="symbols">
                <t>NAMELOOKUP_TIME is the time it took from the start until
                the name resolution is completed.</t>

                <t>CONNECT_TIME is the time it took from the start until the
                connection to the remote host (or proxy) is completed.</t>
              </list></t>

            <t>The second program aims to increase efficiency and speed of the
            testing by using a multi-thread technique. It takes the number of
            threads and an input file listing URLs as parameters. This program
            prints URLs to an output file with the corresponding connection
            time. If something wrong happened so that the connection failed,
            the program returns an error message with the corresponding error
            type.</t>
          </list></t>
      </section>

      <section title="Testing Methodology and Procedure">
        <t>The testing is done using two machines, one that supports the
        HOST_ID TCP options and the other that does not. The second machine is
        used as a reference for the measurements. Testing is performed in
        parallel on the two machines that are directly connected to the
        Internet. For each HOST_ID TCP option, the test is repeated many
        times. The cycle is repeated in different days. Then results are
        grouped into tables where averages are calculated. The comparison
        between the different HOST_ID options results is made by using the
        no-option testing results as a reference.</t>

        <t>Testing was also performed behind a proxy (<xref
        target="second_config"></xref>) to evaluate the impact of embedding
        the HOST_ID TCP options on the connection establishment time when a
        proxy is in the path. When a proxy is present, the connection delay is
        impacted (the delay is calculated for the connection between the host
        and the proxy).</t>

        <t>Tests have been conducted from hosts:<list style="numbers">
            <t>Connected to an enterprise network</t>

            <t>In a lab behind a firewall</t>

            <t>Connected to two (2) commercial ISP networks</t>
          </list></t>
      </section>

      <section title="Check HOST_ID TCP Options are Correctly Injected">
        <t>To check whether the HOST_ID TCP options are correctly injected,
        the local server in <xref target="first_config"></xref> is configured
        to be reachable from Internet. Packets conveying the HOST_ID TCP
        options are sent from a host supporting the options. These packets are
        used without alteration by the local server.</t>

        <t>This configuration confirms the packets sent to remote servers
        conveys HOST_ID TCP options.</t>
      </section>

      <section title="Top Site List">
        <t>The Alexa top sites list has been used to conduct the HTTP
        tests.</t>

        <t>Anonymous FTP sites list from ftp-sites.org has been used to
        conduct the FTP tests.</t>
      </section>
    </section>

    <section anchor="results" title="Experimentation Results">
      <t>Various combinations of the HOST_ID TCP options have been
      tested:<list style="numbers">
          <t>HOST_ID_WING</t>

          <t>HOST_ID_WING has also been adapted to include 32 bits and 64 bits
          values. No particular impact on session establishment has been
          observed.</t>

          <t>HOST_ID_BOUCADAIR (source port)</t>

          <t>HOST_ID_BOUCADAIR (IPv4 address)</t>

          <t>HOST_ID_BOUCADAIR (source port:IPv4 address)</t>

          <t>HOST_ID_BOUCADAIR (IPv6 Prefix)</t>

          <t>HOST_ID_ENABLED</t>
        </list></t>

      <t>Both the success ratio and the average time to establish the TCP
      session are reported below.</t>

      <t></t>

      <section anchor="http_results" title="HTTP Experimentation Results">
        <t>Tests have been conducted from hosts:</t>

        <t><list style="numbers">
            <t>Connected to an enterprise network</t>

            <t>Connected to two commercial ISP networks</t>

            <t>In a lab behind a firewall</t>
          </list></t>

        <section anchor="Configuration1"
                 title="Configuration 1: Connected to an enterprise network">
          <t>The results show that the success ratio for establishing TCP
          connection with legacy servers is almost the same for all the
          HOST_ID options as shown in <xref
          target="topxxxxxx_enterprise"></xref>, <xref
          target="topxxxx00_wing"></xref> and <xref
          target="topxxxx00_boucadair"></xref>.</t>

          <section title="Results">
            <t></t>

            <figure align="center" anchor="topxxxxxx_enterprise"
                    title="Cumulated Success ratio (HOST_ID_WING)">
              <artwork>           +--------------+--------------+--------------+
           |  NO-OPTION   |   O-WING     | Failure Ratio|
-----------+--------------+--------------+--------------+
Top10      |  100,00000%  |  100,00000%  |   0,00000%   |
Top100     |  100,00000%  |  100,00000%  |   0,00000%   |
Top200     |  100,00000%  |  100,00000%  |   0,00000%   |
Top300     |   99,66667%  |   99,66667%  |   0,00000%   |
Top400     |   99,50000%  |   99,50000%  |   0,00000%   |
Top500     |   99,40000%  |   99,40000%  |   0,00000%   |
Top600     |   99,50000%  |   99,50000%  |   0,00000%   |
Top700     |   99,57143%  |   99,57143%  |   0,00000%   |
Top800     |   99,50000%  |   99,50000%  |   0,00000%   |
Top900     |   99,44444%  |   99,44444%  |   0,00000%   |
Top1000    |   99,50000%  |   99,50000%  |   0,00000%   |
Top2000    |   99,35000%  |   99,30000%  |   0,05000%   |
Top3000    |   99,10000%  |   99,06667%  |   0,03333%   |
Top4000    |   99,10000%  |   99,05000%  |   0,05000%   |
Top5000    |   99,14000%  |   99,10000%  |   0,04000%   |
Top6000    |   99,21667%  |   99,18333%  |   0,03333%   |
Top7000    |   99,25714%  |   99,21429%  |   0,04286%   |
Top8000    |   99,15000%  |   99,10000%  |   0,05000%   |
Top9000    |   99,16667%  |   99,12222%  |   0,04444%   |
Top10000   |   99,16000%  |   99,12000%  |   0,04000%   |
Top20000   |   98,50500%  |   98,44000%  |   0,06500%   |
Top30000   |   98,21667%  |   98,11667%  |   0,10000%   |
Top40000   |   98,10750%  |   98,00750%  |   0,10000%   |
Top50000   |   98,00000%  |   97,89800%  |   0,10200%   |
Top60000   |   97,95167%  |   97,85000%  |   0,10167%   |
Top70000   |   97,88857%  |   97,78857%  |   0,10000%   |
Top80000   |   97,84500%  |   97,74875%  |   0,09625%   |
Top90000   |   97,79444%  |   97,69889%  |   0,09556%   |
Top100000  |   97,75100%  |   97,64800%  |   0,10300%   |
-----------+--------------+--------------+--------------+
</artwork>
            </figure>

            <figure align="center" anchor="topxxxx00_wing"
                    title="TopX000 Success Ratio (HOST_ID_WING)">
              <artwork>             +-----------+-----------+--------------+
             | NO-OPTION |  O-WING   | Failure Ratio|
-------------+-----------+-----------+--------------+
1-100        |  100,00%  |  100,00%  |     0,00%    |
101-200      |  100,00%  |  100,00%  |     0,00%    |
201-300      |   99,00%  |   99,00%  |     0,00%    |
301-400      |   99,00%  |   99,00%  |     0,00%    |
401-500      |   99,00%  |   99,00%  |     0,00%    |
501-600      |  100,00%  |  100,00%  |     0,00%    |
601-700      |  100,00%  |  100,00%  |     0,00%    |
701-800      |   99,00%  |   99,00%  |     0,00%    |
801-900      |   99,00%  |   99,00%  |     0,00%    |
901-1000     |  100,00%  |  100,00%  |     0,00%    |
1-1000       |   99,50%  |   99,50%  |     0,00%    |
1001-2000    |   99,20%  |   99,10%  |     0,10%    |
2001-3000    |   98,60%  |   98,60%  |     0,00%    |
3001-4000    |   99,10%  |   99,00%  |     0,10%    |
4001-5000    |   99,30%  |   99,30%  |     0,00%    |
5001-6000    |   99,60%  |   99,60%  |     0,00%    |
6001-7000    |   99,50%  |   99,40%  |     0,10%    |
7001-8000    |   98,40%  |   98,30%  |     0,10%    |
8001-9000    |   99,30%  |   99,30%  |     0,00%    |
9001-10000   |   99,10%  |   99,10%  |     0,00%    |
10001-20000  |   97,85%  |   97,76%  |     0,90%    |
20001-30000  |   97,64%  |   97,47%  |     1,70%    |
30001-40000  |   97,78%  |   97,68%  |     1,00%    |
40001-50000  |   97,57%  |   97,46%  |     1,10%    |
50001-60000  |   97,71%  |   97,61%  |     1,00%    |
60001-70000  |   97,61%  |   97,52%  |     0,90%    |
70001-80000  |   97,44%  |   97,37%  |     0,70%    |
80001-90000  |   97,39%  |   97,30%  |     0,90%    |
90001-100000 |   97,36%  |   97,19%  |     1,70%    |
-------------+-----------+-----------+--------------+
</artwork>
            </figure>

            <figure align="center" anchor="topxxxx00_boucadair"
                    title="TopX000 Success Ratio (HOST_ID_BOUCADAIR)">
              <artwork>             +-----------+-----------+--------------+
             | NO-OPTION |O-BOUCADAIR| Failure Ratio|
-------------+-----------+-----------+--------------+
1-100        |  100,00%  |  100,00%  |     0,00%    |
101-200      |  100,00%  |  100,00%  |     0,00%    |
201-300      |   99,00%  |   99,00%  |     0,00%    |
301-400      |   99,00%  |   99,00%  |     0,00%    |
401-500      |   99,00%  |   99,00%  |     0,00%    |
501-600      |  100,00%  |  100,00%  |     0,00%    |
601-700      |  100,00%  |  100,00%  |     0,00%    |
701-800      |   99,00%  |   99,00%  |     0,00%    |
801-900      |   99,00%  |   99,00%  |     0,00%    |
901-1000     |  100,00%  |  100,00%  |     0,00%    |
0-1000       |   99,50%  |   99,50%  |     0,00%    |
1001-2000    |   99,20%  |   99,10%  |     0,10%    |
2001-3000    |   98,60%  |   98,60%  |     0,00%    |
3001-4000    |   99,30%  |   99,30%  |     0,00%    |
5001-6000    |   99,60%  |   99,60%  |     0,00%    |
6001-7000    |   99,50%  |   99,40%  |     0,10%    |
7001-8000    |   98,40%  |   98,30%  |     0,10%    |
8001-9000    |   99,30%  |   99,20%  |     0,10%    |
9001-10000   |   99,10%  |   99,10%  |     0,00%    |
10001-20000  |   97,85%  |   97,76%  |     0,90%    |
20001-30000  |   97,64%  |   97,46%  |     1,80%    |
30001-40000  |   97,78%  |   97,66%  |     1,20%    |
40001-50000  |   97,57%  |   97,46%  |     1,10%    |
50001-60000  |   97,71%  |   97,61%  |     1,00%    |
60001-70000  |   97,61%  |   97,51%  |     1,00%    |
70001-80000  |   97,44%  |   97,36%  |     0,80%    |
80001-90000  |   97,39%  |   97,30%  |     0,90%    |
90001-100000 |   97,36%  |   97,19%  |     1,70%    |
-------------+-----------+-----------+--------------+
</artwork>
            </figure>
          </section>

          <section title="Analysis">
            <t><list style="symbols">
                <t>For the top 100,000 sites, connection failures occur for
                2249 HTTP sites. These failures were reported as being caused
                by DNS issues (servers not mounted), connection timeouts
                (servers down&hellip;), connection resets by peers, connection
                problems and empty replies from servers. The 2249 failures
                occur, whether HOST_ID options are injected or not.</t>

                <t>When any HOST_ID TCP option is conveyed, 103 servers did
                not respond; however when no option is injected, all these
                servers responded normally.</t>

                <t>Same results were obtained for HOST_ID_WING and
                HOST_ID_ENABLED.</t>

                <t>Same results were obtained for all the HOST_ID_BOUCADAIR
                options (source port, IPv6 prefix, etc.).</t>
              </list></t>

            <t>When HOST_ID_BOUCADAIR is enabled, six (6) additional servers
            did not respond:<list style="symbols">
                <t>Three (3) servers (www.teufel.de &ndash; www.1001fonts.com
                &ndash; www.sigur-ros.co.uk) did not respond to the SYN
                packets sent by the host.</t>

                <t>Three (3) servers (www.lawyers.com, www.lexis.com,
                www.nexis.com) responded with "strange" SYN/ACK packets with
                same TCP options length including a part of the HOST_ID
                options that was sent. This part of HOST_ID option caused an
                erroneous SYN/ACK packet received by the host: in fact the
                second byte of the HOST_ID part is considered as its length
                and this length does not really fit with the real length of
                the part. So the machine does not respond back to the server
                with an ACK packet. This is why we have no response for these
                servers.</t>
              </list></t>

            <t>When HOST_ID_WING or HOST_ID_ENABLED is enabled, also strange
            SYN/ACKs were received by the host but no errors in these packets
            (a long series of NOP options). This justifies the connection
            success for these 2 options.</t>

            <t>The results show that including a HOST_ID TCP option does not
            systematically imply an extra delay for the establishment of the
            TCP session. Based on the average of session establishment with
            the top 100 000 sites, the following results have been
            obtained:<list style="symbols">
                <t>delay(HOST_ID_WING) &lt; delay(NO_OPTION): 42,55 %</t>

                <t>delay(HOST_ID_BOUCADAIR ) &lt; delay(NO_OPTION): 48,16
                %</t>

                <t>delay(HOST_ID_ENABLED) &lt; delay(NO_OPTION): 51,28 %</t>
              </list></t>
          </section>
        </section>

        <section title="Configuration 2: In a lab behind a firewall">
          <t>When a HTTP proxy is in the path, the injection of HOST_ID TCP
          option does not impact the success ratio. This is due to that the
          HTTP proxy strips the HOST_ID TCP options; these options are not
          leaked to remote Internet servers. The testing has been done by
          observing packets received to a server installed with a public IP
          address (no HOST_ID options were seen in the received SYN
          packets).</t>
        </section>

        <section title="Configuration 3: Connected to two commercial ISP networks">
          <t>The results obtained when testing was performed by connecting to
          two ISP networks confirmed the results obtained in the testing
          described in <xref target="Configuration1"></xref></t>
        </section>

        <section title="Additional Results">
          <t>In one of our testing for top 1000 sites, when padding was badly
          implemented for HOST_ID_BOUCADAIR (padding was implemented as a
          prefix so option&rsquo;s Length does not correspond to the real
          length because the padding was not counted), we got for
          configuration(1) in the lab and for one of the ISP the following
          results:</t>

          <t><figure align="center"
              title="Cumulated Success ratio (HOST_ID_Boucadair with wrong padding)">
              <artwork>        +-------------+-------------+--------------+
        | No-Option   | O-BOUCADAIR | Failure Ratio|
--------+-------------+-------------+--------------+
Top10   | 100,00000%  | 100,00000%  |   0,00000%   |
Top100  | 100,00000%  | 100,00000%  |   0,00000%   |
Top200  | 100,00000%  | 100,00000%  |   0,00000%   |
Top300  | 100,00000%  |  99,66667%  |   0,33333%   |
Top400  |  99,75000%  |  99,00000%  |   0,75000%   |
Top500  |  99,80000%  |  99,00000%  |   0,80000%   |
Top600  |  99,83333%  |  98,66667%  |   1,16667%   |
Top700  |  99,85714%  |  98,14286%  |   1,71429%   |
Top800  |  99,75000%  |  98,00000%  |   1,75000%   |
Top900  |  99.66667%  |  97,33333%  |   2,33333%   |
Top1000 |  99,70000%  |  97,10000%  |   2,60000%   |
--------+-------------+-------------+--------------+

</artwork>
            </figure></t>

          <t>The results for HOST_ID_WING for all three configurations are the
          same as Section 6 (this option was correctly coded). Results
          obtained for HOST_ID_BOUCADAIR are not the same.</t>

          <t>For the configuration (2) behind a firewall, we did not face any
          rejection because of parsing the TCP options (the HOST_ID options
          were retrieved from the packet).</t>
        </section>

        <section title="Analysis">
          <t>Configuration (1) in Lab and for one of the two CPEs lead to the
          results because 2.6% of these 1000 servers perform parsing
          validation for the received options so when the bad
          HOST_ID_BOUCADAIR option is sent, 2.6% of the servers treat the
          received SYN packets as erroneous packets and discard them.</t>

          <t>For the connection behind the second ISP, we didn't get a
          response for any of the servers. After investigation, the reason was
          that the Box validates the received packets before sending them to
          the Internet. The erroneous SYN packets holding badly encoded
          options (HOST_ID_BOUCADAIR in this case) were dropped and no
          connection was established. On the other hand, the other box did not
          validate options length for received packets before sending them to
          the Internet.</t>
        </section>
      </section>

      <section title="FTP">
        <t>Various combinations of the HOST_ID TCP options have been
        tested:</t>

        <t><list style="numbers">
            <t>HOST_ID_WING</t>

            <t>HOST_ID_BOUCADAIR (source port)</t>

            <t>HOST_ID_BOUCADAIR (source port:IPv4 address)</t>
          </list></t>

        <t>A list of 5591 FTP servers has been used to conduct these testings.
        Among this list, only 2045 were reachable:<list style="symbols">
            <t>Failure to reach 942 FTP servers due to connection timeout</t>

            <t>Failure to reach 1286 FTP servers due to DNS errors</t>

            <t>Failure to reach 717 FTP servers because access was denied</t>

            <t>Could not connect to 500 FTP servers</t>

            <t>Response reading failed for 81 servers</t>

            <t>Bad response from server for 20 servers</t>
          </list></t>

        <t>When HOST_ID TCP options are injected, 9 errors are observed
        (connection timeout).</t>

        <t><xref target="ftpservers"></xref> and <xref
        target="first_ftpservers"></xref> provide more data about the error
        distribution.</t>

        <t><figure align="center" anchor="ftpservers"
            title="Cumulated Success Ratio (FTP)">
            <artwork>           +-----------+-----------+--------------+
           |    NOB    |  HOST_ID  | Failure Ratio|
-----------+-----------+-----------+--------------+
1-100      |    100%   |   100%    |    0,000%    |
101-200    |    100%   |    99%    |    1,000%    |
201-300    |    100%   |    99%    |    1,000%    |
301-400    |    100%   |   100%    |    0,000%    |
401-500    |    100%   |   100%    |    0,000%    |
501-600    |    100%   |   100%    |    0,000%    |
601-700    |    100%   |   100%    |    0,000%    |
701-800    |    100%   |   100%    |    0,000%    |
801-900    |    100%   |    99%    |    1,000%    |
901-1000   |    100%   |    99%    |    1,000%    |
1001-2000  |    100%   |  99,5%    |    0,500%    |
2000-2045  |    100%   |   100%    |    0,000%    |
-----------+-----------+-----------+--------------+ 

</artwork>
          </figure></t>

        <t><figure align="center" anchor="first_ftpservers"
            title="FirstXXX FTP Servers">
            <artwork>          +-----------+-----------+--------------+
          |    NOB    |  HOST_ID  | Failure Ratio|
----------+-----------+-----------+--------------+
first 10  |  100,000% | 100,000%  |    0,000%    | 
first 100 |  100,000% | 100,000%  |    0,000%    |
first 200 |  100,000% |  99,500%  |    0,500%    |
first 300 |  100,000% |  99,333%  |    0,667%    |
first 400 |  100,000% |  99,500%  |    0,500%    |
first 500 |  100,000% |  99,600%  |    0,400%    |
first 600 |  100,000% |  99,667%  |    0,333%    |
first 700 |  100,000% |  99,714%  |    0,286%    |
first 800 |  100,000% |  99,750%  |    0,250%    |
first 900 |  100,000% |  99,667%  |    0,333%    |
first 1000|  100,000% |  99,600%  |    0,400%    |
first 2000|  100,000% |  99,550%  |    0,450%    |
first 2045|  100,000% |  99,560%  |    0,440%    |
----------+-----------+-----------+--------------+

</artwork>
          </figure></t>

        <t>The results show that including a HOST_ID TCP option does not
        systematically imply an extra delay for the establishment of the TCP
        session with remote FTP servers. Based upon the average of the session
        establishment with the 2045 FTP sites, the following results have been
        obtained:</t>

        <t><list style="symbols">
            <t>delay(HOST_ID_WING) &lt; delay(NO_OPTION): 49,36585 %</t>

            <t>delay(HOST_ID_BOUCADAIR (source port:IPv4 address)) &lt;
            delay(NO_OPTION): 48,41076%</t>

            <t>delay(HOST_ID_BOUCADAIR (source port)) &lt; delay(NO_OPTION):
            48,43902 %</t>
          </list></t>
      </section>

      <section title="SSH">
        <t>The secure shell service has been tested between a host and a SSH
        server connected to the same network.</t>

        <t>SSH connections have been successfully established with the server
        for all the HOST_ID TCP options. Same results were obtained using
        configuration (1) and configuration (2).</t>
      </section>

      <section title="Telnet">
        <t>Telnet sessions have been successfully initiated for all HOST_ID
        TCP options with a server (the CGN used in <xref
        target="third_config"></xref>).<?rfc subcompact="yes" ?></t>
      </section>
    </section>

    <section title="AFTR Module Modifications">
      <t>This section highlights the support the HOST_ID functionalities in
      the AFTR element of the DS-Lite model (<xref
      target="third_config"></xref>) and presents the testing results in order
      to conclude about the HOST_ID TCP options impacts on the performance of
      the CGN.</t>

      <t>We used ISC AFTR implementation.</t>

      <section title="Specification">
        <t>All privately-addressed IPv4 packets sent from DS-Lite serviced
        hosts go through an AFTR device where an isc_aftr daemon program is
        responsible for establishing the tunnel, configuring network
        interfaces and processing received packets.</t>

        <t>The aftr.c source code controls all functionalities to be included
        or modified on packets received by the CGN, e.g., patching TCP MSS
        values, fix MTU, etc.</t>

        <t>In order to activate/deactivate such functionalities, the
        corresponding parameters can be configured in a specific configuration
        file called "aftr.conf". In this file, other parameters are
        configured, e.g., the IPv6 addresses assigned to the tunnel endpoint
        and the global IPv4 address pool maintained by the CGN.</t>

        <t>To support the injection of HOST_ID TCP options, "aftr.c" must be
        updated to inject, retrieve or verify the HOST_ID options depending on
        the HOST_ID parameters defined in "aftr.conf" file. Four HOST_ID
        parameters are defined in the configuration file: <list
            style="numbers">
            <t>hostid: to enable the injection, retrieval, matching... of
            HOST_ID options</t>

            <t>hostid_wing: to enable injection/verification of HOST_ID_WING -
            to disable injection or to remove HOST_ID_WING</t>

            <t>hostid_boucadair: to enable injection/verification of
            HOST_ID_BOUCADAIR - to disable injection or to remove
            HOST_ID_BOUCADAIR</t>

            <t>hostid_enabled: to enable or disable HOST_ID_ENABLED
            injection</t>
          </list></t>

        <t>hostid, hostid_wing and hostid_enabled can be simply enabled or
        disabled. hostid_boucadair can be disabled or enabled with the
        corresponding Origin as HOST_ID data can be: <list style="symbols">
            <t>Source Port Number</t>

            <t>Source IPv4 Address</t>

            <t>Source IPv4 Address + Source Port Number</t>

            <t>56 bits of Tunnel Softwire IPv6 Source Address.</t>
          </list></t>

        <t>Based on different HOST_ID parameters, the "aftr.c" code has been
        modified to control HOST_ID options; the AFTR is able to:<list
            style="symbols">
            <t>Inject the enabled HOST_ID TCP option if it is not already
            present in the packet</t>

            <t>Retrieve an existing HOST_ID TCP option if this option is not
            enabled</t>

            <t>Check an existing HOST_ID option&rsquo;s content if it is
            enabled; if the content&rsquo;s verification failed, the AFTR
            replaces the HOST_ID contents with the suitable information</t>
          </list></t>

        <t>The implementation takes into consideration the SYN mode for all
        the HOST_ID options (even for HOST_ID_enabled). The Support of
        HOST_ID_BOUCADAIR in the ACK mode needs implementation on the server's
        side and since both Enabled and Boucadair&rsquo;s options have been
        tested and no impact observed; the ACK mode should not imply any
        complication in implementation or impact on the performance.</t>
      </section>

      <section title="Verification">
        <t>The verification of HOST_ID implementation in the CGN has taken
        place using the testbed setup shown in <xref
        target="third_config"></xref>. The host used in this testing is a
        modified Linux machine that can inject HOST_ID options. The objective
        of the testing is to verify the different functionalities implemented
        in the AFTR. Verification has occurred using a local server where all
        the received packets were observed to make sure that the content of
        the HOST_ID fields is consistent with the enabled option.</t>

        <t>The testing consists in observing the SYN packets (as SYN mode is
        supported) sent by the host and in comparing these packets to those
        received by the server. Different combinations of HOST_ID options sent
        by the host and HOST_ID configured options at the CGN level have been
        used.</t>

        <t>The results show that once the host sends packets without any
        HOST_ID option injected, the SYN packets received by the server
        contain the correct option that has been enabled by the CGN (if any).
        Once HOST_ID_WING or HOST_ID_BOUCADAIR are injected by the host, if
        the hostid parameter in aftr.conf is enabled, the enabled (in
        "aftr.conf") HOST_ID option will be injected if not already present,
        or else its content will be verified and corrected (if wrong); the
        other disabled option will be discarded if it has already been sent by
        the host.</t>

        <t>One additional case has been tested when both Wing&rsquo;s and
        Boucadair&rsquo;s HOST_ID options are sent by the host, the contents
        of the enabled option are checked and corrected (if wrong), the other
        option is retrieved from the packet. The two options are dropped from
        the packet if they are both disabled.</t>

        <t>The testing has been repeated for all the HOST_ID options sent by
        the host and enabled by the CGN. Verification also occurred for
        HOST_ID_ENABLED option.</t>
      </section>

      <section title="CGN Performance Testing">
        <t>To conclude about the impact of using HOST_ID, a commercial testing
        product has been used. This tool supports multiple application
        protocols such as HTTP and FTP for both IPv4 and IPv6 (including
        encapsulation). The DS-Lite model can be built directly from a port of
        this product: IPv4 packets are directly encapsulated in an IPv6
        tunnel; the client&rsquo;s port emulates hosts and B4 elements at the
        same time. This port is directly connected to the AFTR tunnel
        endpoint. The AFTR&rsquo;s IPv4 interface is connected to the testing
        product server side where servers are assigned IPv4 addresses.</t>

        <t>The testbed setup of this testing is shown in <xref
        target="IXIA_testbed"></xref>:</t>

        <t><figure align="center" anchor="IXIA_testbed"
            title="Platform Testbed">
            <artwork>clients' port      +------------------+      servers' side
+------------------+  Testing Tool    +------------------+
|                  +------------------+                  |
|                                                        |
|                                                        |
|IPv4-in-IPv6 tunnel                                     |
|                                                        |
|                                                        |
|                  +------------------+                  |
+------------------+       AFTR       +------------------+
                   +------------------+</artwork>
          </figure></t>

        <section title="Configuration">
          <t>At the IP level, the testing client port was configured with IPv6
          addresses representing the B4. The testing tool also supports the
          DS-Lite &ldquo;level&rdquo; where the number of clients connected to
          each B4 and their addresses are configured. The AFTR address is
          defined at this level.</t>

          <t>In the current testing, the total number of B4 elements is 5000
          behind; One client is connected to each B4 (in total, 5000 clients
          are configured). However, the number of active users varies from 10
          to 100, 500, 1000 and 10,000 during each testing simulation.</t>

          <t>From the server standpoint, five servers have been assigned IPv4
          addresses. These servers support HTTP and FTP traffic. For each
          HOST_ID TCP option, the testing was repeated for a different number
          of active users (N=10, 100, 500, 1000 and 10,000) and for HTTP and
          FTP traffic.</t>

          <t>The HOST_ID options are injected by the CGN.</t>
        </section>

        <section title="HTTP Testing">
          <t>The testing duration was about 50 seconds during which the number
          of active users varies as a function of time: during the first 10s,
          the number of active users reaches the maximum and remains the same
          for the next 20 s. Then it decreases to zero during the next
          20s.</t>

          <t>Hereafter are provided some testing statistics providing some
          details about connections&rsquo; success ratio, latency and other
          information that can be useful to evaluate the impact of HOST_ID on
          the CGN.</t>

          <figure align="center" anchor="ixia-10" title="Results HTTP (N=10)">
            <artwork>                             +-------+-------+------------+---------+
                             |No-Opt |O-WING |O-BOUCADAIR3|O-ENABLED|
-----------------------------+-------+-------+------------+---------+
TCP connection established   | 1378  |  1267 |    1363    |  1369   |
TCP SYN SENT                 | 1378  |  1267 |    1363    |  1369   |
Success Ratio                |  100  |   100 |     100    |   100   |
TCP Retries                  |  193  |   193 |     197    |   177   |
TCP timeouts                 |  140  |   136 |     152    |   111   |
HTTP connect' latencies t=20s|  0,11 |  0,21 |    0,20    |   0,1   |
                        t=40s|  0,40 |  0,50 |    0,50    |  0,45   |
                        t=60s|  0,60 |  0,60 |    0,50    |   0,6   |
HTTP throughput received     | 46,47 | 45,31 |   45,88    |  46,12  |
TCP Connections Established/s| 20,29 | 19,88 |   20,06    |  20,18  |
-----------------------------+-------+-------+------------+---------+
</artwork>
          </figure>

          <figure align="center" anchor="ixia-100"
                  title="Results HTTP (N=100)">
            <artwork>                             +-------+-------+------------+---------+
                             |No-Opt |O-WING |O-BOUCADAIR3|O-ENABLED|
-----------------------------+-------+-------+------------+---------+
TCP connection established   |  1662 |  1739 |    1813    |   1679  |
TCP SYN SENT                 |  1718 |  1770 |    1819    |   1729  |
Success Ratio                |    96 |    98 |      99    |     97  |
TCP Retries                  |  1577 |  1569 |    1783    |   1576  |
TCP timeouts                 |   798 |   806 |     934    |    808  |
HTTP connect' latencies t=20s|  1,70 |  2,00 |    1,90    |   1,80  |
                        t=30s|  3,30 |  2,40 |    2,25    |   3,30  |
                        t=40s|  4,20 |  3,70 |    3,75    |   4,00  |
                        t=50s|  5,00 |  4,80 |    4,50    |   5,00  |                      
HTTP throughput received     | 47,56 | 46,65 |   48,59    |  48,06  |
TCP Connections Established/s| 20,94 | 20,53 |   21,35    |  21,19  |
-----------------------------+-------+-------+------------+---------+
</artwork>
          </figure>

          <figure align="center" anchor="ixia-1000"
                  title="Results HTTP (N=1000)">
            <artwork>                             +-------+-------+------------+---------+
                             |No-Opt |O-WING |O-BOUCADAIR3|O-ENABLED|
-----------------------------+-------+-------+------------+---------+
TCP connection established   |  1956 |  1923 |    1944    |   1873  |
TCP SYN SENT                 |  2088 |  2095 |    2137    |   1986  |
Success Ratio                |    93 |    91 |      90    |     94  |
TCP Retries                  |  2734 |  2576 |    2453    |   2773  |
TCP timeouts                 |  1261 |  1110 |     995    |   1213  |
HTTP connect' latencies t=20s|  2,00 |  1,80 |    1,50    |   2,30  |
                        t=40s|  4,00 |  3,30 |    2,80    |   4,30  |
                        t=50s|  6,50 |  6,90 |    6,00    |   8,00  |                      
HTTP throughput received     | 70,19 | 65,00 |   69,81    |  67,13  |
TCP Connections Established/s| 30,69 | 28,41 |   30,50    |  29,38  |
-----------------------------+-------+-------+------------+---------+
</artwork>
          </figure>

          <figure align="center" anchor="ixia-10000"
                  title="Results HTTP (N=10000)">
            <artwork>                             +-------+-------+------------+---------+
                             |No-Opt |O-WING |O-BOUCADAIR4|O-ENABLED|
-----------------------------+-------+-------+------------+---------+
TCP connection established   |  1576 |  2000 |    1796    |   1998  |
TCP SYN SENT                 |  2088 |  2304 |    2009    |   2262  |
Success Ratio                |    87 |    86 |      89    |     88  |
TCP Retries                  |  3018 |  3101 |    3013    |   3148  |
TCP timeouts                 |  1167 |  1298 |    1213    |   1417  |
HTTP connect' latencies t=20s|  2,20 |  3,00 |    2,20    |   2,50  |
                        t=40s|  3,70 |  3,00 |    3,30    |   3,00  |
                        t=60s|  7,80 |  5,00 |    7,00    |   5,60  | 
                        t=70s|  9,60 |  6,00 |    8,70    |   7,00  |                     
HTTP throughput received     | 45,00 | 54,52 |   51,45    |  57,20  |
TCP Connections Established/s| 19,98 | 24,05 |   22,45    |  25,04  |
-----------------------------+-------+-------+------------+---------+
</artwork>
          </figure>

          <section title="Analysis of results">
            <t>The results clearly show that there is no impact of any HOST_ID
            option on session establishment success ratio, which is quite
            similar to the success ratio when packets do not hold options or
            when HOST_ID options are not used. Also, the number of established
            connections does not decrease when any HOST_ID option is injected,
            so the CGN performance is not impacted by the fact of adding the
            HOST_ID options.</t>

            <t>Another important factor to study is the latency that can be
            caused by HOST_ID injection. As the results show, the HTTP
            connection latency does not increase when HOST_ID is present if we
            compare the latency measured at different times for the different
            options.</t>

            <t>As a result, we clearly see that the average throughput
            measured at servers is identical, whether HOST_ID options are used
            or not (given that the number of session established is quite the
            same).</t>

            <t>Another consequence is that the TCP connection establishment
            rate at servers is not decreasing when a HOST_ID option is taken
            into account.</t>
          </section>

          <section title="Conclusion">
            <t>The results that have been obtained show that the performance
            of the CGN is not impacted by HOST_ID option injection even when
            the number of active users is high (10,000 is not negligible for a
            CGN run on an ordinary Linux machine): neither the session success
            ratio, nor the connection latency are impacted by the presence of
            the HOST_ID in SYN packets.</t>
          </section>
        </section>

        <section title="FTP">
          <t>The same testing was also run for FTP traffic. No particular
          impact on the performance of the CGN has been observed.</t>
        </section>
      </section>
    </section>

    <section title="IPTABLES: Modifications to Enforce Policies at the Server Side">
      <t></t>

      <section title="Overview">
        <t>iptables module has been updated to: <list style="symbols">
            <t>Log the content of TCP header with HOST_ID</t>

            <t>Drop packets holding a HOST_ID option</t>

            <t>Match any HOST_ID value</t>

            <t>Drop packets holding a specific HOST_ID value</t>

            <t>Strip any existing HOST_ID option</t>
          </list></t>

        <t>To support the above functionalities, modification should take into
        consideration stripping and matching options as described below:</t>

        <t><list style="numbers">
            <t>To strip the content of any existing HOST_ID option, the shared
            library "libxt_TCPOPTSTRIP.so" is modified: the HOST_ID_WING and
            HOST_ID_BOUCADAIR Kinds&rsquo; numbers were defined in the
            corresponding source file (libxt_TCPOPTSTRIP.c) with the
            corresponding names to enforce the iptables stripping rule. After
            enforcing these changes, the shared library must be created to
            replace the existing one and to allow applying the rule of
            stripping of the HOST_ID options. Once modifications have taken
            place, the following command should be used to strip the HOST_ID
            options: <figure>
                <artwork></artwork>
              </figure><figure align="center">
                <artwork>
iptables -t mangle -A INPUT -j TCPOPTSTRIP -p tcp --strip-options
 hostid_wing, hostid_boucadair                                    
        
</artwork>
              </figure></t>

            <t>In order to allow blocking, logging or applying any rule based
            upon the HOST_ID_WING or HOST_ID_BOUCADAIR values or range of
            values, a HOST_ID shared library must be created to:<list
                style="symbols">
                <t>Match HOST_ID options values entered in corresponding
                iptables rules,</t>

                <t>Print the HOST_ID rules on screen,</t>

                <t>Save values,</t>

                <t>Check the values (or range values) entered by user if they
                respect the limit values of these options.</t>
              </list></t>
          </list></t>

        <t><list style="empty">
            <t>In addition to the shared library: a specific Kernel module
            must be built to apply HOST_ID matching rules on the packets
            passing through the network interfaces. This module compares the
            HOST_ID options&rsquo; values held by packets with the HOST_ID
            values specified in the iptables rule table: when a packet matches
            the HOST_ID&rsquo;s range, the corresponding rule will be applied
            for this packet.</t>

            <t>The HOST_ID_WING matching value is 2 bytes long corresponding
            to HOST_ID_WING data.</t>

            <t>The HOST_ID_BOUCADAIR matching value is 8 bytes long
            corresponding to Lifetime + Origin field (1 byte) and HOST_ID_WING
            data (7 bytes).</t>
          </list></t>
      </section>

      <section title="Validation">
        <t>After having updated the iptables package with the suitable HOST_ID
        libraries and module, different HOST_ID policies should be applied and
        tested on the server side. The testing has been done using a simple
        configuration as shown <xref target="platform-hostid"> below
        </xref>.</t>

        <t><figure align="center" anchor="platform-hostid"
            title="Platform configuration: HOST_ID enforcing policies">
            <artwork>+--------+     +--------+     +--------+     +--------------+
|  HOST  |-----|   B4   |-----|  AFTR  |-----| local server |
+--------+     +--------+     +--------+     +--------------+
               </artwork>
          </figure>In the current testing, the AFTR supports HOST_ID options
        injection and iptables is modified at the local server. Logging
        recommendations consists of logging the IPv4 address and the HOST_ID
        option for each connection. Because HOST_ID is sent only in SYN
        packets (in the current implementation), only SYN packets will be
        logged to a specific file called iptables.log: the rsyslog.d must be
        updated with the corresponding command to log iptables messages into
        the specific file. Then rsyslog must be reloaded to apply changes.</t>
      </section>

      <section title="Stripping HOST_ID Options">
        <t>To strip a certain HOST_ID option, TCPOPTSTRIP rule must be called.
        Verification consists in logging and then checking the SYN packets and
        more precisely the corresponding TCP options, e.g., the following
        rules must be applied to strip HOST_ID_WING:</t>

        <t></t>

        <figure align="center">
          <artwork>
iptables -t mangle -A INPUT -j TCPOPTSTRIP -p tcp --strip-options 
 hostid_wing                                                      
iptables -A INPUT -j LOG --log-tcp-options -p tcp --syn           

</artwork>
        </figure>

        <t>The first rule applies for the mangle table. This table allows
        stripping HOST_ID_WING whose role is to remove option Wing&rsquo;s
        fields and replaces them by NOP options (NOP=No Operation=0x01). The
        second rule enables the logging of SYN packets with the corresponding
        TCP options.</t>

        <t>After applying these rules (to strip and log HOST_ID_WING) on the
        local server, we tried to access the server&rsquo;s HTTP pages from
        the host. The test is repeated several times and a different HOST_ID
        option is enabled by the AFTR each time.</t>

        <t>Then the "iptables.log" file is checked: only one SYN packet is
        logged with 4 bytes stripped out in the TCP option part. All IPv4
        packets going through the AFTR are also logged to be compared with the
        server&rsquo;s logged stripped packets.</t>

        <t>The comparison of the SYN packets logged by the server with the SYN
        packets sent by the AFTR clearly shows that the stripped option is
        HOST_ID_WING (all the header fields have been verified to ensure
        packet matching): the 4 bytes corresponding to the HOST_ID_WING option
        are replaced with NOP options (each one of the 4 bytes is equal to
        &lsquo;1&rsquo; = NOP).</t>

        <t>The same testing was repeated with HOST_ID_BOUCADAIR. The testing
        shows that the 10 bytes corresponding to this option were successfully
        stripped.</t>
      </section>

      <section title="Logging a Specific HOST_ID Option Value">
        <t>The remote server should be able to track connections coming from
        different clients; it should log packets headers including the HOST_ID
        TCP option information. This can be enforced using the following
        command:</t>

        <t></t>

        <figure align="center">
          <artwork>
iptables -t mangle -A INPUT -j TCPOPTSTRIP -p tcp --strip-options
 hostid_wing                                                     

</artwork>
        </figure>

        <t>Now, to log packets matching a certain HOST_ID value or range of
        values, the following rule must be applied:</t>

        <t></t>

        <figure align="center">
          <artwork>
iptables -A INPUT -p tcp --syn -m hostid --hostid_wing value[:value]
 -j LOG -log-tcp-options                                           

</artwork>
        </figure>

        <t>This command matches the HOST_ID_WING values held by SYN packets
        with the specific value [or the specific range of values] determined
        by the rule.</t>

        <t>The testing configuration in <xref target="platform-hostid"></xref>
        was used. The HOST_ID_WING data are implemented as being the last 16
        bits of the IPv4 private source address. When the HOST_ID_WING option
        is injected by the CGN, if the data field value corresponds to the
        iptables value (or range of values), the packet header is logged.
        Otherwise, if the HOST_ID_WING data is said out of range or the packet
        does not hold the HOST_ID_WING option, the packet is not logged.</t>

        <t>The same testing was repeated to match HOST_ID_BOUCADAIR data
        information:</t>

        <t></t>

        <figure align="center">
          <artwork>
iptables -A INPUT -p tcp --syn -m hostid --hostid_boucadair value
 [:value] -j LOG -log-tcp-options                                 

</artwork>
        </figure>

        <t>To verify the logging of a specific Boucadair&rsquo;s value, the
        Boucadair&rsquo;s options holding source IP address (Origin=2) or IPv6
        prefix (Origin=4) were tested successfully; these data values are
        fixed since they depend on the host&rsquo;s address. The two other
        options that include source port numbers (variable) cannot be tested
        by value because the port number varies for each connection.</t>

        <t>The iptables rules to log HOST_ID_BOUCADAIR range values have been
        verified successfully for all four HOST_ID_BOUCADAIR options.</t>
      </section>

      <section title="Dropping a specific HOST_ID Option Value">
        <t>The same testing methodology described in the previous section was
        repeated to drop packets matching HOST_ID value (or a range of
        values); e.g. to drop SYN packets matching a particular HOST_ID_WING
        value:</t>

        <t></t>

        <figure align="center">
          <artwork>
iptables -A INPUT -p tcp --syn -m hostid --hostid_wing value[:value]
 -j DROP
                                                             
</artwork>
        </figure>

        <t>In this testing, the HOST_ID_WING option is enabled at the CGN
        level. After applying the previous rule where Wing&rsquo;s specified
        value corresponds to the HOST_ID_WING data value (last 16 bits of the
        host&rsquo;s IPv4 source address), the hosts tries to access HTTP
        pages of the local server. It sends SYN packets but the server does
        not respond. Because this packet matches the iptables matching value,
        the corresponding rule is applied to the SYN packets: a SYN packet is
        dropped so the host does not receive any packet in return.</t>

        <t>When the host is still trying to retrieve pages by sending SYN
        packets, the command &lsquo;iptables &ndash;F&rsquo; will flush all
        iptables rules. Once applied, this command will let the host retrieve
        the required pages and the connection is therefore established
        successfully.</t>

        <t>The same testing was repeated for HOST_ID_BOUCADAIR options. SYN
        packets matching the corresponding rule value or range of values were
        dropped. Once iptables rules are flushed, connection is established
        normally.</t>
      </section>
    </section>

    <section anchor="IANA" title="IANA Considerations">
      <t>This document makes no request of IANA.</t>
    </section>

    <section anchor="Security" title="Security Considerations">
      <t>Security considerations discussed in <xref
      target="I-D.wing-nat-reveal-option"></xref> should be taken into
      account.</t>
    </section>

    <section title="Acknowledgments">
      <t>Many thanks to M. Meulle, P. Ng Tung and L. Valeyre for their help
      and review. Special thanks to C. Jacquenet for his careful review.</t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <?rfc include="reference.I-D.wing-nat-reveal-option"?>

      <?rfc include='reference.RFC.6250'?>
    </references>

    <references title="Informative References">
      <?rfc include="reference.I-D.boucadair-intarea-nat-reveal-analysis"?>

      <?rfc include='reference.RFC.6269'?>
    </references>
  </back>
</rfc>
