Subject: [dhcwg] Renumbering Requirements for Stateless DHCPv6

From: Tim Chown <[email-masked]>
Date: Tue, 10 Feb 2004 13:45:49 +0000

Hi,

There have not been any list comments on a draft that I wrote with Stig and
A.K. after Minneapolis on the issue of how nodes using DHCPv6 only for non
address configuration options should leanr ofconfiguration changes.

http://www.ietf.org/internet-drafts/draft-chown-dhc-stateless-dhcpv6-renumbering-00.txt

There has been a comment regarding the Reconfigure message (and lack of
use of it?) on the list, though not in the context of this draft.

There have also been comments that there are wider issues here, e.g. in terms
of node use of DHCP(v6) servers when moving between networks.

I would be happy to update the above draft to a -01 version if there are
(constructive :) comments.

Note that Stig will present this draft and a solution draft in Seoul.

Tim

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

---

From: "Bernie Volz" <[email-masked]>
Date: Tue, 10 Feb 2004 13:59:45 -0500

Hum ... I thought we did have some discussion but perhaps I dreamed of them?

Anyway, my thoughts are:

- I agree that adding a lifetime to Information-Request information would be
useful:

   o  Conveying a valid lifetime timer to clients for stateless
      DHCPv6-assigned settings.  This could primarily enable planned
      events, but with a small time-out it could to some extent handle
      unplanned events at the expense of the additional request traffic.

- I also feel that even without a lifetime, a client SHOULD re-request the
parameters when certain events occur. We all assume that a client would do
this whenever it detects a possible network reconnect (such as when the
networking cable is plugged back in), but it SHOULD also re-request the
parameters whenever addresses obtained via auto-configuration expire
(preferred lifetime ends) or when new prefixes are added. Of course, the
client should have some throttle control so that it doesn't do this too
rapidly (perhaps once every several minutes max.).

- When DHCPv6 is used to assign addresses, the lifetime of addresses can be
adjusted (downward) before a renumbering event to assure clients receive
timely updated.

- Assuring service redundancy. This is outside the scope of DHCP but it is
normally prudent practice to have multiple DNS servers. This means that a
single failure (or need to change a single address) would not cause a
significant service interruption.

- As reconfigure CAN be used with Information-Request clients (provided
those clients have contacted the DHCPv6 server and indicated support for
Reconfigure), it could be recommended for clients to support this even when
just using Information-Request. But, I suspect this is likely overkill.

- Bernie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Tim
Chown
Sent: Tuesday, February 10, 2004 8:46 AM
To: [email-masked]
Subject: [dhcwg] Renumbering Requirements for Stateless DHCPv6

Hi,

http://www.ietf.org/internet-drafts/draft-chown-dhc-stateless-dhcpv6-renumbe
ring-00.txt

There have also been comments that there are wider issues here, e.g. in
terms
of node use of DHCP(v6) servers when moving between networks.

Tim

---

From: Ralph Droms <[email-masked]>
Date: Tue, 10 Feb 2004 16:56:59 -0500

Tim - I think it would be useful to add a section ("Considerations in
choosing a solution") that lists some of the issues you hint at in section
5, "Solution space".  Here are some candidate considerations:

* must support planned renumbering; desirable to support unplanned renumbering
* security; e.g., avoid DOS attacks mounted through Reconfigure messages
   sent from attacker
* must update options even if network is not renumbered
* desirable to maintain "stateless" property; i.e., no per-client state kept
   in the server

I agree with Bernie's observation that it would be good to add text (already
in RFC 3315 for stateful DHCPv6) specifying conditions under which client
should send an Information-request, such as reconnection to a link.

Another possible solution would be to redefine the semantics of the 'O' flag
in RAs, so toggling the 'O' flag would trigger clients to send an
Information-request message.

Nits:

The current citation for stateless DHCPv6 is "Stateless DHCP Service for
IPv6", draft-ietf-dhc-dhcpv6-stateless-04.txt, January 2004.  (this draft is
currently in the RFC Editor pub queue)

The current citation for the renumbering procedure draft is "Procedures for
Renumbering an IPv6 Network without a Flag Day",
draft-ietf-v6ops-renumbering-procedure-00.txt, February 2004.