rfc9164.original.xml   rfc9164.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc [ <!DOCTYPE rfc [
<!ENTITY nbsp "&#160;"> <!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;"> <!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;"> <!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;"> <!ENTITY wj "&#8288;">
]> ]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.5.12 --> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
<?rfc toc="yes"?> -ietf-cbor-network-addresses-13" number="9164" obsoletes="" updates="" submissio
<?rfc sortrefs="yes"?> nType="IETF" category="std" consensus="true" xml:lang="en" tocInclude="true" sor
<?rfc symrefs="yes"?> tRefs="true" symRefs="true" version="3">
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
-ietf-cbor-network-addresses-13" category="std" consensus="true" obsoletes="" up
dates="" submissionType="IETF" xml:lang="en" tocInclude="true" sortRefs="true" s
ymRefs="true" version="3">
<!-- xml2rfc v2v3 conversion 3.10.0 --> <!-- xml2rfc v2v3 conversion 3.10.0 -->
<front> <front>
<title abbrev="CBOR-IP">CBOR tags for IPv4 and IPv6 addresses and prefixes</ <title abbrev="CBOR Tags for IP">Concise Binary Object Representation (CBOR)
title> Tags for IPv4 and IPv6 Addresses and Prefixes</title>
<seriesInfo name="Internet-Draft" value="draft-ietf-cbor-network-addresses-1 <seriesInfo name="RFC" value="9164"/>
3"/>
<author initials="M." surname="Richardson" fullname="Michael Richardson"> <author initials="M." surname="Richardson" fullname="Michael Richardson">
<organization>Sandelman Software Works</organization> <organization>Sandelman Software Works</organization>
<address> <address>
<email>mcr+ietf@sandelman.ca</email> <email>mcr+ietf@sandelman.ca</email>
</address> </address>
</author> </author>
<author initials="C." surname="Bormann" fullname="Carsten Bormann"> <author initials="C." surname="Bormann" fullname="Carsten Bormann">
<organization>Universität Bremen TZI</organization> <organization>Universität Bremen TZI</organization>
<address> <address>
<postal> <postal>
<country>Germany</country> <country>Germany</country>
</postal> </postal>
<email>cabo@tzi.org</email> <email>cabo@tzi.org</email>
</address> </address>
</author> </author>
<date year="2021" month="October" day="22"/> <date year="2021" month="December"/>
<area>Internet</area> <area>Internet</area>
<workgroup>CBOR Working Group</workgroup> <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> <abstract>
<t>This specification defines two CBOR Tags for use with IPv6 and IPv4 add <t>This specification defines two Concise Binary Object Representation (CB
resses and prefixes.</t> OR) 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> </abstract>
</front> </front>
<middle> <middle>
<section anchor="introduction" numbered="true" toc="default"> <section anchor="introduction" numbered="true" toc="default">
<name>Introduction</name> <name>Introduction</name>
<t><xref target="RFC8949" format="default"/> defines a number of CBOR Tags for common items. <t><xref target="RFC8949" format="default"/> defines a number of CBOR tags for common items.
Tags 260 and 261 were later defined in drafts listed with IANA <xref target="IAN A.cbor-tags" format="default"/>. Tags 260 and 261 were later defined in drafts listed with IANA <xref target="IAN A.cbor-tags" format="default"/>.
These tags were intended to cover addresses (260) and prefixes (261). 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 imp ossible, for example, to drop trailing zeros in the encoding of IP addresses. T ag 261 was not documented well enough for use.</t> Tag 260 distinguishes between IPv6, IPv4, and MAC <xref target="RFC7042" format= "default"/> addresses only through the length of the byte string, making it imp ossible, for example, to drop trailing zeros in the encoding of IP addresses. T ag 261 was not documented well enough for use.</t>
<t>This specification defines tags 54 and 52 achieving
an explicit indication of IPv6 or IPv4 by the tag number. <t>This specification defines tags 54 and 52 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 These new tags are intended to be used in preference to tags 260 and
261. 261.
They provide formats for IPv6 and IPv4 addresses, prefixes, They provide formats for IPv6 and IPv4 addresses, prefixes,
and addresses with prefixes, achieving an explicit indication of IPv6 or IPv4. and addresses with prefixes, while explicitly indicating use of IPv6 or IPv4.
The prefix format omits trailing zeroes in the address part. The prefix format omits trailing zeroes in the address part.
(Due to the complexity of testing, the value of omitting trailing (Due to the complexity of testing, the value of omitting trailing
zeros for the pure address format was considered non-essential and zeros for the pure address format was considered nonessential, and
support for that is not provided in this specification.) support for that is not provided in this specification.)
This specification does not deal with MAC addresses (<xref section="2" sectionFo rmat="of" target="RFC7042" format="default"/>) such as they are used for Etherne t.</t> This specification does not deal with MAC addresses (<xref section="2" sectionFo rmat="of" target="RFC7042" format="default"/>).</t>
</section> </section>
<section anchor="terminology" numbered="true" toc="default"> <section anchor="terminology" numbered="true" toc="default">
<name>Terminology</name> <name>Terminology</name>
<t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14 >REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL</bcp14> <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>", 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 i nterpreted as "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be i nterpreted as
described in BCP 14 <xref target="RFC2119" format="default"/> <xref target="RFC8 174" format="default"/> when, and only when, they described in 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> appear in all capitals, as shown here.</t>
</section> </section>
<section anchor="protocol" numbered="true" toc="default"> <section anchor="protocol" numbered="true" toc="default">
<name>Protocol</name> <name>Protocol</name>
<section anchor="three-forms" numbered="true" toc="default"> <section anchor="three-forms" numbered="true" toc="default">
<name>Three Forms</name> <name>Three Forms</name>
<section anchor="addresses" numbered="true" toc="default"> <section anchor="addresses" numbered="true" toc="default">
<name>Addresses</name> <name>Addresses</name>
<t>These tags can be applied to byte strings to represent a single add ress.</t> <t>These tags can be applied to byte strings to represent a single add ress.</t>
<t>This form is called the Address Format.</t> <t>This form is called the "Address Format".</t>
</section> </section>
<section anchor="prefixes" numbered="true" toc="default"> <section anchor="prefixes" numbered="true" toc="default">
<name>Prefixes</name> <name>Prefixes</name>
<t>When applied to an array that starts with an unsigned integer, they represent a <t>When applied to an array that starts with an unsigned integer, the tags represent a
CIDR-style prefix of that length.</t> 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 . <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> 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> <t>This form is called the "Prefix Format".</t>
</section> </section>
<section anchor="interface-definition" numbered="true" toc="default"> <section anchor="interface-definition" numbered="true" toc="default">
<name>Interface Definition</name> <name>Interface Definition</name>
<t>When applied to an array that starts with a byte string, which stan ds <t>When applied to an array that starts with a byte string, which stan ds
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 <tt>length</tt> bits of the length of a prefix built out of the first <tt>length</tt> bits of the
address, they represent information that is commonly used to specify address, the tags represent information that is commonly used to specify
both the network prefix and the IP address of an interface.</t> 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 b ytes (for IPv4).</t> <t>The length of the byte string is always 16 bytes (for IPv6) and 4 b ytes (for IPv4).</t>
<t>This form is called the Interface Format.</t> <t>This form is called the "Interface Format".</t>
<t>Interface Format definitions support an optional third element to t <t>Interface Format definitions support an optional third element to t
he array, which is to be used as the IPv6 Link-Local zone identifier from <xref he array, which is to be used as the IPv6 link-local zone identifier from <xref
section="6" sectionFormat="of" target="RFC4007" format="default"/>; section="6" sectionFormat="of" target="RFC4007" format="default"/>;
for symmetry this is also provided for IPv4 as in <xref target="RFC4001" format= for symmetry, this is also provided for IPv4 as in <xref target="RFC4001" format
"default"/> and <xref target="RFC6991" format="default"/>. ="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. 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 n ame.</t> It may be a text string, in which case it is to be interpreted as an interface n ame.</t>
<t>As explained in <xref target="RFC4007" format="default"/> the zone <t>As explained in <xref target="RFC4007" format="default"/>, the zone
identifiers are strictly local to the node. identifiers are strictly local to the node.
They are useful for communications within a node about connected addresses (for They are useful for communications within a node about connected addresses (for
instance, where a link-local peer is discovered by one daemon, and another daemo instance, where a link-local peer is discovered by one daemon and another daemon
n needs to be informed). needs to be informed).
They may also have utility in some management protocols.</t> They may also have utility in some management protocols.</t>
<t>In the cases where the Interface Format is being used to represent <t>In the cases where the Interface Format is being used to represent
only an address with a zone identifier, and no interface prefix information, the n the prefix length may be replaced with the CBOR "null" (0xF6).</t> only an address with a zone identifier and no interface prefix information, the prefix length may be replaced with the CBOR "null" (0xF6).</t>
</section> </section>
</section> </section>
<section anchor="ipv6" numbered="true" toc="default"> <section anchor="ipv6" numbered="true" toc="default">
<name>IPv6</name> <name>IPv6</name>
<t>IANA has allocated tag 54 for IPv6 uses. <t>IANA has allocated tag 54 for IPv6 uses.
(This is the ASCII code for '6'.)</t> (This is the ASCII code for '6'.)</t>
<t>An IPv6 address is to be encoded as a sixteen-byte byte string <t>An IPv6 address is to be encoded as a sixteen-byte byte string
(<xref section="3.1" sectionFormat="of" target="RFC8949" format="default"/>, maj or type 2), enclosed in Tag number 54.</t> (<xref section="3.1" sectionFormat="of" target="RFC8949" format="default"/>, maj or type 2), enclosed in tag number 54.</t>
<t>For example:</t> <t>For example:</t>
<artwork name="" type="" align="left" alt=""><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
54(h'20010db81234deedbeefcafefacefeed') 54(h'20010db81234deedbeefcafefacefeed')
]]></artwork> ]]></artwork>
<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>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.
See <xref target="validity" format="default"/> for the detailed construction of the second element.</t> See <xref target="validity" format="default"/> for the detailed construction of the second element.</t>
<t>For example:</t> <t>For example:</t>
<artwork name="" type="" align="left" alt=""><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
54([48, h'20010db81234']) 54([48, h'20010db81234'])
]]></artwork> ]]></artwork>
<t>An IPv6 address combined with a prefix length, such as being used for <t>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.</t> the zone identifier.</t>
<t>For example:</t> <t>For example:</t>
<artwork name="" type="" align="left" alt=""><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
54([h'20010db81234deedbeefcafefacefeed', 56]) 54([h'20010db81234deedbeefcafefacefeed', 56])
]]></artwork> ]]></artwork>
<t>The address-with-prefix form can be reliably distinguished <t>The address-with-prefix form can be reliably distinguished
from the prefix form only in the sequence of the array elements.</t> from the prefix form only in the sequence of the array elements.</t>
<t>Some example of a link-local IPv6 address with a 64-bit prefix:</t> <t>An example of a link-local IPv6 address with a 64-bit prefix:</t>
<artwork name="" type="" align="left" alt=""><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
54([h'fe8000000000020202fffffffe030303', 64, 'eth0']) 54([h'fe8000000000020202fffffffe030303', 64, 'eth0'])
]]></artwork> ]]></artwork>
<t>with a numeric zone identifier:</t> <t>with a numeric zone identifier:</t>
<artwork name="" type="" align="left" alt=""><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
54([h'fe8000000000020202fffffffe030303', 64, 42]) 54([h'fe8000000000020202fffffffe030303', 64, 42])
]]></artwork> ]]></artwork>
<t>An IPv6 link-local address without a prefix length:</t> <t>An IPv6 link-local address without a prefix length:</t>
<artwork name="" type="" align="left" alt=""><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
54([h'fe8000000000020202fffffffe030303', null, 42]) 54([h'fe8000000000020202fffffffe030303', null, 42])
]]></artwork> ]]></artwork>
<t>Zone identifiers may be used with any kind of IP address, not just Li nk-Local addresses. <t>Zone identifiers may be used with any kind of IP address, not just li nk-local addresses.
In particular, they are valid for multicast addresses, and there may still be so me significance In particular, they are valid for multicast addresses, and there may still be so me significance
for Globally Unique Addresses (GUA).</t> for Globally Unique Addresses (GUAs).</t>
</section> </section>
<section anchor="ipv4" numbered="true" toc="default"> <section anchor="ipv4" numbered="true" toc="default">
<name>IPv4</name> <name>IPv4</name>
<t>IANA has allocated tag 52 for IPv4 uses. <t>IANA has allocated tag 52 for IPv4 uses.
(This is the ASCII code for '4'.)</t> (This is the ASCII code for '4'.)</t>
<t>An IPv4 address is to be encoded as a four-byte byte string <t>An IPv4 address is to be encoded as a four-byte byte string
(<xref section="3.1" sectionFormat="of" target="RFC8949" format="default"/>, maj or type 2), enclosed in Tag number 52.</t> (<xref section="3.1" sectionFormat="of" target="RFC8949" format="default"/>, maj or type 2), enclosed in tag number 52.</t>
<t>For example:</t> <t>For example:</t>
<artwork name="" type="" align="left" alt=""><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
52(h'c0000201') 52(h'c0000201')
]]></artwork> ]]></artwork>
<t>An IPv4 prefix, such as 192.0.2.0/24 is to be encoded as a two elemen t array, with the length of the prefix first. <t>An IPv4 prefix, such as 192.0.2.0/24, is to be encoded as a two-eleme nt array, with the length of the prefix first.
See <xref target="validity" format="default"/> for the detailed construction of the second element.</t> See <xref target="validity" format="default"/> for the detailed construction of the second element.</t>
<t>For example:</t> <t>For example:</t>
<artwork name="" type="" align="left" alt=""><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
52([24, h'c00002']) 52([24, h'c00002'])
]]></artwork> ]]></artwork>
<t>An IPv4 address combined with a prefix length, such as being used for <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 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.</t> the zone identifier.</t>
<t>For example, 192.0.2.1/24 is to be encoded as a two element array, <t>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.</t> with the length of the prefix (implied 192.0.2.0/24) last.</t>
<artwork name="" type="" align="left" alt=""><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
52([h'c0000201', 24]) 52([h'c0000201', 24])
]]></artwork> ]]></artwork>
<t>The address-with-prefix form can be reliably distinguished <t>The address-with-prefix form can be reliably distinguished
from the prefix form only in the sequence of the array elements.</t> from the prefix form only in the sequence of the array elements.</t>
</section> </section>
</section> </section>
<section anchor="validity" numbered="true" toc="default"> <section anchor="validity" numbered="true" toc="default">
<name>Tag validity</name> <name>Tag Validity</name>
<t>This section discusses when a tag 54 or tag 52 is valid (<xref section= <t>This section discusses when tag 54 or tag 52 is valid (<xref section="5
"5.3.2" sectionFormat="of" target="RFC8949" format="default"/>). .3.2" sectionFormat="of" target="RFC8949" format="default"/>).
As with all CBOR tags, validity checking can be handled in a generic As with all CBOR tags, validity checking can be handled in a generic
CBOR library or in the application. CBOR library or in the application.
A generic CBOR library needs to document whether and how it handles A generic CBOR library needs to document whether and how it handles
validity checking.</t> validity checking.</t>
<t>The rule <tt>ip-address-or-prefix</tt> in <xref target="cddl-types" for mat="default"/> shows how to check the <t>The rule <tt>ip-address-or-prefix</tt> in <xref target="cddl-types" for mat="default"/> 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. integer values, and the lengths of byte strings.
An instance of tag 52 or 54 is valid if it matches that rule and, for 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 ipv6-prefix and ipv4-prefix, the considerations of Sections
<xref format="counter" target="valid-encoder"/> and <xref format="counter" targe t="valid-decoder"/>.</t> <xref format="counter" target="valid-encoder"/> and <xref format="counter" targe t="valid-decoder"/>.</t>
<section anchor="deterministic-encoding" numbered="true" toc="default"> <section anchor="deterministic-encoding" numbered="true" toc="default">
<name>Deterministic Encoding</name> <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 deterministi c encoding for tags 54 and 52 and require <t>The tag validity rules, combined with the rules in <xref section="4.2 .1" sectionFormat="of" target="RFC8949" format="default"/>, lead to deterministi c encoding for tags 54 and 52 and require
no further Additional Deterministic Encoding Considerations as per no further additional deterministic encoding considerations as per
<xref section="4.2.2" sectionFormat="of" target="RFC8949" format="default"/>.</t > <xref section="4.2.2" sectionFormat="of" target="RFC8949" format="default"/>.</t >
</section> </section>
<section anchor="valid-encoder" numbered="true" toc="default"> <section anchor="valid-encoder" numbered="true" toc="default">
<name>Encoder Considerations for Prefixes</name> <name>Encoder Considerations for Prefixes</name>
<t>For the byte strings used as the second element in the array <t>For the byte strings used as the second element in the array
representing a prefix:</t> representing a prefix:</t>
<t>(1) An encoder <bcp14>MUST</bcp14> set any unused bytes, and any unus <t>(1) An encoder <bcp14>MUST</bcp14> set any unused bytes and any unuse
ed bits in the d bits in the
final byte, if any, to zero. final byte, if any, to zero.
Unused bytes/bits are bytes/bits that are not covered by the prefix length given Unused bytes (or bits) are bytes (or bits) that are not covered by the prefix le
. ngth given.
So for example, <tt>2001:db8:1230::/44</tt> <bcp14>MUST</bcp14> be encoded as:</ So, for example, <tt>2001:db8:1230::/44</tt> <bcp14>MUST</bcp14> be encoded as:<
t> /t>
<artwork name="" type="" align="left" alt=""><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
54([44, h'20010db81230']) 54([44, h'20010db81230'])
]]></artwork> ]]></artwork>
<t>even though variations like:</t> <t>even though variations like:</t>
<artwork name="" type="" align="left" alt=""><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
54([44, h'20010db81233']) 54([44, h'20010db81233'])
54([44, h'20010db8123f']) 54([44, h'20010db8123f'])
54([44, h'20010db8123012']) 54([44, h'20010db8123012'])
]]></artwork> ]]></artwork>
<t>start with the same 44 bits, but are not valid.</t> <t>start with the same 44 bits but are not valid.</t>
<t>(Analogous examples can be constructed for IPv4 prefixes.)</t> <t>(Analogous examples can be constructed for IPv4 prefixes.)</t>
<t>(2) An encoder <bcp14>MUST</bcp14> then omit any right-aligned (trail ing) sequence of <t>(2) An encoder <bcp14>MUST</bcp14> then omit any right-aligned (trail ing) sequence of
bytes that are all zero.</t> bytes in which the bytes are all zeros.</t>
<t>There is no relationship between the number of bytes omitted and the prefix length. <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> For instance, the prefix 2001:db8::/64 is encoded as:</t>
<artwork name="" type="" align="left" alt=""><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
54([64, h'20010db8']) 54([64, h'20010db8'])
]]></artwork> ]]></artwork>
</section> </section>
<section anchor="valid-decoder" numbered="true" toc="default"> <section anchor="valid-decoder" numbered="true" toc="default">
<name>Decoder Considerations for Prefixes</name> <name>Decoder Considerations for Prefixes</name>
<t>A decoder <bcp14>MUST</bcp14> check that all unused bits encoded in t he byte string <t>A decoder <bcp14>MUST</bcp14> check that all unused bits encoded in t he 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.</t> the prefix length, are zero.</t>
<t>A decoder <bcp14>MUST</bcp14> also check that the byte string does no t end in a zero <t>A decoder <bcp14>MUST</bcp14> also check that the byte string does no t end in a zero
byte.</t> byte.</t>
<t>Since encoders are required to remove zero-valued trailing bytes, a <t>Since encoders are required to remove zero-valued trailing bytes, a
decoder <bcp14>MUST</bcp14> handle the case where a prefix length specifies that decoder <bcp14>MUST</bcp14> handle cases where a prefix length specifies that mo
more re
bits are relevant than are actually present in the byte-string.</t> bits are relevant than are actually present in the byte string.</t>
<t>As an example, ::/128 is encoded as</t> <t>As an example, ::/128 is encoded as</t>
<artwork name="" type="" align="left" alt=""><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
54([128, h'']) 54([128, h''])
]]></artwork> ]]></artwork>
<section anchor="example-implementation" numbered="true" toc="default"> <section anchor="example-implementation" numbered="true" toc="default">
<name>Example implementation</name> <name>Example Implementation</name>
<t>A recommendation for prefix decoder implementations is to first cre ate <t>A recommendation for prefix decoder implementations is to first cre ate
an array of 16 (or 4) zero bytes.</t> an array of 16 (or 4) zero bytes.</t>
<t>Then taking whichever is smaller between (a) the length of the <t>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.</t> the byte string into the byte array.</t>
<t>Finally, looking at the number of unused bits in the last byte (if <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 any) of the range covered by the prefix length, check that any unused
bits in the byte string are zero:</t> bits in the byte string are zero:</t>
<sourcecode type="c"><![CDATA[ <sourcecode type="c"><![CDATA[
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();
]]></sourcecode> ]]></sourcecode>
</section> </section>
</section> </section>
</section> </section>
<section anchor="cddl" numbered="true" toc="default"> <section anchor="cddl" numbered="true" toc="default">
<name>CDDL</name> <name>CDDL</name>
<t>For use with CDDL <xref target="RFC8610" format="default"/>, the typena mes defined in <xref target="cddl-types" format="default"/> <t>For use with Concise Data Definition Language (CDDL) <xref target="RFC8 610" format="default"/>, the type names defined in <xref target="cddl-types" for mat="default"/>
are recommended:</t> are recommended:</t>
<figure anchor="cddl-types"> <figure anchor="cddl-types">
<name>CDDL types for tags 54 and 52</name> <name>CDDL Types for Tags 54 and 52</name>
<sourcecode type="cddl"><![CDATA[ <sourcecode type="cddl"><![CDATA[
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 line 304 skipping to change at line 306
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
]]></sourcecode> ]]></sourcecode>
</figure> </figure>
</section> </section>
<section anchor="security-considerations" numbered="true" toc="default"> <section anchor="security-considerations" numbered="true" toc="default">
<name>Security Considerations</name> <name>Security Considerations</name>
<t>This document provides an CBOR encoding for IPv4 and IPv6 address infor mation. <t>This document provides a CBOR encoding for IPv4 and IPv6 address inform ation.
Any applications using these encodings will need to consider the security Any applications using these encodings will need to consider the security
implications of these data in their specific context. For example, identifying implications of this data in their specific context. For example, identifying
which byte sequences in a protocol are addresses may allow an attacker or 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> 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 <t>Applications need to check the validity (<xref target="validity" format ="default"/>) of a tag before
acting on any of its contents. acting on any of its contents.
If the validity checking is not done in the generic CBOR decoder, it If the validity checking is not done in the generic CBOR decoder, it
needs to be done in the application; in any case it needs to be done needs to be done in the application; in any case, it needs to be done
before the tag is transformed into a platform-specific representation before the tag is transformed into a platform-specific representation
that could conceal validity errors.</t> that could conceal validity errors.</t>
<t>The right-hand bits of the prefix, after the prefix-length, are set to <t>The right-hand bits of the prefix, after the prefix length, are set to
zero by this protocol. zero by this protocol.
(Otherwise, a malicious party could use them to transmit covert data (Otherwise, a malicious party could use them to transmit covert data
in a way that would not affect the primary use of this encoding. in a way that would not affect the primary use of this encoding.
Such abuse is detected by tag validity checking, and can also be Such abuse is detected by tag validity checking and can also be
detected by examination of the raw protocol bytes.)</t> detected by examination of the raw protocol bytes.)</t>
</section> </section>
<section anchor="iana-considerations" numbered="true" toc="default"> <section anchor="iana-considerations" numbered="true" toc="default">
<name>IANA Considerations</name> <name>IANA Considerations</name>
<t>IANA has allocated two tags from the Specification Required area of <t>IANA has allocated two tags from the Specification Required <xref targe
the Concise Binary Object Representation (CBOR) Tags <xref target="IANA.cbor-tag t="RFC8126"/> area of
s" format="default"/>:</t> the "Concise Binary Object Representation (CBOR) Tags" registry <xref target="IA
NA.cbor-tags" format="default"/>:</t>
<section anchor="tag-54-ipv6" numbered="true" toc="default"> <section anchor="tag-54-ipv6" numbered="true" toc="default">
<name>Tag 54 - IPv6</name> <name>Tag 54 - IPv6</name>
<artwork name="" type="" align="left" alt=""><![CDATA[ <dl spacing="compact">
Data Item: byte string or array <dt>Data Item:</dt><dd> byte string or array</dd>
Semantics: IPv6, [prefixlen,IPv6], [IPv6,prefixpart] <dt>Semantics:</dt><dd> IPv6, [prefixlen,IPv6], [IPv6,prefixpart]</dd>
]]></artwork> </dl>
</section> </section>
<section anchor="tag-52-ipv4" numbered="true" toc="default"> <section anchor="tag-52-ipv4" numbered="true" toc="default">
<name>Tag 52 - IPv4</name> <name>Tag 52 - IPv4</name>
<artwork name="" type="" align="left" alt=""><![CDATA[ <dl spacing="compact">
Data Item: byte string or array <dt>Data Item:</dt><dd> byte string or array</dd>
Semantics: IPv4, [prefixlen,IPv4], [IPv4,prefixpart] <dt>Semantics:</dt><dd> IPv4, [prefixlen,IPv4], [IPv4,prefixpart]</dd>
]]></artwork> </dl>
</section> </section>
<section anchor="tags-260-and-261" numbered="true" toc="default"> <section anchor="tags-260-and-261" numbered="true" toc="default">
<name>Tags 260 and 261</name> <name>Tags 260 and 261</name>
<t>IANA is requested to add the note "DEPRECATED in favor of 52 and 54 f or IP addresses" to registrations 260 and 261</t> <t>IANA has added the note "DEPRECATED in favor of 52 and 54 for IP addr esses" to registrations 260 and 261.</t>
</section> </section>
</section> </section>
</middle> </middle>
<back> <back>
<references> <references>
<name>References</name> <name>References</name>
<references> <references>
<name>Normative References</name> <name>Normative References</name>
<reference anchor="RFC8949" target="https://www.rfc-editor.org/info/rfc8 <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8126.
949"> xml"/>
<front> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8949.
<title>Concise Binary Object Representation (CBOR)</title> xml"/>
<author fullname="C. Bormann" initials="C." surname="Bormann"> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8610.
<organization/> xml"/>
</author> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.
<author fullname="P. Hoffman" initials="P." surname="Hoffman"> xml"/>
<organization/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.
</author> xml"/>
<date month="December" year="2020"/>
<abstract>
<t>The Concise Binary Object Representation (CBOR) is a data forma
t whose design goals include the possibility of extremely small code size, fairl
y small message size, and extensibility without the need for version negotiation
. These design goals make it different from earlier binary serializations such a
s ASN.1 and MessagePack.</t>
<t>This document obsoletes RFC 7049, providing editorial improveme
nts, new details, and errata fixes while keeping full compatibility with the int
erchange 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/rfc8
610">
<front>
<title>Concise Data Definition Language (CDDL): A Notational Convent
ion to Express Concise Binary Object Representation (CBOR) and JSON Data Structu
res</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 Conci
se Binary Object Representation (CBOR) data structures (RFC 7049). Its main goa
l is to provide an easy and unambiguous way to express structures for protocol m
essages 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/rfc2
119">
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</tit
le>
<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 sig
nify the requirements in the specification. These words are often capitalized.
This document defines these words as they should be interpreted in IETF document
s. 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/rfc8
174">
<front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</ti
tle>
<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 protoco
l specifications. This document aims to reduce the ambiguity by clarifying tha
t 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>
</references> </references>
<references> <references>
<name>Informative References</name> <name>Informative References</name>
<reference anchor="IANA.cbor-tags" target="https://www.iana.org/assignme nts/cbor-tags"> <reference anchor="IANA.cbor-tags" target="https://www.iana.org/assignme nts/cbor-tags">
<front> <front>
<title>Concise Binary Object Representation (CBOR) Tags</title> <title>Concise Binary Object Representation (CBOR) Tags</title>
<author> <author>
<organization>IANA</organization> <organization>IANA</organization>
</author> </author>
<date/> <date/>
</front> </front>
</reference> </reference>
<reference anchor="RFC4007" target="https://www.rfc-editor.org/info/rfc4
007"> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4007.
<front> xml"/>
<title>IPv6 Scoped Address Architecture</title> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4001.
<author fullname="S. Deering" initials="S." surname="Deering"> xml"/>
<organization/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6991.
</author> xml"/>
<author fullname="B. Haberman" initials="B." surname="Haberman"> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7042.
<organization/> xml"/>
</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, expe
cted behavior, textual representation, and usage of IPv6 addresses of different
scopes. According to a decision in the IPv6 working group, this document intent
ionally 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/rfc4
001">
<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="Schoenwae
lder">
<organization/>
</author>
<date month="February" year="2005"/>
<abstract>
<t>This MIB module defines textual conventions to represent common
ly used Internet network layer addressing information. The intent is that these
textual conventions will be imported and used in MIB modules that would otherwi
se 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/rfc6
991">
<front>
<title>Common YANG Data Types</title>
<author fullname="J. Schoenwaelder" initials="J." role="editor" surn
ame="Schoenwaelder">
<organization/>
</author>
<date month="July" year="2013"/>
<abstract>
<t>This document introduces a collection of common data types to b
e 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/rfc7
042">
<front>
<title>IANA Considerations and IETF Protocol and Documentation Usage
for IEEE 802 Parameters</title>
<author fullname="D. Eastlake 3rd" initials="D." surname="Eastlake 3
rd">
<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 IET
F protocols, specifies IANA considerations for assignment of points under the IA
NA 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>
</references> </references>
</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"> <section numbered="false" anchor="acknowledgements" toc="default">
<name>Acknowledgements</name> <name>Acknowledgements</name>
<t><contact fullname="Roman Danyliw"/>, <contact fullname="Donald Eastlake "/>, <contact fullname="Ben Kaduk"/>, <contact fullname="Barry Leiba"/>, and <co ntact fullname="Éric Vyncke"/> reviewed the document and provided suggested text . <t><contact fullname="Roman Danyliw"/>, <contact fullname="Donald Eastlake "/>, <contact fullname="Ben Kaduk"/>, <contact fullname="Barry Leiba"/>, and <co ntact fullname="Éric Vyncke"/> reviewed the document and provided suggested text .
<contact fullname="Jürgen Schönwälder"/> helped finding the history of IPv4 zone identifiers.</t> <contact fullname="Jürgen Schönwälder"/> helped find the history of IPv4 zone id entifiers.</t>
</section> </section>
</back> </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> </rfc>
 End of changes. 55 change blocks. 
417 lines changed or deleted 122 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/