Subject: Renumbering DNS with stateless DHCPv6 - bug?

From: Tim Chown <[email-masked]>
Date: Thu, 13 Nov 2003 19:11:45 +0000

Hi,

I was mulling over the renumbering scenario for hosts that use
stateless autoconf for address allocation and DHCPv6 Light (stateless
DHCPv6) for DNS options.

Let's assume either the site renumbers, or the DNS servers are
renumbered.   The latter case means that you can't just use a new
prefix on an RA as a hint to re-request DNS options via DHCPv6 Light.

With an RA method for DNS option configuration, you put the new DNS
option information in the RA.

With DHCPv6 Light for DNS option configuration, how is the client told
that DNS options have changed?  The reconfigure message seems to be
unicast to the clients, but if the DHCPv6 server is stateless, it won't
have a list of clients (with leased IPs) to send that Reconfigure
message to?

Is this a general problem for any options set by a host that only uses 
stateless DHCPv6 for options, and use RFC2462 for addresses.

One option for passing the new DNS options from the DHCPv6 Light server
to the client is a multicast Reconfigure message.    That would work 
if the DHCPv6 Light server is on link, but if relays are used and there
is no multicast routing on site, this seems to be a gap (and a case for the 
RA method - though of course with RA method you still need to reconfigure 
the router for the new RA...)

Thoughts?

Tim
#----------------------------------------------------------------------
# To unsubscribe, send a message to <[email-masked]>.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 13 Nov 2003 14:05:11 -0600

On 13-nov-03, at 13:11, Tim Chown wrote:

> that DNS options have changed?

Operationally, you'd probably have to support these addresses forever. 
Not just because of DHCP issues but also because users tend to jot down 
dynamic stuff and then hardcode it. (For instance for hosts that don't 
support dynamic DNS discovery (which obviously are almost all of them 
today (in IPv6)).)

> to the client is a multicast Reconfigure message.

Hm, I can already imagine the posters on the men's room at IETF 63: 
"whoever is sending "reconfigure DNS" multicast messages every second, 
quit it as the 1200 DHCPv6 requests per second are killing the wireless 
performance".

There are DoS issues here.

---

From: Tim Chown <[email-masked]>
Date: Thu, 13 Nov 2003 20:59:31 +0000

> Both setting the trigger of re-request on renumbering of prefix in RA,
> and a multicast Reconfigure message might cause all nodes to rush on
> the single DHCPv6-lite server for information-request reply exchange.
> It could work with small number of clients though.

I guess you could add some random delays, but you should also scale your
DHCPv6 server provision to have multiple servers?

I guess we can say that:

(1) Automatic renumbering is broken if people hard-code data in clients

(2) If a secure environment for reconfigure is needed, a multicast message
    adds some complexity

(3) The Reconfigure message is really designed for a fully stateful DHCPv6
    environment, not a purely stateless one providing options info (?)

(4) Periodic polling of the DHCPv6 server by clients allows renumbering
    but is not a full solution for more rapid (unplanned) renumbering.

(5) There isn't really a ethod now for a client to be informed of a
    renumbering event of a stateless DHCPv6 option (DNS, NTP)

(6) We don't want to use RA method because that would also mean an NTP
    extension for RA (?)

(7) If the network renumbers, statelessly configuring hosts should/could
    use the new prefix seen on an RA as a hint to re-request DHCPv6
    options if the O bit is set.

So is something overlooked, or do we not feel we need a solution to (5),
given we could use (7)?   Not sure how explicit (7) is...

Tim

---

From: SHIRASAKI Yasuhiro <[email-masked]>
Date: Fri, 14 Nov 2003 05:12:05 +0900 (JST)

On Thu, 13 Nov 2003 19:11:45 +0000,

Periodical information-request from client side as Ralph suggested,
and multicast advertisement of DNS option itself (w/ DHCPv6-lite, RA, SLP)
seems to work with large number of clients.

--
SHIRASAKI Yasuhiro

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 14 Nov 2003 07:24:06 +0900

Tim Chown;

I think that it is silently assumed that DHCPv6-lite is configured
of DNS server addresses without relaying requests to others.

That is, reconfiguration upon renumbering is necessary.

Or, DHCPv6-lite may be (pre)configured with well known addresses,
as I suggested at the last meeting.

But, let's assume relaying is performed, which is a likely scenario
on "stateful" cases, anyway.

> the router for the new RA...)

W.r.t. inter-link multicast, what multicast protocols is intended
to be used by people in DHC WG?

If it is CBT, PIM-SM or SSM, what happens if CORE, RP or SS crashes
or is renumbered?

Is a well known unicast address is assigned to a primary and
a back-up CORE/RP/SS, which means ANYCAST.

Is DVMRP assumed, instead?

Or, will we wait until yet another multicast protocol is
standardized, hoping that it will solve all the problems?

Assuming that some multicast protocol solves all the
problems, another question is on multicast address.

Is it a well known multicast address? If so, is there any
configuration necessary at a site (or something like that)
border router? If so, what happens if a customer want to relay
DHCP request to ISP's DHCP server? What happens the border
router is wrongly configured?

						Masataka Ohta

PS

It seems to me that relying on multicast does not solve but merely
refer the problem, which is better solved at the point (protocol)
where it is observed.

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 18 Nov 2003 00:57:01 +0900

Stig;

>>>is no multicast routing on site, this seems to be a gap (and a case for 
>>>the RA method - though of course with RA method you still need to 
>>>reconfigure the router for the new RA...)

> I'll comment on your mail, but let me first present how I suggest
> it be done.

Thanks.

> I suggest for server to send reconfigure to clients via relays.
> 
>>From server to relay:
> 
>     If multicast routing available in the site:

