<?xml version='1.0' encoding='utf-8'?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.3.23 -->
<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<?rfc toc="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ietf-cbor-network-addresses-00" category="std" obsoletes="" updates="" submissionType="IETF" xml:lang="en" tocInclude="true" sortRefs="true" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.5.0 -->
  <front>
    <title abbrev="CBOR-IP">CBOR tags for IPv4 and IPv6 addresses and prefixes</title>
    <seriesInfo name="Internet-Draft" value="draft-ietf-cbor-network-addresses-00"/>
    <author initials="M." surname="Richardson" fullname="Michael Richardson">
      <organization>Sandelman Software Works</organization>
      <address>
        <email>mcr+ietf@sandelman.ca</email>
      </address>
    </author>
    <date year="2021" month="March" day="06"/>
    <area>Internet</area>
    <workgroup>CBOR Working Group</workgroup>
    <keyword>Internet-Draft</keyword>
    <abstract>
      <t>This document describes two CBOR Tags to be used with IPv4 and IPv6 addresses and prefixes.</t>
      <t>RFC-EDITOR-please remove: This work is tracked at https://github.com/mcr/cbor-network-address.git</t>
    </abstract>
  </front>
  <middle>
    <section anchor="introduction" numbered="true" toc="default">
      <name>Introduction</name>
      <t><xref target="RFC8949" format="default"/> defines a number of CBOR Tags for common items.</t>
      <t>Not included are ones to indicate if the item is an IPv4 or IPv6 address, or if it is an
address plus prefix length.
This document defines them.</t>
    </section>
    <section anchor="protocol" numbered="true" toc="default">
      <name>Protocol</name>
      <t>These tags can applied to byte strings to represent a single address.</t>
      <t>When applied to an array, the represent a CIDR-style prefix.
When a byte string (without prefix) appears in a context 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 /128 is implied.</t>
      <section anchor="ipv6" numbered="true" toc="default">
        <name>IPv6</name>
        <t>IANA has allocated tag TBD1 for IPv6 uses.</t>
        <t>An IPv6 address is to be encoded as up to sixteen-byte bytestring (<xref target="RFC8949" format="default"/> section, 3.1, major type 2), prefixed with tag TBD1.  Trailing zero octets may be omitted.</t>
        <t>An IPv6 prefix, such as 2001:db8:1234::/48 is to be encoded as a two element array,
with the length of the prefix first:</t>
        <artwork name="" type="" align="left" alt=""><![CDATA[
    TBD1([ 48, h'20010db81234'])
]]></artwork>
      </section>
      <section anchor="ipv4" numbered="true" toc="default">
        <name>IPv4</name>
        <t>IANA has allocated tag TBD2 for IPv4 uses.</t>
        <t>An IPv4 address is to be encoded as a four-byte bytestring (<xref target="RFC8949" format="default"/> section, 3.1, major type 2), prefixed with tag TBD2. Trailing zero octets may be omitted.</t>
        <t>An IPv4 prefix, such as 192.0.2.1/24 is to be encoded as a two element array, with the length of the prefix first:</t>
        <artwork name="" type="" align="left" alt=""><![CDATA[
    TBD2([ 24, h'C0000201'])
]]></artwork>
      </section>
    </section>
    <section anchor="security-considerations" numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>Identifying which byte sequences in a protocol are addresses may allow an attacker or eavesdropper to better understand what parts of a packet to attack.</t>
      <t>Reading the relevant RFC may provide more information, so it would seem that any additional
security that was provided by not being able to identify what are IP addresses falls into the security by obscurity category.</t>
    </section>
    <section anchor="iana-considerations" numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>IANA is asked to allocate two tags from the Specification Required area of the Concise Binary Object Representation (CBOR) Tags, in the ("1+1") area.</t>
      <section anchor="tbd1-ipv6" numbered="true" toc="default">
        <name>TBD1 - IPv6</name>
        <artwork name="" type="" align="left" alt=""><![CDATA[
Data Item: byte-string and array
Semantics: IPv6 or [IPv6,prefixlen]
]]></artwork>
      </section>
      <section anchor="tbd2-ipv4" numbered="true" toc="default">
        <name>TBD2 - IPv4</name>
        <artwork name="" type="" align="left" alt=""><![CDATA[
Data Item: byte-string and array
Semantics: IPv4 or [IPv4,prefixlen]
]]></artwork>
      </section>
    </section>
    <section anchor="acknowledgements" numbered="true" toc="default">
      <name>Acknowledgements</name>
      <t>none yet</t>
    </section>
    <section anchor="changelog" numbered="true" toc="default">
      <name>Changelog</name>
    </section>
  </middle>
  <back>
    <references>
      <name>Normative References</name>
      <reference anchor="BCP14" target="https://www.rfc-editor.org/info/rfc8174">
        <front>
          <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
          <author initials="B." surname="Leiba" fullname="B. Leiba">
            <organization/>
          </author>
          <date year="2017" month="May"/>
          <abstract>
            <t>RFC 2119 specifies common key words that may be used in protocol  specifications.  This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the  defined special meanings.</t>
          </abstract>
        </front>
        <seriesInfo name="BCP" value="14"/>
        <seriesInfo name="RFC" value="8174"/>
        <seriesInfo name="DOI" value="10.17487/RFC8174"/>
      </reference>
      <reference anchor="RFC8949" target="https://www.rfc-editor.org/info/rfc8949">
        <front>
          <title>Concise Binary Object Representation (CBOR)</title>
          <author initials="C." surname="Bormann" fullname="C. Bormann">
            <organization/>
          </author>
          <author initials="P." surname="Hoffman" fullname="P. Hoffman">
            <organization/>
          </author>
          <date year="2020" month="December"/>
          <abstract>
            <t>The Concise Binary Object Representation (CBOR) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. These design goals make it different from earlier binary serializations such as ASN.1 and MessagePack.</t>
            <t>This document obsoletes RFC 7049, providing editorial improvements, new details, and errata fixes while keeping full compatibility with the interchange format of RFC 7049.  It does not create a new version of the format.</t>
          </abstract>
        </front>
        <seriesInfo name="STD" value="94"/>
        <seriesInfo name="RFC" value="8949"/>
        <seriesInfo name="DOI" value="10.17487/RFC8949"/>
      </reference>
    </references>
  </back>
  <!-- ##markdown-source:
