Network Working Group                                            E. Abdo
Internet-Draft                                              M. Boucadair
Intended status: Informational                                J. Queiroz
Expires: April 23, 2012                                   France Telecom
                                                        October 21, 2011


     HOST_ID TCP Options: Implementation & Preliminary Test Results
               draft-abdo-hostid-tcpopt-implementation-00

Abstract

   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.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on April 23, 2012.

Copyright Notice

   Copyright (c) 2011 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as



Abdo, et al.             Expires April 23, 2012                 [Page 1]


Internet-Draft      Report of NAT Reveal TCP Options        October 2011


   described in the Simplified BSD License.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Objectives . . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  NAT Reveal TCP Options: Overview . . . . . . . . . . . . . . .  3
     3.1.  HOST_ID_WING TCP Option  . . . . . . . . . . . . . . . . .  4
     3.2.  HOST_ID_BOUCADAIR TCP Option . . . . . . . . . . . . . . .  4
       3.2.1.  SYN Mode . . . . . . . . . . . . . . . . . . . . . . .  5
       3.2.2.  ACK Mode . . . . . . . . . . . . . . . . . . . . . . .  5
   4.  Overview of the Linux Kernel Modifications . . . . . . . . . .  6
   5.  Testbed Setup & Configuration  . . . . . . . . . . . . . . . .  7
     5.1.  Automated TCP Traffic Generator  . . . . . . . . . . . . .  8
     5.2.  Testing Methodology and Procedure  . . . . . . . . . . . .  9
     5.3.  Top Website List . . . . . . . . . . . . . . . . . . . . .  9
   6.  Experimentation Results  . . . . . . . . . . . . . . . . . . . 10
     6.1.  HTTP Experimentation Results . . . . . . . . . . . . . . . 10
       6.1.1.  Proxy  . . . . . . . . . . . . . . . . . . . . . . . . 11
       6.1.2.  Anomalies  . . . . . . . . . . . . . . . . . . . . . . 11
     6.2.  FTP  . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
     6.3.  SSH  . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
     6.4.  Telnet . . . . . . . . . . . . . . . . . . . . . . . . . . 13
   7.  Next Steps . . . . . . . . . . . . . . . . . . . . . . . . . . 13
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 13
   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 13
   10. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 14
   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
     11.1. Normative References . . . . . . . . . . . . . . . . . . . 14
     11.2. Informative References . . . . . . . . . . . . . . . . . . 14
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14



















Abdo, et al.             Expires April 23, 2012                 [Page 2]


Internet-Draft      Report of NAT Reveal TCP Options        October 2011


