Subject: [dhcwg] Question Regarding RFC 4361

From: "Leino, Tammy" <[email-masked]>
Date: Tue, 9 Oct 2007 12:58:31 -0600

Hello All,

I have a question about RFC 4361.

Regarding the three types of DUIDs defined by RFC 3315; DUID-LLT, DUID-EN and DUID-LL, RFC 4361 states the following:

   . . .DHCPv4 clients MUST NOT use client identifiers based solely on layer two
   addresses that are hard-wired to the layer two device (e.g., the ethernet MAC 
   address) as suggested in RFC 2131, except as allowed in section 9.2 of RFC 3315.  

Does this mean that the DUID-LL DUID format defined in RFC 3315 is deprecated?  DUID-LLT uses the link-layer address, but so does DUID-LL.  DUID-LL is defined in section 9.4, but RFC 4361 does not specifically mention this format as allowable as it does with DUID-LLT.

Best Regards,
Tammy Leino

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

---

From: "David W. Hankins" <[email-masked]>
Date: Tue, 9 Oct 2007 12:22:31 -0700

On Tue, Oct 09, 2007 at 12:58:31PM -0600, Leino, Tammy wrote:
> Does this mean that the DUID-LL DUID format defined in RFC 3315 is deprecated?

I think DUID-LL is suboptimal for DHCPv4 use specifically.

Remember that DHCPv4 carries a 'chaddr' BOOTP header field, which in
the absence of a client identifier is used as identification.

So it is better to simply omit the client identifier option in the
case where the hardware address is the only identifier.

-- 
Ash bugud-gul durbatuluk agh burzum-ishi krimpatul.
Why settle for the lesser evil?	 https://secure.isc.org/store/t-shirt/
-- 
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

---

From: "Leino, Tammy" <[email-masked]>
Date: Tue, 9 Oct 2007 13:37:40 -0600

Thank you for your quick response David.

I don't completely agree with this though since the link-layer specified
in the DUID-LL-type option might not necessarily be the link-layer
address associated with the interface being configured.  If for example
you have two interfaces, you could be using the link-layer address of
the "other" interface as the DUID on the node.

RFC 3315, section 9.4:

   This type of DUID consists of two octets containing the DUID type 3,
   a two octet network hardware type code, followed by the link-layer
   address of any one network interface that is permanently connected to
   the client or server device.

RFC 3315 does not specify to use the link-layer address of the outgoing
interface, but the address of any one network interface.  So then, the
chaddr and the link-layer address in the client id option would not
match.  Furthermore, by not including a client id option, the problems
outlined in RFC 4361 posed by using the link-layer address of the
interfacce as the id would persist.

Best Regards,
Tammy Leino

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Tue, 9 Oct 2007 15:49:20 -0400

There may be other reasons to use the DUID-LL, such as if the client
really wanted multiple addresses as the RFC 4361 client-identifier
option allows this.

Or, there may be cases where there are multiple Virtual Circuits running
over the single interface.

If your client supports RFC 4361 and if the client is "allowed" to use
the DUID-LL (per RFC 3315, section 9.2), then it should use it if there
is a need (such as the above mentioned reasons).

This is far better than manufacturing a chaddr if the client has a
reason to need multiple addresses or is running multiple virtual
circuits over the interface.

Note however RFC 4361 may not be implemented in the server the client is
communicating with and that can have some negative side effects (as
indicated in RFC 4361).

- Bernie

-----Original Message-----
From: Leino, Tammy [mailto:[email-masked]] 
Sent: Tuesday, October 09, 2007 3:38 PM
To: David W. Hankins; DHC WG
Subject: RE: [dhcwg] Question Regarding RFC 4361

RFC 3315, section 9.4:

Best Regards,
Tammy Leino

---

From: Ted Lemon <[email-masked]>
Date: Tue, 9 Oct 2007 13:04:06 -0700

> I think DUID-LL is suboptimal for DHCPv4 use specifically.

No, it's fine.   DUID-LL however is *only* applicable to devices that  
have a hard-wired link-layer address, and only if you use *that*  
address.   If you have a removable ethernet card, you mustn't use  
DUID-LL.   If you aren't sure, you mustn't use DUID-LL.

