Subject: Re: [dhcwg] stateless dhcp6 and timely information update

From: Ted Lemon <[email-masked]>
Date: Thu, 6 May 2010 11:54:10 -0400

I was just going over the conversation in the meeting at IETF 77, and a couple of things jumped out at me that I wanted to mention.

The topic here is what a residential home gateway or similar device does when its upstream provisioning changes, and it is using stateless DHCPv6 to distribute configuration information to its downstream clients.   Stateless DHCPv6 doesn't have a clear mechanism for handling this.   I'm going to summarize the two mechanisms we might use to address this issue.

Mechanism 1:

We talked about the possibility of using DHCP Reconfigure messages to get clients to get new information.   There are three problems with this.  The first is that right now, we don't encourage DHCPv6 clients to ask for Reconfigure messages when sending DHCP Information Request messages.   So these clients would not be receptive to Reconfigure messages.   In order to address this, we would have to issue a new Stateless DHCP draft that corrects the problem.

The second problem is that even if we update the stateless RFC to say that clients SHOULD ask for Reconfigure messages, some clients won't.   We pretty much need to make Reconfigure non-optional in order to actually solve James' problem.

The third problem is that James doesn't want to have to cache client info indefinitely.   This is actually a non-problem--the residential gateway can send an IRT to the client of, say, an hour.   Any client that doesn't re-contact the DHCP server during that hour can be forgotten.   So there is a way to create an upper bound on the amount of state the DHCP server has to retain on "stateless" clients.

The bottom line is that I think this is an unsatisfactory solution to James' problem, although if we decide to pursue it, I think it can be made to work.

Mechanism 2:

DHCPv6 clients make decisions as to when to request new information.   One input into these decisions is the receipt of Router Advertisement messages.   If the DHCPv6 client does the right thing when it receives a Router Advertisement message advertising a new prefix and deprecating an old one, James' problem is solved.

Neither RFC3315 nor RFC3736 say *when* the client should initiate DHCPv6 configuration.   As it happens, neither do RFC4861 (Neighbor Discovery) nor RFC4862 (IPv6 Stateless Address Autoconfiguration).   This is a very serious problem, in my opinion--a potential implementor of a DHCPv6 client has no idea when to initiate DHCPv6, nor when to stop DHCPv6, nor when to re-initiate DHCPv6.

I think the right behavior is that whenever a Router Advertisement message is received that deprecates a prefix the client is using, the client should re-initiate the Information Request process as described in RFC3736.   But there's no document that says DHCPv6 clients should do that.

RFC3736 tries to completely stay away from Neighbor Discovery, and while I think that was a laudable goal in theory, in practice it turns out to have been a bad decision, because RFC4861 tries just as hard to stay away from DHCPv6.   So I propose that we update RFC3736 to say when clients should send Information Request messages.   I think common sense would tell implementors to send Information Request messages at the right times, but experience has shown that we cannot rely on common sense.

And in case it's not obvious, I think Mechanism 2 is the right way to go.

Comments/flames/criticisms?

---

From: james woodyatt <[email-masked]>
Date: Thu, 6 May 2010 09:17:36 -0700

On May 6, 2010, at 08:54, Ted Lemon wrote:
> 
> I think the right behavior is that whenever a Router Advertisement message is received that deprecates a prefix the client is using, the client should re-initiate the Information Request process as described in RFC3736.

Works for me.

--
james woodyatt <[email-masked]>
member of technical staff, communications engineering

---

From: Ted Lemon <[email-masked]>
Date: Thu, 6 May 2010 12:48:42 -0400

> Works for me.

Great.   Do you have time to be the document editor?

:)

---

From: Mohacsi Janos <[email-masked]>
Date: Thu, 6 May 2010 18:58:13 +0200 (CEST)

On Thu, 6 May 2010, Ted Lemon wrote:

> The topic here is what a residential home gateway or similar device does 
> when its upstream provisioning changes, and it is using stateless DHCPv6 
> to distribute configuration information to its downstream clients. 
> Stateless DHCPv6 doesn't have a clear mechanism for handling this.  I'm 
> going to summarize the two mechanisms we might use to address this 
> issue.
>
> Mechanism 1:
>
> We talked about the possibility of using DHCP Reconfigure messages to 
> get clients to get new information.  There are three problems with this. 
> The first is that right now, we don't encourage DHCPv6 clients to ask 
> for Reconfigure messages when sending DHCP Information Request messages. 
> So these clients would not be receptive to Reconfigure messages.  In 
> order to address this, we would have to issue a new Stateless DHCP draft 
> that corrects the problem.
>
> The second problem is that even if we update the stateless RFC to say 
> that clients SHOULD ask for Reconfigure messages, some clients won't. 
> We pretty much need to make Reconfigure non-optional in order to 
> actually solve James' problem.
>
> The third problem is that James doesn't want to have to cache client 
> info indefinitely.  This is actually a non-problem--the residential 
> gateway can send an IRT to the client of, say, an hour.  Any client that 
> doesn't re-contact the DHCP server during that hour can be forgotten. 
> So there is a way to create an upper bound on the amount of state the 
> DHCP server has to retain on "stateless" clients.
>
> The bottom line is that I think this is an unsatisfactory solution to 
> James' problem, although if we decide to pursue it, I think it can be 
> made to work.
>
> Mechanism 2:
>
> DHCPv6 clients make decisions as to when to request new information. 
> One input into these decisions is the receipt of Router Advertisement 
> messages.  If the DHCPv6 client does the right thing when it receives a 
> Router Advertisement message advertising a new prefix and deprecating an 
> old one, James' problem is solved.
>
> Neither RFC3315 nor RFC3736 say *when* the client should initiate DHCPv6 
> configuration.  As it happens, neither do RFC4861 (Neighbor Discovery) 
> nor RFC4862 (IPv6 Stateless Address Autoconfiguration).  This is a very 
> serious problem, in my opinion--a potential implementor of a DHCPv6 
> client has no idea when to initiate DHCPv6, nor when to stop DHCPv6, nor 
> when to re-initiate DHCPv6.
>
> I think the right behavior is that whenever a Router Advertisement 
> message is received that deprecates a prefix the client is using, the 
> client should re-initiate the Information Request process as described 
> in RFC3736.  But there's no document that says DHCPv6 clients should do 
> that.
>
> RFC3736 tries to completely stay away from Neighbor Discovery, and while 
> I think that was a laudable goal in theory, in practice it turns out to 
> have been a bad decision, because RFC4861 tries just as hard to stay 
> away from DHCPv6.  So I propose that we update RFC3736 to say when 
> clients should send Information Request messages.  I think common sense 
> would tell implementors to send Information Request messages at the 
> right times, but experience has shown that we cannot rely on common 
> sense.
>

I also think that client should decide when to initiate dhcpv6 information 
request. The DNS server informations are fairly static in ISPs. They 
assign DNS servers for the all or subest of their users. Changes usually 
occurs when client is connecting to different subnet, changing link, 
changing address etc. Probably worth considering issuing dhcpv6 
Information Request on address autoconfiguration.... to make the 
implementation easier.

Regards,
 	Janos Mohacsi

---

From: Thomas Narten <[email-masked]>
Date: Thu, 06 May 2010 14:17:44 -0400

>  message is received that deprecates a prefix the client is using,
>  the client should re-initiate the Information Request process as
>  described in RFC3736.  But there's no document that says DHCPv6
>  clients should do that.

I disagree. Using prefix info to signal "time for an update" is
overloading the semantics and may work in some cases, but won't in
others.

We have a general problem here and really ought to find a proper
solution. Otherwise we'll revisit this space again in the future, in a
slightly different context. The general problem is when DHC has its
configuration info updated, how can it (in a timely manner) push the
new info out to clients?