1.  Introduction

   To ensure IPv4 service continuity, service providers will need to
   deploy IPv4 address sharing techniques.  Several issues are likely to
   be encountered (refer to [RFC6269] 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.

   Some of these issues may be mitigated owing to the activation of
   advanced features.  Among the solutions analyzed in
   [I-D.boucadair-intarea-nat-reveal-analysis], the use of a new TCP
   option to convey a HOST_ID seems to be a promising solution.

   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 option.  This draft also discusses the impact of using a
   Host_ID TCP option on the time it takes to establish a connection.


2.  Objectives

   The implementation of several HOST_ID TCP options is primarily meant
   to:

   o  Assess the validity of the HOST_ID TCP option approach
   o  Evaluate the impact on a TCP stack to support the HOST_ID TCP
      options
   o  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.
   o  Assess the behavior of legacy TCP servers when receiving a HOST_ID
      TCP option
   o  Assess the success ratio of TCP communications when a HOST_ID TCP
      option is received
   o  Assess the impact of injecting a HOST_ID TCP option on the time it
      takes to establish a connection
   o  Assess the performance impact on the CGN device that has been
      configured to inject the HOST_ID option


3.  NAT Reveal TCP Options: Overview

   The original idea of defining a TCP option is documented in
   [I-D.wing-nat-reveal-option] (denoted as HOST_ID_WING).



Abdo, et al.             Expires April 23, 2012                 [Page 3]


Internet-Draft      Report of NAT Reveal TCP Options        October 2011


   An additional TCP option format to convey a HOST_ID has been also
   considered (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
   [I-D.petersson-forwarded-for].

   The following sub-sections provide an overview of these HOST_ID TCP
   options.

3.1.  HOST_ID_WING TCP Option

   HOST_ID_WING is defined in [I-D.wing-nat-reveal-option].  Figure 1
   shows the format of this option.

                +--------+--------+-----------------------+
                |Kind=TBD|Length=4|    USER_ID Data       |
                +--------+--------+-----------------------+

                Figure 1: Format of HOST_ID_WING TCP Option

   Figure 2 shows an example of using HOST_ID_WING TCP option.

    +------------+        +------------+                 +------------+
    | TCP CLIENT |        |     CGN    |                 | TCP SERVER |
    +------------+        +------------+                 +------------+
          |                     |                              |
          |---TCP SYN---------->|                              |
          |                     |---TCP SYN, HOST_ID=12345---->|
          |                     |                              |

              Figure 2: HOST_ID_WING TCP Option: Flow example

3.2.  HOST_ID_BOUCADAIR TCP Option

   As mentioned above, the HOST_ID_BOUCADAIR TCP Option is inspired form
   HOST_ID_WING and XFF.  Figure 3 shows the format of HOST_ID_BOUCADAIR
   TCP Option.

           +--------+---------+---+---+--------..-------+
           |Kind=TBD|Length=10| L | O |HOST_ID data     | HOST_ID
           +--------+---------+---+---+--------..-------+

             Figure 3: Format of HOST_ID_BOUCADAIR TCP option

   o  L: Indicates the validity lifetime of the enclosed data (in the
      spirit of [RFC6250]).  The following values are supported:





Abdo, et al.             Expires April 23, 2012                 [Page 4]


Internet-Draft      Report of NAT Reveal TCP Options        October 2011


         0: Permanent;
         >0:Dynamic; this value indicates the validity time.
   o  Origin: Indicates the origin of the data conveyed in the data
      field.  The following values are supported:
         0: Internal Port
         1: Internal IPv4 address
         2: Internal Port: Internal IPv4 address
         3: IPv6 Prefix
         >3: No particular semantic
   o  HOST_ID: depends on the content of the Origin field; padding is
      required.

   Two modes are described below: the SYN mode (Section 3.2.1) and the
   ACK mode.  (Section 3.2.2).

   If the ACK mode is used (Section 3.2.2), Figure 4 shows the
   HOST_ID_ENABLED option to be included in the SYN.

                   +--------+---------+
                   |Kind=TBD|Length=2 |   HOST_ID_ENABLED
                   +--------+---------+


                    Figure 4: Format of HOST_ID_ENABLED

3.2.1.  SYN Mode

   This mode is similar to Section 3.1.  In this mode, HOST_ID_BOUCADAIR
   is sent in SYN packets.

   +------------+      +------------+                     +------------+
   | TCP CLIENT |      |     CGN    |                     | TCP SERVER |
   +------------+      +------------+                     +------------+
         |                   |                                    |
         |---TCP SYN-------->|                                    |
         |                   |--TCP SYN, HOST_ID=2001:db8::/5482->|
         |                   |                                    |


                   Figure 5: HOST_ID_BOUCADAIR: SYN Mode

3.2.2.  ACK Mode

   The ACK Mode is as follows (see Figure 6):
   o  Send HOST_ID_ENABLED (Figure 4) in SYN
   o  If the remote TCP server supports that option, it must return it
      in SYNACK




Abdo, et al.             Expires April 23, 2012                 [Page 5]


Internet-Draft      Report of NAT Reveal TCP Options        October 2011


   o  Then the TCP Client sends HOST_ID_BOUCADAIR (Figure 3) in ACK

    +------------+        +------------+                 +------------+
    | TCP CLIENT |        |     CGN    |                 | TCP SERVER |
    +------------+        +------------+                 +------------+
          |                     |                               |
          |---TCP SYN---------->|                               |
          |                     |--TCP SYN, HOSTID_ENABLED=OK-->|
          |                     |<-TCP SYNACK,HOSTID_ENABLED=OK-|
          |<--TCP SYNACK--------|                               |
          |---TCP ACK---------->|                               |
          |                     |--TCP ACK, USER_ID=2001:db8::->|
          |                     |                               |


                                 Figure 6


4.  Overview of the Linux Kernel Modifications

   At this stage, only the SYN mode has been implemented for both
   HOST_ID_WING and HOST_ID_BOUCADAIR TCP options.

   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).  Major modifications have
   been made in the tcp_output.c file (file responsible for building and
   transmitting all TCP packets).  New variables have been defined and
   functions manipulating the TCP options in SYN packets have been
   modified to inject the configured TCP option in the corresponding SYN
   packet.

   Since different options can be injected, they have to be easily
   configurable.  System control variables (a.k.a., sysctl variables)
   are defined for this purpose.

   The Kernel must be recompiled so that the new TCP options are taken
   into account.

   Kernel modifications and recompilation have been done and tested
   successfully on Fedora and Debian Linux distributions, on different
   kernel versions.

   The following configuration options are supported:
   o  Enable/Disable injecting the TCP Option
   o  Support HOST_ID WING and HOST_ID BOUCADAIR





Abdo, et al.             Expires April 23, 2012                 [Page 6]


Internet-Draft      Report of NAT Reveal TCP Options        October 2011


   o  When the HOST_ID TCP option is supported, the information to be
      injected is configurable:
      *  Source IPv6 address or the first 64 bits of the address
      *  Source IPv4 address
      *  Source port number
      *  Source IPv4 address and Source port
      *  IPv6 address or the first 64 bits of the B4 when DS-Lite is
         activated
   o  When the HOST_ID TCP option is enabled, stripping any existing
      HOST_ID TCP option is enabled by default.


5.  Testbed Setup & Configuration

   The setup of three testbed configurations have been considered:
   1.  HOST_ID TCP option is injected by the host itself.  No CGN is
       present in the communication path (Figure 7)
   2.  HOST_ID TCP option is injected by hosts deployed behind a HTTP
       proxy.  No CGN is present in the communication path (Figure 8)
   3.  HOST_ID TCP option is injected by the DS-Lite AFTR element
       (Figure 9).

    +-----------+
    |  HOST_1   |----+
    | NO-Option |    |
    +-----------+    |      +--------------------+        +------------+
                     |      |                    |--------|  server 1  |
    +-----------+    |      |                    |        +------------+
    |  HOST_2   |----|------|        INTERNET    |               ::
    | (HOST_ID) |    |      |                    |        +------------+
    +-----------+    |      |                    |--------|   server n |
                     |      +--------------------+        +------------+
    +-----------+    |
    |  Local    |----+
    |  Server   |
    +-----------+

               Figure 7: Testbed setup: No Proxy and no CGN













Abdo, et al.             Expires April 23, 2012                 [Page 7]


Internet-Draft      Report of NAT Reveal TCP Options        October 2011


    +-----------+
    |  HOST_1   |----+
    | NO-Option |    |
    +-----------+    |        +--------------------+      +------------+
                     |        |                    |------|  server 1  |
    +-----------+  +-----+    |                    |      +------------+
    |  HOST_2   |--|PROXY|----|      INTERNET      |            ::
    | (HOST_ID) |  +-----+  | |                    |      +------------+
    +-----------+           | |                    |------|   server n |
                            | +--------------------+      +------------+
    +-----------+           |
    |  Local    |-----------+
    |  Server   |
    +-----------+

                    Figure 8: Testbed setup: HTTP Proxy

                                            +----...----+   +----------+
    +----+   |           |                  |           |---| server 1 |
    |HOST|---|  +----+   |   +------+   |   |           |   +----------+
    +----+   |--| B4 |---|---| AFTR |---|---| INTERNET  |        ::
                +----+   |   +------+   |   |           |   +----------+
                         |                  |           |---| server n |
                                            +----...----+   +----------+

                     Figure 9: DS-Lite CGN Environment

   Figure 7 and Figure 8 are used to assess the behavior of the top 1000
   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.

   On the other hand, the configuration shown in Figure 9 will be used
   to evaluate the impact on the CGN performances when HOST_ID TCP
   option is injected by the CGN.

5.1.  Automated TCP Traffic Generator

   A Python-coded 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 web pages retrieval is
   based on Pycurl, a Python interface of libcurl.  Libcurl is an URL
   transfer library that supports different protocols (e.g., HTTP, FTP).

   The robot consists of two programs:






Abdo, et al.             Expires April 23, 2012                 [Page 8]


Internet-Draft      Report of NAT Reveal TCP Options        October 2011


   1.  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:
       *  NAMELOOKUP_TIME is the time it took from the start until the
          name resolution is completed.
       *  CONNECT_TIME is the time it took from the start until the
          connection to the remote host (or proxy) is completed.
   2.  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.

5.2.  Testing Methodology and Procedure

   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 performed 10
   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.

   Testing was also performed behind a proxy (Figure 8) 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.

   Tests have been conducted from hosts:
   1.  Connected to a commercial ISP network
   2.  Connected to an enterprise network
   3.  In a lab behind a firewall

5.3.  Top Website List

   The Alexa top sites list has been used to conduct the tests.







Abdo, et al.             Expires April 23, 2012                 [Page 9]


Internet-Draft      Report of NAT Reveal TCP Options        October 2011


6.  Experimentation Results

6.1.  HTTP Experimentation Results

   Various combinations of the HOST_ID TCP options have been tested:

   1.  HOST_ID_WING
   2.  HOST_ID_BOUCADAIR (source port)
   3.  HOST_ID_BOUCADAIR (IPv4 address)
   4.  HOST_ID_BOUCADAIR (source port:IPv4 address)
   5.  HOST_ID_BOUCADAIR (IPv6 Prefix)

   Both the success ratio and the average time to establish the TCP
   session are reported below.

   HOST_ID_WING has also been adapted to include 32 bits and 64 bits
   values.  No particular impact on session establishment has been
   observed.

   The results show that the success ratio for establishing TCP
   connection with legacy servers, is the same for all the HOST_ID
   options Figure 10 and Figure 11.

                      +-----------+-----------+--------------+
                      | NOB       | OB        | 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% |100,00000% |   0,00000%   |
              Top400  | 99,75000% | 99,75000% |   0,00000%   |
              Top500  | 99,80000% | 99,80000% |   0,00000%   |
              Top600  | 99,83333% | 99.83333% |   0,00000%   |
              Top700  | 99,85714% | 99.85714% |   0,00000%   |
              Top800  | 99,75000% | 99.75000% |   0,00000%   |
              Top900  | 99.66667% | 99,66667% |   0,00000%   |
              Top1000 | 99,70000% | 99,70000% |   0,00000%   |
              -------+-----------+------------+--------------+

                    Figure 10: Cumulated success ratio











Abdo, et al.             Expires April 23, 2012                [Page 10]


Internet-Draft      Report of NAT Reveal TCP Options        October 2011


                          +------+-------+--------------+
                          | NOB  |HOST_ID| Failure Ratio|
                  --------+------+-------+--------------+
                  1-100   | 100% | 100%  |    0,00%     |
                  101-200 | 100% | 100%  |    0,00%     |
                  201-300 | 100% | 100%  |    0,00%     |
                  301-400 | 99%  | 99%   |    0,00%     |
                  401-500 | 100% | 100%  |    0,00%     |
                  501-600 | 100% | 100%  |    0,00%     |
                  601-700 | 100% | 100%  |    0,00%     |
                  701-800 | 99%  | 99%   |    0,00%     |
                  801-900 | 99%  | 99%   |    0,00%     |
                  901-1000| 100% | 100%  |    0,00%     |
                  --------+------+-------+--------------+
                                 | Total |    0,00%     |
                                 +-------+--------------+

                      Figure 11: TopX00 Success Ratio

   The above tables clearly show that the injection of the HOST_ID
   option does not alter the success ratio to establish TCP sessions;
   the connection state is the same with or without options.  From the
   top 1000 sites, only 3 errors are observed.  The cause of the
   observed failures is due to DNS.

   These results show that including a HOST_ID TCP option does not
   systematically imply an extra delay for the establishment of the TCP
   session.  Measured delays are even smaller when the options are
   injected for almost 50% of the websites.  Based upon the average of
   the session establishment with the top1000 sites, the following
   results have been obtained:
   o  delay(HOST_ID_WING) < delay(NO_OPTION): 57,3%
   o  delay(HOST_ID_BOUCADAIR (source port:IPv4 address)) <
      delay(NO_OPTION): 51,3%
   o  delay(HOST_ID_BOUCADAIR (source port)) < delay(NO_OPTION): 63,1%

6.1.1.  Proxy

   The testing environment that includes a HTTP proxy yielded the same
   results as described above as far as the success ratio is concerned.
   But no conclusion can be drawn about connection establishment time
   because this metric is impacted by the proxy server.

6.1.2.  Anomalies

   Tests have been conducted from hosts:





Abdo, et al.             Expires April 23, 2012                [Page 11]


Internet-Draft      Report of NAT Reveal TCP Options        October 2011


   1.  Connected to a commercial ISP network
   2.  Connected to an enterprise network
   3.  In a lab behind a firewall

   The results for HOST_ID_WING for all three configurations are the
   same as Section 6.  Surprisingly, results obtained for
   HOST_ID_BOUCADAIR are not the same.  Indeed, (1) and (2)
   configurations lead to the results documented in Section 6 but
   failures have been observed for configuration (3).  Figure 12 and
   Figure 13 shows the observed results.  Note that failures are
   encountered for the same set of servers.

                      +-----------+-----------+--------------+
                      | NOB       | OB        | 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%   |
              -------+-----------+------------+--------------+

                    Figure 12: Cumulated success ratio

                          +------+-------+--------------+
                          | NOB  |HOST_ID| Failure Ratio|
                  --------+------+-------+--------------+
                  1-100   | 100% | 100%  |    0,00%     |
                  101-200 | 100% | 100%  |    0,00%     |
                  201-300 | 100% |  99%  |    1,00%     |
                  301-400 | 99%  |  97%  |    2,00%     |
                  401-500 | 100% |  99%  |    1,00%     |
                  501-600 | 100% |  97%  |    3,00%     |
                  601-700 | 100% |  95%  |    5,00%     |
                  701-800 | 99%  |  97%  |    2,00%     |
                  801-900 | 99%  |  92%  |    7,00%     |
                  901-1000| 100% |  95%  |    5,00%     |
                  --------+------+-------+--------------+
                  | Total | 997  | 971   |    2,60%     |
                  +-------+--------------+--------------+

                      Figure 13: TopX00 Success Ratio



Abdo, et al.             Expires April 23, 2012                [Page 12]


Internet-Draft      Report of NAT Reveal TCP Options        October 2011


   Analysis of the cause of these failures is currently ongoing.

6.2.  FTP

   File transfer has been tested with different mirrors of proftpd.org.
   The transfer was successful for all HOST_ID TCP options.

   The test was repeated for many files from different servers.

6.3.  SSH

   The secure shell service has been tested between a host and a ssh
   server located in the same network.

   SSH connections have been successfully established with the server
   for all the HOST_ID TCP options.

6.4.  Telnet

   Telnet sessions have been successfully initiated for all HOST_ID TCP
   options with a server (the CGN used in Figure 9).


7.  Next Steps

   o  Conduct a massive test campaign for a list of FTP servers
   o  Support the HOST_ID Injection in ACK mode
   o  Support TCP options injection by the CGN and drive the appropriate
      testing to conclude about impact of using these options on the CGN
      performances
   o  Update the iptables module to enforce policies based upon the
      content of the HOST_ID TCP option
   o  Test for top1million websites


8.  IANA Considerations

   This document makes no request of IANA.


9.  Security Considerations

   Security considerations discussed in [I-D.wing-nat-reveal-option]
   should be taken into account.







Abdo, et al.             Expires April 23, 2012                [Page 13]


Internet-Draft      Report of NAT Reveal TCP Options        October 2011


10.  Acknowledgments

   Many thanks to M. Meulle, P. Ng Tung and L. Valeyre for their help
   and review.  Special thanks to C. Jacquent for his careful review


11.  References

11.1.  Normative References

   [I-D.wing-nat-reveal-option]
              Yourtchenko, A. and D. Wing, "Revealing hosts sharing an
              IP address using TCP option",
              draft-wing-nat-reveal-option-02 (work in progress),
              June 2011.

   [RFC6250]  Thaler, D., "Evolution of the IP Model", RFC 6250,
              May 2011.

11.2.  Informative References

   [I-D.boucadair-intarea-nat-reveal-analysis]
              Boucadair, M., Touch, J., Levis, P., and R. Penno,
              "Analysis of Solution Candidates to Reveal a Host
              Identifier in Shared Address Deployments",
              draft-boucadair-intarea-nat-reveal-analysis-04 (work in
              progress), September 2011.

   [I-D.petersson-forwarded-for]
              Petersson, A. and M. Nilsson, "Forwarded HTTP Extension",
              draft-petersson-forwarded-for-01 (work in progress),
              October 2011.

   [RFC6269]  Ford, M., Boucadair, M., Durand, A., Levis, P., and P.
              Roberts, "Issues with IP Address Sharing", RFC 6269,
              June 2011.


Authors' Addresses

   Elie Abdo
   France Telecom
   Issy Les Moulineaux


   Email: elie.abdo@orange.com





Abdo, et al.             Expires April 23, 2012                [Page 14]


Internet-Draft      Report of NAT Reveal TCP Options        October 2011


   Mohamed Boucadair
   France Telecom

   Email: mohamed.boucadair@orange.com


   Jaqueline Queiroz
   France Telecom
   Issy Les Moulineaux


   Email: jaqueline.queiroz@orange.com







































Abdo, et al.             Expires April 23, 2012                [Page 15]