<?xml version='1.0' encoding='utf-8'?> version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.5.12 -->
<?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-13" category="std" consensus="true" number="9164" obsoletes="" updates="" submissionType="IETF" category="std" consensus="true" xml:lang="en" tocInclude="true" sortRefs="true" symRefs="true" version="3">

  <!-- xml2rfc v2v3 conversion 3.10.0 -->

  <front>
    <title abbrev="CBOR-IP">CBOR tags abbrev="CBOR Tags for IP">Concise Binary Object Representation (CBOR) Tags for IPv4 and IPv6 addresses Addresses and prefixes</title> Prefixes</title>
    <seriesInfo name="Internet-Draft" value="draft-ietf-cbor-network-addresses-13"/> name="RFC" value="9164"/>
    <author initials="M." surname="Richardson" fullname="Michael Richardson">
      <organization>Sandelman Software Works</organization>
      <address>
        <email>mcr+ietf@sandelman.ca</email>
      </address>
    </author>
    <author initials="C." surname="Bormann" fullname="Carsten Bormann">
      <organization>Universität Bremen TZI</organization>
      <address>
        <postal>
          <country>Germany</country>
        </postal>
        <email>cabo@tzi.org</email>
      </address>
    </author>
    <date year="2021" month="October" day="22"/> month="December"/>
    <area>Internet</area>
    <workgroup>CBOR Working Group</workgroup>
    <keyword>Internet-Draft</keyword>
    <keyword>binary format</keyword>
    <keyword>data interchange format</keyword>
    <keyword>interface address</keyword>
    <keyword>zone identifier</keyword>

    <abstract>
      <t>This specification defines two CBOR Tags Concise Binary Object Representation (CBOR) tags for use with IPv6 and IPv4 addresses and prefixes.</t>
      <t><cref anchor="track">RFC-EDITOR-please-remove: This work is tracked at https://github.com/cbor-wg/cbor-network-address</cref></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 tags for common items.
Tags 260 and 261 were later defined in drafts listed with IANA <xref target="IANA.cbor-tags" format="default"/>.
These tags were intended to cover addresses (260) and prefixes (261).
Tag 260 distinguishes between IPv6, IPv4, and MAC <xref target="RFC7042" format="default"/> addresses only through the length of the  byte string, making it impossible, for example, to drop trailing zeros in the encoding of IP addresses.  Tag 261 was not documented well enough for use.</t>

<t>This specification defines tags 54 and 52 achieving
an explicit indication to explicitly
indicate use of IPv6 or IPv4 by the tag number.
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 while explicitly indicating use 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 nonessential, and
support for that is not provided in this specification.)
This specification does not deal with MAC addresses (<xref section="2" sectionFormat="of" target="RFC7042" format="default"/>) such as they are used for Ethernet.</t> format="default"/>).</t>
    </section>
    <section anchor="terminology" numbered="true" toc="default">
      <name>Terminology</name>
      <t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL</bcp14>
NOT", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
described in BCP 14 BCP&nbsp;14 <xref target="RFC2119" format="default"/> <xref target="RFC8174" format="default"/> when, and only when, they
appear in all capitals, as shown here.</t>
    </section>
    <section anchor="protocol" numbered="true" toc="default">
      <name>Protocol</name>
      <section anchor="three-forms" numbered="true" toc="default">
        <name>Three Forms</name>
        <section anchor="addresses" numbered="true" toc="default">
          <name>Addresses</name>
          <t>These tags can be applied to byte strings to represent a single address.</t>
          <t>This form is called the Address Format.</t> "Address Format".</t>
        </section>
        <section anchor="prefixes" numbered="true" toc="default">
          <name>Prefixes</name>
          <t>When applied to an array that starts with an unsigned integer, they the tags represent a
CIDR-style prefix of that length.</t>
          <t>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 are relevant.
That is, for IPv4, a /32 is implied, and for IPv6, a /128 is implied.</t>
          <t>This form is called the Prefix Format.</t> "Prefix Format".</t>
        </section>
        <section anchor="interface-definition" numbered="true" toc="default">
          <name>Interface Definition</name>
          <t>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
length of a prefix built out of the first <tt>length</tt> bits of the
address, they the tags represent information that is commonly used to specify
both the network prefix and the IP address of an interface.</t>
          <t>The length of the byte string is always 16 bytes (for IPv6) and 4 bytes (for IPv4).</t>
          <t>This form is called the Interface Format.</t> "Interface Format".</t>
          <t>Interface Format definitions support an optional third element to the array, which is to be used as the IPv6 Link-Local link-local zone identifier from <xref section="6" sectionFormat="of" target="RFC4007" format="default"/>;
for symmetry symmetry, this is also provided for IPv4 as in <xref target="RFC4001" format="default"/> and <xref target="RFC6991" format="default"/>.
The zone identifier may be an 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 interpreted as an interface name.</t>
          <t>As explained in <xref target="RFC4007" format="default"/> format="default"/>, the zone identifiers are strictly local to the node.
They are useful for communications within a node about connected addresses (for instance, where a link-local peer is discovered by one daemon, daemon and another daemon needs to be informed).
They may also have utility in some management protocols.</t>
          <t>In the cases where the Interface Format is being used to represent
