One document matched: draft-arkko-arp-iana-rules-02.xml

<?xml version="1.0" encoding="iso-8859-1" ?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">

<rfc ipr="full3978" docName="draft-arkko-arp-iana-rules-02" category="std" updates="826,1044,951,2131,2132,2225,2834,2835,3315,4338,4361,4701">
<?rfc toc="no"?>
<?rfc symrefs="yes"?>
<?rfc autobreaks="yes"?>
<?rfc tocindent="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>

<front>

<title abbrev="ARP IANA Rules">IANA Allocation Guidelines for the Address Resolution Protocol (ARP)</title>

<author initials="J" surname="Arkko" fullname="Jari Arkko">
<organization>Ericsson</organization>
<address>
<postal>
<street/>
<city>Jorvas</city> <code>02420</code>
<country>Finland</country>
</postal>
<email>jari.arkko@piuha.net</email>
</address>
</author>

        <author fullname="Carlos Pignataro" initials="C.M."
                surname="Pignataro">
        <organization>Cisco Systems</organization>
        <address>
            <postal>
                <street>7200-12 Kit Creek Road</street>
                <street>PO Box 14987</street>
                <city>Research Triangle Park</city>
                <code>27709</code>
                <region>NC</region>
                <country>USA</country>
            </postal>
<!--
            <phone>+1-919-392-7428</phone>
            <facsimile>+1-919-869-1438</facsimile>
-->
            <email>cpignata@cisco.com</email>
            </address>
        </author>


<date month="November" year="2008" />

<keyword>IANA rules</keyword>
<keyword>Address Resolution Protocol</keyword>
<keyword>ARP</keyword>

<abstract>

<t>This document specifies the IANA guidelines for allocating new
values in the Address Resolution Protocol (ARP). This document also
reserves some numbers for experimentation purposes. The changes also
affect other protocols that employ values from the ARP name spaces.
</t>

</abstract>

</front>
<middle>

<section anchor="intro" title="Introduction">

<t>This document specifies the IANA guidelines
<xref target='RFC5226'/> for allocating new values for various fields
in the Address Resolution Protocol (ARP) <xref target='RFC0826'/>. The
change is also applicable to extensions of ARP that use the same
message format, such as <xref target="RFC0903"/> and
<xref target="RFC2390"/>.</t>

<t>The change also affects other protocols that employ values from the
ARP name spaces. For instance, the ARP hardware address type (ar$hrd)
number space is also used in the "htype" (hardware address type)
fields in Bootstrap Protocol (BOOTP) <xref target="RFC0951"/> and
Dynamic Host Configuration Protocol (DHCP) <xref target="RFC2131"/>,
as well as in the "hardware type" field in the DHCP Unique Identifiers
in DHCPv6 <xref target="RFC3315"/>. These protocols are therefore
affected by the update in the IANA rules. Other affected
specifications include the specialized address resolution mechanisms
in HYPERchannel <xref target="RFC1044"/>, DHCP options
<xref target="RFC2132"/>, <xref target="RFC4361"/>, ATM (Asynchronous
Transfer Mode) ARP <xref target="RFC2225"/>, HARP (High-Performance
Parallel Interface ARP) <xref target="RFC2834"/>,
<xref target="RFC2835"/>, FC (Fibre Channel) ARP
<xref target="RFC4338"/>, and DNS Resource Records
<xref target="RFC4701"/>.</t>

<t>The IANA guidelines are given in
<xref target="ianarules"/>. Previously, no IANA guidance existed for
such allocations.</t>

<t>This document also reserves some numbers for experimentation
purposes. These numbers are given in <xref target="expalloc"/>.</t>

</section>

<section anchor="ianarules" title="IANA Considerations">

<t>The following rules apply to the fields of ARP:

<list style="hanging">
<t hangText="ar$hrd (16 bits) Hardware address
space"><vspace blankLines="1"/> Requests for individual new ar$hrd
values are made through First Come First Served
<xref target="RFC5226"/>. Requests for ar$hrd values below 256 or a
batch of several new values are made through Expert Review
[RFC5226]. Note that certain protocols, such as BOOTP and DHCPv4
employ these values within a 8 bit field. The expert should determine
that the need to allocate the new values exists and that the existing
values are insufficient to represent the new hardware address
types. The expert should also determine the applicability of the
request, and assign values higher than 255 for requests that do not
apply to BOOTP/DHCPv4. Similarly, the expert should assign one-octet
values for requests that clearly apply to BOOTP/DHCPv4 but not ARP, as
for example the "IPsec tunnel" with value 31
<xref target="RFC3456"/>. Conversely, ARP-only uses should favor
2-octet values.</t>

