Subject: [dhcwg] FW: RFC3315 question

From: Ralph Droms <[email-masked]>
Date: Fri, 16 Feb 2007 16:53:08 -0500

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: Shane Kerr <[email-masked]>
Date: Sat, 17 Feb 2007 16:14:42 +0100

>    ARP hardware types maintained by IANA at <insert URL here>

That's this, right:

http://www.iana.org/assignments/arp-parameters

- --
Shane

---

From: "Bernie Volz \(volz\)" <[email-masked]>
Date: Sat, 17 Feb 2007 14:18:50 -0500

Ah, good that this is finally being cleaned up (I recall there was some
past discussion on this). Reference to RFC 826 was very poor and really
should have referenced the IANA pages (the Number Hardware Type (hrd)
section of http://www.iana.org/assignments/arp-parameters).

Perhaps a reference to http://www.ietf.org/rfc/rfc2469.txt might also
help to address the canonical address issue? At least the describes
canonical addresses.

Link layer also confused one major vendor into thinking they should use
the EUI-64 identifier, so perhaps an example wouldn't hurt as well (we
have an example for DUID-EN, so why not for the others?).

- Bernie 

-----Original Message-----
From: Ralph Droms (rdroms) 
Sent: Friday, February 16, 2007 4:53 PM
To: dhcwg
Subject: [dhcwg] FW: RFC3315 question

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

                    0                   1

Regarding the IANA/RFC 826 issue, I think it can be addressed by an
errata:

OLD:

NEW:

- Ralph

=====

We'd change it to this:

---

From: "Templin, Fred L" <[email-masked]>
Date: Sat, 17 Feb 2007 11:38:12 -0800

Just to get this idea out, how does one go about getting a new
DUID type defined? In particular, it might be useful to define
a new DUID type that includes a client's public key such as
required by RFC3972. The actual format of the DUID type is for
further study, e.g., in addition to the public key it might be
desireable to include a link-layer address, a timestamp, etc.

Thanks - Fred
[email-masked] 

> From: Bernie Volz (volz) [mailto:[email-masked]] 
> Sent: Saturday, February 17, 2007 11:19 AM
> To: Ralph Droms (rdroms); dhcwg
> Subject: RE: [dhcwg] FW: RFC3315 question
>

---

From: "Bernie Volz \(volz\)" <[email-masked]>
Date: Sat, 17 Feb 2007 17:25:51 -0500

RFC 3315 indicates how ...

24. IANA Considerations

   ...

   New multicast addresses, message types, status codes, and DUID types
   are assigned via Standards Action [11]. 

   ...

   [11] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
        Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.

   ...

- Bernie

-----Original Message-----
From: Templin, Fred L [mailto:[email-masked]] 
Sent: Saturday, February 17, 2007 2:38 PM
To: Bernie Volz (volz); Ralph Droms (rdroms); [email-masked]
Subject: RE: [dhcwg] FW: RFC3315 question

Thanks - Fred

---

From: Ted Lemon <[email-masked]>
Date: Sat, 17 Feb 2007 15:34:09 -0700

> desireable to include a link-layer address, a timestamp, etc.

How big is this key going to be?   I don't think a 1k identifier is a  
good idea.

---

From: "Bernie Volz \(volz\)" <[email-masked]>
Date: Sat, 17 Feb 2007 17:46:14 -0500

I didn't write that! Fred wrote that!!

- Bernie

---

From: Ted Lemon <[email-masked]>
Date: Sat, 17 Feb 2007 16:01:02 -0700

> I didn't write that! Fred wrote that!!

I know, sorry.   I was just being lazy and not fixing it.

---

From: Markus Stenberg <[email-masked]>
Date: Sun, 18 Feb 2007 08:11:38 +0900

On 18.2.2007, at 7.34, Ted Lemon wrote:
> How big is this key going to be?   I don't think a 1k identifier is  
> a good idea.

Well, 1024bit public key would be 128 bytes for example, which is  
still well within pain threshold of the IPv6 minimum UDP packet  
size.. 2048 bit one would be 'safe' and 256 bytes, and ECC keys would  
be even shorter (but patent encumbered). (think 200-ish bits)

-Markus

---

From: "David W. Hankins" <[email-masked]>
Date: Mon, 19 Feb 2007 15:08:51 -0800

On Sat, Feb 17, 2007 at 11:38:12AM -0800, Templin, Fred L wrote:
> In particular, it might be useful to define

I think it's a fantastic idea.

If servers and clients could identify themselves with a public
key, then we could exchange greater varieties of configuration
information (which may require encryption) over an encapsulated
option.

The trust model for such exchanges would need some careful
thought, but on first inspection I see no reason why the SSH
model can't be adopted here (ask the operator, then cache the
key with link layer hints).

I've long wanted to experiment with public keys in DHCPv4
authentication...due to the size limitations in DHCPv4 payloads,
that's sent me down some ratholes I have vague notions for, but
nothing (yet) I wish to expose to the scrutiny of public review.

Since DHCPv4 now defines RFC3315 DUID's as client-identifier
contents (with the IAID prepended), I think there's a great
deal of good that could come from defining a method to transport
unique indexes to public keys, rather than the keys themselves,
in the DUID so that we could leverage the same mechanism for
both protocols (by writing a draft that lifts the DHCPv4 server
restriction that client identifiers be opaque).

I think there are some non-trivial challenges here, but any
effort down this path is worth our learning something from it.

-- 
ISC Training!  http://www.isc.org/training/  [email-masked]
Washington DC area, April 16-20 2007.  DNS & BIND, DDNS & DHCP.
-- 
David W. Hankins	"If you don't do it right the first time,
Software Engineer		you'll just have to do it again."
Internet Systems Consortium, Inc.	-- Jack T. Hankins
_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg