[dhcwg] Re: [Technical Errata Reported] RFC9686 (8600 )
Warren Kumari <[email protected]> Tue, 14 Oct 2025 13:01:56 -0700
| Newsgroups | gmane.ietf.dhc |
|---|---|
| Message-ID | <CAHw9_i+6bYeVv8LV-Q_42sKiqf+UUYxjkivciO-oSEsw1m1KyQ@mail.gmail.com> |
--===============7566958314432765341== Content-Type: multipart/alternative; boundary="0000000000002f3ff9064123dba9" --0000000000002f3ff9064123dba9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I believe that this errata should be rejected, or hold for document update= . "Errata are meant to fix "bugs" in the specification and should not be used to change what the community meant when it approved the RFC." - https://datatracker.ietf.org/doc/statement-iesg-iesg-processing-of-rfc-erra= ta-for-the-ietf-stream-20210507/ While this text could *clearly* be improved, this was the consensus when the document was published, so this isn't really an Errata. IIRC, we did have some discussions around "1% or <some time>, whichever is greater" but we were not able to get any sort of consensus on <some time>, and so the consensus was to go with this=E2=80=A6 W On Tue, Oct 14, 2025 at 2:22 PM, RFC Errata System < [email protected]> wrote: > The following errata report has been submitted for RFC9686, > "Registering Self-Generated IPv6 Addresses Using DHCPv6". > > -------------------------------------- > You may review the report below and at: > https://www.rfc-editor.org/errata/eid8600 > > -------------------------------------- > Type: Technical > Reported by: Patrick Rohr <[email protected]> > > Section: 4.6.1 > > Original Text > ------------- > Whenever the network changes the Valid Lifetime of an existing address by > more than 1%, for example, by sending a Prefix Information Option (PIO) > [RFC4861] with a new Valid Lifetime, the client calculates a new > AddrRegRefreshInterval. > > --- > > * The 1% tolerance ensures that the client will not refresh or reschedule > refreshes if the Valid Lifetime experiences minor changes due to > transmission delays or clock skew between the client and the router(s) > sending the RA. > > Corrected Text > -------------- > Whenever the network changes the Valid Lifetime of an existing address by > more than 3s, for example, by sending a Prefix Information Option (PIO) > [RFC4861] with a new Valid Lifetime, the client calculates a new > AddrRegRefreshInterval. > > --- > > * The 3s tolerance ensures that the client will not refresh or reschedule > refreshes if the Valid Lifetime experiences minor changes due to > transmission delays or clock skew between the client and the router(s) > sending the RA. > > Notes > ----- > Replace 1% tolerance with 3s tolerance. > > Rationale: As the remaining lifetime approaches zero, the 1% tolerance > also approaches zero which can trigger redundant address refreshes. This > problem is exacerbated by potential integer rounding, where 1% of 99s cou= ld > be rounded down to 0s. Android's implementation of this mechanism uses a = 3s > tolerance instead. Since both clock skew and transmission delays are > independent from the address lifetime, using a static tolerance is more > consistent and still follows the original intent of this mechanism. > > Instructions: > ------------- > This erratum is currently posted as "Reported". (If it is spam, it will b= e > removed shortly by the RFC Production Center.) Please use "Reply All" to > discuss whether it should be verified or rejected. When a decision is > reached, the verifying party will log in to change the status and edit th= e > report, if necessary. > > -------------------------------------- > RFC9686 (draft-ietf-dhc-addr-notification-13) > -------------------------------------- > Title : Registering Self-Generated IPv6 Addresses Using DHCPv6 Publicatio= n > Date : December 2024 > Author(s) : W. Kumari, S. Krishnan, R. Asati, L. Colitti, J. Linkova, S. > Jiang Category : PROPOSED STANDARD > Source : Dynamic Host Configuration > Stream : IETF > Verifying Party : IESG > > --0000000000002f3ff9064123dba9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <html><head></head><body><div><div><div class=3D""><div class=3D""><div cla= ss=3D""><div class=3D"">I believe=C2=A0that this errata should be rejected,= or=C2=A0=C2=A0hold for document update.<br></div><div class=3D""><br></div= ><div class=3D"">"Errata are meant to fix "bugs" in the spec= ification and should not be used to change what the community meant when it= approved the RFC." -=C2=A0<a href=3D"https://datatracker.ietf.org/doc= /statement-iesg-iesg-processing-of-rfc-errata-for-the-ietf-stream-20210507/= " class=3D"">https://datatracker.ietf.org/doc/statement-iesg-iesg-processin= g-of-rfc-errata-for-the-ietf-stream-20210507/</a><br></div><div class=3D"">= <br></div></div></div></div><div class=3D"">While this text could *clearly*= be improved, this was the <span class=3D"">consensus</span>=C2=A0when the = document was published, so this isn't really an Errata.<br></div><div c= lass=3D""><div class=3D""><div class=3D""><div class=3D""><br></div><div cl= ass=3D""><br></div><div class=3D"">IIRC, we did have some discussions aroun= d=C2=A0"1% or <some time>, whichever is greater" but we wer= e not able=C2=A0to get any sort of consensus=C2=A0on <some time>, and= so the consensus=C2=A0was to go with this=E2=80=A6<br></div><div class=3D"= "><br></div><div class=3D"">W<br></div><div class=3D""><br></div></div><div= class=3D"sh-signature"><div class=3D"gmail_signature"><br></div></div></di= v><div class=3D""><br></div><div class=3D"sh-quoted-content"><div class=3D"= "><div class=3D"gmail_quote"><div class=3D"">On Tue, Oct 14, 2025 at 2:22 P= M, RFC Errata System <span class=3D"" dir=3D"ltr"><<a class=3D"" href=3D= "mailto:[email protected]">[email protected]</a>></span>= wrote:<br></div><blockquote style=3D"margin:0 0 0 .8ex;border-left:1px #cc= c solid;padding-left:1ex" class=3D"gmail_quote"><div class=3D"gmail_extra">= <div class=3D"gmail_quote"><p class=3D""></p><div class=3D"">The following = errata report has been submitted for RFC9686, <br></div><div class=3D""> &q= uot;Registering Self-Generated IPv6 Addresses Using DHCPv6".<br></div>= <p></p><p class=3D""></p><div class=3D"">----------------------------------= ---- <br></div><div class=3D""> You may review the report below and at: <br= ></div><div class=3D""> <a class=3D"" href=3D"https://www.rfc-editor.org/er= rata/eid8600" rel=3D"noopener noreferrer">https:/<wbr>/<wbr>www.<wbr>rfc-ed= itor.<wbr>org/<wbr>errata/<wbr>eid8600</a><br></div><p></p><p class=3D""></= p><div class=3D"">-------------------------------------- <br></div><div cla= ss=3D""> Type: Technical <br></div><div class=3D""> Reported by: Patrick Ro= hr <<a class=3D"" href=3D"mailto:[email protected]" rel=3D"noopener noref= errer">prohr@<wbr>google.<wbr>com</a>><br></div><p></p><p class=3D"">Sec= tion: 4.6.1 <br></p><p class=3D""></p><div class=3D"">Original Text <br></d= iv><div class=3D""> ------------- <br></div><div class=3D""> Whenever the n= etwork changes the Valid Lifetime of an existing address by more than 1%, for example, by sending a Prefix Information Option (PIO) [RFC4861] with a new Valid Lifetime, the client calculates a new AddrRegRefreshInterval.<br></div><p></p><p class=3D"">--- = <br></p><p class=3D"">* The 1% tolerance ensures that the client will not = refresh or reschedule refreshes if the Valid Lifetime experiences minor changes due to transmission delays or clock skew between the client and the router(s) sending the RA. <br></p><p class=3D""></p><div cla= ss=3D"">Corrected Text <br></div><div class=3D""> -------------- <br></div>= <div class=3D""> Whenever the network changes the Valid Lifetime of an exis= ting address by more than 3s, for example, by sending a Prefix Information Option (PIO) [RFC4861] with a new Valid Lifetime, the client calculates a new AddrRegRefreshInterval.<br></div><p></p><p class=3D"">--- = <br></p><p class=3D"">* The 3s tolerance ensures that the client will not = refresh or reschedule refreshes if the Valid Lifetime experiences minor changes due to transmission delays or clock skew between the client and the router(s) sending the RA. <br></p><p class=3D""></p><div cla= ss=3D"">Notes <br></div><div class=3D""> ----- <br></div><div class=3D""> R= eplace 1% tolerance with 3s tolerance.<br></div><p></p><p class=3D"">Ration= ale: As the remaining lifetime approaches zero, the 1% tolerance also appro= aches zero which can trigger redundant address refreshes. This problem is e= xacerbated by potential integer rounding, where 1% of 99s could be rounded = down to 0s. Android's implementation of this mechanism uses a 3s tolerance instead.= Since both clock skew and transmission delays are independent from the add= ress lifetime, using a static tolerance is more consistent and still follow= s the original intent of this mechanism. <br></p><p class=3D""></p><div cla= ss=3D"">Instructions: <br></div><div class=3D""> ------------- <br></div><d= iv class=3D""> This erratum is currently posted as "Reported". (I= f it is spam, it=20 will be removed shortly by the RFC Production Center.) Please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party =20 will log in to change the status and edit the report, if necessary.<br></di= v><p></p><p class=3D""></p><div class=3D"">--------------------------------= ------ <br></div><div class=3D""> RFC9686 (draft-ietf-dhc-addr-notification= -13) <br></div><div class=3D""> -------------------------------------- <br>= </div><div class=3D""> Title : Registering Self-Generated IPv= 6 Addresses Using DHCPv6 Publication Date : December 2024 <br></div><div class=3D""> Author(s) = : W. Kumari, S. Krishnan, R. Asati, L. Colitti, J. Linkova, S. Jian= g Category : PROPOSED STANDARD <br></div><div class=3D""> Source = : Dynamic Host Configuration <br></div><div class=3D""> Stream = : IETF <br></div><div class=3D""> Verifying Party : IESG<b= r></div><p></p></div></div></blockquote></div></div></div></div><div class= =3D""><br></div></div><div></div></div></body></html> --0000000000002f3ff9064123dba9-- --===============7566958314432765341== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KZGhjd2cgbWFp bGluZyBsaXN0IC0tIGRoY3dnQGlldGYub3JnClRvIHVuc3Vic2NyaWJlIHNlbmQgYW4gZW1haWwg dG8gZGhjd2ctbGVhdmVAaWV0Zi5vcmcK --===============7566958314432765341==--