draft-ietf-cbor-network-addresses-13.txt   rfc9164.txt 
CBOR Working Group M. Richardson Internet Engineering Task Force (IETF) M. Richardson
Internet-Draft Sandelman Software Works Request for Comments: 9164 Sandelman Software Works
Intended status: Standards Track C. Bormann Category: Standards Track C. Bormann
Expires: 25 April 2022 Universität Bremen TZI ISSN: 2070-1721 Universität Bremen TZI
22 October 2021 December 2021
CBOR tags for IPv4 and IPv6 addresses and prefixes Concise Binary Object Representation (CBOR) Tags for IPv4 and IPv6
draft-ietf-cbor-network-addresses-13 Addresses and Prefixes
Abstract Abstract
This specification defines two CBOR Tags for use with IPv6 and IPv4 This specification defines two Concise Binary Object Representation
addresses and prefixes. (CBOR) tags for use with IPv6 and IPv4 addresses and prefixes.
// RFC-EDITOR-please-remove: This work is tracked at
// https://github.com/cbor-wg/cbor-network-address
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on 25 April 2022. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9164.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Simplified BSD License text to this document. Code Components extracted from this document must
as described in Section 4.e of the Trust Legal Provisions and are include Revised BSD License text as described in Section 4.e of the
provided without warranty as described in the Simplified BSD License. Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology
3. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Protocol
3.1. Three Forms . . . . . . . . . . . . . . . . . . . . . . . 3 3.1. Three Forms
3.1.1. Addresses . . . . . . . . . . . . . . . . . . . . . . 3 3.1.1. Addresses
3.1.2. Prefixes . . . . . . . . . . . . . . . . . . . . . . 3 3.1.2. Prefixes
3.1.3. Interface Definition . . . . . . . . . . . . . . . . 4 3.1.3. Interface Definition
3.2. IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.2. IPv6
3.3. IPv4 . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.3. IPv4
4. Tag validity . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Tag Validity
4.1. Deterministic Encoding . . . . . . . . . . . . . . . . . 6 4.1. Deterministic Encoding
4.2. Encoder Considerations for Prefixes . . . . . . . . . . . 6 4.2. Encoder Considerations for Prefixes
4.3. Decoder Considerations for Prefixes . . . . . . . . . . . 7 4.3. Decoder Considerations for Prefixes
4.3.1. Example implementation . . . . . . . . . . . . . . . 7 4.3.1. Example Implementation
5. CDDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 5. CDDL
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 6. Security Considerations
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 7. IANA Considerations
7.1. Tag 54 - IPv6 . . . . . . . . . . . . . . . . . . . . . . 10 7.1. Tag 54 - IPv6
7.2. Tag 52 - IPv4 . . . . . . . . . . . . . . . . . . . . . . 10 7.2. Tag 52 - IPv4
7.3. Tags 260 and 261 . . . . . . . . . . . . . . . . . . . . 10 7.3. Tags 260 and 261
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 8. References
8.1. Normative References . . . . . . . . . . . . . . . . . . 10 8.1. Normative References
8.2. Informative References . . . . . . . . . . . . . . . . . 11 8.2. Informative References
Appendix A. Changelog . . . . . . . . . . . . . . . . . . . . . 11 Acknowledgements
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction 1. Introduction
[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 documents 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 non-essential 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]) such as they are with MAC addresses (Section 2 of [RFC7042]).
used for 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
3.1. Three Forms 3.1. Three Forms
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
integer, in which case it is to be interpreted as the interface integer, in which case it is to be interpreted as the interface
index. It may be a text string, in which case it is to be index. It may be a text string, in which case it is to be
interpreted as an interface name. interpreted as an interface name.
As explained in [RFC4007] the zone identifiers are strictly local to As explained in [RFC4007], the zone identifiers are strictly local to
the node. They are useful for communications within a node about the node. They are useful for communications within a node about
connected addresses (for instance, where a link-local peer is connected addresses (for instance, where a link-local peer is
discovered by one daemon, and another daemon needs to be informed). discovered by one daemon and another daemon needs to be informed).
They may also have utility in some management protocols. They may also have utility in some management protocols.
In the cases where the Interface Format is being used to represent In the cases where the Interface Format is being used to represent
only an address with a zone identifier, and no interface prefix only an address with a zone identifier and no interface prefix
information, then the prefix length may be replaced with the CBOR information, the prefix length may be replaced with the CBOR "null"
"null" (0xF6). (0xF6).
3.2. IPv6 3.2. IPv6
IANA has allocated tag 54 for IPv6 uses. (This is the ASCII code for IANA has allocated tag 54 for IPv6 uses. (This is the ASCII code for
'6'.) '6'.)
An IPv6 address is to be encoded as a sixteen-byte byte string An IPv6 address is to be encoded as a sixteen-byte byte string
(Section 3.1 of [RFC8949], major type 2), enclosed in Tag number 54. (Section 3.1 of [RFC8949], major type 2), enclosed in tag number 54.
For example: For example:
54(h'20010db81234deedbeefcafefacefeed') 54(h'20010db81234deedbeefcafefacefeed')
An IPv6 prefix, such as 2001:db8:1234::/48 is to be encoded as a two An IPv6 prefix, such as 2001:db8:1234::/48, is to be encoded as a
element array, with the length of the prefix first. See Section 4 two-element array, with the length of the prefix first. See
for the detailed construction of the second element. Section 4 for the detailed construction of the second element.
For example: For example:
54([48, h'20010db81234']) 54([48, h'20010db81234'])
An IPv6 address combined with a prefix length, such as being used for An IPv6 address combined with a prefix length, such as one used for
configuring an interface, is to be encoded as a two element array, configuring an interface, is to be encoded as a two-element array,
with the (full-length) IPv6 address first and the length of the with the (full-length) IPv6 address first and the length of the
associated network the prefix next; a third element can be added for associated network the prefix next; a third element can be added for
the zone identifier. the zone identifier.
For example: For example:
54([h'20010db81234deedbeefcafefacefeed', 56]) 54([h'20010db81234deedbeefcafefacefeed', 56])
The address-with-prefix form can be reliably distinguished from the The address-with-prefix form can be reliably distinguished from the
prefix form only in the sequence of the array elements. prefix form only in the sequence of the array elements.
Some example of a link-local IPv6 address with a 64-bit prefix: An example of a link-local IPv6 address with a 64-bit prefix:
54([h'fe8000000000020202fffffffe030303', 64, 'eth0']) 54([h'fe8000000000020202fffffffe030303', 64, 'eth0'])
with a numeric zone identifier: with a numeric zone identifier:
54([h'fe8000000000020202fffffffe030303', 64, 42]) 54([h'fe8000000000020202fffffffe030303', 64, 42])
An IPv6 link-local address without a prefix length: An IPv6 link-local address without a prefix length:
54([h'fe8000000000020202fffffffe030303', null, 42]) 54([h'fe8000000000020202fffffffe030303', null, 42])
Zone identifiers may be used with any kind of IP address, not just Zone identifiers may be used with any kind of IP address, not just
Link-Local addresses. In particular, they are valid for multicast link-local addresses. In particular, they are valid for multicast
addresses, and there may still be some significance for Globally addresses, and there may still be some significance for Globally
Unique Addresses (GUA). Unique Addresses (GUAs).
3.3. IPv4 3.3. IPv4
IANA has allocated tag 52 for IPv4 uses. (This is the ASCII code for IANA has allocated tag 52 for IPv4 uses. (This is the ASCII code for
'4'.) '4'.)
An IPv4 address is to be encoded as a four-byte byte string An IPv4 address is to be encoded as a four-byte byte string
(Section 3.1 of [RFC8949], major type 2), enclosed in Tag number 52. (Section 3.1 of [RFC8949], major type 2), enclosed in tag number 52.
For example: For example:
52(h'c0000201') 52(h'c0000201')
An IPv4 prefix, such as 192.0.2.0/24 is to be encoded as a two
An IPv4 prefix, such as 192.0.2.0/24, is to be encoded as a two-
element array, with the length of the prefix first. See Section 4 element array, with the length of the prefix first. See Section 4
for the detailed construction of the second element. for the detailed construction of the second element.
For example: For example:
52([24, h'c00002']) 52([24, h'c00002'])
An IPv4 address combined with a prefix length, such as being used for An IPv4 address combined with a prefix length, such as being used for
configuring an interface, is to be encoded as a two element array, configuring an interface, is to be encoded as a two-element array,
with the (full-length) IPv4 address first and the length of the with the (full-length) IPv4 address first and the length of the
associated network the prefix next; a third element can be added for associated network the prefix next; a third element can be added for
the zone identifier. the zone identifier.
For example, 192.0.2.1/24 is to be encoded as a two element array, For example, 192.0.2.1/24 is to be encoded as a two-element array,
with the length of the prefix (implied 192.0.2.0/24) last. with the length of the prefix (implied 192.0.2.0/24) last.
52([h'c0000201', 24]) 52([h'c0000201', 24])
The address-with-prefix form can be reliably distinguished from the The address-with-prefix form can be reliably distinguished from the
prefix form only in the sequence of the array elements. prefix form only in the sequence of the array elements.
4. Tag validity 4. Tag Validity
This section discusses when a tag 54 or tag 52 is valid This section discusses when tag 54 or tag 52 is valid (Section 5.3.2
(Section 5.3.2 of [RFC8949]). As with all CBOR tags, validity of [RFC8949]). As with all CBOR tags, validity checking can be
checking can be handled in a generic CBOR library or in the handled in a generic CBOR library or in the application. A generic
application. A generic CBOR library needs to document whether and CBOR library needs to document whether and how it handles validity
how it handles validity checking. checking.
The rule ip-address-or-prefix in Figure 1 shows how to check the The rule ip-address-or-prefix in Figure 1 shows how to check the
overall structure of these tags and their content, the ranges of overall structure of these tags and their content, the ranges of
integer values, and the lengths of byte strings. An instance of tag integer values, and the lengths of byte strings. An instance of tag
52 or 54 is valid if it matches that rule and, for ipv6-prefix and 52 or 54 is valid if it matches that rule and, for ipv6-prefix and
ipv4-prefix, the considerations of Sections 4.2 and 4.3. ipv4-prefix, the considerations of Sections 4.2 and 4.3.
4.1. Deterministic Encoding 4.1. Deterministic Encoding
The tag validity rules, combined with the rules in Section 4.2.1 of The tag validity rules, combined with the rules in Section 4.2.1 of
[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) sequence (2) An encoder MUST then omit any right-aligned (trailing) sequence
of bytes that are all zero. of bytes in which the bytes are all zeros.
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
the prefix length, are zero. the prefix length, are zero.
A decoder MUST also check that the byte string does not end in a zero A decoder MUST also check that the byte string does not end in a zero
byte. byte.
Since encoders are required to remove zero-valued trailing bytes, a Since encoders are required to remove zero-valued trailing bytes, a
decoder MUST handle the case where a prefix length specifies that decoder MUST handle cases where a prefix length specifies that more
more bits are relevant than are actually present in the byte-string. bits are relevant than are actually present in the byte string.
As an example, ::/128 is encoded as As an example, ::/128 is encoded as
54([128, h'']) 54([128, h''])
4.3.1. Example implementation 4.3.1. Example Implementation
A recommendation for prefix decoder implementations is to first A recommendation for prefix decoder implementations is to first
create an array of 16 (or 4) zero bytes. create an array of 16 (or 4) zero bytes.
Then taking whichever is smaller between (a) the length of the Then, taking whichever is smaller between (a) the length of the
included byte-string, and (b) the number of bytes covered by the included byte string and (b) the number of bytes covered by the
prefix-length rounded up to the next multiple of 8: fail if that prefix length rounded up to the next multiple of 8, fail if that
number is greater than 16 (or 4), and then copy that many bytes from number is greater than 16 (or 4) and then copy that many bytes from
the byte-string into the byte array. the byte string into the byte array.
Finally, looking at the number of unused bits in the last byte (if Finally, when looking at the number of unused bits in the last byte
any) of the range covered by the prefix length, check that any unused (if any) of the range covered by the prefix length, check that any
bits in the byte string are zero: unused bits in the byte string are zero:
unused_bits = (8 - (prefix_length_in_bits % 8)) % 8; unused_bits = (8 - (prefix_length_in_bits % 8)) % 8;
if (length_in_bytes > 0 && if (length_in_bytes > 0 &&
(address_bytes[length_in_bytes - 1] & ~(0xFF << unused_bits)) (address_bytes[length_in_bytes - 1] & ~(0xFF << unused_bits))
!= 0) != 0)
fail(); fail();
5. CDDL 5. CDDL
For use with CDDL [RFC8610], the typenames defined in Figure 1 are For use with Concise Data Definition Language (CDDL) [RFC8610], the
recommended: type names defined in Figure 1 are recommended:
ip-address-or-prefix = ipv6-address-or-prefix / ip-address-or-prefix = ipv6-address-or-prefix /
ipv4-address-or-prefix ipv4-address-or-prefix
ipv6-address-or-prefix = #6.54(ipv6-address / ipv6-address-or-prefix = #6.54(ipv6-address /
ipv6-address-with-prefix / ipv6-address-with-prefix /
ipv6-prefix) ipv6-prefix)
ipv4-address-or-prefix = #6.52(ipv4-address / ipv4-address-or-prefix = #6.52(ipv4-address /
ipv4-address-with-prefix / ipv4-address-with-prefix /
ipv4-prefix) ipv4-prefix)
skipping to change at page 9, line 36 skipping to change at line 367
ipv4-prefix-length = 0..32 ipv4-prefix-length = 0..32
ipv6-prefix = [ipv6-prefix-length, ipv6-prefix-bytes] ipv6-prefix = [ipv6-prefix-length, ipv6-prefix-bytes]
ipv4-prefix = [ipv4-prefix-length, ipv4-prefix-bytes] ipv4-prefix = [ipv4-prefix-length, ipv4-prefix-bytes]
ipv6-prefix-bytes = bytes .size (uint .le 16) ipv6-prefix-bytes = bytes .size (uint .le 16)
ipv4-prefix-bytes = bytes .size (uint .le 4) ipv4-prefix-bytes = bytes .size (uint .le 4)
ip-zone-identifier = uint / text ip-zone-identifier = uint / text
Figure 1: CDDL types for tags 54 and 52 Figure 1: CDDL Types for Tags 54 and 52
6. Security Considerations 6. Security Considerations
This document provides an CBOR encoding for IPv4 and IPv6 address This document provides a CBOR encoding for IPv4 and IPv6 address
information. Any applications using these encodings will need to information. Any applications using these encodings will need to
consider the security implications of these data in their specific consider the security implications of this data in their specific
context. For example, identifying which byte sequences in a protocol context. For example, identifying which byte sequences in a protocol
are addresses may allow an attacker or eavesdropper to better are addresses may allow an attacker or eavesdropper to better
understand what parts of a packet to attack. understand what parts of a packet to attack.
Applications need to check the validity (Section 4) of a tag before Applications need to check the validity (Section 4) of a tag before
acting on any of its contents. If the validity checking is not done acting on any of its contents. If the validity checking is not done
in the generic CBOR decoder, it needs to be done in the application; in the generic CBOR decoder, it needs to be done in the application;
in any case it needs to be done before the tag is transformed into a in any case, it needs to be done before the tag is transformed into a
platform-specific representation that could conceal validity errors. platform-specific representation that could conceal validity errors.
The right-hand bits of the prefix, after the prefix-length, are set The right-hand bits of the prefix, after the prefix length, are set
to zero by this protocol. (Otherwise, a malicious party could use to zero by this protocol. (Otherwise, a malicious party could use
them to transmit covert data in a way that would not affect the them to transmit covert data in a way that would not affect the
primary use of this encoding. Such abuse is detected by tag validity primary use of this encoding. Such abuse is detected by tag validity
checking, and can also be detected by examination of the raw protocol checking and can also be detected by examination of the raw protocol
bytes.) bytes.)
7. IANA Considerations 7. IANA Considerations
IANA has allocated two tags from the Specification Required area of IANA has allocated two tags from the Specification Required [RFC8126]
the Concise Binary Object Representation (CBOR) Tags area of the "Concise Binary Object Representation (CBOR) Tags"
[IANA.cbor-tags]: registry [IANA.cbor-tags]:
7.1. Tag 54 - IPv6 7.1. Tag 54 - IPv6
Data Item: byte string or array Data Item: byte string or array
Semantics: IPv6, [prefixlen,IPv6], [IPv6,prefixpart] Semantics: IPv6, [prefixlen,IPv6], [IPv6,prefixpart]
7.2. Tag 52 - IPv4 7.2. Tag 52 - IPv4
Data Item: byte string or array Data Item: byte string or array
Semantics: IPv4, [prefixlen,IPv4], [IPv4,prefixpart] Semantics: IPv4, [prefixlen,IPv4], [IPv4,prefixpart]
7.3. Tags 260 and 261 7.3. Tags 260 and 261
IANA is requested to add the note "DEPRECATED in favor of 52 and 54 IANA has added the note "DEPRECATED in favor of 52 and 54 for IP
for IP addresses" to registrations 260 and 261 addresses" to registrations 260 and 261.
8. References 8. References
8.1. Normative References 8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data
Definition Language (CDDL): A Notational Convention to Definition Language (CDDL): A Notational Convention to
Express Concise Binary Object Representation (CBOR) and Express Concise Binary Object Representation (CBOR) and
JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610,
June 2019, <https://www.rfc-editor.org/info/rfc8610>. June 2019, <https://www.rfc-editor.org/info/rfc8610>.
skipping to change at page 11, line 35 skipping to change at line 466
[RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types",
RFC 6991, DOI 10.17487/RFC6991, July 2013, RFC 6991, DOI 10.17487/RFC6991, July 2013,
<https://www.rfc-editor.org/info/rfc6991>. <https://www.rfc-editor.org/info/rfc6991>.
[RFC7042] Eastlake 3rd, D. and J. Abley, "IANA Considerations and [RFC7042] Eastlake 3rd, D. and J. Abley, "IANA Considerations and
IETF Protocol and Documentation Usage for IEEE 802 IETF Protocol and Documentation Usage for IEEE 802
Parameters", BCP 141, RFC 7042, DOI 10.17487/RFC7042, Parameters", BCP 141, RFC 7042, DOI 10.17487/RFC7042,
October 2013, <https://www.rfc-editor.org/info/rfc7042>. October 2013, <https://www.rfc-editor.org/info/rfc7042>.
Appendix A. Changelog
This section is to be removed before publishing as an RFC.
* 03
* 02
* 01 added security considerations about covert channel
Acknowledgements Acknowledgements
Roman Danyliw, Donald Eastlake, Ben Kaduk, Barry Leiba, and Éric Roman Danyliw, Donald Eastlake, Ben Kaduk, Barry Leiba, and Éric
Vyncke reviewed the document and provided suggested text. Jürgen Vyncke reviewed the document and provided suggested text. Jürgen
Schönwälder helped finding the history of IPv4 zone identifiers. Schönwälder helped find the history of IPv4 zone identifiers.
Authors' Addresses Authors' Addresses
Michael Richardson Michael Richardson
Sandelman Software Works Sandelman Software Works
Email: mcr+ietf@sandelman.ca Email: mcr+ietf@sandelman.ca
Carsten Bormann Carsten Bormann
Universität Bremen TZI Universität Bremen TZI
Germany Germany
Email: cabo@tzi.org Email: cabo@tzi.org
 End of changes. 54 change blocks. 
149 lines changed or deleted 139 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/