Tightly coupling DHCP behavior to RAs is arguably a bad idea. Think of
the long discussions (and non-agreement) on how to define the M&O
bits. Many of the concerns here surround ability of the DHC and RA
bits to *really* be in sync.

The fundamental problem is that if you tie correct behavior of DHC to
RAs (or vice versa), you've now made your overall system more complex
and less reliable.

If (and this is an if) we want to have RAs trigger clients to contact
DHC servers again, it should be done in a generic manner, for example
with a generic option that says "current info is X, go fetch it if
yours is older". (X would be a sequence number or something
short). This would be a more general solution than looking at a prefix
timing in and out.

Unfurtunately, we have only two general approaches:

1) poll, where the client polls periodically. This will always have
   the problem that if you make the timeout long, clients may be late
   in obtaining critical info. But if the timeout is short, you beat
   up the network and server unnecessarily.

2) Push, where some message can be sent asynchronously to prompt
   clients to go back for new info. 

But the proposal is to couple DHC and RAs together so that "push" uses
the RA rather than having a DHCP "reconfigure" that does the same
thing.

How is using an RA to signal "contact your server again" really any
different than just having the DHC server do so directly?

I know this would solve the more general problem, but I think we
should really do that. The problem is a real one that is arguably a
significant weakness in DHC, and we would do well to fix it.

Thomas

---

From: Ted Lemon <[email-masked]>
Date: Thu, 6 May 2010 14:56:11 -0400

> significant weakness in DHC, and we would do well to fix it.

Right now, DHCPv6 service and RAs are tightly coupled.   We base our decision to do DHCPv6 on the contents of router advertisements, although the latest RFC says that if we don't get any RAs, we can also do DHCPv6, which is a decoupling of sorts, I suppose.

The reason I want to use RAs for this is because we are already using them for this--we just don't have current RFCs that say how to do it, and the slack this creates means we can't count on clients to send information-request messages at the right time.

If we really don't think the M and O bits have anything to do with DHCP, then let's write a draft that explicitly decouples DHCP from the M and O bits, and describe how it should operate instead.   If we *do* think that the M and O bits should be used by DHCP, then we should be explicit in saying how DHCP uses them, not only when hearing an RA on a link for the first time, but also in general.

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Sat, 8 May 2010 15:05:43 -0500

Thomas:

What is the scope of problem here? Are your comments restricted to the
stateless case?

Clearly, if the client detects that it has moved, DHCP needs to be
informed in order to react (CONFIRM, INFORMATION_REQUEST, etc). So,
prefix changes should always be a trigger to DHCP.

Thus, I'm fully in favor of Ted's "Mechanism 2".

>How is using an RA to signal "contact your server again" really any
different than just having the DHC server do so >directly?

The difference is HUGE ... as RAs are already sent periodically and
there is no current periodic message from the DHC server (and clients
generally aren't listening for DHCP traffic -- expect if they've
negotiated for Reconfigure). Also, in the case of Reconfigure, this
requires some state (knowing the client's address and nonce) that are
easily lost (ie, on a home gateway reset) and thus may not be available.
These issues generally don't exist for RAs as they are multicast (DHCP
clients currently only process unicast DHCP traffic).

However, there are situations where the RA won't indicate any change and
this is a case that needs to be handled for DHCP (ie,
Information-Request data has changed but no prefix changes occurred).
Reconfigure (if extended to Information-Request only clients), certainly
could work here unless of course the gateway has lost that information
(ie, reboot with loss of state).

We could certainly consider a periodic DHCP server announcements about
the DHCP configuration state and if there are any changes, a client
would trigger a CONFIRM/INFORMATION REQUEST.

- Bernie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Thomas Narten
Sent: Thursday, May 06, 2010 2:18 PM
To: Ted Lemon
Cc: DHC Working Group
Subject: Re: [dhcwg] stateless dhcp6 and timely information update

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

---

From: Thomas Narten <[email-masked]>
Date: Mon, 10 May 2010 09:13:04 -0400