only an address with a zone identifier, identifier and no interface prefix information, then the prefix length may be replaced with the CBOR "null" (0xF6).</t>
        </section>
      </section>
      <section anchor="ipv6" numbered="true" toc="default">
        <name>IPv6</name>
        <t>IANA has allocated tag 54 for IPv6 uses.
(This is the ASCII code for '6'.)</t>
        <t>An IPv6 address is to be encoded as a sixteen-byte byte string
(<xref section="3.1" sectionFormat="of" target="RFC8949" format="default"/>, major type 2), enclosed in Tag tag number 54.</t>
        <t>For example:</t>
        <artwork name="" type="" align="left" alt=""><![CDATA[
54(h'20010db81234deedbeefcafefacefeed')
]]></artwork>
        <t>An IPv6 prefix, such as 2001:db8:1234::/48 2001:db8:1234::/48, is to be encoded as a two element two-element array, with the length of the prefix first.
See <xref target="validity" format="default"/> for the detailed construction of the second element.</t>
        <t>For example:</t>
        <artwork name="" type="" align="left" alt=""><![CDATA[
54([48, h'20010db81234'])
]]></artwork>
        <t>An IPv6 address combined with a prefix length, such as being one used for
configuring an interface, is to be encoded as a two element two-element array,
with the (full-length) IPv6 address first and the length of the
associated network the prefix next; a third element can be added for
the zone identifier.</t>
        <t>For example:</t>
        <artwork name="" type="" align="left" alt=""><![CDATA[
54([h'20010db81234deedbeefcafefacefeed', 56])
]]></artwork>
        <t>The address-with-prefix form can be reliably distinguished
from the prefix form only in the sequence of the array elements.</t>
        <t>Some
        <t>An example of a link-local IPv6 address with a 64-bit prefix:</t>
        <artwork name="" type="" align="left" alt=""><![CDATA[
54([h'fe8000000000020202fffffffe030303', 64, 'eth0'])
]]></artwork>
        <t>with a numeric zone identifier:</t>
        <artwork name="" type="" align="left" alt=""><![CDATA[
54([h'fe8000000000020202fffffffe030303', 64, 42])
]]></artwork>
        <t>An IPv6 link-local address without a prefix length:</t>
        <artwork name="" type="" align="left" alt=""><![CDATA[
54([h'fe8000000000020202fffffffe030303', null, 42])
]]></artwork>
        <t>Zone identifiers may be used with any kind of IP address, not just Link-Local link-local addresses.
In particular, they are valid for multicast addresses, and there may still be some significance
for Globally Unique Addresses (GUA).</t> (GUAs).</t>
      </section>
      <section anchor="ipv4" numbered="true" toc="default">
        <name>IPv4</name>
        <t>IANA has allocated tag 52 for IPv4 uses.
(This is the ASCII code for '4'.)</t>
        <t>An IPv4 address is to be encoded as a four-byte byte string
(<xref section="3.1" sectionFormat="of" target="RFC8949" format="default"/>, major type 2), enclosed in Tag tag number 52.</t>
        <t>For example:</t>
        <artwork name="" type="" align="left" alt=""><![CDATA[
52(h'c0000201')
]]></artwork>
        <t>An IPv4 prefix, such as 192.0.2.0/24 192.0.2.0/24, is to be encoded as a two element two-element array, with the length of the prefix first.
See <xref target="validity" format="default"/> for the detailed construction of the second element.</t>
        <t>For example:</t>
        <artwork name="" type="" align="left" alt=""><![CDATA[
52([24, h'c00002'])
]]></artwork>
        <t>An IPv4 address combined with a prefix length, such as being used for
configuring an interface, is to be encoded as a two element two-element array,
with the (full-length) IPv4 address first and the length of the
associated network the prefix next; a third element can be added for
the zone identifier.</t>
        <t>For example, 192.0.2.1/24 is to be encoded as a two element two-element array,
with the length of the prefix (implied 192.0.2.0/24) last.</t>
        <artwork name="" type="" align="left" alt=""><![CDATA[
52([h'c0000201', 24])
]]></artwork>
        <t>The address-with-prefix form can be reliably distinguished
from the prefix form only in the sequence of the array elements.</t>
      </section>
    </section>
    <section anchor="validity" numbered="true" toc="default">
      <name>Tag validity</name> Validity</name>
      <t>This section discusses when a tag 54 or tag 52 is valid (<xref section="5.3.2" sectionFormat="of" target="RFC8949" format="default"/>).
As with all CBOR tags, validity checking can be handled in a generic
CBOR library or in the application.
A generic CBOR library needs to document whether and how it handles
validity checking.</t>
      <t>The rule <tt>ip-address-or-prefix</tt> in <xref target="cddl-types" format="default"/> shows how to check the