H4sIAK8eRGAAA61WTW/cNhC981cMkkNsZKX9iJDaOtVet8Uekhi2gRyCoKAk
7oqxRKok5fU2SH9731Bae40EQVJ0D7bEj/l48+aNkiQRQYdG5bQ8f3dFQW48
ra2j1eVdRtJU/PCaZFU55b3ycalzaq3vlReyKJy6G64mq0tR2dLIFrYqJ9ch
0Sqsk7KwLjEqbK27TR7sJLOZED7A2p+ysQZXguuVELpz8dGHxWx2OlsI6ZTM
aWWCcjAitpsx0Pcwp82G/nC278Tt9vFMcsHORSlDTj5UQnQ6J/yeUykN9V6R
dE7u6EivSTYN7ZQ/JmRcS19TrZwSRMGWOW/g0VsXkK/Po4lKrWXfBI8T+/1d
O2zzq5B9qK3LhRAJaYPVNyld6bKWrvLW4PiAzxteUs3TLeuQ3DUgUU2LSK/t
OmyRfkyVPalW6iantnQvGdlf/f5oWkohjHWtDPpO5Th6vrycZzld/b48mf+S
YYGfTrNTBKbN+vGkSJKEZOGDk2UQ4qbWnlDEvlUmIFdfOl2g6CjegPoN0wOp
F4qBrGirQ/1DVEmFQAjJbxerG1Cla5REHZxqLaKg6Jb5QfjPodzCtAxUh9D5
fDrdwEtfpKVtp0h++i1GpTgzZNPqqmrApOdMCGervgwa8IrPn0cMvnzhKmrD
EZLp20I5suuD/Jj+8NVaQzqolmN/awPKWTZ9xZGhJpavAwhtKg2mKQKZQq3i
Bc4C9YuwDJ30gMqEF3BUh+GQGNepa3o/gkWNMptQp19VY4gZXtqU07t0FjS1
DZdNAc3Yukxx2XWNRpxcpx1CQ3XRKTFcp+DDszlJHouN2kcGk+9r9eQym+JO
mcTMDq8uVxdXiQ87XB9iTsfLhw7piNlh+zCeOWbbSjoP0HCytOjX+0Bbbjm8
j8kjZXXfqTKoKvo1I1YD6aT3QAPR1aAHN2+h0YtcEKcadSdNYNgk35g8yNgE
1qevFmxFtzG7SeTmuP867s8XJwcHGODncVOI1dnbMxYH9me51hVDTTfnF/MH
E9wNDOGZeVLux8CVKW3kjqe+4zWv74NSJomA8Z89aIc89SqSd0Kv0vmEWvkJ
7sKuU7Q4nuxba2zCfUgp0Y2DTrCtv5WzZAElMGqheIjDtjqEmN8+1MHMhHxf
1hwedHeeV8VJPl+8yvJ8mp18MwsZRQGgR3IOPBFDJCDLQGFuK34bS7vWzgdo
zj/4CVZkjvfoA2UnE6pfsN8Z/LLbFx+Ph1NjFbLvVWHxOK+eVCH7bhUkbvXu
/4Z/kf4U+tlX6M9PF+ksXaTz6SL7Ydzp53FfAPdFxrgvZ/gtZvMDzOlalb3T
YUdLa7yulJOMA8bbqoJXvd5xftsaw2tsePVXjxjV2NrdqEyxMR/nAYPA1dtG
ZQmBdd6xICp5p3zlLOTBDRkDJUc9xpuL3wjwhZ7upAOUyA0e+G6IIhXt8HhR
suKwBq0axIDHXnSLiO6QB7UWET1MQC6ttywwW9s3FdKAeA/SYnYcuOYzshF+
j0fc3Eq/N1ghfzIYDoVi37KAIvJUGGEa4mYUVpcHQKyBAkOFkxztg3XYsoUf
X5jjG+t2Uesj+78qBi/yGPG3o2CPrREpMnzJOdtGH9eQVL3mUYW7dIV6aTeM
MrlnC8yXGnPkXBvpdvSu+AT64+go+8PNIx6Tx3FOTrjYfPHo2fzl/NlxNDYI
Z9TGZNTPSKoLGSStMBzzyJhkbDeubeSwuMbXDTAr8ckUZQm0+BDFeSAxiP3x
URJi1yejMvwX+9nefvYN+3RW3hq7bVS1iV3m+ePKKHzgBd5d1tJsVGM3Yvjg
KMA/If4F8NXLH0kLAAA=

-->

</rfc>
