<html xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"> <head> <meta http-equiv="Content-Type" content="text/html; charset=windows-1251"> <meta name="Generator" content="Microsoft Word 15 (filtered medium)"> <style></style> </head> <body lang="EN-IN" link="blue" vlink="purple"> <div class="WordSection1"> Please move this to GitHub with all the informations. It’s easy there to keep track.<o:p></o:p> <o:p> </o:p> <div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm"> From: systemd-devel <systemd-devel-bounces@lists.freedesktop.org> Date: Monday, 13 April 2020 at 11:36 PM To: systemd-devel@lists.freedesktop.org <systemd-devel@lists.freedesktop.org> Subject: Re: [systemd-devel] networkd: IPv6 prefix delegation not updated when prefix changes<o:p></o:p> </div> <div> Andrei Borzenkov <arvidjaar@gmail.com> writes: > 13.04.2020 18:18, Tobias Brink ןטרוע: > > DHCPv6 IA prefix option includes lifetime. Client is expected to renew > delegation before lifetime expires. If information handed out to client > expires before this timer, standard defines Reconfigure message that can > be used by server to inform client that it needs to renew lease. In both > cases it is really up to provider and its equipment. I did check this. Unfortunately, the CPE does not send a Reconfigure message. That would be the best, but there's nothing I can do about it. Nevertheless, that's not the whole issue. As stated in the other subthread, when the prefix is up for renewal, networkd sends a request and gets a NoBinding reponse because the prefix is no longer valid. At that point, it keeps retrying the (now) invalid prefix instead of requesting a new one. The (now) invalid routes are also never removed. I will re-test this extensively with the git master version of networkd and open an issue just on that part if it still occurs there. > Still even if all of this is implemented there is still some short > period of lost connectivity, before client has renewed delegation and > pushed updated information downstream. To make it completely transparent > provider would need to keep both prefixes as valid for some transitional > time. I am in fact not 100% sure if the old routes do not stay valid for a (very?) short time, I would have to do some testing. I suspect that the lifetimes passed on by the CPE do not necessarily reflect the ones on the ISP side. Not the most important for me, though, because I can set the renewal time to be in the night in the CPE so that I mostly wouldn't notice. The primary concern for the moment is to get the new prefix at all. Tobias _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org <a href="https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Fsystemd-devel&data=02%7C01%7Cssahani%40vmware.com%7C4fa36f838f674b4432db08d7dfd5738c%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637223980174319702&sdata=Ws3h6sKfl%2FPrKr%2F47s79KuLXPWsLlQTWaEtzF5nt4RU%3D&reserved=0">https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Fsystemd-devel&data=02%7C01%7Cssahani%40vmware.com%7C4fa36f838f674b4432db08d7dfd5738c%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637223980174319702&sdata=Ws3h6sKfl%2FPrKr%2F47s79KuLXPWsLlQTWaEtzF5nt4RU%3D&reserved=0</a><o:p></o:p> </div> </div> </body> </html>