Re: [v6ops] A broken promise - "You said PD Prefix Valid Lifetime is going to be X" (Re: SLAAC renum: Problem Statement & Operational workarounds)

On Tue, 12 Nov 2019, 04:11 Ted Lemon, <mellon@fugue.com> wrote:

> Nobody is expecting you to never renumber.   Well, at least I am not.
>

I'm not either.

IPv6's Preferred and Valid lifetime mechanisms are for planned renumbering.

What I am talking about here is deliberate, opportunistic renumbering. If
> your topology changes and you have to renumber, so be it.
>

Unplanned "flash" renumbering due to a topology change implies an unplanned
"flash" topology change. That's going to be a rare event, and ideally
shouldn't ever occur, because I think it is a sign that some other planning
hasn't been occurring.

I don't really understand what is so hard about all this.

You either provide prefix stability using a client's DUID, or you can use
RADIUS.

Stable PD prefixes are similar to IPv4 RADIUS Framed-Routes.

IETF RADIUS attributes exist to provide IPv6 PD prefixes to BNGs that use
them with their local DHCPV6-PD server - see RFC 6911.

This is the method used on the IPv6 residential broadband project I worked
on in 2010, and I'm pretty confident it is still being used today, as I've
been a customer of it for the past 8 years.

If you can avoid that it’s better, and if you can give notice it’s also
> better. If you can do it gracefully with temporary routes, even better. But
> you shouldn’t be renumbering just ‘cuz.
>

> On Nov 11, 2019, at 11:21, Richard Patterson <richard@helix.net.nz> wrote:
>
> 
> On Mon, 11 Nov 2019 at 11:02, Ted Lemon <mellon@fugue.com> wrote:
>
>>
>> The ISP has to install a DHCPv6 server in order to do an IPv6
>> deployment.  We’ve already heard from one of the main vendors of DHCPv6
>> servers that their server behaves correctly and does not do flash
>> renumbering.   The two DHCPv6 servers that I have worked on don’t either.
>> So why is the ISP going to have to delay?  The one time I was asked to help
>> an ISP to set up DHCPv6 in a way that would allow frequent renumbering, it
>> was a major engineering effort (which we wound up not doing).   The ISP
>> would have to go *out of their way* to not support stable prefixes.
>>
>
> This is an oversimplification, ignoring the complexities introduced by
> various topology, architectural and indeed vendor decisions.
> i.e.
> - Centralised vs distributed DHCP server.
> Distributed helps scale but centralised is easier to manage.
> Centralised would require some topology-awareness to know where a
> subscriber is to be numbered from, unless you're OK with deaggregation and
> the scaling impact it has.
>
> - Via a relay or direct?
> Direct could mean large broadcast domains and may not scale, but helps
> minimise the need for the server to be topology-aware.
> Relays would help scale but will need to keep state, and to completely
> avoid flash renumbering during planned or unplanned outages, they would
> need to write leases to persistent storage also.    (see draft-fkhp-dhc-dhcpv6-pd-relay-requirements
> )
>
> - DHCPv6 server colocated on the BNG/CMTS, or an off-box solution?
> Off-box solution is yet-another-thing to manage and scale.  Presumably
> there'll also need to be an IPAM, if we're to do 100% fixed statics, just
> for subscriber assignments.
> BNG/CMTS Vendor server may have it's on constraints and limitations.
>
>
> As a network operator, we can make sure we do as much as we can to keep
> PDs stable and honour leases up to the lease-time advertised, but there
> will always be the risk that sometimes we have to revoke the validity of a
> lease, either intentionally or unintentionally.  And sadly in the worse
> case scenarios, we may not be able to offer the same PD or NA as previously
> leased.
> If we can offer some recommendations to CPE & DHCP client/relay/server
> developers, as well as Operators, to help minimise this impact, I think
> it's worthwhile to do.
> If we can slightly tweak protocols to help minimise this impact, I
> understand that it may be a contentious idea, but would like to think it's
> also worthwhile looking in to?
>
>
>
>
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>