Subject: RE: [dhcwg] Question about 3315id-for-v4

From: "Situ, Kevin" <[email-masked]>
Date: Tue, 20 Apr 2004 13:09:55 -0400

We are running into an issue with multiple vendors using option 43.  We
use Lucent DHCP that do not support vender class ID in option 43, which
only can store the value without Vendor class ID. We have a work around
by having multiples scope in the subnet,  But we try to  use one
template and one scope.  Does any have any suggestion

Thanks

Kevin  

-----Original Message-----
From: Ralph Droms [mailto:[email-masked]] 
Sent: Tuesday, April 20, 2004 11:59 AM
To: [email-masked]
Subject: [dhcwg] Question about 3315id-for-v4

It seems one of the motivations for draft-ietf-dhc-3315id-for-v4 is to
specify a way in which a dual-stack host can use the same identifier in
DHCPv4 and in DHCPv6.  A uniform identifier for both versions of DHCP
would be useful in the DHCID RR when detecting and reconciling DNS name
clashes.

So, is there consensus that draft-ietf-dhc-3315id-for-v4 should be
designed to support the consistent identification of a host in a DHCID
RR regardless of whether the host uses DHCPv4 or DHCPv6?

If the answer is yes, how can that consistent identification be
achieved?  I think the identifier in the latest revision of
draft-ietf-dhc-3315id-for-v4 could be used, if the DHCP server and the
client agree to use only the DUID in the DHCID RR.  However, I think it
would be better to avoid requiring the DHCPv4 server to parse the
3315id-for-v4 client identifier for use in the DHCID RR.  Is there some
other way in which the use of the DHCID RR can be defined to avoid
requiring the parsing of any client identification (either DHCpv4 or
DHCPv6)?

- Ralph

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

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

---

From: "Richard Barr Hibbs" <[email-masked]>
Date: Wed, 21 Apr 2004 15:02:12 -0700

-----Original Message-----
From: Richard Barr Hibbs [mailto:[email-masked]]
Sent: Wednesday, 21 April 2004 09:13
To: Ted Lemon
Subject: RE: [dhcwg] Question about 3315id-for-v4

comments in-line

--Barr

> From: Ted Lemon
> Sent: Tuesday, 20 April 2004 17:35
>
> On Apr 20, 2004, at 8:58 AM, Ralph Droms wrote:
> > Is there some other way in which the use of the
> > DHCID RR can be defined to avoid requiring the
> > parsing of any client identification (either
> > DHCpv4 or DHCPv6)?
>
> No.   During the last call both Bernie and Barr
> expressed a wish that we could do this, and we
> discussed and rejected a method for doing this.
> The problem is that the only way to make it so
> the server doesn't have to parse the identifier
> is to add an additional identifier option, and
> if we do that, clients supporting the new
> identifier style will not interoperate with
> servers that do not in some cases.
>
...I'll take another look at the DHCID RR, the DNS update
I-D, and the proposed change to the client identifier today
to see if we may have been too quick to reject proposed
solutions.

> The only objection I can think of to the server
> parsing the client identifier option is that we
> have historically said the client identifier is
> opaque.  However, there is a good reason to
> break with this tradition, and I don't see how
> doing so would create an interoperability
> problem.  So if we try to keep this tradition,
> we break interoperability with old servers.  If
> we break this tradition, we do not.   So I
> think we have to use the IAID+DUID form of the
> client identifier option, and not add a separate
> IAID option.
>
...I don't believe that we have ever identified a good
reason why the client identifier MUST be an opaque value,
save that it does simplify one aspect of interoperability:
if the value is opaque, it can be changed by the client for
any reason, especially convenience, without worrying how a
server will react to the change.

So, if I may restate the issue, "Do we want a client
identifier that contains no data that can be processed by
the server to glean any information about the client, such
as additional qualification similar to vendor or user class
information, or not?"

There are really two competing philosophies here:  (1) keep
the size of the packet (and number of options sent/received)
as small as possible by avoiding duplicated or overlapping
data; and (2) maintain absolute clarity as to the purpose
and interpretation of every option by having one and only
one use for each.  Both are valid perspectives, but I lean a
bit towards the second because of the Law of Unintended
Consequences, which in this case would suggest that changing
the client identifier will have some as yet unforeseen
complication.