> case where the hardware address is the only identifier.

That's not precisely true.   The two can be taken to mean different  
things.   Indeed, ISC DHCP 3.0 at least does treat them  
differently.   If you want to ensure consistent treatment across  
multiple DHCP servers, you are better off sending the client  
identifier.   It's true that you can probably get away with not  
sending it, but why take chances?   Good manners don't cost nuffin,  
do they?   :')

---

From: "David W. Hankins" <[email-masked]>
Date: Tue, 9 Oct 2007 13:54:36 -0700

> address associated with the interface being configured.  If for example

Hm, yeah.

From my point of view, the most important thing to eliminate is the
practice where a single piece of hardware running different software
at different stages of booting (or for different operators, or at the
operator's indication at different times...) sometimes identifies
itself using chaddr, sometimes using a client-identifier with
identical contents to chaddr (preceded by htype), and sometimes using
DUID-LL (with the same chaddr contents).

So I still don't really think DUID-LL is "generally" appropriate, and
it confuses things more than it solves any real problems (for DHCPv4).

But so long as you're in a situation where its use doesn't promote
confusion, it's probably fine.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 9 Oct 2007 14:24:06 -0700

> confusion, it's probably fine.

The reason we wrote what we wrote in RFC3315 is because we've had  
quite a bit of experience with what can go wrong in DHCP  
deployments.   So there are actually really good reasons why the  
standard says what it says.   I'm very uncomfortable with leaving the  
above statement lie, because what you seem to be saying is that we  
should just use our judgement, rather than following the standard.

If you disagree with the standard, that's a worthy topic of debate,  
but what you are saying seems to encourage people not to comply with  
this aspect of the standard if it's inconvenient for them.   I  
apologize for being a fusspot, but I simply can't leave an  
implication like that unclarified.

---

From: "Leino, Tammy" <[email-masked]>
Date: Thu, 11 Oct 2007 09:14:50 -0600

Thank you all for your insight.

If an interface supports IPv4 and IPv6 and is performing DHCP over both
IPv4 and IPv6, should the IAID be the same for both?  I understand that
the DUID is the same, but I am not sure about the IAID.

The RFC specifies that each interface should have a unique IAID, but it
does not mention whether this same IAID should be used for both IPv4 and
IPv6 DHCP transactions.  I think the IAID should be the same, but since
it is not clear, I was hoping to get an expert opinion.

Best Regards,
Tammy Leino

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Thu, 11 Oct 2007 14:01:16 -0400

Your choice. IMHO, it makes sense to use the same IAID as the "first"
one used for an interface.

- Bernie 

-----Original Message-----
From: Leino, Tammy [mailto:[email-masked]] 
Sent: Thursday, October 11, 2007 11:15 AM
To: Ted Lemon; David W. Hankins
Cc: DHC WG
Subject: RE: [dhcwg] Question Regarding RFC 4361

Best Regards,
Tammy Leino

---

From: Ted Lemon <[email-masked]>
Date: Thu, 11 Oct 2007 11:25:44 -0700

> it is not clear, I was hoping to get an expert opinion.

It should not make a difference.   The reason that we use the same  
DUID between v4 and v6 is so that transitional infrastructures, where  
DHCPv4 and DHCPv6 are both deployed, can tell that the the DHCPv4 and  
DHCPv6 clients intend to be treated as the same device.   Keeping  
IAIDs consistent didn't occur to any of us when we were working on  
RFC4361, so I think it would be a waste of effort to try to keep them  
consistent - there will be implementations where they aren't  
consistent, so having a client that keeps them consistent might  
actually encourage non-confirming DHCP server implementations.

---

From: "Leino, Tammy" <[email-masked]>
Date: Thu, 11 Oct 2007 12:39:05 -0600

Thank you Ted and Bernie.  

Since this RFC is in proposed standard state, is there any chance we
could get this IAID point addressed in the standard version of this RFC?
Also clarification on whether DUID-LL type is allowed would also be
nice.

Best Regards,
Tammy Leino