[dnsext] DNS RR (RFC 4701) impacts from draft-arkko-arp-iana-rules

Jari Arkko <jari.arkko@piuha.net> Mon, 01 December 2008 21:37 UTC

Return-Path: <owner-namedroppers@ops.ietf.org>
X-Original-To: ietfarch-dnsext-archive@core3.amsl.com
Delivered-To: ietfarch-dnsext-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A715C28C0F2; Mon, 1 Dec 2008 13:37:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.519
X-Spam-Level:
X-Spam-Status: No, score=-102.519 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a2e1fcVQgJW7; Mon, 1 Dec 2008 13:37:28 -0800 (PST)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id AA6BC28C0F9; Mon, 1 Dec 2008 13:37:28 -0800 (PST)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from <owner-namedroppers@ops.ietf.org>) id 1L7GND-0002ew-HS for namedroppers-data@psg.com; Mon, 01 Dec 2008 21:32:07 +0000
Received: from [2001:14b8:400::130] (helo=smtp.piuha.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from <jari.arkko@piuha.net>) id 1L7GN6-0002eO-09 for namedroppers@ops.ietf.org; Mon, 01 Dec 2008 21:32:03 +0000
Received: from smtp.piuha.net (localhost [127.0.0.1]) by smtp.piuha.net (Postfix) with ESMTP id 2988719876B; Mon, 1 Dec 2008 23:31:58 +0200 (EET)
Received: from [127.0.0.1] (unknown [IPv6:2001:14b8:400::130]) by smtp.piuha.net (Postfix) with ESMTP id C25E1198639; Mon, 1 Dec 2008 23:31:57 +0200 (EET)
Message-ID: <493457BA.5020203@piuha.net>
Date: Mon, 01 Dec 2008 23:31:38 +0200
From: Jari Arkko <jari.arkko@piuha.net>
User-Agent: Thunderbird 2.0.0.18 (X11/20081125)
MIME-Version: 1.0
To: namedroppers@ops.ietf.org
CC: Carlos Pignataro <cpignata@cisco.com>, Russ Housley <housley@vigilsec.com>
Subject: [dnsext] DNS RR (RFC 4701) impacts from draft-arkko-arp-iana-rules
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: ClamAV using ClamSMTP
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
List-ID: <namedroppers.ops.ietf.org>

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



--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>