overall structure of these tags and their content, the ranges of
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 ipv4-prefix, the considerations of Sections
<xref format="counter" target="valid-encoder"/> and <xref format="counter" target="valid-decoder"/>.</t>
      <section anchor="deterministic-encoding" numbered="true" toc="default">
        <name>Deterministic Encoding</name>
        <t>The tag validity rules, combined with the rules in <xref section="4.2.1" sectionFormat="of" target="RFC8949" format="default"/>, lead to deterministic encoding for tags 54 and 52 and require
no further Additional Deterministic Encoding Considerations additional deterministic encoding considerations as per
<xref section="4.2.2" sectionFormat="of" target="RFC8949" format="default"/>.</t>
      </section>
      <section anchor="valid-encoder" numbered="true" toc="default">
        <name>Encoder Considerations for Prefixes</name>
        <t>For the byte strings used as the second element in the array
representing a prefix:</t>
        <t>(1) An encoder <bcp14>MUST</bcp14> set any unused bytes, bytes and any unused bits in the
	final byte, if any, to zero.
Unused bytes/bits bytes (or bits) are bytes/bits bytes (or bits) that are not covered by the prefix length given.
So
So, for example, <tt>2001:db8:1230::/44</tt> <bcp14>MUST</bcp14> be encoded as:</t>
        <artwork name="" type="" align="left" alt=""><![CDATA[
54([44, h'20010db81230'])
]]></artwork>
        <t>even though variations like:</t>
        <artwork name="" type="" align="left" alt=""><![CDATA[
54([44, h'20010db81233'])
54([44, h'20010db8123f'])
54([44, h'20010db8123012'])
]]></artwork>
        <t>start with the same 44 bits, bits but are not valid.</t>
        <t>(Analogous examples can be constructed for IPv4 prefixes.)</t>
        <t>(2) An encoder <bcp14>MUST</bcp14> then omit any right-aligned (trailing) sequence of
bytes that in which the bytes are all zero.</t> zeros.</t>
        <t>There is no relationship between the number of bytes omitted and the prefix length.
For instance, the prefix 2001:db8::/64 is encoded as:</t>
        <artwork name="" type="" align="left" alt=""><![CDATA[
54([64, h'20010db8'])
]]></artwork>
      </section>
      <section anchor="valid-decoder" numbered="true" toc="default">
        <name>Decoder Considerations for Prefixes</name>
        <t>A decoder <bcp14>MUST</bcp14> check that all unused bits encoded in the byte string
ipv6-prefix-bytes/ipv4-prefix-bytes, i.e., the bits to the right of
the prefix length, are zero.</t>
        <t>A decoder <bcp14>MUST</bcp14> also check that the byte string does not end in a zero
byte.</t>
        <t>Since encoders are required to remove zero-valued trailing bytes, a
decoder <bcp14>MUST</bcp14> handle the case cases where a prefix length specifies that more
bits are relevant than are actually present in the byte-string.</t> byte string.</t>
        <t>As an example, ::/128 is encoded as</t>
        <artwork name="" type="" align="left" alt=""><![CDATA[
54([128, h''])
]]></artwork>
        <section anchor="example-implementation" numbered="true" toc="default">
          <name>Example implementation</name> Implementation</name>
          <t>A recommendation for prefix decoder implementations is to first create
	  an array of 16 (or 4) zero bytes.</t>
          <t>Then
          <t>Then, taking whichever is smaller between (a) the length of the
included byte-string, byte string and (b) the number of bytes covered by the
prefix-length
prefix length rounded up to the next multiple of 8: 8, fail if that
number is greater than 16 (or 4), 4) and then copy that many bytes from
the byte-string byte string into the byte array.</t>
          <t>Finally, when looking at the number of unused bits in the last byte (if
any) of the range covered by the prefix length, check that any unused
bits in the byte string are zero:</t>
          <sourcecode type="c"><![CDATA[
unused_bits = (8 - (prefix_length_in_bits % 8)) % 8;
if (length_in_bytes > 0 &&
    (address_bytes[length_in_bytes - 1] & ~(0xFF << unused_bits))
       != 0)
  fail();
]]></sourcecode>
        </section>
      </section>
    </section>
    <section anchor="cddl" numbered="true" toc="default">
      <name>CDDL</name>
      <t>For use with CDDL Concise Data Definition Language (CDDL) <xref target="RFC8610" format="default"/>, the typenames type names defined in <xref target="cddl-types" format="default"/>
are recommended:</t>
      <figure anchor="cddl-types">
        <name>CDDL types Types for tags Tags 54 and 52</name>
        <sourcecode type="cddl"><![CDATA[
ip-address-or-prefix = ipv6-address-or-prefix /
                       ipv4-address-or-prefix

ipv6-address-or-prefix = #6.54(ipv6-address /
                               ipv6-address-with-prefix /
                               ipv6-prefix)
ipv4-address-or-prefix = #6.52(ipv4-address /
                               ipv4-address-with-prefix /
                               ipv4-prefix)

ipv6-address = bytes .size 16
ipv4-address = bytes .size 4

ipv6-address-with-prefix = [ipv6-address,
                            ipv6-prefix-length / null,
                            ?ip-zone-identifier]
ipv4-address-with-prefix = [ipv4-address,
                            ipv4-prefix-length / null,
                            ?ip-zone-identifier]