Hi Bernie.

> What is the scope of problem here? Are your comments restricted to the

No. IMO, it would undesirable to have a solution only for the
stateless case, but not the stateful case. Remember, stateless is a
subset of stateful. They should not be *different* protocols in
practice.

> prefix changes should always be a trigger to DHCP.

I assume this is really best handled as part of the DNA work, but we
are waiting for a revised document to fully understand what the
recommendation is...

> clients currently only process unicast DHCP traffic).

If we adopt/recommend a change in DHC client behavior, e.g., that
changes in advertised prefixes trigger DHC invocation, that would
require a change to deployed code. I.e., will require code
modifications. IMO, that is not a small bar. If code changes are
needed anyway, it's reasonable to consider code changes that solve the
problem more generally.

> (ie, reboot with loss of state).

Right. But I think Reconfigure as it is architected is kindof broken
in practice.

> would trigger a CONFIRM/INFORMATION REQUEST.

That is what I'm suggesting. What are (at a high-level) the  pros/cons
of such an approach?

pros:

done entirely by DHC servers, no dependencies on RAs (and
pushing info from DHC servers to all impacted routers)

General solution for handling any unplanned change in configuration
information that must be communicated quickly

cons:

Makes it easier to hijack DHC? I.e., an attacker could presumably use
such a message to initiate a client request that is then specifically
attacked/hijackked/etc. (But how much worse would this be than  using
a trigger in an RA to do this?)

Would have to revisit original Reconfigure considerations that led to
its current (restricted) design. My recollection is that Reconfigure
used to do essentially what we need, but was neutered over security
concerns.

Longer to get deployed in practice.

How would DHCP servers  arrange to multicast such messages on each
link (since servers are not on each links, would this require relay
agents resend them?)

(Lot's more I've probably not mentioned here.)

Thomas

---

From: Ralph Droms <[email-masked]>
Date: Mon, 10 May 2010 09:34:53 -0400

Thomas - My understanding is that we're trying to *avoid* any changes  
to DHCPv6 as part of DNA.  Tha is, DNA may make an early decision to  
reuse DHCPv6 information, but won't otherwise change when and how  
DHCPv6 is initiated.

I agree that we need to wait for a revised DNA doc to understand its  
itneraction with DHCPv6.

- Ralph

On May 10, 2010, at 9:13 AM 5/10/10, Thomas Narten wrote:

> [...]

---

From: Thomas Narten <[email-masked]>
Date: Mon, 10 May 2010 09:40:21 -0400

> reuse DHCPv6 information, but won't otherwise change when and how  

That is my understanding too. But I think that is the draft we should

> >> prefix changes should always be a trigger to DHCP.

The above type of recommendation presumably is better dealt with in
DNA than as yet another one-off for a special situation.

But we need to wait to see exactly what the revised document says...

Thomas

---

From: Ted Lemon <[email-masked]>
Date: Mon, 10 May 2010 12:44:08 -0400

> But we need to wait to see exactly what the revised document says...

DNA has nothing to do with this particular discussion.   DNA is on the other side of the gateway.   On the side of the gateway we're talking about, no DNA event has occurred.   The only thing that's changed is that the old prefix we were using will no longer work, and we are seeing a new prefix advertised.   It's also the case that DNA doesn't use RA in its calculations, so even if there were some DNA action going on here, I don't think the DNA draft would help us.

However, I think Thomas is right that Reconfigure needs a rethink.   The original security issue that drove the design of Reconfigure was that we didn't want to make it possible for a blind off-network attack to put all the DHCP clients on the network into a predictable state.   We wanted to make sure that the DHCP server had to reach out and touch each client individually--that is, we wanted to require that the DHCP server have knowledge of the clients it directed to reconfigure, knowledge that an off-network attacker would not have.

