INTEGER TYPE
~~~~~~~~~~~
[options="header"]
|==================
|Name | Keyword | Size | Base type
|Integer |
integer |
variable |
-
|===================

The integer type is used for numeric values. It may be specified as a decimal,
hexadecimal or octal number. The integer type does not have a fixed size, its
size is determined by the expression for which it is used.

BITMASK TYPE
~~~~~~~~~~~~
[options="header"]
|==================
|Name | Keyword | Size | Base type
|Bitmask |
bitmask |
variable |
integer
|===================

The bitmask type (*bitmask*) is used for bitmasks.

STRING TYPE
~~~~~~~~~~~~
[options="header"]
|==================
|Name | Keyword | Size | Base type
|String |
string |
variable |
-
|===================

The string type is used for character strings. A string begins with an
alphabetic character (a-zA-Z) followed by zero or more alphanumeric characters
or the characters /, -, _ and .. In addition, anything enclosed in double
quotes (") is recognized as a string.

.String specification
----------------------
# Interface name
filter input iifname eth0

# Weird interface name
filter input iifname "(eth0)"
----------------------------

LINK LAYER ADDRESS TYPE
~~~~~~~~~~~~~~~~~~~~~~~
[options="header"]
|==================
|Name | Keyword | Size | Base type
|Link layer address |
lladdr|
variable |
integer
|===================

The link layer address type is used for link layer addresses. Link layer
addresses are specified as a variable amount of groups of two hexadecimal digits
separated using colons (:).

.Link layer address specification
----------------------
# Ethernet destination MAC address
filter input ether daddr 20:c9:d0:43:12:d9
----------------------------

IPV4 ADDRESS TYPE
~~~~~~~~~~~~~~~~~
[options="header"]
|==================
|Name | Keyword | Size | Base type
|IPV4 address|
ipv4_addr|
32 bit|
integer
|===================

The IPv4 address type is used for IPv4 addresses. Addresses are specified in
either dotted decimal, dotted hexadecimal, dotted octal, decimal, hexadecimal,
octal notation or as a host name. A host name will be resolved using the
standard system resolver.

.IPv4 address specification
----------------------
# dotted decimal notation
filter output ip daddr 127.0.0.1

# host name
filter output ip daddr localhost
----------------------------

IPV6 ADDRESS TYPE
~~~~~~~~~~~~~~~~~
[options="header"]
|==================
|Name | Keyword | Size | Base type
|IPv6 address|
ipv6_addr|
128 bit|
integer
|===================

The IPv6 address type is used for IPv6 addresses. Addresses are specified as a
host name or as hexadecimal halfwords separated by colons. Addresses might be
enclosed in square brackets ("[]") to differentiate them from port numbers.

.IPv6 address specification
----------------------
# abbreviated loopback address
filter output ip6 daddr ::1
----------------------------

.IPv6 address specification with bracket notation
----------------------
# without [] the port number (22) would be parsed as part of the
# ipv6 address
ip6 nat prerouting tcp dport 2222 dnat to [1ce::d0]:22
----------------------------

BOOLEAN TYPE
~~~~~~~~~~~~
[options="header"]
|==================
|Name | Keyword | Size | Base type
|Boolean |
boolean |
1 bit |
integer
|===================

The boolean type is a syntactical helper type in userspace. Its use is in the
right-hand side of a (typically implicit) relational expression to change the
expression on the left-hand side into a boolean check (usually for existence). +

.The following keywords will automatically resolve into a boolean type with given value

[options="header"]
|==================
|Keyword | Value
|exists |
1 |
missing |
0
|===================

.expressions support a boolean comparison
[options="header"]
|======================================
|Expression | Behaviour
|fib |
Check route existence.
|exthdr|
Check IPv6 extension header existence.
|tcp option |
Check TCP option header existence.
|===================

.Boolean specification
----------------------
# match if route exists
filter input fib daddr . iif oif exists

# match only non-fragmented packets in IPv6 traffic
filter input exthdr frag missing

# match if TCP timestamp option is present
filter input tcp option timestamp exists
------------------------------------------

ICMP TYPE TYPE
~~~~~~~~~~~~~~
[options="header"]
|==================
|Name | Keyword | Size | Base type
|ICMP Type |
icmp_type |
8 bit |
integer
|===================
The ICMP Type type is used to conveniently specify the ICMP header's type field.

.Keywords may be used when specifying the ICMP type
[options="header"]
|==================
|Keyword | Value
|echo-reply |
0
|destination-unreachable |
3
|source-quench|
4
|redirect|
5
|echo-request|
8
|router-advertisement|
9
|router-solicitation|
10
|time-exceeded|
11
|parameter-problem|
12
|timestamp-request|
13
|timestamp-reply|
14
|info-request|
15
|info-reply|
16
|address-mask-request|
17
|address-mask-reply|
18
|===================

.ICMP Type specification
------------------------
# match ping packets
filter output icmp type { echo-request, echo-reply }
------------------------

ICMP CODE TYPE
~~~~~~~~~~~~~~
[options="header"]
|==================
|Name | Keyword | Size | Base type
|ICMP Code |
icmp_code |
8 bit |
integer
|===================

The ICMP Code type is used to conveniently specify the ICMP header's code field.

.Keywords may be used when specifying the ICMP code
[options="header"]
|==================
|Keyword | Value
|net-unreachable |
0
|host-unreachable |
1
|prot-unreachable|
2
|port-unreachable|
3
|frag-needed|
4
|net-prohibited|
9
|host-prohibited|
10
|admin-prohibited|
13
|===================

ICMPV6 TYPE TYPE
~~~~~~~~~~~~~~~~
[options="header"]
|==================
|Name | Keyword | Size | Base type
|ICMPv6 Type |
icmpx_code |
8 bit |
integer
|===================

The ICMPv6 Type type is used to conveniently specify the ICMPv6 header's type field.

.keywords may be used when specifying the ICMPv6 type:
[options="header"]
|==================
|Keyword | Value
|destination-unreachable |
1
|packet-too-big|
2
|time-exceeded|
3
|parameter-problem|
4
|echo-request|
128
|echo-reply|
129
|mld-listener-query|
130
|mld-listener-report|
131
|mld-listener-done |
132
|mld-listener-reduction|
132
|nd-router-solicit |
133
|nd-router-advert|
134
|nd-neighbor-solicit|
135
|nd-neighbor-advert|
136
|nd-redirect|
137
|router-renumbering|
138
|ind-neighbor-solicit|
141
|ind-neighbor-advert|
142
|mld2-listener-report|
143
|===================

.ICMPv6 Type specification
--------------------------
# match ICMPv6 ping packets
filter output icmpv6 type { echo-request, echo-reply }
--------------------------

ICMPV6 CODE TYPE
~~~~~~~~~~~~~~~~
[options="header"]
|==================
|Name | Keyword | Size | Base type
|ICMPv6 Code |
icmpv6_code |
8 bit |
integer
|===================

The ICMPv6 Code type is used to conveniently specify the ICMPv6 header's code field.

.keywords may be used when specifying the ICMPv6 code
[options="header"]
|==================
|Keyword |Value
|no-route|
0
|admin-prohibited|
1
|addr-unreachable|
3
|port-unreachable|
4
|policy-fail|
5
|reject-route|
6
|==================

ICMPVX CODE TYPE
~~~~~~~~~~~~~~~~
[options="header"]
|==================
|Name | Keyword | Size | Base type
|ICMPvX Code |
icmpv6_type |
8 bit |
integer
|===================

The ICMPvX Code type abstraction is a set of values which overlap between ICMP
and ICMPv6 Code types to be used from the inet family.

.keywords may be used when specifying the ICMPvX code
[options="header"]
|==================
|Keyword |Value
|no-route|
0
|port-unreachable|
1
|host-unreachable|
2
|admin-prohibited|
3
|=================

CONNTRACK TYPES
~~~~~~~~~~~~~~~

.overview of types used in ct expression and statement
[options="header"]
|==================
|Name | Keyword |Size |Base type
|conntrack state|
ct_state|
4 byte|
bitmask
|conntrack direction|
ct_dir |
8 bit|
integer
|conntrack status|
ct_status|
4 byte|
bitmask
|conntrack event bits|
ct_event |
4 byte |
bitmask
|conntrack label|
ct_label |
128 bit|
bitmask
|=================

For each of the types above, keywords are available for convenience:

.conntrack state (ct_state)
[options="header"]
|==================
|Keyword| Value
|invalid|
1
|established|
2
|related|
4
|new|
8
|untracked|
64
|================

.conntrack direction (ct_dir)
[options="header"]
|==================
|Keyword| Value
|original|
0
|reply|
1
|================

.conntrack status (ct_status)
[options="header"]
|==================
|Keyword| Value
|expected|
1
|seen-reply|
2
|assured|
4
|confirmed|
8
|snat|
16
|dnat|
32
|dying|
512
|================

.conntrack event bits (ct_event)
[options="header"]
|==================
|Keyword| Value
|new|
1
|related|
2
|destroy|
4
|reply|
8
|assured|
16
|protoinfo|
32
|helper|
64
|mark|
128
|seqadj|
256
|secmark|
512
|label|
1024
|==================

Possible keywords for conntrack label type (ct_label) are read at runtime from /etc/connlabel.conf.

DCCP PKTTYPE TYPE
~~~~~~~~~~~~~~~~
[options="header"]
|==================
|Name | Keyword | Size | Base type
|DCCP packet type |
dccp_pkttype |
4 bit |
integer
|===================

The DCCP packet type abstracts the different legal values of the respective
four bit field in the DCCP header, as stated by RFC4340. Note that possible
values 10-15 are considered reserved and therefore not allowed to be used. In
iptables' *dccp* match, these values are aliased 'INVALID'. With nftables, one
may simply match on the numeric value range, i.e. *10-15*.

.keywords may be used when specifying the DCCP packet type
[options="header"]
|==================
|Keyword |Value
|request|
0
|response|
1
|data|
2
|ack|
3
|dataack|
4
|closereq|
5
|close|
6
|reset|
7
|sync|
8
|syncack|
9
|=================