ipv6-prefix-length = 0..128
ipv4-prefix-length = 0..32

ipv6-prefix = [ipv6-prefix-length, ipv6-prefix-bytes]
ipv4-prefix = [ipv4-prefix-length, ipv4-prefix-bytes]

ipv6-prefix-bytes = bytes .size (uint .le 16)
ipv4-prefix-bytes = bytes .size (uint .le 4)

ip-zone-identifier = uint / text

]]></sourcecode>
      </figure>
    </section>
    <section anchor="security-considerations" numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>This document provides an a CBOR encoding for IPv4 and IPv6 address information.
Any applications using these encodings will need to consider the security
implications of these this data in their specific context.  For example, 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>Applications need to check the validity (<xref target="validity" format="default"/>) of a tag before
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 any case case, it needs to be done
before the tag is transformed into a platform-specific representation
that could conceal validity errors.</t>
      <t>The right-hand bits of the prefix, after the prefix-length, prefix length, are set to
zero by this protocol.
(Otherwise, a malicious party could use 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 checking, checking and can also be
detected by examination of the raw protocol bytes.)</t>
    </section>
    <section anchor="iana-considerations" numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>IANA has allocated two tags from the Specification Required <xref target="RFC8126"/> area of
the Concise "Concise Binary Object Representation (CBOR) Tags Tags" registry <xref target="IANA.cbor-tags" format="default"/>:</t>
      <section anchor="tag-54-ipv6" numbered="true" toc="default">
        <name>Tag 54 - IPv6</name>
        <artwork name="" type="" align="left" alt=""><![CDATA[
Data Item:
<dl spacing="compact">
<dt>Data Item:</dt><dd> byte string or array
Semantics: array</dd>
<dt>Semantics:</dt><dd> IPv6, [prefixlen,IPv6], [IPv6,prefixpart]
]]></artwork> [IPv6,prefixpart]</dd>
</dl>
      </section>
      <section anchor="tag-52-ipv4" numbered="true" toc="default">
        <name>Tag 52 - IPv4</name>
        <artwork name="" type="" align="left" alt=""><![CDATA[
Data Item:
<dl spacing="compact">
<dt>Data Item:</dt><dd> byte string or array
Semantics: array</dd>
<dt>Semantics:</dt><dd> IPv4, [prefixlen,IPv4], [IPv4,prefixpart]
]]></artwork> [IPv4,prefixpart]</dd>
</dl>
      </section>
      <section anchor="tags-260-and-261" numbered="true" toc="default">
        <name>Tags 260 and 261</name>
        <t>IANA is requested to add has added the note "DEPRECATED in favor of 52 and 54 for IP addresses" to registrations 260 and 261</t> 261.</t>
      </section>
    </section>
  </middle>
  <back>
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <reference anchor="RFC8949" target="https://www.rfc-editor.org/info/rfc8949">
          <front>
            <title>Concise Binary Object Representation (CBOR)</title>
            <author fullname="C. Bormann" initials="C." surname="Bormann">
              <organization/>
            </author>
            <author fullname="P. Hoffman" initials="P." surname="Hoffman">
              <organization/>
            </author>
            <date month="December" year="2020"/>
            <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>
        <reference anchor="RFC8610" target="https://www.rfc-editor.org/info/rfc8610">
          <front>
            <title>Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures</title>
            <author fullname="H. Birkholz" initials="H." surname="Birkholz">
              <organization/>
            </author>
            <author fullname="C. Vigano" initials="C." surname="Vigano">
              <organization/>
            </author>
            <author fullname="C. Bormann" initials="C." surname="Bormann">
              <organization/>
            </author>
            <date month="June" year="2019"/>
            <abstract>
              <t>This document proposes a notational convention to express Concise Binary Object Representation (CBOR) data structures (RFC 7049).  Its main goal is to provide an easy and unambiguous way to express structures for protocol messages and data formats that use CBOR or JSON.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8610"/>
          <seriesInfo name="DOI" value="10.17487/RFC8610"/>
        </reference>
        <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <author fullname="S. Bradner" initials="S." surname="Bradner">
              <organization/>
            </author>
            <date month="March" year="1997"/>
            <abstract>
              <t>In many standards track documents several words are used to signify the requirements in the specification.  These words are often capitalized. This document defines these words as they should be interpreted in IETF documents.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="2119"/>
          <seriesInfo name="DOI" value="10.17487/RFC2119"/>
        </reference>
        <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <author fullname="B. Leiba" initials="B." surname="Leiba">
              <organization/>
            </author>
            <date month="May" year="2017"/>
            <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>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8126.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8949.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8610.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>

      </references>
      <references>
        <name>Informative References</name>

        <reference anchor="IANA.cbor-tags" target="https://www.iana.org/assignments/cbor-tags">
          <front>
            <title>Concise Binary Object Representation (CBOR) Tags</title>
            <author>
              <organization>IANA</organization>
            </author>
            <date/>
          </front>
        </reference>
        <reference anchor="RFC4007" target="https://www.rfc-editor.org/info/rfc4007">
          <front>
            <title>IPv6 Scoped Address Architecture</title>
            <author fullname="S. Deering" initials="S." surname="Deering">
              <organization/>
            </author>
            <author fullname="B. Haberman" initials="B." surname="Haberman">
              <organization/>
            </author>
            <author fullname="T. Jinmei" initials="T." surname="Jinmei">
              <organization/>
            </author>
            <author fullname="E. Nordmark" initials="E." surname="Nordmark">
              <organization/>
            </author>
            <author fullname="B. Zill" initials="B." surname="Zill">
              <organization/>
            </author>
            <date month="March" year="2005"/>
            <abstract>
              <t>This document specifies the architectural characteristics, expected behavior, textual representation, and usage of IPv6 addresses of different scopes.  According to a decision in the IPv6 working group, this document intentionally avoids the syntax and usage of unicast site-local addresses.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4007"/>
          <seriesInfo name="DOI" value="10.17487/RFC4007"/>
        </reference>
        <reference anchor="RFC4001" target="https://www.rfc-editor.org/info/rfc4001">
          <front>
            <title>Textual Conventions for Internet Network Addresses</title>
            <author fullname="M. Daniele" initials="M." surname="Daniele">
              <organization/>
            </author>
            <author fullname="B. Haberman" initials="B." surname="Haberman">
              <organization/>
            </author>
            <author fullname="S. Routhier" initials="S." surname="Routhier">
              <organization/>
            </author>
            <author fullname="J. Schoenwaelder" initials="J." surname="Schoenwaelder">
              <organization/>
            </author>
            <date month="February" year="2005"/>
            <abstract>
              <t>This MIB module defines textual conventions to represent commonly used Internet network layer addressing information.  The intent is that these textual conventions will be imported and used in MIB modules that would otherwise define their own representations.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4001"/>
          <seriesInfo name="DOI" value="10.17487/RFC4001"/>
        </reference>
        <reference anchor="RFC6991" target="https://www.rfc-editor.org/info/rfc6991">
          <front>
            <title>Common YANG Data Types</title>
            <author fullname="J. Schoenwaelder" initials="J." role="editor" surname="Schoenwaelder">
              <organization/>
            </author>
            <date month="July" year="2013"/>
            <abstract>
              <t>This document introduces a collection of common data types to be used with the YANG data modeling language.  This document obsoletes RFC 6021.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6991"/>
          <seriesInfo name="DOI" value="10.17487/RFC6991"/>
        </reference>
        <reference anchor="RFC7042" target="https://www.rfc-editor.org/info/rfc7042">
          <front>
            <title>IANA Considerations and IETF Protocol and Documentation Usage for IEEE 802 Parameters</title>
            <author fullname="D. Eastlake 3rd" initials="D." surname="Eastlake 3rd">
              <organization/>
            </author>
            <author fullname="J. Abley" initials="J." surname="Abley">
              <organization/>
            </author>
            <date month="October" year="2013"/>
            <abstract>
              <t>Some IETF protocols make use of Ethernet frame formats and IEEE 802 parameters.  This document discusses several uses of such parameters in IETF protocols, specifies IANA considerations for assignment of points under the IANA OUI (Organizationally Unique Identifier), and provides some values for use in documentation. This document obsoletes RFC 5342.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="141"/>
          <seriesInfo name="RFC" value="7042"/>
          <seriesInfo name="DOI" value="10.17487/RFC7042"/>
        </reference>

