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/