+/* Open vSwitch fields
+ * ===================
+ *
+ * A "field" is a property of a packet. Most familiarly, "data fields" are
+ * fields that can be extracted from a packet.
+ *
+ * Some data fields are always present as a consequence of the basic networking
+ * technology in use. Ethernet is the assumed base technology for current
+ * versions of OpenFlow and Open vSwitch, so Ethernet header fields are always
+ * available.
+ *
+ * Other data fields are not always present. A packet contains ARP fields, for
+ * example, only when its Ethernet header indicates the Ethertype for ARP,
+ * 0x0806. We say that a field is "applicable" when it is it present in a
+ * packet, and "inapplicable" when it is not, and refer to the conditions that
+ * determine whether a field is applicable as "prerequisites". Some
+ * VLAN-related fields are a special case: these fields are always applicable,
+ * but have a designated value or bit that indicates whether a VLAN header is
+ * present, with the remaining values or bits indicating the VLAN header's
+ * content (if it is present). See MFF_VLAN_TCI for an example.
+ *
+ * Conceptually, an inapplicable field does not have a value, not even a
+ * nominal ``value'' such as all-zero-bits. In many circumstances, OpenFlow
+ * and Open vSwitch allow references only to applicable fields. For example,
+ * one may match a given field only if the match includes the field's
+ * prerequisite, e.g. matching an ARP field is only allowed if one also matches
+ * on Ethertype 0x0806.
+ *
+ * (Practically, however, OVS represents a field's value as some fixed member
+ * in its "struct flow", so accessing that member will obtain some value. Some
+ * members are used for more than one purpose, e.g. the "tp_src" member
+ * represents the TCP, UDP, and SCTP source port, so the value read may not
+ * even make sense. For this reason, it is important to know whether a field's
+ * prerequisites are satisfied before attempting to read it.)
+ *
+ * Sometimes a packet may contain multiple instances of a header. For example,
+ * a packet may contain multiple VLAN or MPLS headers, and tunnels can cause
+ * any data field to recur. OpenFlow and Open vSwitch do not address these
+ * cases uniformly. For VLAN and MPLS headers, only the outermost header is
+ * accessible, so that inner headers may be accessed only by ``popping''
+ * (removing) the outer header. (Open vSwitch supports only a single VLAN
+ * header in any case.) For tunnels, e.g. GRE or VXLAN, the outer header and
+ * inner headers are treated as different data fields.
+ *
+ * OpenFlow and Open vSwitch support some fields other than data fields.
+ * "Metadata fields" relate to the origin or treatment of a packet, but they
+ * are not extracted from the packet data itself. One example is the physical
+ * port on which a packet arrived at the switch. "Register fields" act like
+ * variables: they give an OpenFlow switch space for temporary storage while
+ * processing a packet. Existing metadata and register fields have no
+ * prerequisites.
+ *
+ * A field's value consists of an integral number of bytes. Most data fields
+ * are copied directly from protocol headers, e.g. at layer 2, MFF_ETH_SRC is
+ * copied from the Ethernet source address and MFF_ETH_DST from the destination
+ * address. Other data fields are copied from a packet with padding, usually
+ * with zeros and in the most significant positions (see e.g. MFF_MPLS_LABEL)
+ * but not always (see e.g. MFF_IP_DSCP). A final category of data fields is
+ * transformed in other ways as they are copied from the packets, to make them
+ * more useful for matching, e.g. MFF_IP_FRAG describes whether a packet is a
+ * fragment but it is not copied directly from the IP header.
+ *
+ *
+ * Field specifications
+ * ====================
+ *
+ * Each of the enumeration values below represents a field. The comments
+ * preceding each enum must be in a stylized form that is parsed at compile
+ * time by the extract-ofp-fields program. The comment itself consists of a
+ * series of paragraphs separate by blank lines. The paragraphs consist of:
+ *
+ * - The first paragraph gives the user-visible name of the field as a
+ * quoted string. This is the name used for parsing and formatting the
+ * field.
+ *
+ * For historical reasons, some fields have an additional name that is
+ * accepted as an alternative in parsing. This name, when there is one,
+ * is given as a quoted string in parentheses along with "aka". For
+ * example:
+ *
+ * "tun_id" (aka "tunnel_id").
+ *
+ * New fields should have only one name.
+ *
+ * - Any number of paragraphs of free text that describe the field. This
+ * is meant for human readers, so extract-ofp-fields ignores it.
+ *
+ * - A final paragraph that consists of a series of key-value pairs, one
+ * per line, in the form "key: value." where the period at the end of the
+ * line is a mandatory part of the syntax.
+ *
+ * Every field must specify the following key-value pairs:
+ *
+ * Type:
+ *
+ * The format and size of the field's value. Some possible values are
+ * generic:
+ *
+ * u8: A one-byte field.
+ * be16: A two-byte field.
+ * be32: A four-byte field.
+ * be64: An eight-byte field.
+ *
+ * The remaining values imply more about the value's semantics, though OVS
+ * does not currently take advantage of this additional information:
+ *
+ * MAC: A six-byte field whose value is an Ethernet address.
+ * IPv6: A 16-byte field whose value is an IPv6 address.
+ * tunnelMD: A variable length field, up to 124 bytes, that carries
+ * tunnel metadata.
+ *
+ * Maskable:
+ *
+ * Either "bitwise", if OVS supports matching any subset of bits in the
+ * field, or "no", if OVS only supports matching or wildcarding the entire
+ * field.
+ *
+ * Formatting:
+ *
+ * Explains how a field's value is formatted and parsed for human
+ * consumption. Some of the options are fairly generally useful:
+ *
+ * decimal: Formats the value as a decimal number. On parsing, accepts
+ * decimal (with no prefix), hexadecimal with 0x prefix, or octal
+ * with 0 prefix.
+ *
+ * hexadecimal: Same as decimal except nonzero values are formatted in
+ * hex with 0x prefix. The default for parsing is *not* hexadecimal:
+ * only with a 0x prefix is the input in hexadecimal.
+ *
+ * Ethernet: Formats and accepts the common format xx:xx:xx:xx:xx:xx.
+ * 6-byte fields only.
+ *
+ * IPv4: Formats and accepts the common format w.x.y.z. 4-byte fields
+ * only.
+ *
+ * IPv6: Formats and accepts the common IPv6 formats. 16-byte fields
+ * only.
+ *
+ * OpenFlow 1.0 port: Accepts an OpenFlow well-known port name
+ * (e.g. "IN_PORT") in uppercase or lowercase, or a 16-bit port
+ * number in decimal. Formats ports using their well-known names in
+ * uppercase, or in decimal otherwise. 2-byte fields only.
+ *
+ * OpenFlow 1.1+ port: Same syntax as for OpenFlow 1.0 ports but for
+ * 4-byte OpenFlow 1.1+ port number fields.
+ *
+ * Others are very specific to particular fields:
+ *
+ * frag: One of the strings "no", "first", "later", "yes", "not_later"
+ * describing which IPv4/v6 fragments are matched.
+ *
+ * tunnel flags: Any number of the strings "df", "csum", "key", or
+ * "oam" separated by "|".
+ *
+ * TCP flags: See the description of tcp_flags in ovs-ofctl(8).
+ *
+ * Prerequisites:
+ *
+ * The field's prerequisites. The values should be straightfoward.
+ *
+ * Access:
+ *
+ * Either "read-only", for a field that cannot be changed via OpenFlow, or
+ * "read/write" for a modifiable field.
+ *
+ * NXM:
+ *
+ * If the field has an NXM field assignment, then this specifies the NXM
+ * name of the field (e.g. "NXM_OF_ETH_SRC"), followed by its nxm_type in
+ * parentheses, followed by "since v<x>.<y>" specifying the version of Open
+ * vSwitch that first supported this field in NXM (e.g. "since v1.1" if it
+ * was introduced in Open vSwitch 1.1).
+ *
+ * The NXM name must begin with NXM_OF_ or NXM_NX_. This allows OVS to
+ * determine the correct NXM class.
+ *
+ * If the field does not have an NXM field assignment, specify "none".
+ *
+ * OXM:
+ *
+ * If the field has an OXM field assignment, then this specifies the OXM
+ * name of the field (e.g. "OXM_OF_ETH_SRC"), followed by its nxm_type in
+ * parentheses, followed by "since OF<a>.<b> v<x>.<y>" specifying the
+ * versions of OpenFlow and Open vSwitch that first supported this field in
+ * OXM (e.g. "since OF1.3 and v1.10" if it was introduced in OpenFlow 1.3
+ * and first supported by Open vSwitch in version 1.10).
+ *
+ * Some fields have more than one OXM field assignment. For example,
+ * actset_output has an experimenter OXM assignment in OpenFlow 1.3 and a
+ * standard OXM assignment in OpenFlow 1.5. In such a case, specify both,
+ * separated by commas.
+ *
+ * OVS uses the start of the OXM field name to determine the correct OXM
+ * class. To support a new OXM class, edit the mapping table in
+ * build-aux/extract-ofp-fields.
+ *
+ * If the field does not have an OXM field assignment, specify "none".
+ *
+ * The following key-value pairs are optional. Open vSwitch already supports
+ * all the fields to which they apply, so new fields should probably not
+ * include these pairs:
+ *
+ * OF1.0:
+ *
+ * Specify this as "exact match" if OpenFlow 1.0 can match or wildcard the
+ * entire field, or as "CIDR mask" if OpenFlow 1.0 can match any CIDR
+ * prefix of the field. (OpenFlow 1.0 did not support bitwise matching.)
+ * Omit, if OpenFlow 1.0 did not support this field.
+ *
+ * OF1.1:
+ *
+ * Specify this as "exact match" if OpenFlow 1.1 can match or wildcard the
+ * entire field, or as "bitwise" if OpenFlow 1.1 can match any subset of
+ * bits in the field. Omit, if OpenFlow 1.1 did not support this field.
+ *
+ * The following key-value pair is optional:
+ *
+ * Prefix lookup member:
+ *
+ * If this field makes sense for use with classifier_set_prefix_fields(),
+ * specify the name of the "struct flow" member that corresponds to the
+ * field.
+ *
+ * Finally, a few "register" fields have very similar names and purposes,
+ * e.g. MFF_REG0 through MFF_REG7. For these, the comments may be merged
+ * together using <N> as a metasyntactic variable for the numeric suffix.
+ * Lines in the comment that are specific to one of the particular fields by
+ * writing, e.g. <1>, to consider that line only for e.g. MFF_REG1.
+ */
+
+enum OVS_PACKED_ENUM mf_field_id {
+/* ## -------- ## */
+/* ## Metadata ## */
+/* ## -------- ## */
+
+ /* "dp_hash".
+ *
+ * Flow hash computed in the datapath. Internal use only, not programmable
+ * from controller.
+ *
+ * The OXM code point for this is an attempt to test OXM experimenter
+ * support, which is otherwise difficult to test due to the dearth of use
+ * out in the wild. Because controllers can't add flows that match on
+ * dp_hash, this doesn't commit OVS to supporting this OXM experimenter
+ * code point in the future.
+ *
+ * Type: be32.
+ * Maskable: bitwise.
+ * Formatting: hexadecimal.
+ * Prerequisites: none.
+ * Access: read-only.
+ * NXM: NXM_NX_DP_HASH(35) since v2.2.
+ * OXM: NXOXM_ET_DP_HASH(0) since OF1.5 and v2.4.
+ */
+ MFF_DP_HASH,
+
+ /* "recirc_id".
+ *
+ * ID for recirculation. The value 0 is reserved for initially received
+ * packets. Internal use only, not programmable from controller.
+ *
+ * Type: be32.
+ * Maskable: no.
+ * Formatting: decimal.
+ * Prerequisites: none.
+ * Access: read-only.
+ * NXM: NXM_NX_RECIRC_ID(36) since v2.2.
+ * OXM: none.
+ */
+ MFF_RECIRC_ID,
+
+ /* "conj_id".
+ *
+ * ID for "conjunction" actions. Please refer to ovs-ofctl(8)
+ * documentation of "conjunction" for details.
+ *
+ * Type: be32.
+ * Maskable: no.
+ * Formatting: decimal.
+ * Prerequisites: none.
+ * Access: read-only.
+ * NXM: NXM_NX_CONJ_ID(37) since v2.4.
+ * OXM: none. */
+ MFF_CONJ_ID,
+
+ /* "tun_id" (aka "tunnel_id").
+ *
+ * The "key" or "tunnel ID" or "VNI" in a packet received via a keyed
+ * tunnel. For protocols in which the key is shorter than 64 bits, the key
+ * is stored in the low bits and the high bits are zeroed. For non-keyed
+ * tunnels and packets not received via a tunnel, the value is 0.
+ *
+ * Type: be64.
+ * Maskable: bitwise.
+ * Formatting: hexadecimal.
+ * Prerequisites: none.
+ * Access: read/write.
+ * NXM: NXM_NX_TUN_ID(16) since v1.1.
+ * OXM: OXM_OF_TUNNEL_ID(38) since OF1.3 and v1.10.
+ * Prefix lookup member: tunnel.tun_id.
+ */
+ MFF_TUN_ID,
+
+ /* "tun_src".
+ *
+ * The IPv4 source address in the outer IP header of a tunneled packet.
+ *
+ * For non-tunneled packets, the value is 0.
+ *
+ * Type: be32.
+ * Maskable: bitwise.
+ * Formatting: IPv4.
+ * Prerequisites: none.
+ * Access: read/write.
+ * NXM: NXM_NX_TUN_IPV4_SRC(31) since v2.0.
+ * OXM: none.
+ * Prefix lookup member: tunnel.ip_src.
+ */
+ MFF_TUN_SRC,
+
+ /* "tun_dst".
+ *
+ * The IPv4 destination address in the outer IP header of a tunneled
+ * packet.
+ *
+ * For non-tunneled packets, the value is 0.
+ *
+ * Type: be32.
+ * Maskable: bitwise.
+ * Formatting: IPv4.
+ * Prerequisites: none.
+ * Access: read/write.
+ * NXM: NXM_NX_TUN_IPV4_DST(32) since v2.0.
+ * OXM: none.
+ * Prefix lookup member: tunnel.ip_dst.
+ */
+ MFF_TUN_DST,
+
+ /* "tun_ipv6_src".
+ *
+ * The IPv6 source address in the outer IP header of a tunneled packet.
+ *
+ * For non-tunneled packets, the value is 0.
+ *
+ * Type: be128.
+ * Maskable: bitwise.
+ * Formatting: IPv6.
+ * Prerequisites: none.
+ * Access: read/write.
+ * NXM: NXM_NX_TUN_IPV6_SRC(109) since v2.5.
+ * OXM: none.
+ * Prefix lookup member: tunnel.ipv6_src.
+ */
+ MFF_TUN_IPV6_SRC,
+
+ /* "tun_ipv6_dst".
+ *
+ * The IPv6 destination address in the outer IP header of a tunneled
+ * packet.
+ *
+ * For non-tunneled packets, the value is 0.
+ *
+ * Type: be128.
+ * Maskable: bitwise.
+ * Formatting: IPv6.
+ * Prerequisites: none.
+ * Access: read/write.
+ * NXM: NXM_NX_TUN_IPV6_DST(110) since v2.5.
+ * OXM: none.
+ * Prefix lookup member: tunnel.ipv6_dst.
+ */
+ MFF_TUN_IPV6_DST,
+
+ /* "tun_flags".
+ *
+ * Flags representing aspects of tunnel behavior.
+ *
+ * This field currently only has a single flag defined:
+ *
+ * - NX_TUN_FLAG_OAM: The tunnel protocol indicated that this is an
+ * OAM control packet.
+ *
+ * The switch may reject matches against values that it is not aware of.
+ *
+ * Note that it is possible for newer version of Open vSwitch to
+ * introduce additional flags with varying meaning. It is therefore not
+ * recommended to use an exact match on this field since the behavior of
+ * these new flags is unknown and should be ignored.
+ *
+ * For non-tunneled packets, the value is 0.
+ *
+ * Type: be16 (low 1 bits).
+ * Maskable: bitwise.
+ * Formatting: tunnel flags.
+ * Prerequisites: none.
+ * Access: read/write.
+ * NXM: NXM_NX_TUN_FLAGS(104) since v2.5.
+ * OXM: none.
+ */
+ MFF_TUN_FLAGS,
+
+ /* "tun_ttl".
+ *
+ * The TTL in the outer IP header of a tunneled packet. Internal use only,
+ * not programmable from controller.
+ *
+ * For non-tunneled packets, the value is 0.
+ *
+ * Type: u8.
+ * Maskable: no.
+ * Formatting: decimal.
+ * Prerequisites: none.
+ * Access: read-only.
+ * NXM: none.
+ * OXM: none.
+ */
+ MFF_TUN_TTL,
+
+ /* "tun_tos".
+ *
+ * The ToS value in the outer IP header of a tunneled packet. Internal use
+ * only, not programmable from controller.
+ *
+ * Type: u8.
+ * Maskable: no.
+ * Formatting: decimal.
+ * Prerequisites: none.
+ * Access: read-only.
+ * NXM: none.
+ * OXM: none.
+ */
+ MFF_TUN_TOS,
+
+ /* "tun_gbp_id".
+ *
+ * VXLAN Group Policy ID
+ *
+ * Type: be16.
+ * Maskable: bitwise.
+ * Formatting: decimal.
+ * Prerequisites: none.
+ * Access: read/write.
+ * NXM: NXM_NX_TUN_GBP_ID(38) since v2.4.
+ * OXM: none.
+ */
+ MFF_TUN_GBP_ID,
+
+ /* "tun_gbp_flags".
+ *
+ * VXLAN Group Policy flags
+ *
+ * Type: u8.
+ * Maskable: bitwise.
+ * Formatting: hexadecimal.
+ * Prerequisites: none.
+ * Access: read/write.
+ * NXM: NXM_NX_TUN_GBP_FLAGS(39) since v2.4.
+ * OXM: none.
+ */
+ MFF_TUN_GBP_FLAGS,
+
+#if TUN_METADATA_NUM_OPTS == 64
+ /* "tun_metadata<N>".
+ *
+ * Encapsulation metadata for tunnels.
+ *
+ * Each NXM can be dynamically mapped onto a particular tunnel field using
+ * OpenFlow commands. The individual NXMs can each carry up to 124 bytes
+ * of data and a combined total of 256 across all allocated fields.
+ *
+ * Type: tunnelMD.
+ * Maskable: bitwise.
+ * Formatting: hexadecimal.
+ * Prerequisites: none.
+ * Access: read/write.
+ * NXM: NXM_NX_TUN_METADATA0(40) since v2.5. <0>
+ * NXM: NXM_NX_TUN_METADATA1(41) since v2.5. <1>
+ * NXM: NXM_NX_TUN_METADATA2(42) since v2.5. <2>
+ * NXM: NXM_NX_TUN_METADATA3(43) since v2.5. <3>
+ * NXM: NXM_NX_TUN_METADATA4(44) since v2.5. <4>
+ * NXM: NXM_NX_TUN_METADATA5(45) since v2.5. <5>
+ * NXM: NXM_NX_TUN_METADATA6(46) since v2.5. <6>
+ * NXM: NXM_NX_TUN_METADATA7(47) since v2.5. <7>
+ * NXM: NXM_NX_TUN_METADATA8(48) since v2.5. <8>
+ * NXM: NXM_NX_TUN_METADATA9(49) since v2.5. <9>
+ * NXM: NXM_NX_TUN_METADATA10(50) since v2.5. <10>
+ * NXM: NXM_NX_TUN_METADATA11(51) since v2.5. <11>
+ * NXM: NXM_NX_TUN_METADATA12(52) since v2.5. <12>
+ * NXM: NXM_NX_TUN_METADATA13(53) since v2.5. <13>
+ * NXM: NXM_NX_TUN_METADATA14(54) since v2.5. <14>
+ * NXM: NXM_NX_TUN_METADATA15(55) since v2.5. <15>
+ * NXM: NXM_NX_TUN_METADATA16(56) since v2.5. <16>
+ * NXM: NXM_NX_TUN_METADATA17(57) since v2.5. <17>
+ * NXM: NXM_NX_TUN_METADATA18(58) since v2.5. <18>
+ * NXM: NXM_NX_TUN_METADATA19(59) since v2.5. <19>
+ * NXM: NXM_NX_TUN_METADATA20(60) since v2.5. <20>
+ * NXM: NXM_NX_TUN_METADATA21(61) since v2.5. <21>
+ * NXM: NXM_NX_TUN_METADATA22(62) since v2.5. <22>
+ * NXM: NXM_NX_TUN_METADATA23(63) since v2.5. <23>
+ * NXM: NXM_NX_TUN_METADATA24(64) since v2.5. <24>
+ * NXM: NXM_NX_TUN_METADATA25(65) since v2.5. <25>
+ * NXM: NXM_NX_TUN_METADATA26(66) since v2.5. <26>
+ * NXM: NXM_NX_TUN_METADATA27(67) since v2.5. <27>
+ * NXM: NXM_NX_TUN_METADATA28(68) since v2.5. <28>
+ * NXM: NXM_NX_TUN_METADATA29(69) since v2.5. <29>
+ * NXM: NXM_NX_TUN_METADATA30(70) since v2.5. <30>
+ * NXM: NXM_NX_TUN_METADATA31(71) since v2.5. <31>
+ * NXM: NXM_NX_TUN_METADATA32(72) since v2.5. <32>
+ * NXM: NXM_NX_TUN_METADATA33(73) since v2.5. <33>
+ * NXM: NXM_NX_TUN_METADATA34(74) since v2.5. <34>
+ * NXM: NXM_NX_TUN_METADATA35(75) since v2.5. <35>
+ * NXM: NXM_NX_TUN_METADATA36(76) since v2.5. <36>
+ * NXM: NXM_NX_TUN_METADATA37(77) since v2.5. <37>
+ * NXM: NXM_NX_TUN_METADATA38(78) since v2.5. <38>
+ * NXM: NXM_NX_TUN_METADATA39(79) since v2.5. <39>
+ * NXM: NXM_NX_TUN_METADATA40(80) since v2.5. <40>
+ * NXM: NXM_NX_TUN_METADATA41(81) since v2.5. <41>
+ * NXM: NXM_NX_TUN_METADATA42(82) since v2.5. <42>
+ * NXM: NXM_NX_TUN_METADATA43(83) since v2.5. <43>
+ * NXM: NXM_NX_TUN_METADATA44(84) since v2.5. <44>
+ * NXM: NXM_NX_TUN_METADATA45(85) since v2.5. <45>
+ * NXM: NXM_NX_TUN_METADATA46(86) since v2.5. <46>
+ * NXM: NXM_NX_TUN_METADATA47(87) since v2.5. <47>
+ * NXM: NXM_NX_TUN_METADATA48(88) since v2.5. <48>
+ * NXM: NXM_NX_TUN_METADATA49(89) since v2.5. <49>
+ * NXM: NXM_NX_TUN_METADATA50(90) since v2.5. <50>
+ * NXM: NXM_NX_TUN_METADATA51(91) since v2.5. <51>
+ * NXM: NXM_NX_TUN_METADATA52(92) since v2.5. <52>
+ * NXM: NXM_NX_TUN_METADATA53(93) since v2.5. <53>
+ * NXM: NXM_NX_TUN_METADATA54(94) since v2.5. <54>
+ * NXM: NXM_NX_TUN_METADATA55(95) since v2.5. <55>
+ * NXM: NXM_NX_TUN_METADATA56(96) since v2.5. <56>
+ * NXM: NXM_NX_TUN_METADATA57(97) since v2.5. <57>
+ * NXM: NXM_NX_TUN_METADATA58(98) since v2.5. <58>
+ * NXM: NXM_NX_TUN_METADATA59(99) since v2.5. <59>
+ * NXM: NXM_NX_TUN_METADATA60(100) since v2.5. <60>
+ * NXM: NXM_NX_TUN_METADATA61(101) since v2.5. <61>
+ * NXM: NXM_NX_TUN_METADATA62(102) since v2.5. <62>
+ * NXM: NXM_NX_TUN_METADATA63(103) since v2.5. <63>
+ * OXM: none.
+ */
+ MFF_TUN_METADATA0,
+ MFF_TUN_METADATA1,
+ MFF_TUN_METADATA2,
+ MFF_TUN_METADATA3,
+ MFF_TUN_METADATA4,
+ MFF_TUN_METADATA5,
+ MFF_TUN_METADATA6,
+ MFF_TUN_METADATA7,
+ MFF_TUN_METADATA8,
+ MFF_TUN_METADATA9,
+ MFF_TUN_METADATA10,
+ MFF_TUN_METADATA11,
+ MFF_TUN_METADATA12,
+ MFF_TUN_METADATA13,
+ MFF_TUN_METADATA14,
+ MFF_TUN_METADATA15,
+ MFF_TUN_METADATA16,
+ MFF_TUN_METADATA17,
+ MFF_TUN_METADATA18,
+ MFF_TUN_METADATA19,
+ MFF_TUN_METADATA20,
+ MFF_TUN_METADATA21,
+ MFF_TUN_METADATA22,
+ MFF_TUN_METADATA23,
+ MFF_TUN_METADATA24,
+ MFF_TUN_METADATA25,
+ MFF_TUN_METADATA26,
+ MFF_TUN_METADATA27,
+ MFF_TUN_METADATA28,
+ MFF_TUN_METADATA29,
+ MFF_TUN_METADATA30,
+ MFF_TUN_METADATA31,
+ MFF_TUN_METADATA32,
+ MFF_TUN_METADATA33,
+ MFF_TUN_METADATA34,
+ MFF_TUN_METADATA35,
+ MFF_TUN_METADATA36,
+ MFF_TUN_METADATA37,
+ MFF_TUN_METADATA38,
+ MFF_TUN_METADATA39,
+ MFF_TUN_METADATA40,
+ MFF_TUN_METADATA41,
+ MFF_TUN_METADATA42,
+ MFF_TUN_METADATA43,
+ MFF_TUN_METADATA44,
+ MFF_TUN_METADATA45,
+ MFF_TUN_METADATA46,
+ MFF_TUN_METADATA47,
+ MFF_TUN_METADATA48,
+ MFF_TUN_METADATA49,
+ MFF_TUN_METADATA50,
+ MFF_TUN_METADATA51,
+ MFF_TUN_METADATA52,
+ MFF_TUN_METADATA53,
+ MFF_TUN_METADATA54,
+ MFF_TUN_METADATA55,
+ MFF_TUN_METADATA56,
+ MFF_TUN_METADATA57,
+ MFF_TUN_METADATA58,
+ MFF_TUN_METADATA59,
+ MFF_TUN_METADATA60,
+ MFF_TUN_METADATA61,
+ MFF_TUN_METADATA62,
+ MFF_TUN_METADATA63,
+#else
+#error "Need to update MFF_TUN_METADATA* to match TUN_METADATA_NUM_OPTS"