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

From: Ralph Droms <[email-masked]>
Date: Tue, 20 Apr 2004 11:58:56 -0400

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

---

From: Ted Lemon <[email-masked]>
Date: Tue, 20 Apr 2004 17:35:28 -0700

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

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.

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.

---

From: Ralph Droms <[email-masked]>
Date: Wed, 21 Apr 2004 09:42:49 -0400

Ted - I looked back through the last call e-mail and found the specifics:

www1.ietf.org/mail-archive/working-groups/dhcwg/current/msg03389.html
www1.ietf.org/mail-archive/working-groups/dhcwg/current/msg03283.html
www1.ietf.org/mail-archive/working-groups/dhcwg/current/msg03284.html

I missed the subtleties of the discussion; others might have, too, as the
discussion was pretty brief.

Now that we see the tie-in between 3315id-for-v4 and the DHCID RR, I think
we need to get a more definitive statement about how a server users
3315id-for-v4 identifiers with the DHCID RR.  We also need to get a more
detailed evaluation of the backward-compatibility issues, if 3315id-for-v4
will require changes in server behavior (for parsing the IAID+DUID).  Are
other server vendors comfortable with the effect of 3315id-for-v4 on
currently deployed servers?

- Ralph

At 05:35 PM 4/20/2004 -0700, Ted Lemon wrote:
>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.
>
>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.