Subject: Re: [dhcwg] RE: draft-ietf-dhc-3315id-for-v4-01.txt

From: Ted Lemon <[email-masked]>
Date: Thu, 29 Jan 2004 15:52:22 -0600

On Jan 29, 2004, at 3:02 PM, Ralph Droms wrote:
> Looks to me like we're waiting for a new
> revision to continue the discussion.

That's right.   Also, I published an individual submission that I'd 
like the WG to consider before Seoul.   This is about a related issue.  
  I haven't brought it up yet because I wanted to bring it up in 
connection with a discussion about the -02 version of the 3315id draft, 
which I haven't yet had time to prepare.   :'/

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

---

From: Ralph Droms <[email-masked]>
Date: Thu, 29 Jan 2004 16:02:08 -0500

Sorry - I'm behind on the discussion on the WG mailing list, where this
draft has already been discussed.  Looks to me like we're waiting for a new
revision to continue the discussion.

- Ralph

---

From: "Bernie Volz" <[email-masked]>
Date: Fri, 30 Jan 2004 10:18:05 -0500

Ted:

I assume you refer to draft-lemon-dhcpv4-to-v6-id-trans-00.txt. I reviewed
it quickly and is this pain really worth it just to change your identifier?
I doubt it. Many identifiers are derived from NIC addresses and few think
twice about changing that hardware ... you just go with a new address.

Also, the switch to using the DUID would likely occur after a software
upgrade which typically also requires a reboot. So, there would usually be
no sessions active and thus no major issue if the address changes.

And, just like with other upgrades, if a site started rolling out large
numbers of new clients, they could adjust the lease times on the servers to
use shorter leases for the rollout to allow faster reuse of addresses.

For the cases where a system needs to keep its current address, likely there
is a reservation for that lease. So, if the client's software upgrade
procedure reports the current client identifier and the new DUID it will use
(before using it), the server's configuration can be updated. Ideally,
servers might want to allow multiple client identifiers for a reservation to
support changes in client identifiers?

The above also avoids security issues, especially with client options to
change ids, etc. Though, it does increase the chance of error as someone may
mistype the client identifiers or fail to update the server before rebooting
the client.

- Bernie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ted
Lemon
Sent: Thursday, January 29, 2004 4:52 PM
To: Ralph Droms
Cc: [email-masked]
Subject: Re: [dhcwg] RE: draft-ietf-dhc-3315id-for-v4-01.txt

---

From: Ted Lemon <[email-masked]>
Date: Fri, 30 Jan 2004 10:13:16 -0600

> twice about changing that hardware ... you just go with a new address.

Right, that was my thinking too.   I wrote it up because there was some 
demand for a solution, but I think the demand was uninformed, and this 
draft should help people to understand just what a pain in the neck it 
would be to define a formal transition procedure.