The situation has changed since RFC3315 was written--we now have CGA.   It's therefore possible for the client to be assured that it is talking to the same server it was talking to previously, without the use of a nonce, and with the use of a multicast.   So if we use CGA to authenticate the client's original exchange with the server, we can use CGA to authenticate the Reconfigure, and this means we can multicast the Reconfigure.   *This*, I believe, would solve James' problem quite neatly.

There is an additional problem, however, which we don't address if we solve James' problem this way: current specs do not tell us how to initiate the DHCP process in the presence of RA messages.   Because the M and O bits are no longer documented, but RFC3315 relied on them, we are in limbo.   If there is no RA, we do have a spec that tells us we can try DHCPv6 now, which is an improvement over the previous situation, but that same spec does not tell us what to do if an RA is present.

So I think that if we go this route, we need to write a document that solves James' problem, and another document that solves the startup problem.

---

From: james woodyatt <[email-masked]>
Date: Mon, 10 May 2010 09:55:50 -0700

> Great.   Do you have time to be the document editor?

Doubtful.  I can ask, but I'm not optimistic.  On the other hand, see the excerpts of this thread below which I find pertinent to the discussion...

On May 6, 2010, at 11:17, Thomas Narten wrote:
>  
> [...] Tightly coupling DHCP behavior to RAs is arguably a bad idea. Think of the long discussions (and non-agreement) on how to define the M&O bits. Many of the concerns here surround ability of the DHC and RA bits to *really* be in sync. [...]

On May 8, 2010, at 13:05, Bernie Volz (volz) wrote:

> [...] The difference is HUGE ... as RAs are already sent periodically and there is no current periodic message from the DHC server (and clients generally aren't listening for DHCP traffic -- expect if they've negotiated for Reconfigure). Also, in the case of Reconfigure, this requires some state (knowing the client's address and nonce) that are easily lost (ie, on a home gateway reset) and thus may not be available. [...]

On May 10, 2010, at 06:34, Ralph Droms wrote:

> My understanding is that we're trying to *avoid* any changes to DHCPv6 as part of DNA.  Tha is, DNA may make an early decision to reuse DHCPv6 information, but won't otherwise change when and how DHCPv6 is initiated. [...]

I will say this whole discussion continues to remind me of monkeys and weasels.  However, since I brought up the topic in DHC at IETF-77 in Anaheim, 6MAN has now taken up moving RFC 5006 into standard track.  The latest draft has added the domain search list alongside the server addresses, which is enough from my perspective to move the whole stateless configuration problem out of DHCP entirely.

If I had my druthers, what we would do is define a cheap way to put DHCP options into DNS records and define a simple method for statelessly configured hosts to locate them.  We would then revise the appropriate standards to say that the M-bit in RA means hosts may rely on the presence of a DHCP server to provide stateful configuration of address and/or prefix information, and that the O-bit in conjunction with RDNSS options means that hosts may search for stateless configuration parameters in the DNS accordingly.

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Mon, 10 May 2010 12:51:49 -0500

Ted:

>The only thing that's changed is that the old prefix we were
>using will no longer work, and we are seeing a new prefix
>advertised.  

Does this mean that the old prefix is deprecated by an RA?

>> I think the right behavior is that whenever a Router Advertisement
message is received that deprecates a prefix the >client is using, the
client should re-initiate the Information Request process as described
in RFC3736.
>Works for me.

So, isn't this exactly what we were talking about ... prefix changes
should re-initiate the Information Request process? Deprecating an old
prefix, especially if one or more configuration parameters used one of
those addresses, would clearly be a reason for a "reconfiguration".
Adding a new prefix should also be a trigger (as obviously something in
the network has changed).

We might have to have some words about limiting the frequency of
Information Requests in cases where there are RA conflicts or a large
number of changes.

There is an additional case that Jamie wrote about in an email on
3/25/2010 when the prefix doesn't change that this won't handle.

>Now consider what happens next: WAN link goes down for
>a few minutes, and when it comes back up, the gateway's
>DHCP6 client fails to renew, instead needs to rebind. 
>(Alternatively, this same scenario could arise with the
>reconfiguration update subprotocol, but let's not get
>ahead of ourselves.)  Residential gateway gets new DNS
>server addresses and service no longer available at old
>addresses.  If there is also a new prefix, then that
>goes out in router advertisements, and the hosts on the
>LAN all renumber properly, but the issue arises even
>when the prefix doesn't change.

And, this really is no different from a configuration change in the
network/DHCP server that "needs" to be pushed out to all clients
immediately (unplanned outage of the resolving DNS server(s)). And, yes,
this is the case that would need a multicast reconfiguration mechanism
of some kind.

And, I do agree that this new mechanism should not make use of a nonce
(as the DHCP server may not have storage available).

One issue we will need to look at for any multicast mechanism is how to
handle missing packets. The server could send out Reconfigure
notifications every few seconds for a period of time -- but there would
need to be some kind of 'configuration generation' identifier so that
clients that had that server's current configuration would not
re-initiate a Reconfigure.

---

>There is an additional problem, however, which we don't
>address if we solve James' problem this way: current
>specs do not tell us how to initiate the DHCP process
>in the presence of RA messages.

I don't really understand this point as I didn't see Jamie having an
issue with this? After all, he wouldn't have the problem he has if the
clients weren't doing DHCP (though the clients would then have
problems). Perhaps I missing this in Jamie's set of issues?

