Subject: [dhcwg] DHCP impacts from draft-arkko-arp-iana-rules

From: Jari Arkko <[email-masked]>
Date: Mon, 01 Dec 2008 23:28:46 +0200

Folks,

I recently wrote a draft about the IANA rules regarding ARP, as no such 
rules were defined before.

During last call, it became apparent that there are a few other 
protocols that use the same numbers. For instance, specialized forms of 
ARP for certain link layers or DHCPv4/6. Having realized this, we did a 
more thorough search of the RFC series to attempt to find all such uses. 
The new version of my draft lists all these uses and updates the RFCs in 
question.

I would like to ask for your review to make sure (a) that the ARP rule 
change is OK from the perspective of your protocol and (b) we have found 
all uses of the ARP numbers. Here's what the draft says:

"The change is also applicable to extensions of ARP that use the same 
message format, such as [RFC0903], [RFC1931], and [RFC2390].

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) [RFC0951] and Dynamic Host Configuration 
Protocol (DHCP) [RFC2131], as well as in the "hardware type" field in 
the DHCP Unique Identifiers in DHCPv6 [RFC3315]. These protocols are 
therefore affected by the update in the IANA rules.  Other affected 
specifications include the specialized address resolution mechanisms in 
HYPERchannel [RFC1044], DHCP options [RFC2132], [RFC4361], ATM 
(Asynchronous Transfer Mode) ARP [RFC2225], HARP (High-Performance 
Parallel Interface ARP) [RFC2834], [RFC2835], Dual MAC FDDI (Fiber 
Distributed Data Interface) ARP [RFC1329], MAPOS (Multiple Access 
Protocol over Synchronous Optical Network/Synchronous Digital Hierarchy) 
ARP [RFC2176], FC (Fibre Channel) ARP [RFC4338], and DNS Resource 
Records [RFC4701]."

(We have only listed a protocol as affected when uses ARP values 
directly, e.g., in its own protocol message formats. Use of ARP as-is is 
of course not an issue. I have also not listed the many IP over Foo 
specifications that talk about how to use ARP in Foo, describing what 
hardware type values to use, etc.)

Here's the URL for the draft: 
http://tools.ietf.org/html/draft-arkko-arp-iana-rules-04

Jari

_______________________________________________
dhcwg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dhcwg

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Mon, 1 Dec 2008 18:02:53 -0500

Hum ... Didn't realize this was such a problem.

There's no issue that I can see with DHCPv4 - you've addressed the
1-octet issue for future assignments because of the limit on the htype
field. For DHCPv6, there is no issue as it has a 2-octet field.

Thus, draft looks OK to me.

- Bernie 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Jari Arkko
Sent: Monday, December 01, 2008 4:29 PM
To: Dhcwg
Cc: Carlos Pignataro (cpignata); Russ Housley
Subject: [dhcwg] DHCP impacts from draft-arkko-arp-iana-rules

Folks,

question.

Jari

---

From: Ralph Droms <[email-masked]>
Date: Tue, 2 Dec 2008 07:03:30 -0500

Jari - I agree with Bernie's analysis about the impact of your draft  
on DHCPv*.

I have a question about the mechanics of the request to IANA: do you  
want to specify how the request to IANA is documented?  For example,  
RFC 2939 requires that new DHCP options be documented in an RFC before  
IANA receives a request for the associated option code.  Will a simple  
request to IANA, for example through http://iana.org/cgi-bin/assignments.pl 
, be sufficient for new ARP codes?

- Ralph

---

From: Jari Arkko <[email-masked]>
Date: Tue, 02 Dec 2008 18:49:12 +0200

Ralph, Bernie,

> Jari - I agree with Bernie's analysis about the impact of your draft 

Good -- I just wanted to know its not a problem.

> request to IANA, for example through 
> http://iana.org/cgi-bin/assignments.pl, be sufficient for new ARP codes?
These depend on the particular namespace. For ar$op, we specified IETF 
Review or IESG Approval. The former involves the publication of an RFC 
from the IETF. The latter is for exceptional situations and we'd have to 
consider the circumstances to decide what is going to be required. But 
I'd say we would probably require an RFC even in this case.

For ar$hrd, individual values can be allocated via FCFS. However, one 
byte values require expert review. No special requirements have been set 
for the documentation in either case. You could argue that such 
requirements should be set. But note that my draft is already a 
tightening of the rules from the current unspecified situation. We don't 
want to make things too hard, either.

Jari