Subject: [dhcwg] LAN side Information Refresh Option time values derived from WAN side DHCPv6-PD timers?

From: Mark Smith <[email-masked]>
Date: Thu, 13 Jan 2011 12:39:14 +1030

Hi,

I'm doing some work with a residential CPE vendor on their IPv6
implementation.

I've asked them to implement Information Refresh time option support on
the stateless DHCPv6 server that is available on the LAN interfaces.
I've realised that the time value that this option provides needs to be
derived from the DHCPv6-PD timers used on the WAN interface, so that an
ISP change of supplied parameters can be propagated to the LAN attached
devices in a timely manner.

I've reviewed parts of the DHCPv6-PD and Information Refresh Option 
RFCs, and the 09 revision of the CPE draft, and haven't found anything 
conclusive.

Has there been any related discussion or are there any other references 
as to how to derive the Information Refresh time from DHCPv6-PD timers? 
My current thoughts would be to set the Information Refresh time value 
to either the remaining DHCPv6-PD REBIND time when the stateless DHCPv6 
request is made or the initial DHCPv6-PD REBIND time. Would that be 
reasonable?

Thanks,
Mark.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 13 Jan 2011 13:21:51 -0500

I don't see any particular point in syncing up the refresh times.   On a small LAN, just set the timer to some low value, like five minutes, or something like that.   It's not going to cause enough traffic to be an issue.   I suppose the ISP might have a renewal time shorter than that, but it seems like that would be a poor choice from a reliability standpoint.

If you try to sync to PD refresh timers, you run the risk of not propagating state when there's a network transient--the cable modem going offline and coming back on, for instance, and getting different information in its PD request.

---

From: Mark Smith <[email-masked]>
Date: Fri, 14 Jan 2011 11:23:08 +1030

Hi Ted,

Thanks very much for getting back to me.

> I don't see any particular point in syncing up the refresh times.   On a small LAN, just set the timer to some low value, like five minutes, or something like that.   It's not going to cause enough…

The reason I was thinking about the refresh timers being synchronised or 
derived from the DHCPv6-PD timers is so that an ISP has a known and 
generally bounded period of transition between old and new services 
whose parameters are conveyed with these options.

For example, if the information request refresh time was a similar time 
period to the delegated prefix preferred time, which I think would 
translate into an equivalent DHCPv6-PD REBIND time, then when an ISP 
transitions it's customers from, for example, old DNS servers to new 
ones, the maximum time period both the old and new DNS servers would 
have to be available during the transition would be approximately 2 
times the delegated prefix preferred time.

Having an known and predictable upper bound for how long legacy services 
will be used would much better than today's situation with IPv4, where 
legacy services have to be available for potentially years, and there is 
still have a likelyhood that a customer's services will be disrupted 
when those legacy services are eventually decommissioned.

 > If you try to sync to PD refresh timers, you run the risk of not 
propagating state when there's a network transient--the cable modem 
going offline and coming back on, for instance, and getting different 
information in its PD request.

I think that might be a limitation of stateless DHCPv6 itself 
unfortunately. Without some sort of flash update or expire message that 
the CPE can send to the LAN devices upon change of parameters acquired 
via DHCPv6-PD, as the absolute minimum time for the information refresh 
looks to be 10 minutes, there would be fairly significant periods where 
end-nodes are trying to use invalid parameters.

Thanks,
Mark.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 13 Jan 2011 22:09:45 -0500

On Jan 13, 2011, at 7:53 PM, Mark Smith wrote:
> For example, if the information request refresh time was a similar time period to the delegated prefix preferred time, which I think would translate into an equivalent DHCPv6-PD REBIND time, then when an ISP transitions it's customers from, for example, old DNS servers to new ones, the maximum time period both the old and new DNS servers would have to be available during the transition would be approximately 2 times the delegated prefix preferred time.

This is a solution to a problem that doesn't exist.  ISPs don't need to switch customers from name server A to name server B on a time schedule that tight.   Or, if they do, we need to be talking in detail about the scenario where you think this is necessary; talking about IRT times is putting the cart before the horse.

> Having an known and predictable upper bound for how long legacy services will be used would much better than today's situation with IPv4, where legacy services have to be available for potentially years, and there is still have a likelyhood that a customer's services will be disrupted when those legacy services are eventually decommissioned.

