rfc9164v1.txt		rfc9164.txt
	skipping to change at line 84 ¶		skipping to change at line 84 ¶
	[RFC8949] defines a number of CBOR tags for common items. Tags 260		[RFC8949] defines a number of CBOR tags for common items. Tags 260
	and 261 were later defined in drafts listed with IANA		and 261 were later defined in drafts listed with IANA
	[IANA.cbor-tags]. These tags were intended to cover addresses (260)		[IANA.cbor-tags]. These tags were intended to cover addresses (260)
	and prefixes (261). Tag 260 distinguishes between IPv6, IPv4, and		and prefixes (261). Tag 260 distinguishes between IPv6, IPv4, and
	MAC [RFC7042] addresses only through the length of the byte string,		MAC [RFC7042] addresses only through the length of the byte string,
	making it impossible, for example, to drop trailing zeros in the		making it impossible, for example, to drop trailing zeros in the
	encoding of IP addresses. Tag 261 was not documented well enough for		encoding of IP addresses. Tag 261 was not documented well enough for
	use.		use.
	This specification defines tags 54 and 52 achieving an explicit		This specification defines tags 54 and 52 to explicitly indicate use
	indication of IPv6 or IPv4 by the tag number. These new tags are		of IPv6 or IPv4 by the tag number. These new tags are intended to be
	intended to be used in preference to tags 260 and 261. They provide		used in preference to tags 260 and 261. They provide formats for
	formats for IPv6 and IPv4 addresses, prefixes, and addresses with		IPv6 and IPv4 addresses, prefixes, and addresses with prefixes, while
	prefixes, achieving an explicit indication of IPv6 or IPv4. The		explicitly indicating use of IPv6 or IPv4. The prefix format omits
	prefix format omits trailing zeroes in the address part. (Due to the		trailing zeroes in the address part. (Due to the complexity of
	complexity of testing, the value of omitting trailing zeros for the		testing, the value of omitting trailing zeros for the pure address
	pure address format was considered nonessential, and support for that		format was considered nonessential, and support for that is not
	is not provided in this specification.) This specification does not		provided in this specification.) This specification does not deal
	deal with MAC addresses (Section 2 of [RFC7042]) as they are used for		with MAC addresses (Section 2 of [RFC7042]).
	Ethernet.
	2. Terminology		2. Terminology
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in		"OPTIONAL" in this document are to be interpreted as described in
	BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all		BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
	capitals, as shown here.		capitals, as shown here.
	3. Protocol		3. Protocol
	skipping to change at line 117 ¶		skipping to change at line 116 ¶
	3.1.1. Addresses		3.1.1. Addresses
	These tags can be applied to byte strings to represent a single		These tags can be applied to byte strings to represent a single
	address.		address.
	This form is called the "Address Format".		This form is called the "Address Format".
	3.1.2. Prefixes		3.1.2. Prefixes
	When applied to an array that starts with an unsigned integer, they		When applied to an array that starts with an unsigned integer, the
	represent a CIDR-style prefix of that length.		tags represent a CIDR-style prefix of that length.
	When the Address Format (i.e., without prefix) appears in a context		When the Address Format (i.e., without prefix) appears in a context
	where a prefix is expected, then it is to be assumed that all bits		where a prefix is expected, then it is to be assumed that all bits
	are relevant. That is, for IPv4, a /32 is implied, and for IPv6, a		are relevant. That is, for IPv4, a /32 is implied, and for IPv6, a
	/128 is implied.		/128 is implied.
	This form is called the "Prefix Format".		This form is called the "Prefix Format".
	3.1.3. Interface Definition		3.1.3. Interface Definition
	When applied to an array that starts with a byte string, which stands		When applied to an array that starts with a byte string, which stands
	for an IP address, followed by an unsigned integer giving the bit		for an IP address, followed by an unsigned integer giving the bit
	length of a prefix built out of the first length bits of the address,		length of a prefix built out of the first length bits of the address,
	they represent information that is commonly used to specify both the		the tags represent information that is commonly used to specify both
	network prefix and the IP address of an interface.		the network prefix and the IP address of an interface.
	The length of the byte string is always 16 bytes (for IPv6) and 4		The length of the byte string is always 16 bytes (for IPv6) and 4
	bytes (for IPv4).		bytes (for IPv4).
	This form is called the "Interface Format".		This form is called the "Interface Format".
	Interface Format definitions support an optional third element to the		Interface Format definitions support an optional third element to the
	array, which is to be used as the IPv6 link-local zone identifier		array, which is to be used as the IPv6 link-local zone identifier
	from Section 6 of [RFC4007]; for symmetry, this is also provided for		from Section 6 of [RFC4007]; for symmetry, this is also provided for
	IPv4 as in [RFC4001] and [RFC6991]. The zone identifier may be an		IPv4 as in [RFC4001] and [RFC6991]. The zone identifier may be an
	skipping to change at line 270 ¶		skipping to change at line 269 ¶
	[RFC8949], lead to deterministic encoding for tags 54 and 52 and		[RFC8949], lead to deterministic encoding for tags 54 and 52 and
	require no further additional deterministic encoding considerations		require no further additional deterministic encoding considerations
	as per Section 4.2.2 of [RFC8949].		as per Section 4.2.2 of [RFC8949].
	4.2. Encoder Considerations for Prefixes		4.2. Encoder Considerations for Prefixes
	For the byte strings used as the second element in the array		For the byte strings used as the second element in the array
	representing a prefix:		representing a prefix:
	(1) An encoder MUST set any unused bytes and any unused bits in the		(1) An encoder MUST set any unused bytes and any unused bits in the
	final byte, if any, to zero. Unused bytes/bits are bytes/bits that		final byte, if any, to zero. Unused bytes (or bits) are bytes (or
	are not covered by the prefix length given. So, for example,		bits) that are not covered by the prefix length given. So, for
	2001:db8:1230::/44 MUST be encoded as:		example, 2001:db8:1230::/44 MUST be encoded as:
	54([44, h'20010db81230'])		54([44, h'20010db81230'])
	even though variations like:		even though variations like:
	54([44, h'20010db81233'])		54([44, h'20010db81233'])
	54([44, h'20010db8123f'])		54([44, h'20010db8123f'])
	54([44, h'20010db8123012'])		54([44, h'20010db8123012'])
	start with the same 44 bits but are not valid.		start with the same 44 bits but are not valid.
	(Analogous examples can be constructed for IPv4 prefixes.)		(Analogous examples can be constructed for IPv4 prefixes.)
	(2) An encoder MUST then omit any right-aligned (trailing) sequences		(2) An encoder MUST then omit any right-aligned (trailing) sequence
	of bytes that are all zero.		of bytes that is all zero.
	There is no relationship between the number of bytes omitted and the		There is no relationship between the number of bytes omitted and the
	prefix length. For instance, the prefix 2001:db8::/64 is encoded as:		prefix length. For instance, the prefix 2001:db8::/64 is encoded as:
	54([64, h'20010db8'])		54([64, h'20010db8'])
	4.3. Decoder Considerations for Prefixes		4.3. Decoder Considerations for Prefixes
	A decoder MUST check that all unused bits encoded in the byte string		A decoder MUST check that all unused bits encoded in the byte string
	ipv6-prefix-bytes/ipv4-prefix-bytes, i.e., the bits to the right of		ipv6-prefix-bytes/ipv4-prefix-bytes, i.e., the bits to the right of
End of changes. 5 change blocks.
	20 lines changed or deleted		19 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/