Subject: [dhcwg] renumbering event request either from CPE or from server

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 23 Jul 2014 15:53:59 +0200 (CEST)

Hi,

just writing down what I said at the mic (and more...)

I would like the following use-cases to be supported and would like to see 
guidance how it should be done. Since I am no DHCP expert, I am going to 
write in generic terms as to confuse less by getting the DHC terms wrong.

User goes into the CPE web-gui and:

* presses the "Emergency renumber NOW" button, and the CPE and network 
(after some signalling) drops the current prefix/address, and CPE requests 
a new one and gets it. This might be because the user is receiving 
unwanted traffic and wants to renumber. This probably needs signaling from 
the CPE on intent to not want current prefix.

* presses the "renumber" button, the CPE indicates that it wants a second 
prefix with intent of not wanting the existing one again after an overlap 
time. CPE initiates renumbering event, local hosts connected to it 
de-prefer the original prefix, and after a while, deprecates, it and CPE 
and network drops it. This might be because of privacy reasons.

* The CPE gets a /60 and then discovers that it needs more because of its 
local networks has more than 16 subnetworks. Do we need additional 
information to the server as to "why" the client requests additional 
space? Is there a difference from wanting more prefixes with the intent to 
renumber (and thus will drop the existing one in a short while), or 
wanting more because it needs more permanently?

We also need to handle the use-case of the server enforcing policy that 
the CPE must renumber once every day for instance, without the user doing 
anything. Can the server indicate to the CPE that after the lease time of 
the current prefix expires, it won't get it back and it should ask for a 
new one before the current prefix expires, and in the mean time initiate a 
renumbering event?

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Wed, 23 Jul 2014 16:38:47 +0000

I think all of these can be handled within what exists today.

If a client wants a completely new prefix (whether or not it wants to keep the old), it can always initiate this by Requesting it (IA_PD option with different IAID). Stateful issues will make this easier as client can do in Renew.

If old prefix is no longer desired, client can always release (either immediately or after its own steps to deprecate it - i.e., using shorter lifetimes than what server granted).

Thus, 

Case 1 - emergency renumber - request new PD (different IAID), release old after getting new.
Case 2 - same, but keep old for a while (this could include renewing it). Release when deprecated (either using servers lifetimes or shorter ones).
Case 3 - same, but keep renewing old.

So I don't think new options are really needed.

Note: the above fails if server takes steps to prevent a client from obtaining multiple prefixes, but that is hopefully not often the case (though some limits may exist to prevent using too many).

The final case is handled by the server simply not renewing a lease and, hopefully, providing a new one. A server is allowed to add more prefixes on any renewal.

- Bernie (from iPad)

> On Jul 23, 2014, at 9:54 AM, "Mikael Abrahamsson" <[email-masked]> wrote:
> 
> 
> Hi,
> 
> I would like the following use-cases to be supported and would like to see guidance how it should be done. Since I am no DHCP expert, I am going to write in generic terms as to confuse less by getting the DHC terms wrong.
> 
> * presses the "Emergency renumber NOW" button, and the CPE and network (after some signalling) drops the current prefix/address, and CPE requests a new one and gets it. This might be because the user is receiving unwanted traffic and wants to renumber. This probably needs signaling from the CPE on intent to not want current prefix.
> 
> * presses the "renumber" button, the CPE indicates that it wants a second prefix with intent of not wanting the existing one again after an overlap time. CPE initiates renumbering event, local hosts connected to it de-prefer the original prefix, and after a while, deprecates, it and CPE and network drops it. This might be because of privacy reasons.
> 
> * The CPE gets a /60 and then discovers that it needs more because of its local networks has more than 16 subnetworks. Do we need additional information to the server as to "why" the client requests additional space? Is there a difference from wanting more prefixes with the intent to renumber (and thus will drop the existing one in a short while), or wanting more because it needs more permanently?
> 
> We also need to handle the use-case of the server enforcing policy that the CPE must renumber once every day for instance, without the user doing anything. Can the server indicate to the CPE that after the lease time of the current prefix expires, it won't get it back and it should ask for a new one before the current prefix expires, and in the mean time initiate a renumbering event?
> 
> -- 
> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dhcwg

---

From: Simon Hobson <[email-masked]>
Date: Wed, 23 Jul 2014 21:14:52 +0100

Mikael Abrahamsson <[email-masked]> wrote:

> We also need to handle the use-case of the server enforcing policy that the CPE must renumber once every day for instance, without the user doing anything.

Over on the ISC DHCP users list, there have been a number of threads along the lines of "how can we make clients change address every <period>" - usually because "management" have decided it's the way to prevent users running servers.

The response has generally been along the lines of "start looking for a new job, because your customers will go elsewhere when you p**s them off".

This is in the IPv4 space, it's hard to see why the arguments should be any different in the IPv6 space.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 23 Jul 2014 17:31:26 -0400

> This is in the IPv4 space, it's hard to see why the arguments should be any different in the IPv6 space.

It's a little less bad in the IPv6 space if you just make the customer renumber.   And there are privacy advantages to renumbering.   So it's not a completely bad thing to enable mandatory renumbering; what's important is that it be done in a way that doesn't blow up people's multi-hour flows.   You probably aren't going to win with multi-day flows.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 24 Jul 2014 16:20:55 +0200 (CEST)

On Wed, 23 Jul 2014, Simon Hobson wrote:

> Over on the ISC DHCP users list, there have been a number of threads 
> along the lines of "how can we make clients change address every 
> <period>" - usually because "management" have decided it's the way to 
> prevent users running servers.

There are markets where part of the customer base demands to be renumbered 
regularily. You might think they're stupid, but ISPs in those markets lose 
customers if they don't have this functionality.

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Thu, 24 Jul 2014 16:01:26 +0000

This should all be possible and work through existing DHCPv6 operations. Server can add new address and deprecate old one when client renews.

- Bernie (from iPad)

> On Jul 24, 2014, at 10:21 AM, "Mikael Abrahamsson" <[email-masked]> wrote:
> 
> There are markets where part of the customer base demands to be renumbered regularily. You might think they're stupid, but ISPs in those markets lose customers if they don't have this functionality.
> 
> --

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 24 Jul 2014 19:12:39 +0200 (CEST)

> So I don't think new options are really needed.

Depends if the operator only wants the customer to have a single DHCPv6-PD 
prefix at any given time, then the combination of this requirement and 
above wouldn't seem to work for Case 1?

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Thu, 24 Jul 2014 20:23:17 +0000

> > If a client wants a completely new prefix (whether or not it wants to keep
> the old), it can always initiate this by Requesting it (IA_PD option with
> different IAID). Stateful issues will make this easier as client can do in Renew.
> >
> > If old prefix is no longer desired, client can always release (either
> immediately or after its own steps to deprecate it - i.e., using shorter
> lifetimes than what server granted).

In many access networks, stable addressing is achieved by associating the prefix with the access link (customer). If this has been done, then release and renew will always result in the same prefix; and it's often not allowed (per policy) to have multiple prefixes. Associating the prefix with the customer allows the prefix to be stable across power outages.
A strong message has been given to ISPs that stable addressing is recommended as standard behavior for IPv6.

Therefore, I don't think either of these methods is sufficient to signal to an ISP that a different prefix is desired.
Alternately, there could be a recommendation that release/renew implies "I want a different address/prefix". But I don't think that would be popular, because so many DHCPv4 servers today do everything they can to give a device the same assignment every time. In my home router I have to manually clear out the DHCPv4 assignments to force new IPv4 addresses. The router maintains a memory of MAC address to IPv4 address.
Barbara