"site" is not a useful concept for autoconfiguration, when
the "site" is really small, which is, perhaps, the primary
target case of "stateless", which is why I asked multicast
over site boundaries.

Note also that "site" local unicast addresses are to be
deprecated.

Moreover, multicast is unreliable unless the server have a list
of relays, unless unicast ACK is returned from each relay.

And, then, use of multicast reduces the number of traffic
by half (ignoring frequent multicast control traffic some are
broadcast over a domain), which is not essential.

So,

>     If multicast routing not available in the site:
> 
> 	unicast to each relay, server has a list of relays

is a rational approach for either case.

Of course, the server have a stable storage.

However, some says "has a list of relays" is a "stateful"
approach and is no good.

Lack of well definedness of "stateless" is making design and
discussion very hard.

> Then from relay to client you can always use multicast on link.

It is unreliable that relays also should have lists of clients
and stable storages or the server directly take care of the
clients, in either of which case, unicast is good enough.

> Reconfigure messages should be protected due to possible DoS
> attacks. I didn't consider that at first. I think that can be
> done using public key crypto. Server has a single key pair.
> Clients get public key together with the config info, and the
> reconfigure message is signed with the private key.

Sorry, public key crypto is computationary expensive that it
rather amplifies than prevents DoS effect.

With your case, reconfigure messages with bogus signature will
force clients perform expensive public key crypto computation.

> I'm not sure that should be specified. At least as long as it
> isn't SSM, the DHCP infrastructure is completely independent
> of which multicast protocols are used, just like other
> multicast applications.

I asked not "specified" but "intended".

When we want to analyse specific application, we must take into
account all the layers to calculate number of packets, periods
of delay, redundancy, security etc.

> Interesting question. It's relatively easy with standard
> PIM-SM. You only need to reconfigure the RP address on the
> routers, and if you use say BSR, you only need to change on
> the c-BSRs and c-RPs.

It is more straight forward to change addresses of a DHCP server
on relayes to be used for unicast relaying. However, a DHCP server
is a single point of failure.

> And only within the site.

"site" is not a good idea.

> There are
> also ways to secure multicast against RP crashes etc.

This type of approach improve reliability for certain
types of failure but does not improve or rather disimprove
reliability for other types.

> Discussion on multicast reliability and renumbering could be
> a good topic for mboned wg. It doesn't belong here.

I'm afraid it is not an attractive idea to involve yet another
WG in the thread.

> For SSM, relays would need to know unicast addresses of DHCP
> servers, and if you do reconfigure with multicast, you also
> need servers to know unicast addresses of relays. Then you
> might as well use unicast.

Yup. But, is it "stateless"?

> Anycast might be used

An interesting fact is that there are someone who don't want to
use "anycast" for DNS servers, because it intermingles DNS and
routing system. However DNS servers by DHCP with multicast is 
already eaqually bad. Then, are we having DHCP with multicast
with anycast CORE/RP/SS?

> I think multicast works pretty well, but this should rather
> be discussed in mboned.

Sure. However, mboned is the worst place to discuss "multicast
does not work at all".

> Yes
> Of course things can be wrongly configured, but most things
> can break then.

Yes.

My intention here is to demonstrate that, with multicast, routing
and DHCP are intermingled.

> If you want to relay DHCP requests out of the
> site, the best is to use unicast between relay and server I
> think, using site multicast is only an option.

And, multicast is not a useful option, which means we need something
for redundancy.

						Masataka Ohta

---

From: Thomas Narten <[email-masked]>
Date: Tue, 18 Nov 2003 12:55:12 -0500

> have a list of clients (with leased IPs) to send that Reconfigure

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.

Point is, requiring that a node always be ready to receive an
asynchronous message from an arbitrary DHC server is potentially
problematical in practice.

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.

"Bernie Volz" <[email-masked]> writes:

> There was some discussion about adding a "configuration lifetime" option for
> Information-Request/Reply messages. This would be similar to the address
> lifetimes and the idea would be that this would give the client an
> indication of when to obtain updated configuration information. While this
> does not solve the problem completely, it would help solve the problem when
> scheduled changes in the network are planned.

> We may also want to have clients that initiate an Information-Request after
> detecting a configuration change that may invalidate existing information
> (such as prefixes in configuration information that are no longer valid) use
> a random delay before sending the Information-Request (just as they would
> for the 'first' Information-Request). Perhaps this just means clarifying
> what is meant in section 18.1.5 (RFC 3115) by first:

>    The first Information-request message from the client on the
>    interface MUST be delayed by a random amount of time between 0 and
>    INF_MAX_DELAY.

> There are also larger issues here when renumbering happens as the client may
> need to its DNS information (dynamic DNS), etc. So, when renumbering happens
> (new addresses are added or old ones are deprecated), the client needs to do
> some thinking and one of the outcomes is to obtain updated configuration
> information.

> - Bernie

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Tim
> Chown
> Sent: Thursday, November 13, 2003 4:00 PM
> To: SHIRASAKI Yasuhiro
> Cc: [email-masked]; [email-masked]
> Subject: Re: [dhcwg] Renumbering DNS with stateless DHCPv6 - bug?

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

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

---

From: Tim Chown <[email-masked]>
Date: Tue, 18 Nov 2003 22:39:53 +0000

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

> 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

---

From: "Eric A. Hall" <[email-masked]>
Date: Tue, 18 Nov 2003 17:03:15 -0600

> like adding a new NTP server or changing the DNS search path.

This is another area where the simplicity of using multicast well-known
addresses for configuration requests provides a major inherent advantage:
if none of the servers you previously discovered are responding anymore
(or if an SOA timer has reset, or whatever), simply reissue the request.
There's no need to get other services involved (EG, having the resolver
pass a request to the DHCP agent), no need for external data, or any of
that other stuff.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/