Re: [v6ops] draft-ietf-v6ops-slaac-renum and draft-ietf-v6ops-cpe-slaac-renum

[Philip Homburg <[e-mail]>]

>> In my opinion, L-15 needs to be a SHOULD NOT or otherwise have space
>> for the operator of the router to override this behavior. I have provided
>> a use case for that in the past.
>
>These are requirements for the CPE, not for the operator. i.e., what the 
>CPE is expected to do without human intervention. It would seem to me 
>that, in that light the current "MUST" conveys the meaning of "if you 
>don't follow this, you are breaking things".  A device that employs 
>local addresses for more than the leased time may potentially employ 
>addresses for longer than valid.

I think the need to relax L-15 comes from the fact that ISPs have an 
incentive to use very short lease times.

I don't know the details, but what seems to happen is that when a
customer swaps one CPE for anothor, the old CPE doesn't release the
lease (i.e., people just poweroff or disconnect the old CPE).

Then when the new CPE asks for a lease and the customer has a fixed
prefix, the radius daemon finds that the lease is already in use by
the old CPE and doesn't give any lease to the new CPE.

The hacky quick fix for this is to set lifetimes in the lease to only
a few hours at most and ask people to wait.

We have to be careful, that we don't reserve the term CPE for
'device used by a customer who doesn't know any better'.

Historically, we allow operators of routers to set all kinds of parameters
even if they would shoot themselves in the foot doing that. So the CPE
specs are useful set of specifications to connect a router to a DSL or
cable connection. But that doesn't mean we should prevent to owner of the
CPE from configuring the local network as that person sees fit.

Now I think there is a workaround for the L-15 requirement. The CPE
could allow the user to not advertise the prefix obtained through
DHCPv6 PD and allow the user to statically configure a prefix to
advertised.

I think this workaround is more convoluted than allowing the user to
directly override the lifetime parameters. But that seems to be what
this wg wants.