Subject: DHCPv6 address selection option and stateless DHCPv6?

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 6 Sep 2013 20:13:51 +0900

Not sure if it's too late to fix this, but I happened to notice this text
in draft-ietf-6man-addr-select-opt-11:

"When the information from the DHCP server goes stale, the policy received
from the DHCP server SHOULD be deprecated."

Unfortunately, as RFC 4076 points out, information received via stateless
DHCPv6 never expires. (That's one of the many reasons why DHCPv6... but I
digress). What's the intent here?

1. This option is not recommended for use with stateless DHCPv6?
2. This option can be used with stateless DHCPv6, but its contents never
expire?
3. This option can be used with stateless DHCPv6, and the client expires it
whenever it feels like it?

If #2, then perhaps this option needs a lifetime value? Unless the plan is
that a) who/whatever solves the problem statement in RFC 4076 will solve
this too, or b) that everyone needing this option will use stateful DHCPv6.

Either way, it seems prudent to say something about this in the document,
as otherwise it's a bit of a trap for the unwary.

---

From: Tim Chown <[email-masked]>
Date: Fri, 6 Sep 2013 13:23:03 +0100

On 6 Sep 2013, at 12:13, Lorenzo Colitti <[email-masked]> wrote:

> Not sure if it's too late to fix this, but I happened to notice this text in draft-ietf-6man-addr-select-opt-11:
> 
> "When the information from the DHCP server goes stale, the policy received from the DHCP server SHOULD be deprecated."
> 
> Unfortunately, as RFC 4076 points out, information received via stateless DHCPv6 never expires. (That's one of the many reasons why DHCPv6... but I digress). What's the intent here?
> 
> 2. This option can be used with stateless DHCPv6, but its contents never expire?
> 3. This option can be used with stateless DHCPv6, and the client expires it whenever it feels like it?

A good question. It would be desirable not to preclude its use with stateless DHCPv6.  I've not caught up with all IESG comments yet; it may have been raised there also.

> If #2, then perhaps this option needs a lifetime value? Unless the plan is that a) who/whatever solves the problem statement in RFC 4076 will solve this too, or b) that everyone needing this option will use stateful DHCPv6.

What about use of RFC 4242, which SHOULD be supported in IPv6 CE's, for example (as per RFC 6204)?  RFC 4242 was produced to address the problems discussed in RFC 4076.

> Either way, it seems prudent to say something about this in the document, as otherwise it's a bit of a trap for the unwary.

Agreed, and thanks.

Tim

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 6 Sep 2013 21:30:58 +0900

On Fri, Sep 6, 2013 at 9:23 PM, Tim Chown <[email-masked]> wrote:

> > If #2, then perhaps this option needs a lifetime value? Unless the plan
> is that a) who/whatever solves the problem statement in RFC 4076 will solve
> What about use of RFC 4242, which SHOULD be supported in IPv6 CE's, for
> example (as per RFC 6204)?  RFC 4242 was produced to address the problems
> discussed in RFC 4076.
>

That seems like it would work. (Thanks for pointing it out, I hadn't seen
it. It's unfortunate that the minimum is 10 minutes, but for this
particular use case it doesn't matter.)

Perhaps just say that clients that process this option MUST either
implement OPTION_INFORMATION_REFRESH_TIME or assign it a default lifetime
of a day or somesuch?

Also, perhaps you might want to better specify what happens in the stateful
DHCPv6 case instead of just saying "when it's stale"? For example, you
could explicitly state that the lifetime of the option is the same as the
lease time?

Cheers,
Lorenzo

---

From: Arifumi Matsumoto <[email-masked]>
Date: Sun, 8 Sep 2013 13:17:38 +0900

Hi Lorenzo,

The current text describes the meaning of "stale" as follows in 3.2.

   The received information can be considered stale in several cases,
   e.g., when the interface goes down, the DHCP server does not respond
   for a certain amount of time, and the Information Refresh Time is
   expired.

We should add stateful DHCPv6 case here, as you mention it.

Best regards,

On 2013/09/06, at 21:30, Lorenzo Colitti <[email-masked]> wrote:

> That seems like it would work. (Thanks for pointing it out, I hadn't seen it. It's unfortunate that the minimum is 10 minutes, but for this particular use case it doesn't matter.)
> 
> Perhaps just say that clients that process this option MUST either implement OPTION_INFORMATION_REFRESH_TIME or assign it a default lifetime of a day or somesuch?
> 
> Also, perhaps you might want to better specify what happens in the stateful DHCPv6 case instead of just saying "when it's stale"? For example, you could explicitly state that the lifetime of the option is the same as the lease time?
> 
> Cheers,
> Lorenzo