HOST_ID TCP Options:
Implementation & Preliminary Test ResultsFrance TelecomIssy-les-Moulineauxelie.abdo@orange.comFrance Telecommohamed.boucadair@orange.comFrance TelecomIssy-les-Moulineauxjaqueline.queiroz@orange.comTCP Option, HOST_ID, Shared AddressThis 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.To ensure IPv4 service continuity, service providers will need to
deploy IPv4 address sharing techniques. Several issues are likely to be
encountered (refer to 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 , 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 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.The implementation of several HOST_ID TCP options is primarily meant
to:Assess the validity of the HOST_ID TCP option approachEvaluate the impact on the TCP stack to support the HOST_ID TCP
optionsImprove 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.Assess the behavior of legacy TCP servers when receiving a
HOST_ID TCP optionAssess the success ratio of TCP communications when a HOST_ID TCP
option is receivedAssess the impact of injecting a HOST_ID TCP option on the time
it takes to establish a connectionAssess the performance impact on the CGN device that has been
configured to inject the HOST_ID optionThe original idea of defining a TCP option is documented in and denoted as
HOST_ID_WING.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.The following sub-sections provide an overview of these HOST_ID TCP
options.HOST_ID_WING is defined in . shows the format of this option.This option must be sent only upon the initial connection request,
i.e., in SYN packets as shown in As mentioned above, the HOST_ID_BOUCADAIR TCP Option is inspired
from HOST_ID_WING and XFF.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 L: Indicates the validity lifetime of the enclosed data (in the
spirit of ). The following values
are supported:0: Permanent;>0:Dynamic; this value indicates the validity time.Origin: Indicates the origin of the data conveyed in the data
field. The following values are supported:0: Internal Port1: Internal IPv4 address2: Internal Port: Internal IPv4 address3: IPv6 Prefix>3: No particular semanticHOST_ID_data depends on the content of the Origin field;
padding is required.Two modes are described below: the SYN mode () and the ACK mode. ().If the ACK mode is used (), shows the HOST_ID_ENABLED option
(2-bytes long) to be included in the SYN.This mode is similar to the mode described in . In this mode, HOST_ID_BOUCADAIR is sent in
SYN packets.The ACK Mode is as follows (see ):Send HOST_ID_ENABLED () in
SYNIf the remote TCP server supports that option, it must return
it in SYNACKThen the TCP Client sends an ACK in which the CGN injects
HOST_ID_BOUCADAIR ()
The objective of this phase is to support HOST_ID_WING,
HOST_ID_BOUCADAIR and HOST_ID_ENABLED in the SYN mode.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.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.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.Once modifications have taken place, 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:Enable/Disable injecting the TCP OptionSupport HOST_ID WING, HOST_ID BOUCADAIR and HOST_ID_ENABLEDWhen the HOST_ID TCP option is supported, the information to be
injected is configurable:Source IPv6 address or the first 56 bits of the addressSource IPv4 addressSource port numberSource IPv4 address and Source portIPv6 address or the first 56 bits of the B4 when DS-Lite is
activatedThe setup of three testbed configurations have been considered:HOST_ID TCP option is injected by the host itself. No CGN is
present in the forwarding path ()HOST_ID TCP option is injected by hosts deployed behind a HTTP
proxy. No CGN is present in the forwarding path ()HOST_ID TCP option is injected by the DS-Lite AFTR element (). and 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.On the other hand, the configuration shown in will be used to evaluate the impact on the
CGN performances when HOST_ID TCP option is injected by the CGN.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).The robot consists of two programs: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.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.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.Testing was also performed behind a proxy () 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).Tests have been conducted from hosts:Connected to an enterprise networkIn a lab behind a firewallConnected to two (2) commercial ISP networksTo check whether the HOST_ID TCP options are correctly injected,
the local server in 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.This configuration confirms the packets sent to remote servers
conveys HOST_ID TCP options.The Alexa top sites list has been used to conduct the HTTP
tests.Anonymous FTP sites list from ftp-sites.org has been used to
conduct the FTP tests.Various combinations of the HOST_ID TCP options have been
tested:HOST_ID_WINGHOST_ID_WING has also been adapted to include 32 bits and 64 bits
values. No particular impact on session establishment has been
observed.HOST_ID_BOUCADAIR (source port)HOST_ID_BOUCADAIR (IPv4 address)HOST_ID_BOUCADAIR (source port:IPv4 address)HOST_ID_BOUCADAIR (IPv6 Prefix)HOST_ID_ENABLEDBoth the success ratio and the average time to establish the TCP
session are reported below.Tests have been conducted from hosts:Connected to an enterprise networkConnected to two commercial ISP networksIn a lab behind a firewallThe 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 , and .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…), connection resets by peers, connection
problems and empty replies from servers. The 2249 failures
occur, whether HOST_ID options are injected or not.When any HOST_ID TCP option is conveyed, 103 servers did
not respond; however when no option is injected, all these
servers responded normally.Same results were obtained for HOST_ID_WING and
HOST_ID_ENABLED.Same results were obtained for all the HOST_ID_BOUCADAIR
options (source port, IPv6 prefix, etc.).When HOST_ID_BOUCADAIR is enabled, six (6) additional servers
did not respond:Three (3) servers (www.teufel.de – www.1001fonts.com
– www.sigur-ros.co.uk) did not respond to the SYN
packets sent by the host.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.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.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:delay(HOST_ID_WING) < delay(NO_OPTION): 42,55 %delay(HOST_ID_BOUCADAIR ) < delay(NO_OPTION): 48,16
%delay(HOST_ID_ENABLED) < delay(NO_OPTION): 51,28 %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).The results obtained when testing was performed by connecting to
two ISP networks confirmed the results obtained in the testing
described in 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’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: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.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).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.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.Various combinations of the HOST_ID TCP options have been
tested:HOST_ID_WINGHOST_ID_BOUCADAIR (source port)HOST_ID_BOUCADAIR (source port:IPv4 address)A list of 5591 FTP servers has been used to conduct these testings.
Among this list, only 2045 were reachable:Failure to reach 942 FTP servers due to connection timeoutFailure to reach 1286 FTP servers due to DNS errorsFailure to reach 717 FTP servers because access was deniedCould not connect to 500 FTP serversResponse reading failed for 81 serversBad response from server for 20 serversWhen HOST_ID TCP options are injected, 9 errors are observed
(connection timeout). and provide more data about the error
distribution.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:delay(HOST_ID_WING) < delay(NO_OPTION): 49,36585 %delay(HOST_ID_BOUCADAIR (source port:IPv4 address)) <
delay(NO_OPTION): 48,41076%delay(HOST_ID_BOUCADAIR (source port)) < delay(NO_OPTION):
48,43902 %The secure shell service has been tested between a host and a SSH
server connected to the same network.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).Telnet sessions have been successfully initiated for all HOST_ID
TCP options with a server (the CGN used in ).This section highlights the support the HOST_ID functionalities in
the AFTR element of the DS-Lite model () and presents the testing results in order
to conclude about the HOST_ID TCP options impacts on the performance of
the CGN.We used ISC AFTR implementation.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.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.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.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: hostid: to enable the injection, retrieval, matching... of
HOST_ID optionshostid_wing: to enable injection/verification of HOST_ID_WING -
to disable injection or to remove HOST_ID_WINGhostid_boucadair: to enable injection/verification of
HOST_ID_BOUCADAIR - to disable injection or to remove
HOST_ID_BOUCADAIRhostid_enabled: to enable or disable HOST_ID_ENABLED
injectionhostid, 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: Source Port NumberSource IPv4 AddressSource IPv4 Address + Source Port Number56 bits of Tunnel Softwire IPv6 Source Address.Based on different HOST_ID parameters, the "aftr.c" code has been
modified to control HOST_ID options; the AFTR is able to:Inject the enabled HOST_ID TCP option if it is not already
present in the packetRetrieve an existing HOST_ID TCP option if this option is not
enabledCheck an existing HOST_ID option’s content if it is
enabled; if the content’s verification failed, the AFTR
replaces the HOST_ID contents with the suitable informationThe 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’s options have been
tested and no impact observed; the ACK mode should not imply any
complication in implementation or impact on the performance.The verification of HOST_ID implementation in the CGN has taken
place using the testbed setup shown in . 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.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.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.One additional case has been tested when both Wing’s and
Boucadair’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.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.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’s port emulates hosts and B4 elements at the
same time. This port is directly connected to the AFTR tunnel
endpoint. The AFTR’s IPv4 interface is connected to the testing
product server side where servers are assigned IPv4 addresses.The testbed setup of this testing is shown in :At the IP level, the testing client port was configured with IPv6
addresses representing the B4. The testing tool also supports the
DS-Lite “level” where the number of clients connected to
each B4 and their addresses are configured. The AFTR address is
defined at this level.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.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.The HOST_ID options are injected by the CGN.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.Hereafter are provided some testing statistics providing some
details about connections’ success ratio, latency and other
information that can be useful to evaluate the impact of HOST_ID on
the CGN.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.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.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).Another consequence is that the TCP connection establishment
rate at servers is not decreasing when a HOST_ID option is taken
into account.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.The same testing was also run for FTP traffic. No particular
impact on the performance of the CGN has been observed.iptables module has been updated to: Log the content of TCP header with HOST_IDDrop packets holding a HOST_ID optionMatch any HOST_ID valueDrop packets holding a specific HOST_ID valueStrip any existing HOST_ID optionTo support the above functionalities, modification should take into
consideration stripping and matching options as described below: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’ 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: 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:Match HOST_ID options values entered in corresponding
iptables rules,Print the HOST_ID rules on screen,Save values,Check the values (or range values) entered by user if they
respect the limit values of these options.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’ values held by packets with the HOST_ID
values specified in the iptables rule table: when a packet matches
the HOST_ID’s range, the corresponding rule will be applied
for this packet.The HOST_ID_WING matching value is 2 bytes long corresponding
to HOST_ID_WING data.The HOST_ID_BOUCADAIR matching value is 8 bytes long
corresponding to Lifetime + Origin field (1 byte) and HOST_ID_WING
data (7 bytes).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 below
.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.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:The first rule applies for the mangle table. This table allows
stripping HOST_ID_WING whose role is to remove option Wing’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.After applying these rules (to strip and log HOST_ID_WING) on the
local server, we tried to access the server’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.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’s logged stripped packets.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
‘1’ = NOP).The same testing was repeated with HOST_ID_BOUCADAIR. The testing
shows that the 10 bytes corresponding to this option were successfully
stripped.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:Now, to log packets matching a certain HOST_ID value or range of
values, the following rule must be applied: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.The testing configuration in
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.The same testing was repeated to match HOST_ID_BOUCADAIR data
information:To verify the logging of a specific Boucadair’s value, the
Boucadair’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’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.The iptables rules to log HOST_ID_BOUCADAIR range values have been
verified successfully for all four HOST_ID_BOUCADAIR options.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:In this testing, the HOST_ID_WING option is enabled at the CGN
level. After applying the previous rule where Wing’s specified
value corresponds to the HOST_ID_WING data value (last 16 bits of the
host’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.When the host is still trying to retrieve pages by sending SYN
packets, the command ‘iptables –F’ will flush all
iptables rules. Once applied, this command will let the host retrieve
the required pages and the connection is therefore established
successfully.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.This document makes no request of IANA.Security considerations discussed in should be taken into
account.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.