draft-ietf-cbor-network-addresses-06.txt   draft-ietf-cbor-network-addresses-07.txt 
CBOR Working Group M. Richardson CBOR Working Group M. Richardson
Internet-Draft Sandelman Software Works Internet-Draft Sandelman Software Works
Intended status: Standards Track C. Bormann Intended status: Standards Track C. Bormann
Expires: 26 January 2022 Universität Bremen TZI Expires: 2 February 2022 Universität Bremen TZI
25 July 2021 1 August 2021
CBOR tags for IPv4 and IPv6 addresses and prefixes CBOR tags for IPv4 and IPv6 addresses and prefixes
draft-ietf-cbor-network-addresses-06 draft-ietf-cbor-network-addresses-07
Abstract Abstract
This specification describes two CBOR Tags to be used with IPv4 and This specification defines two CBOR Tags to be used with IPv6 and
IPv6 addresses and prefixes. IPv4 addresses and prefixes.
// RFC-EDITOR-please-remove: This work is tracked at // RFC-EDITOR-please-remove: This work is tracked at
// https://github.com/cbor-wg/cbor-network-address // 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 Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on 26 January 2022. This Internet-Draft will expire on 2 February 2022.
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 (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 23 skipping to change at page 2, line 23
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Three Forms . . . . . . . . . . . . . . . . . . . . . . . 3 3.1. Three Forms . . . . . . . . . . . . . . . . . . . . . . . 3
3.1.1. Addresses . . . . . . . . . . . . . . . . . . . . . . 3 3.1.1. Addresses . . . . . . . . . . . . . . . . . . . . . . 3
3.1.2. Prefixes . . . . . . . . . . . . . . . . . . . . . . 3 3.1.2. Prefixes . . . . . . . . . . . . . . . . . . . . . . 3
3.1.3. Interface Definition . . . . . . . . . . . . . . . . 3 3.1.3. Interface Definition . . . . . . . . . . . . . . . . 3
3.2. IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3.2. IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.3. IPv4 . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.3. IPv4 . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Encoder Considerations for Prefixes . . . . . . . . . . . . . 5 4. Encoder Considerations for Prefixes . . . . . . . . . . . . . 5
5. Decoder Considerations for Prefixes . . . . . . . . . . . . . 5 5. Decoder Considerations for Prefixes . . . . . . . . . . . . . 6
6. CDDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 6. CDDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
8.1. Tag 54 - IPv6 . . . . . . . . . . . . . . . . . . . . . . 7 8.1. Tag 54 - IPv6 . . . . . . . . . . . . . . . . . . . . . . 8
8.2. Tag 52 - IPv4 . . . . . . . . . . . . . . . . . . . . . . 8 8.2. Tag 52 - IPv4 . . . . . . . . . . . . . . . . . . . . . . 8
9. Normative References . . . . . . . . . . . . . . . . . . . . 8 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
9.1. Normative References . . . . . . . . . . . . . . . . . . 8
9.2. Informative References . . . . . . . . . . . . . . . . . 8
Appendix A. Changelog . . . . . . . . . . . . . . . . . . . . . 8 Appendix A. Changelog . . . . . . . . . . . . . . . . . . . . . 8
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 8 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
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 through IANA. These tags cover addresses and 261 were later defined through IANA [IANA.cbor-tags]. These tags
(260), and prefixes (261). Tag 260 distinguishes between IPv4, IPv6 cover addresses (260), and prefixes (261). Tag 260 distinguishes
and Ethernet through the length of the byte string only. Tag 261 was between IPv6, IPv4 and Ethernet through the length of the byte string
not documented well enough to be used. only. Tag 261 was not documented well enough to be used.
This specification provides a format for IPv6 and IPv4 addresses,
prefixes, and addresses with prefixes, achieving an explicit
indication of IPv4 or IPv6. Prefixes omit trailing zeroes in the
address. (Due to the complexity of testing, the value of omitting
trailing zeros for addresses was considered non-essential and support
for that was removed in this specification.)
This specification does not deal with 6 or 8-byte Ethernet addresses. This specification defines tags 54 and 52. These new tags are
intended to be used in preference to tags 260 and 261. They provide
formats for IPv6 and IPv4 addresses, prefixes, and addresses with
prefixes, achieving an explicit indication of IPv6 or IPv4. The
prefix format omits trailing zeroes in the address part. (Due to the
complexity of testing, the value of omitting trailing zeros for the
pure address format was considered non-essential and support for that
is not provided in this specification.) This specification does not
deal with 6- or 8-byte Ethernet addresses.
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 page 3, line 26 skipping to change at page 3, line 29
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 a number, they represent a When applied to an array that starts with an unsigned integer, they
CIDR-style prefix of that length. 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, that stands When applied to an array that starts with a byte string, which stands
for an IP address, followed by the bit length of a prefix built out for an IP address, followed by an unsigned integer giving the bit
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 network prefix and the IP address of an interface.
This form is called the Interface Format. This form is called the Interface Format.
3.2. IPv6 3.2. IPv6
IANA has allocated tag 54 for IPv6 uses. (Note that this is the IANA has allocated tag 54 for IPv6 uses. (Note that this is the
ASCII code for '6'.) ASCII code for '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.
skipping to change at page 7, line 49 skipping to change at page 7, line 49
The right-hand bits of the prefix, after the prefix-length, are The right-hand bits of the prefix, after the prefix-length, are
ignored by this protocol. A malicious party could use them to ignored by this protocol. A malicious party could use them to
transmit covert data in a way that would not affect the primary use transmit covert data in a way that would not affect the primary use
of this encoding. Such abuse would be detected by examination of the of this encoding. Such abuse would be detected by examination of the
raw protocol bytes. Users of this encoding should be aware of this raw protocol bytes. Users of this encoding should be aware of this
possibility. possibility.
8. IANA Considerations 8. IANA Considerations
IANA has allocated two tags from the Specification Required area of IANA has allocated two tags from the Specification Required area of
the Concise Binary Object Representation (CBOR) Tags: the Concise Binary Object Representation (CBOR) Tags
[IANA.cbor-tags]:
8.1. Tag 54 - IPv6 8.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]
8.2. Tag 52 - IPv4 8.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]
9. Normative References 9. References
9.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>.
[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>.
skipping to change at page 8, line 34 skipping to change at page 8, line 39
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>.
[RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object
Representation (CBOR)", STD 94, RFC 8949, Representation (CBOR)", STD 94, RFC 8949,
DOI 10.17487/RFC8949, December 2020, DOI 10.17487/RFC8949, December 2020,
<https://www.rfc-editor.org/info/rfc8949>. <https://www.rfc-editor.org/info/rfc8949>.
9.2. Informative References
[IANA.cbor-tags]
IANA, "Concise Binary Object Representation (CBOR) Tags",
<http://www.iana.org/assignments/cbor-tags>.
Appendix A. Changelog Appendix A. Changelog
This section is to be removed before publishing as an RFC. This section is to be removed before publishing as an RFC.
* 03 * 03
* 02 * 02
* 01 added security considerations about covert channel * 01 added security considerations about covert channel
Acknowledgements Acknowledgements
none yet none yet
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. 19 change blocks. 
32 lines changed or deleted 47 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/