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/