Subject: [dhcwg] Renumbering stateless DHCPv6 as dhc WG charter item

From: Ralph Droms <[email-masked]>
Date: Mon, 15 Mar 2004 11:48:42 -0500

Here is proposed text for a dhc WG charter item to address renumbering 
stateless DHCPv6:

The DHCPv6 specification in RFC3315 includes a mechanism through which
clients can obtain other configuration information without obtaining
an address or addresses.  This mechanisms is sometimes called
"stateless DHCPv6".  RFC3315 includes no provision for notifying
DHCPv6 clients using stateless DHCPv6 of changes in the configuration
information supplied to the client.  The dhc WG will assess the
requirements for informing DHCPv6 clients of changes in configuration
information, review alternative solutions and select a solution, and
develop, review and publish a specification for the chosen solution.

- Ralph

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

---

From: Ted Lemon <[email-masked]>
Date: Mon, 15 Mar 2004 12:05:00 -0600

> Here is proposed text for a dhc WG charter item to address renumbering 

Needless to say, I'm in favor of adding this to the charter.   The text 
looks fine.   :')

---

From: "Bernie Volz" <[email-masked]>
Date: Tue, 16 Mar 2004 08:30:00 -0500

Would it make sense to revise the text to also include "suggested"
client-detected events, such as receiving Router Advertisements with a
new prefix, that might trigger a client generated request?

Other than that, the proposed text is fine.

- Bernie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Ralph Droms
Sent: Monday, March 15, 2004 11:49 AM
To: [email-masked]
Subject: [dhcwg] Renumbering stateless DHCPv6 as dhc WG charter item

The DHCPv6 specification in RFC3315 includes a mechanism through which
clients can obtain other configuration information without obtaining an
address or addresses.  This mechanisms is sometimes called "stateless
DHCPv6".  RFC3315 includes no provision for notifying DHCPv6 clients
using stateless DHCPv6 of changes in the configuration information
supplied to the client.  The dhc WG will assess the requirements for
informing DHCPv6 clients of changes in configuration information, review
alternative solutions and select a solution, and develop, review and
publish a specification for the chosen solution.

- Ralph

---

From: Ralph Droms <[email-masked]>
Date: Tue, 16 Mar 2004 08:36:36 -0500

Bernie - sounds like a reasonable revision.  Please suggest some
specific text...

- Ralph

---

From: Tim Chown <[email-masked]>
Date: Tue, 16 Mar 2004 13:40:56 +0000

> Other than that, the proposed text is fine.

I agree there are other "events" and scenarios to maybe consider, especially
from the client perspective.  I think whoever said we'll get a better picture
from the DNA WG work has a good point, so we should track that closely.

Basically I think we should adopt the lifetime draft as a "general fit"
solution to refine (as there is currently a gap) and in parallel think about 
other cues and scenarios that can be described in the problem statement 
draft.    There may then be a need for other work to emerge, for specific
identified scenarios.

Getting both drafts adopted will help us focus on that task.

Tim

---

From: "Bernie Volz" <[email-masked]>
Date: Tue, 16 Mar 2004 08:47:20 -0500

BTW: Isn't the statement "RFC3315 includes no provision" incorrect?
There
is the Reconfigure message (provided the client supports it).

How about:

supplied to the client or any recommendations as to when a client should
obtain possibly updated information.  The dhc WG will assess the

- Bernie

-----Original Message-----
From: Ralph Droms [mailto:[email-masked]] 
Sent: Tuesday, March 16, 2004 8:37 AM
To: Bernie Volz
Cc: [email-masked]
Subject: RE: [dhcwg] Renumbering stateless DHCPv6 as dhc WG charter item

- Ralph

>informing DHCPv6 clients of changes in configuration information, 
>review alternative solutions and select a solution, and develop, review

>and publish a specification for the chosen solution.
>
>- Ralph
>
>

---

From: "Bernie Volz" <[email-masked]>
Date: Tue, 16 Mar 2004 08:57:23 -0500

I agree. Having the lifetime should be able to reasonably handle the
planned events.

Other client-side triggers, such as new prefixes in an RA or expired
prefixes, should
be able to handle some unplanned events.

An individual server failing and being replaced at a different address
will likely
always be a tricky situation and is best handled by using redundancy or
DNS names
(instead of addresses) whenever possible.

- Bernie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Tim Chown
Sent: Tuesday, March 16, 2004 8:41 AM
To: [email-masked]
Subject: Re: [dhcwg] Renumbering stateless DHCPv6 as dhc WG charter item

