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

Ralph Droms <rdroms@cisco.com> Wed, 21 April 2004 14:19 UTC

Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24154 for <dhcwg-archive@odin.ietf.org>; Wed, 21 Apr 2004 10:19:00 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGIUj-0000oq-Qj for dhcwg-archive@odin.ietf.org; Wed, 21 Apr 2004 10:14:33 -0400
Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3LEEX2M003144 for dhcwg-archive@odin.ietf.org; Wed, 21 Apr 2004 10:14:33 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGIOR-00056o-Md for dhcwg-web-archive@optimus.ietf.org; Wed, 21 Apr 2004 10:08:03 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22650 for <dhcwg-web-archive@ietf.org>; Wed, 21 Apr 2004 10:08:00 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGIOP-0004Wl-OI for dhcwg-web-archive@ietf.org; Wed, 21 Apr 2004 10:08:01 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGINU-0004N2-00 for dhcwg-web-archive@ietf.org; Wed, 21 Apr 2004 10:07:04 -0400
Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGIMj-0004DX-00 for dhcwg-web-archive@ietf.org; Wed, 21 Apr 2004 10:06:17 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGI8u-0004Mv-7V; Wed, 21 Apr 2004 09:52:00 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGI2A-0000rZ-5j for dhcwg@optimus.ietf.org; Wed, 21 Apr 2004 09:45:02 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20718 for <dhcwg@ietf.org>; Wed, 21 Apr 2004 09:44:59 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGI28-0000Qz-7N for dhcwg@ietf.org; Wed, 21 Apr 2004 09:45:00 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGI1E-0000Hv-00 for dhcwg@ietf.org; Wed, 21 Apr 2004 09:44:05 -0400
Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BGI0b-00007J-00 for dhcwg@ietf.org; Wed, 21 Apr 2004 09:43:25 -0400
Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 21 Apr 2004 05:53:26 +0000
Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i3LDgq8k010586 for <dhcwg@ietf.org>; Wed, 21 Apr 2004 06:42:52 -0700 (PDT)
Received: from rdroms-w2k01.cisco.com (che-vpn-cluster-1-60.cisco.com [10.86.240.60]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AHT30598; Wed, 21 Apr 2004 09:42:51 -0400 (EDT)
Message-Id: <4.3.2.7.2.20040421091104.02710008@flask.cisco.com>
X-Sender: rdroms@flask.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Wed, 21 Apr 2004 09:42:49 -0400
To: dhcwg@ietf.org
From: Ralph Droms <rdroms@cisco.com>
Subject: Re: [dhcwg] Question about 3315id-for-v4
In-Reply-To: <C9E790A8-932B-11D8-AE44-000A95D9C74C@fugue.com>
References: <4.3.2.7.2.20040420115100.01f91588@flask.cisco.com> <4.3.2.7.2.20040420115100.01f91588@flask.cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Sender: dhcwg-admin@ietf.org
Errors-To: dhcwg-admin@ietf.org
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Id: <dhcwg.ietf.org>
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>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org
X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60

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:
>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.
>
>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.


_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg