RE: [dhcwg] FW: RFC3315 question
"Bernie Volz \(volz\)" <volz@cisco.com> Thu, 01 March 2007 20:47 UTC
Return-path: <dhcwg-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMsBv-0005kW-Cz; Thu, 01 Mar 2007 15:47:55 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMsBu-0005kI-KA for dhcwg@ietf.org; Thu, 01 Mar 2007 15:47:54 -0500
Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HMsBs-0001O6-3I for dhcwg@ietf.org; Thu, 01 Mar 2007 15:47:54 -0500
Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 01 Mar 2007 15:47:52 -0500
X-IronPort-AV: i="4.14,238,1170651600"; d="scan'208"; a="114745217:sNHT71472344"
Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l21KlpX1008145 for <dhcwg@ietf.org>; Thu, 1 Mar 2007 15:47:51 -0500
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l21KlkVl012355 for <dhcwg@ietf.org>; Thu, 1 Mar 2007 15:47:51 -0500 (EST)
Received: from xmb-rtp-20a.amer.cisco.com ([64.102.31.15]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 Mar 2007 15:47:44 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [dhcwg] FW: RFC3315 question
Date: Thu, 01 Mar 2007 15:47:43 -0500
Message-ID: <8E296595B6471A4689555D5D725EBB21036425D9@xmb-rtp-20a.amer.cisco.com>
In-Reply-To: <C20CA379.3BF70%rdroms@cisco.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [dhcwg] FW: RFC3315 question
Thread-Index: Acc/Psc6ympXzt39SmqKB5J9mTvDMQS1hDHhAosb8V0AADaU8A==
From: "Bernie Volz (volz)" <volz@cisco.com>
To: "Ralph Droms (rdroms)" <rdroms@cisco.com>, dhcwg <dhcwg@ietf.org>
X-OriginalArrivalTime: 01 Mar 2007 20:47:44.0083 (UTC) FILETIME=[DC87C230:01C75C42]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=8474; t=1172782071; x=1173646071; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=volz@cisco.com; z=From:=20=22Bernie=20Volz=20\(volz\)=22=20<volz@cisco.com> |Subject:=20RE=3A=20[dhcwg]=20FW=3A=20RFC3315=20question |Sender:=20 |To:=20=22Ralph=20Droms=20\(rdroms\)=22=20<rdroms@cisco.com>, =20=22dhcwg= 22=20<dhcwg@ietf.org>; bh=uahbi55zijPmyA864N8bdG2yItB8hdLDZXJe+tvZttA=; b=A2E1i3noDx7AKsIT3QzpjE4P0P0HBf2ycbhd0kh6EmTHvINYL/Eimdr2IJ6Z07DkZJTQIAVl /4rdFTcjj1uASnY0876IP7UA2KiGjpk1Qj6+PhBanTWEpYHRz5t2A1Zl;
Authentication-Results: rtp-dkim-1; header.From=volz@cisco.com; dkim=pass (s ig from cisco.com/rtpdkim1001 verified; );
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 140baa79ca42e6b0e2b4504291346186
Cc:
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
Errors-To: dhcwg-bounces@ietf.org
While perhaps this is beating this thing to death, the language "The hardware type MUST be a valid hardware type from the list ..." implies that I'm free to pick any value as long as it is on that list? Wouldn't we want to say something about that it MUST be the hardware type for the interface from which the link-layer address was taken? - Bernie -----Original Message----- From: Ralph Droms (rdroms) Sent: Thursday, March 01, 2007 3:36 PM To: Ralph Droms (rdroms); dhcwg Subject: Re: [dhcwg] FW: RFC3315 question Summarizing the discussion on these issues, in reverse order: The IANA/RFC826 issue can be addressed by an erratum: OLD: The hardware type MUST be a valid hardware type assigned by the IANA as described in RFC 826 [14]. NEW: The hardware type MUST be a valid hardware type from the list of ARP hardware types maintained by IANA at <insert URL here> I haven't read anything defining specific text for the first issue beyond the text Ted suggested in his original (off-list) e-mail exchange. Therefore, I suggest we use his suggested text in an erratum: OLD: 9.2. DUID Based on Link-layer Address Plus Time [DUID-LLT] This type of DUID consists of a two octet type field containing the value 1, a two octet hardware type code, four octets containing a time value, followed by link-layer address of any one network interface that is connected to the DHCP device at the time that the DUID is generated. The time value is the time that the DUID is generated represented in seconds since midnight (UTC), January 1, 2000, modulo 2^32. The hardware type MUST be a valid hardware type assigned by the IANA as described in RFC 826 [14]. Both the time and the hardware type are stored in network byte order. The link-layer address is stored in canonical form, as described in RFC 2464 [2]. NEW: 9.2. DUID Based on Link-layer Address Plus Time [DUID-LLT] This type of DUID consists of a two octet type field containing the value 1, a two octet hardware type code, four octets containing a time value, followed by link-layer address of any one network interface that is connected to the DHCP device at the time that the DUID is generated. The time value is the time that the DUID is generated represented in seconds since midnight (UTC), January 1, 2000, modulo 2^32. The hardware type MUST be a valid hardware type assigned by the IANA as described in RFC 826 [14]. Both the time and the hardware type are stored in network byte order. The details of how the link-layer address is formatted are defined in the appropriate "IPv6 over <link>" specification such as "IPv6 over Ethernet" [RFC2464], "IPv6 over FDDI" [RFCnnnn], etc. Specifically, the link-layer address should appear in the DUID-LLT option just as it does in the frame header for that particular link type. For example the link-layer address for an ethernet interface would be formatted in the same way as the Destination Ethernet Address field of the ethernet frame as described in the section of "IPv6 over Ethernet" [RFC2464] titled "Frame Format." - Ralph On 2/16/07 4:53 PM, "Ralph Droms" <rdroms@cisco.com> wrote: > Alain Durand asked me a couple of questions about the definition of the DUID > formats based on link-layer addresses in RFC 3315. The first question is > about this text, which appears in both section 9.2, DUID Based on Link-layer > Address Plus Time [DUID-LLT], and section 9.4, DUID Based on Link-layer > Address [DUID-LL]: > > The link-layer > address is stored in canonical form, as described in RFC 2464. > > Alain checked RFC 2464, and he can't find how a link layer address is > supposed to be stored in canonical form. The closest thing he found is: > > The Source/Target Link-layer > Address option has the following form when the link layer is > Ethernet. > > 0 1 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type | Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > +- Ethernet -+ > | | > +- Address -+ > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > And, RFC 2464 only describes Ethernet and is silent on other link-layer > addresses. > > There is also an issue with the text: > > The hardware type MUST be a > valid hardware type assigned by the IANA, as described in RFC 826. > > ...but, RFC 826 makes no reference to IANA. > > Ted Lemon and I exchanged e-mail about the DUID issue, and I've included > Ted's response below. > > Regarding the IANA/RFC 826 issue, I think it can be addressed by an errata: > > OLD: > > The hardware type MUST be a valid hardware type > assigned by the IANA as described in RFC 826 [14]. > > NEW: > > The hardware type MUST be a valid hardware type from the list of > ARP hardware types maintained by IANA at <insert URL here> > > - Ralph > > ===== > > To be honest, I have no idea where the RFC2464 reference came from. > I'd never read that RFC, and wasn't even aware of its existence. > The word 'canonical' is only used twice in the RFC, and nowhere in > the RFC is the meaning of 'canonical' described. The point Alain > raises is a really good one, and applies to RFC2464 as well, to some > extent - it should define 'canonical'. > > However, RFC2464 does give us some clue about this in section 2.5.1, > Interface Identifiers, on page 8, where it describes in detail how to > construct an interface identifier. This does tell us what the > author of RFC2464 thought the canonical form is. But Alain's still > right that the reference to RFC2464 is a mistake in isolation, > because it leaves out all other possible frame header formats. > Having said that, the problem remains - without specifying the > arrangement of bits, you are left guessing. People seem to have > muddled through with RFC2131/2132, and I think they probably will > with 3315 as well, but it could have been better specified. > > I think the correct fix for the RFC2464 problem is to add some text > like what's in RFC2373: > > The details of forming interface identifiers are defined in the > appropriate "IPv6 over <link>" specification such as "IPv6 over > Ethernet" [ETHER], "IPv6 over FDDI" [FDDI], etc. > > We'd change it to this: > > The details of how the link-layer address is formatted are > defined in the > appropriate "IPv6 over <link>" specification such as "IPv6 over > Ethernet" [RFC2464], "IPv6 over FDDI" [RFCnnnn], etc. > Specifically, the > link-layer address should appear in the DUID-LLT option just as > it does > in the frame header for that particular link type. For example the > link-layer address for an ethernet interface would be formatted > in the > same way as the Destination Ethernet Address field of the > ethernet frame > as described in the section of "IPv6 over Ethernet" [RFC2464] > titled "Frame > Format." > > This doesn't really solve the problem, because RFC2464 isn't specific > about it either, but it gets rid of the erroneous reference to > RFC2464 as the _only_ place to go, and it also gives the implementor > a valuable clue for how to format the DUID-LLT - look at a frame you > captured live on the wire. That way. That's lame, but it's better > than nothing. Really, RFC2464 should be more particular about > referencing the document (presumably IEEE) that defines the 802.11 > header format. You can see that the author had access to that > document by reading section 2.5.1, but unfortunately s/he never > references it. > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg
- [dhcwg] FW: RFC3315 question Ralph Droms
- Re: [dhcwg] FW: RFC3315 question Shane Kerr
- RE: [dhcwg] FW: RFC3315 question Bernie Volz (volz)
- RE: [dhcwg] FW: RFC3315 question Templin, Fred L
- RE: [dhcwg] FW: RFC3315 question Bernie Volz (volz)
- Re: [dhcwg] FW: RFC3315 question Ted Lemon
- RE: [dhcwg] FW: RFC3315 question Bernie Volz (volz)
- Re: [dhcwg] FW: RFC3315 question Ted Lemon
- Re: [dhcwg] FW: RFC3315 question Markus Stenberg
- Re: [dhcwg] FW: RFC3315 question David W. Hankins
- Re: [dhcwg] FW: RFC3315 question Ralph Droms
- RE: [dhcwg] FW: RFC3315 question Bernie Volz (volz)
- Re: [dhcwg] FW: RFC3315 question Ted Lemon