I personally never understood the debate about the M & O bits -- they
seemed pretty simple and straight forward to me. Yet, I fear this could
just start that long debate again.

Be nice to also fix RFC 3315 to allow Solicit without IA's as then even
stateless clients could be given Reconfiguration information. A server
that has no stable storage can always elect not to honor the traditional
reconfigure.

However, a new multicast reconfigure mechanism would eliminate the need
for this change and be better as it avoids the nonce storage issue.

- Bernie

-----Original Message-----
From: Ted Lemon [mailto:[email-masked]] 
Sent: Monday, May 10, 2010 12:44 PM
To: Thomas Narten
Cc: Ralph Droms; Bernie Volz (volz); DHC Working Group
Subject: Re: [dhcwg] stateless dhcp6 and timely information update

> But we need to wait to see exactly what the revised document says...

DNA has nothing to do with this particular discussion.   DNA is on the
other side of the gateway.   On the side of the gateway we're talking
about, no DNA event has occurred.   The only thing that's changed is
that the old prefix we were using will no longer work, and we are seeing
a new prefix advertised.   It's also the case that DNA doesn't use RA in
its calculations, so even if there were some DNA action going on here, I
don't think the DNA draft would help us.

However, I think Thomas is right that Reconfigure needs a rethink.   The
original security issue that drove the design of Reconfigure was that we
didn't want to make it possible for a blind off-network attack to put
all the DHCP clients on the network into a predictable state.   We
wanted to make sure that the DHCP server had to reach out and touch each
client individually--that is, we wanted to require that the DHCP server
have knowledge of the clients it directed to reconfigure, knowledge that
an off-network attacker would not have.

The situation has changed since RFC3315 was written--we now have CGA.
It's therefore possible for the client to be assured that it is talking
to the same server it was talking to previously, without the use of a
nonce, and with the use of a multicast.   So if we use CGA to
authenticate the client's original exchange with the server, we can use
CGA to authenticate the Reconfigure, and this means we can multicast the
Reconfigure.   *This*, I believe, would solve James' problem quite
neatly.

There is an additional problem, however, which we don't address if we
solve James' problem this way: current specs do not tell us how to
initiate the DHCP process in the presence of RA messages.   Because the
M and O bits are no longer documented, but RFC3315 relied on them, we
are in limbo.   If there is no RA, we do have a spec that tells us we
can try DHCPv6 now, which is an improvement over the previous situation,
but that same spec does not tell us what to do if an RA is present.

So I think that if we go this route, we need to write a document that
solves James' problem, and another document that solves the startup
problem.