<t hangText="ar$pro (16 bits) Protocol address
space"><vspace blankLines="1"/> These numbers share the Ethertype
space.  The Ethertype space is administered as described in
<xref target="RFC5342"/>.</t>

<t hangText="ar$op (16 bits) Opcode"><vspace blankLines="1"/> Requests
for new ar$op values are made through IETF Review or IESG Approval
<xref target="RFC5226"/>.</t>

</list></t>

</section>

<section anchor="expalloc" title="Allocations Defined in This Document">

<t>When testing new protocol extension ideas, it is often necessary to
use an actual constant in order to use the new function, even when
testing in a closed environment. This document reserves the following
numbers for experimentation purposes in ARP:

<list style="symbols">

<t>One new ar$hrd value is allocated for experimental purposes,
HW_EXP (TBD).</t>

<t>Two new values for the ar$op are allocated for experimental
purposes, OP_EXP1 (TBD, but below 256) and OP_EXP2 (TBD, but above 255
and preferrably with different values in the least and most
significant octets).</t>

</list></t>

<t>Note that <xref target="RFC5342"/>, Section B.2 lists two
Ethertypes that can be used for experimental purposes.</t>

<t>In addition, for both ar$hrd and ar$op the values 0 and 65535 are
marked as reserved. This means that they are not available for
allocation.</t>

</section>

<section title='Security Considerations'>

<t>This specification does not change the security properties
of the affected protocols.</t>

<t>However, a few words are necessary about the use of the
experimental code points defined in
<xref target="expalloc"/>. Potentially harmful side-effects from the
use of the experimental values needs to be carefully evaluated before
deploying any experiment across networks that the owner of the
experiment does not entirely control. Guidance given in
<xref target="RFC3692"/> about the use of experimental values needs to
be followed.</t>

</section>

<section title="Acknowledgments">

<t>The lack of any current rules has come up as new values were
requested from IANA.  The author would like to thank Michelle Cotton
in particular for bringing this issue up.  When no rules exist, IANA
consults the IESG for approval of the new values. The purpose of this
specification is to establish the rules and allow IANA to operate
based on the rules, without requiring confirmation from the IESG. The
author would also like to thank Brian Carpenter, Thomas Narten, Scott
Bradner, Donald Eastlake, Andrew G. Malis, Brian Haberman, and Dave
Thaler for feedback.</t>

</section>

</middle>
<back>

<references title="Normative References">
      <?rfc include="reference.RFC.0826.xml"?>
      <?rfc include="reference.RFC.0951.xml"?>
      <?rfc include="reference.RFC.1044.xml"?>
      <?rfc include="reference.RFC.2131.xml"?>
      <?rfc include="reference.RFC.2132.xml"?>
      <?rfc include="reference.RFC.2225.xml"?>
      <?rfc include="reference.RFC.2834.xml"?>
      <?rfc include="reference.RFC.2835.xml"?>
      <?rfc include="reference.RFC.3315.xml"?>
      <?rfc include="reference.RFC.3692.xml"?>
      <?rfc include="reference.RFC.4338.xml"?>
      <?rfc include="reference.RFC.4361.xml"?>
      <?rfc include="reference.RFC.4701.xml"?>
      <?rfc include="reference.RFC.5226.xml"?>
      <?rfc include="reference.RFC.5342.xml"?>
</references>

<references title="Informative References">
      <?rfc include="reference.RFC.0903.xml"?>
      <?rfc include="reference.RFC.2390.xml"?>
      <?rfc include="reference.RFC.3456.xml"?>
</references>

<section title="Changes from the Original RFCs">

<t>This document specifies only the IANA rules associated with various
fields in ARP.  The specification of these rules also affects the
allocation of corresponding fields in protocols listed
in <xref target="intro"/> that share the registry. This document does
not make any changes in the operation of these protocols
themselves.</t>

</section>

</back>
</rfc>