> Other than that, the proposed text is fine.

I agree there are other "events" and scenarios to maybe consider,
especially from the client perspective.  I think whoever said we'll get
a better picture from the DNA WG work has a good point, so we should
track that closely.

Basically I think we should adopt the lifetime draft as a "general fit"
solution to refine (as there is currently a gap) and in parallel think
about 
other cues and scenarios that can be described in the problem statement 
draft.    There may then be a need for other work to emerge, for
specific
identified scenarios.

Tim

---

From: Tim Chown <[email-masked]>
Date: Tue, 16 Mar 2004 14:00:08 +0000

> is the Reconfigure message (provided the client supports it).

Isn't that only the case though where the server knows the IP addresses
of the clients to unicast the reconfigure message to?  It won't know this 
in the stateless case because the server has no IP state for leases?
 
> develop, review and publish a specification for the chosen solution.

Sounds good.

Tim

---

From: "Bernie Volz" <[email-masked]>
Date: Tue, 16 Mar 2004 09:07:49 -0500

Yes, it all depends on the server. The DHCP server *COULD* keep a list
of the
addresses to which it sent Reply messages (in response to
Information-Request)
for those clients that support Reconfigure and unicast Reconfigures.

Just because the client is using stateless, does not mean that the
server needs
to be.

- Bernie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Tim Chown
Sent: Tuesday, March 16, 2004 9:00 AM
To: [email-masked]
Subject: Re: [dhcwg] Renumbering stateless DHCPv6 as dhc WG charter item

On Tue, Mar 16, 2004 at 08:47:20AM -0500, Bernie Volz wrote:
> There is the Reconfigure message (provided the client supports it).

Isn't that only the case though where the server knows the IP addresses
of the clients to unicast the reconfigure message to?  It won't know
this 
in the stateless case because the server has no IP state for leases?
 
> clients can obtain other configuration information without obtaining
an 

Sounds good.

Tim

---

From: Tim Chown <[email-masked]>
Date: Tue, 16 Mar 2004 14:14:39 +0000

> Just because the client is using stateless, does not mean that the

OK, if that's the case (and I had assumed it wasn't, sorry :) then I'll
update the text in the problem statement.    I had assumed a key point
of stateless DHCPv6 was that the server did not have to keep the state
information, so was easier/cheaper to implement.    

I note that from Ralph's comments all DHCPv6 implementations to date (albeit
not a lot of them!) are full 3315 implementations, not stateless subset ones.
This may or may not remain the case...

Tim

---

From: Cristian Cadar <[email-masked]>
Date: Tue, 16 Mar 2004 15:44:36 +0100

Hi Tim,

On Tuesday 16 March 2004 15:14, Tim Chown wrote:
> I note that from Ralph's comments all DHCPv6 implementations to date
> (albeit not a lot of them!) are full 3315 implementations, not stateless
> subset ones. This may or may not remain the case...
>

In my view (and implementation) stateful and stateless are completely 
separated I mean in stateless mode the server does not mantain any 
information on the IP leases since it is distributed by the RA daemon.
How should the server guess the IP addresses of the clients which was provided 
by the RA daemon? I mean it would be a big overhead for the administrator to 
do so and useless .
Should the server in stateless mode send Reconfigure messages to clients with 
unicast to force them to update their non IP address information? I think a 
much simpler solution would be to define for example an All-Clients IPv6 
multicast address instead, the server to notify easily the clients on planned 
and unplanned events too.

Cristian

---

From: Ralph Droms <[email-masked]>
Date: Tue, 16 Mar 2004 09:47:56 -0500

Tim, Bernie - just because the server can keep a list of clients
that has contacted it doesn't mean it has to keep that list.  So,
the Reconfigure message would require a server with enough
complexity to keep a list of clients (and security information
for those clients).  Most of the point of "stateless DHCPv6" is
to reduce server complexity, not client complexity (note that
if we had some sort of lifetime option, we require that the client
keep that lifetime as "state").

Even a server that fully implements RFC 3315 might not bother
to keep state for clients that use an Information-request message
to obtain configuration information.  If I remember correctly,
that is the case with the IOS DHCPv6 server.

- Ralph

---

From: Tim Chown <[email-masked]>
Date: Tue, 16 Mar 2004 15:00:13 +0000

> by the RA daemon? I mean it would be a big overhead for the administrator to 

I think it would see the requests for "other configured data" and could 
cache the source IP addresses seen for such requests.    But I agree with 
Ralph's summise.

Tim