idnits 2.17.1 draft-arkko-arp-iana-rules-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 12, 2009) is 5545 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Informational RFC: RFC 1329 ** Downref: Normative reference to an Informational RFC: RFC 2176 ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) ** Obsolete normative reference: RFC 5342 (Obsoleted by RFC 7042) Summary: 5 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Arkko 3 Internet-Draft Ericsson 4 Updates: C. Pignataro 5 826,951,1044,1329,2131,2132,2176,2225,2834,2835,3315,4338,4361,4701Cisco 6 (if approved) February 12, 2009 7 Intended status: Standards Track 8 Expires: August 16, 2009 10 IANA Allocation Guidelines for the Address Resolution Protocol (ARP) 11 draft-arkko-arp-iana-rules-06 13 Status of this Memo 15 This Internet-Draft is submitted to IETF in full conformance with the 16 provisions of BCP 78 and BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on August 16, 2009. 36 Copyright Notice 38 Copyright (c) 2009 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. 48 Abstract 50 This document specifies the IANA guidelines for allocating new values 51 in the Address Resolution Protocol (ARP). This document also 52 reserves some numbers for experimentation purposes. The changes also 53 affect other protocols that employ values from the ARP name spaces. 55 1. Introduction 57 This document specifies the IANA guidelines [RFC5226] for allocating 58 new values for various fields in the Address Resolution Protocol 59 (ARP) [RFC0826]. The change is also applicable to extensions of ARP 60 that use the same message format, such as [RFC0903], [RFC1931], and 61 [RFC2390]. 63 The change also affects other protocols that employ values from the 64 ARP name spaces. For instance, the ARP hardware address type 65 (ar$hrd) number space is also used in the "htype" (hardware address 66 type) fields in Bootstrap Protocol (BOOTP) [RFC0951] and Dynamic Host 67 Configuration Protocol (DHCP) [RFC2131], as well as in the "hardware 68 type" field in the DHCP Unique Identifiers in DHCPv6 [RFC3315]. 69 These protocols are therefore affected by the update in the IANA 70 rules. Other affected specifications include the specialized address 71 resolution mechanisms in HYPERchannel [RFC1044], DHCP options 72 [RFC2132], [RFC4361], ATM (Asynchronous Transfer Mode) ARP [RFC2225], 73 HARP (High-Performance Parallel Interface ARP) [RFC2834], [RFC2835], 74 Dual MAC FDDI (Fiber Distributed Data Interface) ARP [RFC1329], MAPOS 75 (Multiple Access Protocol over Synchronous Optical Network/ 76 Synchronous Digital Hierarchy) ARP [RFC2176], FC (Fibre Channel) ARP 77 [RFC4338], and the DNS DHCID Resource Record [RFC4701]. 79 The IANA guidelines are given in Section 2. Previously, no IANA 80 guidance existed for such allocations. The purpose of this document 81 is to allow IANA to manage number assignments based on these 82 guidelines in a consistent manner. 84 This document also reserves some numbers for experimentation 85 purposes. These numbers are given in Section 3. 87 2. IANA Considerations 89 The following rules apply to the fields of ARP: 91 ar$hrd (16 bits) Hardware address space 93 Requests for ar$hrd values below 256 or a batch of more than one 94 new value are made through Expert Review [RFC5226]. 96 Note that certain protocols, such as BOOTP and DHCPv4 employ these 97 values within a 8 bit field. The expert should determine that the 98 need to allocate the new values exists and that the existing 99 values are insufficient to represent the new hardware address 100 types. The expert should also determine the applicability of the 101 request, and assign values higher than 255 for requests that do 102 not apply to BOOTP/DHCPv4. Similarly, the expert should assign 103 one-octet values for requests that apply to BOOTP/DHCPv4, as for 104 example the "IPsec tunnel" with value 31 [RFC3456]. Conversely, 105 ARP-only uses without a foreseeable reason to use the same value 106 in BOOTP/DHCPv4 should favor 2-octet values. 108 Requests for individual new ar$hrd values that do not specify a 109 value, or where the requested value is greater than 255, are made 110 through First Come First Served [RFC5226]. The assignment will 111 always result in a 2-octet value. 113 ar$pro (16 bits) Protocol address space 115 These numbers share the Ethertype space. The Ethertype space is 116 administered as described in [RFC5342]. 118 ar$op (16 bits) Opcode 120 Requests for new ar$op values are made through IETF Review or IESG 121 Approval [RFC5226]. 123 Upon the approval of this specification, IANA should update all three 124 registration policies listed in arp-parameters registry as specified 125 in the above list, and add a reference to either this RFC or RFC 126 5342, as appropriate. RFC Editor: This paragraph can be removed upon 127 publication. 129 3. Allocations Defined in This Document 131 When testing new protocol extension ideas, it is often necessary to 132 use an actual constant in order to use the new function, even when 133 testing in a closed environment. This document reserves the 134 following numbers for experimentation purposes in ARP: 136 o Two new ar$hrd values are allocated for experimental purposes, 137 HW_EXP1 (TBD-BY-IANA-1, but below 256) and HW_EXP2 (TBD-BY-IANA-2, 138 but above 255 and preferably with different values in the least 139 and most significant octets). 141 o Two new values for the ar$op are allocated for experimental 142 purposes, OP_EXP1 (TBD-BY-IANA-3, any value will be sufficient) 143 and OP_EXP2 (TBD-BY-IANA-4, any value will be sufficient). 145 Note that [RFC5342], Section B.2 lists two Ethertypes that can be 146 used for experimental purposes. 148 In addition, for both ar$hrd and ar$op the values 0 and 65535 are 149 marked as reserved. This means that they are not available for 150 allocation. 152 Upon the approval of this specification, IANA should add the two new 153 allocations and two reserved values for both ar$hrd and ar$op to the 154 arp-parameters registry, and reference this RFC. RFC Editor: This 155 paragraph can be removed upon publication. 157 4. Security Considerations 159 This specification does not change the security properties of the 160 affected protocols. 162 However, a few words are necessary about the use of the experimental 163 code points defined in Section 3. Potentially harmful side-effects 164 from the use of the experimental values needs to be carefully 165 evaluated before deploying any experiment across networks that the 166 owner of the experiment does not entirely control. Guidance given in 167 [RFC3692] about the use of experimental values needs to be followed. 169 5. Acknowledgments 171 The lack of any current rules has come up as new values were 172 requested from IANA and they contacted IESG for advice. The author 173 would like to thank Michelle Cotton in particular for bringing this 174 issue up. The author would also like to thank Brian Carpenter, 175 Thomas Narten, Scott Bradner, Donald Eastlake, Andrew G. Malis, Brian 176 Haberman, Robert Sparks, Larry Zhu, and Dave Thaler for feedback. 178 6. References 179 6.1. Normative References 181 [RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or 182 converting network protocol addresses to 48.bit Ethernet 183 address for transmission on Ethernet hardware", STD 37, 184 RFC 826, November 1982. 186 [RFC0951] Croft, B. and J. Gilmore, "Bootstrap Protocol", RFC 951, 187 September 1985. 189 [RFC1044] Hardwick, K. and J. Lekashman, "Internet Protocol on 190 Network System's HYPERchannel: Protocol specification", 191 STD 45, RFC 1044, February 1988. 193 [RFC1329] Kuehn, P., "Thoughts on Address Resolution for Dual MAC 194 FDDI Networks", RFC 1329, May 1992. 196 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 197 RFC 2131, March 1997. 199 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 200 Extensions", RFC 2132, March 1997. 202 [RFC2176] Murakami, K. and M. Maruyama, "IPv4 over MAPOS Version 1", 203 RFC 2176, June 1997. 205 [RFC2225] Laubach, M. and J. Halpern, "Classical IP and ARP over 206 ATM", RFC 2225, April 1998. 208 [RFC2834] Pittet, J., "ARP and IP Broadcast over HIPPI-800", 209 RFC 2834, May 2000. 211 [RFC2835] Pittet, J., "IP and ARP over HIPPI-6400 (GSN)", RFC 2835, 212 May 2000. 214 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 215 and M. Carney, "Dynamic Host Configuration Protocol for 216 IPv6 (DHCPv6)", RFC 3315, July 2003. 218 [RFC3692] Narten, T., "Assigning Experimental and Testing Numbers 219 Considered Useful", BCP 82, RFC 3692, January 2004. 221 [RFC4338] DeSanti, C., Carlson, C., and R. Nixon, "Transmission of 222 IPv6, IPv4, and Address Resolution Protocol (ARP) Packets 223 over Fibre Channel", RFC 4338, January 2006. 225 [RFC4361] Lemon, T. and B. Sommerfeld, "Node-specific Client 226 Identifiers for Dynamic Host Configuration Protocol 227 Version Four (DHCPv4)", RFC 4361, February 2006. 229 [RFC4701] Stapp, M., Lemon, T., and A. Gustafsson, "A DNS Resource 230 Record (RR) for Encoding Dynamic Host Configuration 231 Protocol (DHCP) Information (DHCID RR)", RFC 4701, 232 October 2006. 234 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 235 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 236 May 2008. 238 [RFC5342] Eastlake. , D., "IANA Considerations and IETF Protocol 239 Usage for IEEE 802 Parameters", BCP 141, RFC 5342, 240 September 2008. 242 6.2. Informative References 244 [RFC0903] Finlayson, R., Mann, T., Mogul, J., and M. Theimer, 245 "Reverse Address Resolution Protocol", STD 38, RFC 903, 246 June 1984. 248 [RFC1931] Brownell, D., "Dynamic RARP Extensions for Automatic 249 Network Address Acquisition", RFC 1931, April 1996. 251 [RFC2390] Bradley, T., Brown, C., and A. Malis, "Inverse Address 252 Resolution Protocol", RFC 2390, September 1998. 254 [RFC3456] Patel, B., Aboba, B., Kelly, S., and V. Gupta, "Dynamic 255 Host Configuration Protocol (DHCPv4) Configuration of 256 IPsec Tunnel Mode", RFC 3456, January 2003. 258 Appendix A. Changes from the Original RFCs 260 This document specifies only the IANA rules associated with various 261 fields in ARP. The specification of these rules also affects the 262 allocation of corresponding fields in protocols listed in Section 1 263 that share the registry. This document does not make any changes in 264 the operation of these protocols themselves. 266 Authors' Addresses 268 Jari Arkko 269 Ericsson 270 Jorvas 02420 271 Finland 273 Email: jari.arkko@piuha.net 275 Carlos Pignataro 276 Cisco Systems 277 7200-12 Kit Creek Road 278 PO Box 14987 279 Research Triangle Park, NC 27709 280 USA 282 Email: cpignata@cisco.com