+.IP \fBct\fR
+.IQ \fBct\fB(\fR[\fIargument\fR][\fB,\fIargument\fR...]\fB)
+Send the packet through the connection tracker. Refer to the \fBct_state\fR
+documentation above for possible packet and connection states. The following
+arguments are supported:
+
+.RS
+.IP \fBcommit\fR
+.RS
+Commit the connection to the connection tracking module. Information about the
+connection will be stored beyond the lifetime of the packet in the pipeline.
+Some \fBct_state\fR flags are only available for committed connections.
+.RE
+.IP \fBtable=\fInumber\fR
+Fork pipeline processing in two. The original instance of the packet will
+continue processing the current actions list as an untracked packet. An
+additional instance of the packet will be sent to the connection tracker, which
+will be re-injected into the OpenFlow pipeline to resume processing in table
+\fInumber\fR, with the \fBct_state\fR and other ct match fields set. If the
+\fBtable\fR is not specified, then the packet is submitted to the connection
+tracker, but the pipeline does not fork and the ct match fields are not
+populated. It is strongly recommended to specify a table later than the current
+table to prevent loops.
+.IP \fBzone=\fIvalue\fR
+.IQ \fBzone=\fIsrc\fB[\fIstart\fB..\fIend\fB]\fR
+A 16-bit context id that can be used to isolate connections into separate
+domains, allowing overlapping network addresses in different zones. If a zone
+is not provided, then the default is to use zone zero. The \fBzone\fR may be
+specified either as an immediate 16-bit \fIvalue\fR, or may be provided from an
+NXM field \fIsrc\fR. The \fIstart\fR and \fIend\fR pair are inclusive, and must
+specify a 16-bit range within the field.
+.IP \fBexec\fB(\fR[\fIaction\fR][\fB,\fIaction\fR...]\fB)\fR
+Perform actions within the context of connection tracking. These actions
+are in the same format as the actions accepted as part of a flow, however
+there are additional restrictions applied. For instance, only actions which
+modify the ct fields are accepted within the \fBexec\fR action. Furthermore,
+some actions may only be performed in this context, for instance modifying the
+ct_mark field:
+.
+.RS
+.IP \fBset_field:\fIvalue\fR->ct_mark\fR
+Store a 32-bit metadata value with the connection. If the connection is
+committed, then subsequent lookups for packets in this connection will
+populate the \fBct_mark\fR flow field when the packet is sent to the
+connection tracker with the \fBtable\fR specified.
+.IP \fBset_field:\fIvalue\fR->ct_label\fR
+Store a 128-bit metadata value with the connection. If the connection is
+committed, then subsequent lookups for packets in this connection will
+populate the \fBct_label\fR flow field when the packet is sent to the
+connection tracker with the \fBtable\fR specified.
+.RE
+.IP
+The \fBcommit\fR parameter must be specified to use \fBexec(...)\fR.
+.
+.IP \fBalg=\fIalg\fR
+Specify application layer gateway \fIalg\fR to track specific connection
+types. Supported types include:
+.RS
+.IP \fBftp\fR
+Look for negotiation of FTP data connections. If a subsequent FTP data
+connection arrives which is related, the \fBct\fR action will set the
+\fBrel\fR flag in the \fBct_state\fR field for packets sent through \fBct\fR.
+.RE
+.
+.RE
+.IP
+The \fBct\fR action may be used as a primitive to construct stateful firewalls
+by selectively committing some traffic, then matching the \fBct_state\fR to
+allow established connections while denying new connections. The following
+flows provide an example of how to implement a simple firewall that allows new
+connections from port 1 to port 2, and only allows established connections to
+send traffic from port 2 to port 1:
+ \fBtable=0,priority=1,action=drop
+ table=0,priority=10,arp,action=normal
+ table=0,priority=100,ip,ct_state=-trk,action=ct(table=1)
+ table=1,in_port=1,ip,ct_state=+trk+new,action=ct(commit),2
+ table=1,in_port=1,ip,ct_state=+trk+est,action=2
+ table=1,in_port=2,ip,ct_state=+trk+new,action=drop
+ table=1,in_port=2,ip,ct_state=+trk+est,action=1\fR
+.IP
+If \fBct\fR is executed on IP (or IPv6) fragments, then the message is
+implicitly reassembled before sending to the connection tracker and
+refragmented upon \fBoutput\fR, to the original maximum received fragment size.
+Reassembly occurs within the context of the \fBzone\fR. Pipeline processing
+for the initial fragments is halted; When the final fragment is received,
+the message is assembled and pipeline processing will continue for that flow.
+Because packet ordering is not guaranteed by IP protocols, it is not possible
+to determine which IP fragment will cause message reassembly (and therefore
+continue pipeline processing). As such, it is strongly recommended that
+multiple flows should not execute \fBct\fR to reassemble fragments from the
+same IP message.
+.IP
+Currently, connection tracking is only available on Linux kernels with the
+nf_conntrack module loaded.
+.
+.RE
+.