[dhcwg] Re: [Technical Errata Reported] RFC9686 (8600 )
Warren Kumari <[email protected]> Thu, 16 Oct 2025 14:18:52 -0400
| Newsgroups | gmane.ietf.dhc |
|---|---|
| Message-ID | <CAHw9_iK0BvLGPOfvOA2Du_koFcLJBVp8RoBhofd8JfFJtpEtAA@mail.gmail.com> |
--===============5958830246209234329== Content-Type: multipart/alternative; boundary="00000000000046862606414aa6b9" --00000000000046862606414aa6b9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Oct 14, 2025 at 4:48 PM, Patrick Rohr <[email protected]> wrote: > I guess I more so wanted to point out the flaw in the prescribed mechanis= m > that was discovered during implementation, as I am sure others will > encounter the same problem. > Yup, I agree that it's an issue, and Eric's "Hold For Document Update" works for this - there is a red "Errata" blob on the document, and so people will hopefully see this. Thank you for noting it! W The quoted text is inside a SHOULD section, so maybe it doesn't need to be > updated at all. > > On Tue, Oct 14, 2025 at 1:01=E2=80=AFPM Warren Kumari <[email protected]>= wrote: > > 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-errata-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 i= s > 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 <rfc-editor@rfc-editor= . > org> 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 : Dynam= ic > Host Configuration > Stream : IETF > Verifying Party : IESG > > --00000000000046862606414aa6b9 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""><br></div></div><br><div class=3D"sh-signature"><di= v class=3D"gmail_signature"><br></div></div></div><br><div class=3D"sh-quot= ed-content"><div class=3D""><div class=3D"gmail_quote">On Tue, Oct 14, 2025= at 4:48 PM, Patrick Rohr <span dir=3D"ltr" class=3D""><<a href=3D"mailt= o:[email protected]" target=3D"_blank" class=3D"">[email protected]</a>></= span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8e= x;border-left:1px #ccc solid;padding-left:1ex"><div class=3D"gmail_extra"><= div class=3D"gmail_quote"><p class=3D"">I guess I more so wanted to point o= ut the flaw in the prescribed mechanism that was discovered during implementation, as I am sure others will encounter the same problem. <br></p></div></div></blockquote></= div></div></div></div><div><div><br></div><div>Yup, I agree that it's a= n issue, and Eric's "Hold For Document Update" works for this= - there is a red "Errata" blob on the document, and so people wi= ll hopefully see this.=C2=A0<br></div><div><br></div><div>Thank you for not= ing it!<br></div><div>W</div><div><br></div><div><br></div><div><br></div><= /div><div class=3D""><div class=3D"sh-quoted-content"><div class=3D""><div = class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0= 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class=3D"gmail_ex= tra"><div class=3D"gmail_quote"><p class=3D"">The quoted text is inside a SHOULD section, so maybe it doesn't need to be updated at all. <br></p><p class=3D""> On Tue, Oct 14, 2025 at 1:01=E2=80=AFPM Warren Kumari <<a target=3D"_bla= nk" rel=3D"noopener noreferrer" href=3D"mailto:[email protected]" class=3D"= ">warren@<wbr>kumari.<wbr>net</a>> wrote: <br></p><blockquote class=3D""><p class=3D""> I believe that this errata should be rejected, or hold for document update= . <br></p><p class=3D""> "Errata are meant to fix "bugs" in the specification and sho= uld not be used to change what the community meant when it approved the RFC= ." - <a target=3D"_blank" rel=3D"noopener noreferrer" href=3D"https://= datatracker.ietf.org/doc/statement-iesg-iesg-processing-of-rfc-errata-for-t= he-ietf-stream-20210507/" class=3D"">https:/<wbr>/<wbr>datatracker.<wbr>iet= f.<wbr>org/<wbr>doc/<wbr>statement-iesg-iesg-processing-of-rfc-errata-for-t= he-ietf-stream-20210507/<wbr></a> <br></p><p class=3D""> While this text could *clearly* be improved, this was the consensus when th= e document was published, so this isn't really an Errata. <br></p><p class=3D""> IIRC, we did have some discussions around "1% or <some time>, wh= ichever 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 <br></p><p class=3D""> W <br></p><p class=3D""> On Tue, Oct 14, 2025 at 2:22 PM, RFC Errata System <<a target=3D"_blank"= rel=3D"noopener noreferrer" href=3D"mailto:[email protected]" clas= s=3D"">rfc-editor@<wbr>rfc-editor.<wbr>org</a>> wrote: <br></p><blockquote class=3D""><p class=3D""> The following errata report has been submitted for RFC9686, <br> "Registering Self-Generated IPv6 Addresses Using DHCPv6". </p><p class=3D""> -------------------------------------- <br> You may review the report below and at: <br> <a target=3D"_blank" rel=3D"noopener noreferrer" href=3D"https://www.rfc-ed= itor.org/errata/eid8600" class=3D"">https:/<wbr>/<wbr>www.<wbr>rfc-editor.<= wbr>org/<wbr>errata/<wbr>eid8600</a> </p><p class=3D""> -------------------------------------- <br> Type: Technical <br> Reported by: Patrick Rohr <<a target=3D"_blank" rel=3D"noopener noreferr= er" href=3D"mailto:[email protected]" class=3D"">prohr@<wbr>google.<wbr>com<= /a>> </p><p class=3D""> Section: 4.6.1 <br></p><p class=3D""> Original Text <br> ------------- <br> Whenever the network changes the Valid Lifetime of an existing address by m= ore than 1%, for example, by sending a Prefix Information Option (PIO) [RFC= 4861] with a new Valid Lifetime, the client calculates a new AddrRegRefresh= Interval. </p><p class=3D""> --- <br></p><p class=3D""> * The 1% tolerance ensures that the client will not refresh or reschedule r= efreshes if the Valid Lifetime experiences minor changes due to transmissio= n delays or clock skew between the client and the router(s) sending the RA. <br></p><p class=3D""> Corrected Text <br> -------------- <br> Whenever the network changes the Valid Lifetime of an existing address by m= ore than 3s, for example, by sending a Prefix Information Option (PIO) [RFC= 4861] with a new Valid Lifetime, the client calculates a new AddrRegRefresh= Interval. </p><p class=3D""> --- <br></p><p class=3D""> * The 3s tolerance ensures that the client will not refresh or reschedule r= efreshes if the Valid Lifetime experiences minor changes due to transmissio= n delays or clock skew between the client and the router(s) sending the RA. <br></p><p class=3D""> Notes <br> ----- <br> Replace 1% tolerance with 3s tolerance. </p><p class=3D""> Rationale: As the remaining lifetime approaches zero, the 1% tolerance also= approaches zero which can trigger redundant address refreshes. This proble= m is exacerbated by potential integer rounding, where 1% of 99s could be ro= unded down to 0s. Android's implementation of this mechanism uses a 3s = tolerance instead. Since both clock skew and transmission delays are indepe= ndent from the address lifetime, using a static tolerance is more consisten= t and still follows the original intent of this mechanism. <br></p><p class=3D""> Instructions: <br> ------------- <br> This erratum is currently posted as "Reported". (If it is spam, i= t will be removed shortly by the RFC Production Center.) Please use "R= eply 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 the report, if necessary. </p><p class=3D""> -------------------------------------- <br> RFC9686 (draft-ietf-dhc-addr-notification-13) <br> -------------------------------------- <br> Title : Registering Self-Generated IPv6 Addresses Using DHCPv6 Publication = Date : December 2024 Author(s) : W. Kumari, S. Krishnan, R. Asati, L. Colitti, J. Linkova, S. Ji= ang Category : PROPOSED STANDARD Source : Dynamic Host Configuration <br> Stream : IETF <br> Verifying Party : IESG</p></blockquote></blockquote></div></div></blockquot= e></div></div></div></div><div><br></div></div><div></div></div></body></ht= ml> --00000000000046862606414aa6b9-- --===============5958830246209234329== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KZGhjd2cgbWFp bGluZyBsaXN0IC0tIGRoY3dnQGlldGYub3JnClRvIHVuc3Vic2NyaWJlIHNlbmQgYW4gZW1haWwg dG8gZGhjd2ctbGVhdmVAaWV0Zi5vcmcK --===============5958830246209234329==--