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

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

<rfc ipr="full3978" docName="draft-arkko-arp-iana-rules-00" category="std" updates="826,903,2390,1931,2225">
<?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>

<date month="October" 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.
</t>

</abstract>

</front>
<middle>

<section 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 defined in
<xref target="RFC0903"/>, <xref target="RFC2390"/>,
<xref target="RFC1931"/>, and <xref target="RFC2225"/>. The 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 a batch of several new ar$hrd
values are made through Expert Review <xref target="RFC5226"/>. 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.</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) and OP_EXP2 (TBD).</t>

</list></t>

<t>Note that <xref target="RFC5342"/>, Section B.2 lists two
Ethertypes that can be used for experimental purposes.</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"/>. Production networks do not necessarily
support the use of experimental code points in ARP. Potentially
harmful side-effects from the use of the experimental values should be
carefully evaluated before deploying any experiment across networks
that the owner of the experiment does not entirely control.</t>

<t>The network administrators should also ensure that each code point
is used consistently to avoid interference between experiments.</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, and Dave Thaler for feedback.</t>

</section>

</middle>
<back>

<references title="Normative References">
      <?rfc include="reference.RFC.0826.xml"?>
      <?rfc include="reference.RFC.0903.xml"?>
      <?rfc include="reference.RFC.1931.xml"?>
      <?rfc include="reference.RFC.2225.xml"?>
      <?rfc include="reference.RFC.2390.xml"?>
      <?rfc include="reference.RFC.5226.xml"?>
      <?rfc include="reference.RFC.5342.xml"?>
</references>

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

<t>This document specifies only the IANA rules associated with various
fields in ARP, and does not make any other changes in the operation of
the protocol itself.</t>

</section>

</back>
</rfc>