RE: [dhcwg] Re: Renumbering DNS with stateless DHCPv6 - bug?

["Bernie Volz" <[e-mail]>]

Tim/Ralph:

Personally, I'd prefer we take two approaches to address these problems
(text taken from Tim's document, section 5):

   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.

   o  Using some form of Router Advertisement as a hint to request new
      stateless DHCPv6-assigned settings.  Using only an observed new
      Router Advertisement prefix as a hint to re-request settings would
      not handle changes that are purely to NTP, DNS or other options.

The first handles planned changes. The second handles renumbering. For the
second case, the client SHOULD send an Information-Request when any prefix
for an address conveyed in the last Reply transitions from a) preferred to
valid (i.e., preferred lifetime expires) or b) is no longer valid (i.e.,
valid lifetime expires). [I'm not certain how easy this is to implement in
most operating systems, but periodic polls by the DHCP Client can probably
discover these changes within reasonable time periods. Note that care must
be taken for the client not to consider prefixes it knows nothing about.]

There is no mechanism to address unplanned changes (such as changing a DNS
server's address as discussed in 3.2). But, that's where redundancy comes in
- by having multiple servers a client can contact, this problem can be
minimized (until the "valid lifetime timer" expires). This IS covered by a
client (and server) supporting Reconfigure in the Information-Request case -
RFC 3315 does not prohibit this in an Information-Request (and Appendix A
shows it is allowed). So, in essence, all THREE of Tim's Section 5 possible
solutions are available. It would be optional, because as Thomas indicated
there are security concerns for forcing a client to listen for unsolicited
traffic (and a server may also choose not to support it).

So what actions are needed?

1. Someone needs to publish a "valid lifetime" draft. Tim, are you planning
on doing this? Ralph?

2. Words should be added to draft-ietf-dhc-dhcpv6-stateless-01.txt to
recommend (SHOULD?) that clients use certain events to trigger resending
Information-Requests (see above and also the triggers for sending Confirm
messages in RFC 3315?).

3. Perhaps the stateless draft should also add words to the effect that
supporting Reconfigure has advantages. Personally, this is where my view of
what draft-ietf-dhc-dhcpv6-stateless-*.txt should discuss and what it does
differ. I don't feel it should say that DHCP servers and clients are
stateless, just what is required when DHCP is NOT used for address
allocation (because stateless address configuration is being used in the
network). I believe this ONLY impacts text in the Abstract and section 1,
Introduction, of draft-ietf-dhc-dhcpv6-stateless-01.txt.

- Bernie

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of Tim
Chown
Sent: Tuesday, November 18, 2003 5:40 PM
To: [e-mail]; [e-mail]
Subject: [dhcwg] Re: Renumbering DNS with stateless DHCPv6 - bug?

On Tue, Nov 18, 2003 at 12:55:12PM -0500, Thomas Narten wrote:
> 
> note that there are issues with unicast reconfigure. During the IESG
> review of the DHCv6 spec, concerns were raised about the
> appropriateness of _requiring_ that all nodes have an open port on
> which DHC messages could be sent. This is viewed as a security
> issue. E.g., for security reasons, some sites require that clients
> have no open ports on which they are listening for arbitrary packets
> from anyone. Consequently, the DHCPv6 spec was revised to make the use
> of this feature more of a negotiation between the client and
> server. See the RFC for details.

There may be other methods to give the hint for a (RFC2462) client to send 
a new (options) request to the (stateless) DHCP server.   This might involve
something in an RA, some new form of Reconfigure message (although I can see
this isn't favoured, it is specified for stateful servers to use), or some
other method.

> Personally, I think something along the lines of Bernie's suggestion
> seems the simplest. E.g., just define a lifetime that applies to all
> options that don't themselves have a lifetime.  Client can then
> recheck at appropriate intervals.

A timer is an improvement; at least then the timer could be tuned down a
bit like DNS TTL for a planned renumbering event, or for simpler events
like adding a new NTP server or changing the DNS search path.

Attached is a draft that I've just submitted describing the problem
statement.  Vijay and Stig are both working on proposals for solutions.
It would be great to get your input on those based on the IESG discussion
experience (for example on the security requirements).

The problem/gap is a bit broader then just site renumbering, so the draft
name is not ideal.

Tim



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