<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4007.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4001.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6991.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7042.xml"/>

      </references>
    </references>
    <section removeInRFC="true" anchor="changelog" numbered="true" toc="default">
      <name>Changelog</name>
      <ul spacing="normal">
        <li>03</li>
        <li>02</li>
        <li>01 added security considerations about covert channel</li>
      </ul>
    </section>
    <section numbered="false" anchor="acknowledgements" toc="default">
      <name>Acknowledgements</name>
      <t><contact fullname="Roman Danyliw"/>, <contact fullname="Donald Eastlake"/>, <contact fullname="Ben Kaduk"/>, <contact fullname="Barry Leiba"/>, and <contact fullname="Éric Vyncke"/> reviewed the document and provided suggested text.
<contact fullname="Jürgen Schönwälder"/> helped finding find the history of IPv4 zone identifiers.</t>
    </section>
  </back>
  <!-- ##markdown-source:
H4sIABHKcmEAA9Vb3XLbyJW+76foyLVjMktQJA1rZHqcjSzJEyX22CvJm0pc
3jEINMgegQC3AYjmqJT7vEUu8gy5ytX6xfb8dDcAUvJ6pnZrs5oai2w0Tp8+
5zu/3QqCQFS6ytRUHj9/fS6raF7KtDDy7M11KKM8wQ8HMkoSo8pSlTS0MirV
H1UpotnMqGt+NTh7I5IizqMl0EpMlFaBVlUaxLPCBLmq1oW5CjydYPxIiLIC
at9HWZHDK5WplRB6ZehjWU1GoyejiYiMiqbyLK+UASJiPbeM/h7I6XwuvzVF
vRJX62ZOcIKLiziqprKsEhEXeanysi7dGis9lfDzQMZRLutSyciYaCN7OpVR
lsmNKvsSJLCIyoVcKKOElFURT/EBfCwLU8H+yymRSFQa1VlVwgz3fLPkx/hV
RHW1KMxUCBFIncPoq6E81/EiMklZ5DCd5fUKh1TWfVQY2OwFiEhlS+D0okir
NYiDto4rqWWks6lcxuafUdK/Lt3UYRzhekz6ODJlpXL5vDDwyNN9m+trZUpd
ffprJZ8btYQpl388a8jG0az4dfWjHsJ0GI2LOq/MZiq/VUhnI0SOBCugMoXH
5y+OD5+ET+A1ULf9fjAewfckyUCtedqefXb03dGQgIF4mxLq+KVwNPp66j+O
7ceDJ0/cx69H4QTEGQSBjGZlZaK4EuJyoUtZrlSsUw1610WOitE54BVwx4C5
dMhGja91tbDIZoiH90B8KMS7f8dVrt43n6bISHB6cnYJsF9lKipVABIsYHOS
WEGsS/hN01Uio0ouqmpVTvf357ByPRvGxXKfBLCe799lIbzDpQbpAWIfILhN
kdQx7k2Imxsr79tbv9FI5vVypows0q0Nw1pLkIiu1BL2Q8OTgxFtc3IwlmuA
uMwiMB5LKwGksgWXMtMAnsTKC7Qmb25IZ7e3QGmhQJTkMYiGBgMEBCZoCzEI
w7Rk2oMV+x3J4tC4T/wQOwmsBAZd6xLIyhmIQwEkUUcDUtCA3n51dCxp94gD
2H2zQpFnG1ktwB3MF/AbtqTyOXAN4sBvcrapFPgDA2sM5DIi56ErqZeroiz1
LFMDEpb6GC1X+AU2kZhihTrUGU7+UZmiRNEgOZXHRYKjQP7sTcPGUEreEMg1
KmVeVBKcYg3WRWJU4F9UTixaKA4/j14U7mN2xI8nMooXWl3DsgL8gfq4ynSM
W8gT9x5xA6h2Dny2IW6BjEWH01qu1kw82lLcTCFXBAHUFOg1jxU+qFq4EbA/
orSBScW1TpRk+/ax4y7DGnjdDwQ+bXRH8PIPm23KL9smsWLft4zIYqmrsqs8
5bVnV5aryFRD0TupeYfwBGwFtP9RVxsCjiJMDujRdZTBPBhF0jjsqQuGBm4d
J65q0yxh2UEwYCACURmQbl7kAW49r3SUkUTLerWCyGKJwBua0WPlmzDr20AZ
9u9ED26VoKeAOgkX7aZljTc3F4p8iZzAjoS3p74s63ghgdkKlYvgIDQgV6cw
hPF1iP7oEqKAzousmG8ESf8KpoMDS0q59+rtxeXegH/L717T5/PTf317dn56
gp8vfnP08qX/IOyMi9+8fvvypPnUvHn8+tWr0+9O+GUYlZ0hsffq6A977B32
Xr+5PHv93dHLPS8uZ320F8Y3wt0AWtAio1IkqoyNnrGInx+/+c+/jEPwMb8A
oUzGY3Sx/OVw/HUIX9YLlfNq5HH4K0pLRKuVigxSwTQijla6ijKEM+hnUaxz
SiZAer98h5KBKPLNLF6Nw1/ZAdxwZ9DJrDNIMtsd2XmZhXjH0B3LeGl2xrck
3eX36A+d707urUFEyRtTQOZUQALwACCzMErJF2APJX5/II8cHkU7lGBSBkoC
YWbauqTGc1OeZRQorySdyhIGM29tzpmi0aEBxaAIpAH4tIvR+hFh+AHyZxNZ
8XtQY3tNYIKzQrJFSFRNZd0U5oxgx3OOk5WaK8P6b/Mljs9OzoOy2mTeL1Ec
AlocloZ2yV3WIA8dquGAFivqyr7el4wucmERupJKfawQfehr3BqwZXCXYNkq
IZ5yinClxX1UlmAKCbOBEJ2hi0S7MCpT11FeoSMl1zPwNQDAV+4/miAVCJUo
Hga/8/P0fDw5bE34jBZY4F0lUN6eRhBlTjDqaU5xfoJCuqF9vYAcWlJpUQrk
MspbERo3lmXFGohCbLxDl3KuKfIgtyAf0WQRXsqzWmcQYEA3NrdINaTY8gNP
/cBi5UfCL7uFEJ8QF7l395yngU8hlwt7Zq++EbOi4pTGJomOEdQDDjfbIz5z
9nAo0iE7524q1BIXLhtl62hTyvEBPYDg4FTL+Vq4NRz2P6PfRpdexdtDnNuQ
lsEv2qgHPBcrHIJ4BW7bJBIQSW7bxmXSvVOuRzQJioMVJwQvdX4VvCyAI/kj
VJUSIieE2FSDXlNTLGUT9w5QGrbguL19SkiB0m2poMjhyEGiKYsmAjdlMVkh
paFYpGAaCoKi71ip2Nx4h4MloBfNMG/8BpDhLcVQQ3SMtRukaIdeq5gKqY9D
cVZ5mpLcgbOBLybbxgrVi6CwI3IiWeQqAbdPEBOxsbUt9iC4clwBdjMSvtVa
XiTK5ok2lUjrzNckdW4TFjZkcmz4BhR2aFzg43JyZe3EBd+FOhqsO1YD7/4y
VDuvvFIgaYz7uqQahA0dWU4iKNFs6I4gO1pgwUNjYFcqaSSEuFZJ3zKOEiYc
LKJr2EIFGR8kh8BsWSwVPM2jOSN1ZYNdSaDnbDKi7Ja4vMs8kNGZQjt0Ju89
hCBPgF7PWrb1dVvS5+3kRUuNLhY0HsbGgqpJkq1DsOiBRTN405Z5OI0KyL28
zrI92Rt9fHGARo9BHK0MtoeV4ALxk6HUUUdYYkCh4tP/Gosh0bu0lkRx7uL4
7AzUytWCfHjwENJXcZR3WkwNVKnEsjCFOP+xgnowIN/VcmCilco+Go6tUXNp
jGXeD5hOb1ZKTvoDpJgVtri59CURsA2be9HUflMh/gQ/4nHYWzycgIGPktnh
ePIoTAAmM6XSOEoVijqF7w/7PNnvgyU88Ik0EpgCgSlSmE73w8N7toidCuf1
nLtz+ug6cFfpYNgZigvIqm5uoDrRCSATjNTVIYmqoD4B8lh4VIabB45GqWDU
u9l7BfAuPBzIrhQevt/eslMdGPWMvIbFagdsjURaiAdWsT+X6nltbL3ngTz4
YjkJL6ce+Jcs4AX7XeY4SLuQ2RGogMyoiDXh2IXYlpxzcK1PceFOYHJ5amJD
g7jDN6LR3CPXL0DWQD4+8LK+bMrWALcbtMpdxwukcTqagdto91ISQZGvjRt8
hdyLLYdL9R81lfkWG5xo2Y2iO7tAV2c3walQy+N2pGw1fxAGkAXZBbvbTtXh
yP9M8L+Uf9ToEf4H2z6ArPOhqhajBmqWLlisgkCzLeeftUI42QFya1ftDWE0
2kLzT14RfWlnzT9uh1HrjMkubKWxkVcaC820k8FiZf9DDWBuZTtNAwpjD/Y1
dFxnkStNMPqShyDnsKwzeByhOTS9GWsZRhEjgB8sEBRHOUyRqb0AIKFM6dus
mIHv32AbGbDTlHKy9+3bo1awCO8PFpMmofqCYBG2gkX43wSLtKjN/06kmNxn
0RMIFTFrf7wVEsKdkDB+MhmOhvD//iT8/xMMJr13kxCDAe+zsc0drfwDxoHw
/zoOvGj3lj0Cxj8FAeLzCOjZ8rsDr77MIsRFo8MWTgdyEv5jBJgHZGUOtvLm
gUewa49by8W0vi5tVo0Fg807EeXsVGAye7rG3sXj4aMhNjolnUbe3oKDOnKx
CtycP/kcNCzECxXTGYHd+gIQk7FDiORc5RiGBL2Y6ZmJoGikyoS3h20L26AV
R2627Mz2JYdvUMKGqCZBaC6KNZZtvGgpdriydb2pIR5/0Ct3ahQUxqrtA1du
ePoWoFcrwRVgE7Ik0nhAg5QI9FgloRTYK2DvmrXkGnLWVLThrlNecTvcRPkc
j11S4Ton1CBvIolFKfUk2i28IfoLV8PRWqy4AjPxRn06RQlAARPjeRD1SGi7
QJ26U0Kvrg+CVicEvoeBc7Xcy+d+u60xYSWLh1Lc3HxDqwRscsaX8HY4UXaY
elTyBOpl7Hcj6mN5as9+WAdVG7jIIUig6wArqynbNXBBKET7R/lZUA5AYBEV
gUlnOX/UlDLIOwdC8MuAcWmjBBSBaW0IQhCOte2m3M26PO7KBjzOShnRZa5t
MSyHU5bW9tvImGulOtv1kmXXt9V3Kjutm2748VaETkL4gpjCQpNR9sZ9CTiy
q0hqoJeqoqSpzok69a1cvd+MYneOlxCpRhHhvAHiDWbRuR8e5wzF2xaVfd8q
bX3lPqpRlJC1mg27dfZcXytwBRdF94jxQ7s2HGFtGH7gnXSCQaccC7fKsVaO
rK6pyKfTxevIaKudTF+pz5J4hCTufJLe+2Q0biUA1I1tsF5GkDKGIUl6IGd1
IyRCBkCpdwRyL+ZFXTph+L6/T0/aDTd/Gg8pYG+yq3hqb+CxHCna6PmiCmAp
6uv23Cldvx2GBDc1vQrRAbLa0ajxTBRP0DDgsRQXeuXPpKmz5c/amRCdCaK2
rO/r6H9IJtC0rVoTPAKm+wfk/O5W+0FH/q3Ui5zTlxul82uQs0n7mSXowoE9
GWjbiuPImmU7pW654IANo+WEA2t/fJxh++mlaw2SklARO9IakEKsMrbYpEZc
i9ftdrY/+VS5DdVIh5SNZaxG5VvkuJMPcp6294ZXOOiNgGJZ0pwfO18iOuxw
fPatvu3jGGv99nDWwW1ZgLPeOXrBZzlDEYIw1VbNWYHfZ8D75C4tHY5bVwL4
sYcwDYBa+IFnCKAGOHjwcmoLeswbyfNGfPRyBExhfxZkyAcUCCW7Jbf97juu
EOPcOjYKUmjhT2zASMYHsgdEIB1F6bI02dRgb3wXgxrW6pq7t+USzxSMN7le
1L8jXQd1ZnVifXTgmt9ogr1Z/04z7XppYYFqqZqiplsQ9cr3r7GpTtWybXwc
TmUKiMBggboUlj5wPKdNG1aj365PhnJYemUPr/D6lOUHM2expVysfIoG2SRD
LCAwVmUQoLKiIIFZ+Ddb3A1wlPwzmZ5OQSObvkvBKX37bNQadJyCD6CiTb9t
e85q2W/JWPD872n+M9k7lIHs8Qrf8wrf65yf/pM87Pfx36cCJNtrPSUp/UqO
5FdfCby017OZLj95tz0zkOP38iv5J+xZv5DffCNbPPT7RAF+fvFMjvALqrLX
fyqsK5XHJycvOV3xd8RwCO88YSKNKRrdpoF8Gs9KyvZ9qW6uLdi0rRWpxPpy
dxvujoQdJETedPfBvmN7+4d87c58Ie6h80w+OBiCM2g/vp94a5GGWLsu/LI3
7em1uJtXy9Ok1378RZTDn81T6HnqCApYYQgNS/2jAgvusLz1NNwScpuHZ/Jd
+9ngsyy1A6j1QvvcKvzsa/8CCMIWQ9C0GN6Le6XCHIVfzFH4P8WRuGN7YHrD
IYQjccdC9OzRpPOel2dn6kDupB7v2xT9nnffCrfe2k1itpTdq8Ehy2GGoOiL
HQr3zg4JYdtSgek0Y59ObG2IvpnKB437kHQh+9ke+R4e2S399m7RY0G5Vhss
PLvJn22a+NaCPcKmlIG6EJ2a8s6r3u3zQ6zYN+2uBpZv9pJE2dyFxI4K5I7Y
2eAroMySK/GIUUFNqrgpyZkEJBqRjSna+Nts7prLUMpO+8xKc4MpKJ9zcxyy
6b29I+POYzmp8g1qPs/NijUdrlYV3tCF8GmEiq5ViVc+V8gzNuQqDOiYExi6
TgIpCkTCFd084fsg+C5dUWA6mJa1heQl4XotTaOg127S9pkcdhJmKsX0EHJA
ulyaU+AtsBVSuvYLtvjTLjXfrNLuyim2HzlEd7pPNn0DEULu0jr0br/Q0vNT
kiRw4O4RbL8jmF9/yZTvPOclH6FzJgNygiIKRwKvWF/Vc8pJKUZc1Bm1p2O8
tej3powpTOkaXlTaYdrdvmXjG+xRWlm8bdk9XVEgVQmbgPIdD4eRoei9xs7J
WpcKbzRB+qljjfUpqntjecOsAGYtKT3EbWLFSSlURQgWhLu1u6S0ppdQH1Ga
qriyjOkl9v+QFnHvUnZK6y+oNT7Dh2i/quILEMhuu83k9M3pJVbOVBjNlGi/
gvYCSWO70W+idWMXnIX36Xo5ntFs+5C7Dm7W9iKwb/ledG6enrtyCv9sw1V3
QDcGucrnwAzs/PXsBxTGeQcCsof47POldX/HfMoXB7nFG9jLB+QxT9BhnFVq
Oe3koHjdi9pGFwqy7ErH5dTeUnvHiABADHDgPYzQAx5GLb/3pRGvOOEVw5+1
Yri9YmhXDO9dsXMr30ofQIAVqqJL+GhLSWIv1gAHeyenb85Pj48uT0/QTtPo
uqA6wPYF/W2MxvntcZk71/iHE+yjOmvi3xzMwJFRMrzACiEr5hiduDTWuUnj
Z3v4VzQYfn4pR4/wnwn+M7YnIM7Rb3df3Z0eMpYYaOcKr4XKo/gqL9aZSvgW
TYmrcUmjkmd7KeCa1rq5uTkv8K9gTsAdZXp9i8k4DJ5gkzORp1DnZNGVcsPP
oeD6XZTUV34AlLSRL5WeRTTE3d6bT39G1/hvmzymd2Gf11qt7WW25uow/dmC
vQVW1vO51QeGJuTst5/+bsDNyot48elv+frTXzPqHd/KhcpW2MfCq+v2TiHY
e1WYjb3CHu7cphqK/wKfLUT9kzUAAA==

-->
</rfc>