This is why the ISPs should have been using DHCP with leases.   With leases, you *know* the information will be invalidated when the lease expires; if it's not, the client is out of spec.   If you need a protocol that doesn't cause customer failures when the customer is running software that's out of spec, that's a really large solution space, and I don't think we can help you.

> I think that might be a limitation of stateless DHCPv6 itself unfortunately. Without some sort of flash update or expire message that the CPE can send to the LAN devices upon change of parameters acquired via DHCPv6-PD, as the absolute minimum time for the information refresh looks to be 10 minutes, there would be fairly significant periods where end-nodes are trying to use invalid parameters.

Prefix delegation isn't meant to force rapid renumbering or any sort of rapid reconfiguration on clients.   If you use it that way, yes, you will definitely experience problems.   That's not a problem with the protocol.   Or, I should say, if you think it's a problem with the protocol, you're going to need to change a lot more than the DHCP protocol to get something reliable that can be renumbered that quickly.

The idea with renumbering in IPv6 is to deprecate the old prefix, but continue to allow its use for some period after it's deprecated.   Meanwhile you give the PD client a new prefix.   The PD client immediately starts advertising the new prefix, and deprecates the old prefix.   At this point I would actually expect a DHCP client to reconfigure, because it's got a new prefix.

But even if it doesn't, as long as it reconfigures before the deprecated prefix expires, life should be okay.   If this is happening more rapidly than every five minutes, something very weird is going on.

I guess my point is that what you're asking for, and the problems you're anticipating, seem out of line with the solution you're proposing, and with the deployment scenario I understood you to be describing.   So it would be good if you could talk some more about that, so that we can get a better understanding of why you think you have a problem.

---

From: Mark Smith <[email-masked]>
Date: Mon, 17 Jan 2011 14:37:02 +1030

Hi Ted,

> This is a solution to a problem that doesn't exist.  ISPs don't need to switch customers from name server A to name server B on a time schedule that tight.   Or, if they do, we need to be talking i…

It's not clear yet nor does there seem to be a common practice as to 
what preferred and valid lifetimes ISPs are likely to use, so I suppose 
the RFC4861 defaults of 7 and 30 days would be reasonable ones to start 
with as an example.

Assuming there are no hardware acquisition lead times, my experience has 
been that it is possible to build and have ready for production two 
replacement DNS resolvers in a week, for use in an ISP with 50K+ 
subscribers. I think a reasonable goal would then be to have all those 
subscribers using those new DNS resolvers four weeks from when they are 
first made available to subscribers.

If a customer's CPE is doing a rebind of it's delegated prefix at around 
the 7 day period, then I'd assume that would also be when the new DNS 
servers addresses would be provided to the CPE at that time. I think 
that would mean that the last customer CPE to receive the new DNS 
servers addresses would be the ones that rebound their delegated prefix 
moments before the DNS servers addresses where changed in the 
DHCPv6(-PD) server. So within about 7 days from when the DNS servers go 
into production, it is very probable that all the customers' CPE would 
now have knowledge of the new ones.

Ideally if the end-nodes are asking for and receiving the DNS options 
from the stateless DHCPv6 server on the LAN interface of the CPE, then 
they should be updated within a time period that is predictable by the 
ISP, based on a parameter that the ISP defines. Thinking about it a bit 
more, if the information refresh option time was set to around 7 days 
(i.e. preferred lifetime for delegated prefix set by the ISP) on the 
LAN, then I think end-nodes should have acquired the new DNS servers 
addresses within a maximum of 14 days from when the DNS servers were 
first made available to subscribers via updated settings in the ISP's 
DHCPv6 server. That would fall well within the 4 week goal of 
transitioning from old DNS servers to new ones.

So maybe as a more general rule, the information refresh time value 
conveyed by a stateless DHCPv6 server on the LAN interface of a CPE 
would be set to the rebind time value of the DHCPv6(-PD) client on the 
WAN interface.

> This is why the ISPs should have been using DHCP with leases.   With leases, you *know* the information will be invalidated when the lease expires; if it's not, the client is out of spec.   If you…

DHCPv6-PD (i.e. with leases), is being used by the ISP (i.e. us). The 
issue is how updates to DHCPv6 options provided by via DHCPv6(-PD) on 
the WAN side of the CPE are propagated in a timely manner to end-nodes 
on the LAN side of the CPE, via the stateless DHCPv6 server on the LAN 
side of the CPE.

Thanks,
Mark.