rfc-9164

Concise Binary Object Representation (CBOR) Tags for IPv4 and IPv6 Addresses and Prefixes

M. Richardson, C. Bormann
date2021-12 streamIETF areaart wgcbor statusPROPOSED STANDARD pages10 canonicalhttps://www.rfc-editor.org/rfc/rfc9164 doi10.17487/RFC9164
This specification defines two Concise Binary Object Representation (CBOR) tags for use with IPv6 and IPv4 addresses and prefixes.

Extracted elements (26)

design-rationale §3.2

Tag 54 was chosen for IPv6 and tag 52 for IPv4 because 54 and 52 are the ASCII codes for '6' and '4' respectively, providing a memorable mnemonic for implementers.

cbor, ip

design-rationale §1

Tags 260 and 261 were insufficient: tag 260 distinguishes IPv6, IPv4, and MAC addresses only by byte-string length, making it impossible to drop trailing zeros in encodings, and tag 261 was not documented well enough for use. Tags 54 and 52 were introduced to explicitly signal IPv6 vs. IPv4 by tag number.

cbor, ip

design-rationale §1

The prefix format omits trailing zero bytes to save space; the pure address format does not omit trailing zeros because the complexity of testing was judged to outweigh the marginal benefit for fixed-length addresses.

cbor, ip

design-rationale §4.1

The tag validity rules combined with RFC 8949's deterministic encoding rules (Section 4.2.1) make the encoding of tags 54 and 52 fully deterministic with no additional considerations required under Section 4.2.2 of RFC 8949.

cbor, ip

interoperability-note §1

Tags 260 and 261 are deprecated in favor of tags 52 and 54. New implementations should use 52 and 54; tag 260 cannot distinguish IPv6 from IPv4 from MAC addresses without relying solely on byte-string length, preventing trailing-zero omission.

cbor, ip

normative-requirement §4.3 MUST

A decoder MUST check that all unused bits in the prefix byte string (bits to the right of the prefix length) are zero.

cbor, ip

normative-requirement §4.3 MUST

A decoder MUST check that the prefix byte string does not end in a zero byte.

cbor, ip

normative-requirement §4.3 MUST

A decoder MUST handle cases where a prefix length specifies more bits are relevant than are actually present in the encoded byte string, because encoders are required to remove zero-valued trailing bytes. For example, ::/128 is encoded as 54([128, h'']).

cbor, ip

normative-requirement §4.2 MUST

An encoder MUST omit any right-aligned (trailing) sequence of bytes in which all bytes are zero from the prefix byte string. There is no relationship between the number of bytes omitted and the prefix length; for example, 2001:db8::/64 encodes as 54([64, h'20010db8']).

cbor, ip

normative-requirement §4.2 MUST

An encoder MUST set any unused bytes and any unused bits in the final byte of a prefix byte string to zero. Unused bits are those not covered by the declared prefix length.

cbor, ip

protocol-element §4

Tag validity is defined by the CDDL rule ip-address-or-prefix (Figure 1), which constrains overall structure, integer value ranges (IPv6 prefix length 0..128, IPv4 0..32), and byte-string lengths (IPv6 address exactly 16 bytes, IPv4 exactly 4 bytes, prefix byte strings at most 16 or 4 bytes). An instance is valid if it matches this rule and satisfies the encoder/decoder prefix constraints of Sections 4.2 and 4.3.

cbor, ip

protocol-element §3.1

Tags 54 and 52 each support three encoding forms: Address Format (tag applied to a byte string), Prefix Format (tag applied to a two-element array [prefix-length, truncated-bytes]), and Interface Format (tag applied to a two-element array [full-address-bytes, prefix-length] with an optional third zone-identifier element).

cbor, ip

protocol-element §5

The CDDL definitions in Figure 1 provide canonical type names for tags 54 and 52: ipv6-address-or-prefix, ipv4-address-or-prefix, ipv6-prefix, ipv4-prefix, ipv6-address-with-prefix, ipv4-address-with-prefix, and ip-zone-identifier. These names are recommended for use in CDDL schemas that reference these tags.

cbor, ip

protocol-element §3.1.3

The zone identifier, an optional third element in the Interface Format array, represents a link-local or multicast scope per RFC 4007. It may be an unsigned integer (interface index) or a text string (interface name), and is strictly local to the node. The prefix length field may be replaced with CBOR null (0xF6) when only an address with zone identifier is needed.

cbor, ip

registry §7.3

IANA added the note 'DEPRECATED in favor of 52 and 54 for IP addresses' to existing CBOR tag registrations 260 and 261.

cbor, ip, registry

registry §7.2

IANA allocated CBOR tag 52 (from the Specification Required area of the CBOR Tags registry) for IPv4 uses. Data item: byte string or array. Semantics: IPv4, [prefixlen, IPv4], [IPv4, prefixpart].

cbor, ip, registry

registry §7.1

IANA allocated CBOR tag 54 (from the Specification Required area of the CBOR Tags registry) for IPv6 uses. Data item: byte string or array. Semantics: IPv6, [prefixlen, IPv6], [IPv6, prefixpart].

cbor, ip, registry

security-consideration §6

Applications using these tags MUST check tag validity (Section 4) before acting on any content and before transforming the tag into a platform-specific representation, since such transformation could conceal validity errors. Validity checking may be done in a generic CBOR library or in the application, but it must happen in one of them.

cbor, ip, security

security-consideration §6

Explicitly identifying byte sequences as IPv4 or IPv6 addresses via these tags may allow an attacker or eavesdropper to better understand which parts of a packet to target. Applications must consider the security implications of exposing address information in their specific deployment context.

cbor, ip, security

security-consideration §6

The right-hand bits of a prefix after the prefix length are required to be zero; this prevents a malicious party from using those bits to transmit covert data. Such abuse is detected by tag validity checking and also by inspection of the raw protocol bytes.

cbor, ip, security

wire-format §3.3

An IPv4 address is encoded as a 4-byte byte string (CBOR major type 2) enclosed in tag 52. Example: 52(h'c0000201') for 192.0.2.1.

cbor, ip

wire-format §3.3

An IPv4 address-with-prefix (Interface Format) is encoded as tag 52 wrapping a two-element array with the full 4-byte address first, followed by the network prefix length; the Prefix Format and Interface Format are distinguished solely by whether the first array element is an integer (prefix) or a byte string (interface address).

cbor, ip

wire-format §3.3

An IPv4 prefix is encoded as tag 52 wrapping a two-element array with the prefix length (unsigned integer) first, followed by the minimal-length prefix byte string with trailing zero bytes omitted. Example: 52([24, h'c00002']) for 192.0.2.0/24.

cbor, ip

wire-format §3.2

An IPv6 address is encoded as a 16-byte byte string (CBOR major type 2) enclosed in tag 54. Example: 54(h'20010db81234deedbeefcafefacefeed').

cbor, ip

wire-format §3.2

An IPv6 address-with-prefix (Interface Format) is encoded as tag 54 wrapping a two-element array with the full 16-byte address first, followed by the network prefix length; an optional third element carries the zone identifier as an integer (interface index) or text string (interface name).

cbor, ip

wire-format §3.2

An IPv6 prefix is encoded as tag 54 wrapping a two-element array with the prefix length (unsigned integer) first, followed by the minimal-length prefix byte string with trailing zero bytes omitted. Example: 54([48, h'20010db81234']) for 2001:db8:1234::/48.

cbor, ip