Re: A common problem with SLAAC in "renumbering" scenarios

[Mark Smith <[e-mail]>]

On Tue., 5 Feb. 2019, 21:41 Jan Zorz - Go6 <[e-mail] wrote:

> On 04/02/2019 14:47, Philip Homburg wrote:
> >> Unless I'm mistaken, Ole is saying that a dhcp6-pd lease for time period
> >> X is a contract for time period X, during which the ISP should retain
> >> enough state that if the CPE issues another dhcp request within time
> >> period X, they will receive the same prefix.  However, when time period
> >> X elapses, the ISP is fully within their rights to assign a different
> >> prefix.
> >
> > The way I understand DHCP leases is that for the duration of the lease,
> > the party that obtained the lease has exclusive use of the address or
> prefix.
> > So it is a requirement on the DHCP server to avoid giving the lease to
> another
> > party.
> >
> > As far as I know it never said anything about getting the same address or
> > prefix if you do a DISCOVER.
>
> That seems to be the core of the problem, me think :) BRAS-es with
> defined IPv6 pools assigning PD-s randomly, regardless of anything and
> everything.
>


I don't know about other implementations, however Cisco IOS XE can source
stable prefix information for the BNG DHCPv6 server from RADIUS per RFC4818.




> >
> > A related point, and that's where it starts getting complicated, is that
> > over time DHCP got used for access control. Initially DHCP was just a way
> > for making sure that everybody got a unique address, but you could just
> > use any address you liked at the risk of collision.
> >
> > These days access routers restrict source addresses to whatever was
> offered in
> > a DHCP lease. And this is where it gets messy.
> >
> > In theory we could specify how access routers could do the right thing.
> And then
> > get CPEs to do the right thing as well.
>
> I'm starting to think that we should make all 3 places (access router,
> CPE and host) more robust and binding to some defined standard.
>
> Cheers, Jan
>
> >
> > But I think it would be more productive to make hosts more robust.
> >
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > [e-mail]
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------
> >
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>