[dhcwg] Re: [Technical Errata Reported] RFC9686 (8600 )
"Eric Vyncke \(evyncke\)" <[email protected]> Wed, 15 Oct 2025 09:06:19 +0000
| Newsgroups | gmane.ietf.dhc |
|---|---|
| Message-ID | <PH0PR11MB4966CB7460B567D290677C05A9E8A@PH0PR11MB4966.namprd11.prod.outlook.com> |
--===============6449588399874815111== Content-Language: en-GB Content-Type: multipart/alternative; boundary="_000_PH0PR11MB4966CB7460B567D290677C05A9E8APH0PR11MB4966namp_" --_000_PH0PR11MB4966CB7460B567D290677C05A9E8APH0PR11MB4966namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Thanks all for the replies and comments (as well as reporting the erratum, = Patrick). I will mark it as =91hold for document update=92 because it cannot be accep= ted per the RFC Editor policy (like written below by Warren), but this is a= lso an interesting suggestion. Regards -=E9ric From: Warren Kumari <[email protected]> Date: Tuesday, 14 October 2025 at 22:02 To: RFC Errata System <[email protected]> Cc: [email protected] <[email protected]>, rajiv.asati@gmai= l.com <[email protected]>, [email protected] <[email protected]>, fur= [email protected] <[email protected]>, [email protected] <shengjiang@bupt= .edu.cn>, [email protected] <[email protected]>, Eric Vyncke (evyncke) <evy= [email protected]>, [email protected] <[email protected]>, [email protected] <bevolz@= gmail.com>, [email protected] <[email protected]>, [email protected] <dhcwg@ietf= .org> Subject: Re: [Technical Errata Reported] RFC9686 (8600) 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://da= tatracker.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 th= e 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=85 W On Tue, Oct 14, 2025 at 2:22 PM, RFC Errata System <[email protected]= rg<mailto:[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]<mailto:[email protected]>> Section: 4.6.1 Original Text ------------- 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. --- * 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. Corrected Text -------------- 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. --- * 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. 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 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 tole= rance instead. Since both clock skew and transmission delays are independen= t from the address lifetime, using a static tolerance is more consistent an= d still follows the original intent of this mechanism. Instructions: ------------- This erratum is currently posted as "Reported". (If it is spam, it will be = removed shortly by the RFC Production Center.) Please use "Reply All" to di= scuss 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. -------------------------------------- RFC9686 (draft-ietf-dhc-addr-notification-13) -------------------------------------- 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 Stream : IETF Verifying Party : IESG --_000_PH0PR11MB4966CB7460B567D290677C05A9E8APH0PR11MB4966namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable <html xmlns:o=3D"urn:schemas-microsoft-com:office:office" xmlns:w=3D"urn:sc= hemas-microsoft-com:office:word" xmlns:m=3D"http://schemas.microsoft.com/of= fice/2004/12/omml" xmlns=3D"http://www.w3.org/TR/REC-html40"> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3DWindows-1= 252"> <meta name=3D"Generator" content=3D"Microsoft Word 15 (filtered medium)"> <style><!-- /* Font Definitions */ @font-face {font-family:"Cambria Math"; panose-1:2 4 5 3 5 4 6 3 2 4;} @font-face {font-family:Aptos; panose-1:2 11 0 4 2 2 2 2 2 4;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0cm; font-size:12.0pt; font-family:"Aptos",sans-serif;} a:link, span.MsoHyperlink {mso-style-priority:99; color:blue; text-decoration:underline;} span.EmailStyle19 {mso-style-type:personal-reply; font-family:"Aptos",sans-serif; color:windowtext;} .MsoChpDefault {mso-style-type:export-only; font-size:10.0pt; mso-ligatures:none;} @page WordSection1 {size:612.0pt 792.0pt; margin:72.0pt 72.0pt 72.0pt 72.0pt;} div.WordSection1 {page:WordSection1;} --></style> </head> <body lang=3D"en-BE" link=3D"blue" vlink=3D"purple" style=3D"word-wrap:brea= k-word"> <div class=3D"WordSection1"> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;mso-f= areast-language:EN-US">Thanks all for the replies and comments (as well as = reporting the erratum, Patrick).<o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;mso-f= areast-language:EN-US"><o:p> </o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;mso-f= areast-language:EN-US">I will mark it as =91hold for document update=92 bec= ause it cannot be accepted per the RFC Editor policy (like written below by= Warren), but this is also an interesting suggestion.<o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;mso-f= areast-language:EN-US"><o:p> </o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;mso-f= areast-language:EN-US">Regards<o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;mso-f= areast-language:EN-US"><o:p> </o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;mso-f= areast-language:EN-US">-=E9ric<o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;mso-f= areast-language:EN-US"><o:p> </o:p></span></p> <div id=3D"mail-editor-reference-message-container"> <div> <div> <div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm = 0cm 0cm"> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:0cm;margin-right:0cm;mar= gin-bottom:12.0pt;margin-left:36.0pt"> <b><span style=3D"color:black">From: </span></b><span style=3D"color:black"= >Warren Kumari <[email protected]><br> <b>Date: </b>Tuesday, 14 October 2025 at 22:02<br> <b>To: </b>RFC Errata System <[email protected]><br> <b>Cc: </b>[email protected] <[email protected]>, raj= [email protected] <[email protected]>, [email protected] <lo= [email protected]>, [email protected] <[email protected]>, shengjia= [email protected] <[email protected]>, [email protected] <[email protected]>, Eric Vyncke (evyncke) <[email protected]>= , [email protected] <[email protected]>, [email protected] <bevolz@gmail.= com>, [email protected] <[email protected]>, [email protected] <dhcw= [email protected]><br> <b>Subject: </b>Re: [Technical Errata Reported] RFC9686 (8600)<o:p></o:p></= span></p> </div> <div> <div> <div> <div> <div> <div> <p class=3D"MsoNormal" style=3D"margin-left:36.0pt">I believe that thi= s errata should be rejected, or hold for document update.<o:p></= o:p></p> </div> <div> <p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><o:p> </o:p></p> </div> <div> <p class=3D"MsoNormal" style=3D"margin-left:36.0pt">"Errata are meant = to fix "bugs" in the specification and should not be used to chan= ge what the community meant when it approved the RFC." - <a href= =3D"https://datatracker.ietf.org/doc/statement-iesg-iesg-processing-of-rfc-= errata-for-the-ietf-stream-20210507/">https://datatracker.ietf.org/doc/stat= ement-iesg-iesg-processing-of-rfc-errata-for-the-ietf-stream-20210507/</a><= o:p></o:p></p> </div> <div> <p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><o:p> </o:p></p> </div> </div> </div> </div> <div> <p class=3D"MsoNormal" style=3D"margin-left:36.0pt">While this text could *= clearly* be improved, this was the consensus when the document was pub= lished, so this isn't really an Errata.<o:p></o:p></p> </div> <div> <div> <div> <div> <p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><o:p> </o:p></p> </div> <div> <p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><o:p> </o:p></p> </div> <div> <p class=3D"MsoNormal" style=3D"margin-left:36.0pt">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 <s= ome time>, and so the consensus was to go with this=85<o:p></o:p></= p> </div> <div> <p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><o:p> </o:p></p> </div> <div> <p class=3D"MsoNormal" style=3D"margin-left:36.0pt">W<o:p></o:p></p> </div> <div> <p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><o:p> </o:p></p> </div> </div> <div> <div> <p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><o:p> </o:p></p> </div> </div> </div> <div> <p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><o:p> </o:p></p> </div> <div> <div> <div> <div> <p class=3D"MsoNormal" style=3D"margin-left:36.0pt">On Tue, Oct 14, 2025 at= 2:22 PM, RFC Errata System <<a href=3D"mailto:[email protected]= ">[email protected]</a>> wrote:<o:p></o:p></p> </div> <blockquote style=3D"border:none;border-left:solid #CCCCCC 1.0pt;padding:0c= m 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm"> <div> <div> <div> <p class=3D"MsoNormal" style=3D"margin-left:36.0pt">The following errata re= port has been submitted for RFC9686, <o:p></o:p></p> </div> <div> <p class=3D"MsoNormal" style=3D"margin-left:36.0pt">"Registering Self-= Generated IPv6 Addresses Using DHCPv6".<o:p></o:p></p> </div> <div> <p class=3D"MsoNormal" style=3D"margin-left:36.0pt">-----------------------= --------------- <o:p></o:p></p> </div> <div> <p class=3D"MsoNormal" style=3D"margin-left:36.0pt">You may review the repo= rt below and at: <o:p></o:p></p> </div> <div> <p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><a href=3D"https://www.= rfc-editor.org/errata/eid8600">https://www.rfc-editor.org/errata/eid8600</a= ><o:p></o:p></p> </div> <div> <p class=3D"MsoNormal" style=3D"margin-left:36.0pt">-----------------------= --------------- <o:p></o:p></p> </div> <div> <p class=3D"MsoNormal" style=3D"margin-left:36.0pt">Type: Technical <o:p></= o:p></p> </div> <div> <p class=3D"MsoNormal" style=3D"margin-left:36.0pt">Reported by: Patrick Ro= hr <<a href=3D"mailto:[email protected]">[email protected]</a>><o:p></o= :p></p> </div> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto;margin-left:36.0pt"> Section: 4.6.1 <o:p></o:p></p> <div> <p class=3D"MsoNormal" style=3D"margin-left:36.0pt">Original Text <o:p></o:= p></p> </div> <div> <p class=3D"MsoNormal" style=3D"margin-left:36.0pt">------------- <o:p></o:= p></p> </div> <div> <p class=3D"MsoNormal" style=3D"margin-left:36.0pt">Whenever the network ch= anges the Valid Lifetime of an existing address by more than 1%, for exampl= e, by sending a Prefix Information Option (PIO) [RFC4861] with a new Valid = Lifetime, the client calculates a new AddrRegRefreshInterval.<o:p></o:p></p> </div> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto;margin-left:36.0pt"> --- <o:p></o:p></p> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto;margin-left:36.0pt"> * 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. <o:p></o:p></p> <div> <p class=3D"MsoNormal" style=3D"margin-left:36.0pt">Corrected Text <o:p></o= :p></p> </div> <div> <p class=3D"MsoNormal" style=3D"margin-left:36.0pt">-------------- <o:p></o= :p></p> </div> <div> <p class=3D"MsoNormal" style=3D"margin-left:36.0pt">Whenever the network ch= anges the Valid Lifetime of an existing address by more than 3s, for exampl= e, by sending a Prefix Information Option (PIO) [RFC4861] with a new Valid = Lifetime, the client calculates a new AddrRegRefreshInterval.<o:p></o:p></p> </div> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto;margin-left:36.0pt"> --- <o:p></o:p></p> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto;margin-left:36.0pt"> * 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. <o:p></o:p></p> <div> <p class=3D"MsoNormal" style=3D"margin-left:36.0pt">Notes <o:p></o:p></p> </div> <div> <p class=3D"MsoNormal" style=3D"margin-left:36.0pt">----- <o:p></o:p></p> </div> <div> <p class=3D"MsoNormal" style=3D"margin-left:36.0pt">Replace 1% tolerance wi= th 3s tolerance.<o:p></o:p></p> </div> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto;margin-left:36.0pt"> 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 t= ransmission delays are independent from the address lifetime, using a stati= c tolerance is more consistent and still follows the original intent of thi= s mechanism. <o:p></o:p></p> <div> <p class=3D"MsoNormal" style=3D"margin-left:36.0pt">Instructions: <o:p></o:= p></p> </div> <div> <p class=3D"MsoNormal" style=3D"margin-left:36.0pt">------------- <o:p></o:= p></p> </div> <div> <p class=3D"MsoNormal" style=3D"margin-left:36.0pt">This erratum is current= ly posted as "Reported". (If it is spam, it will be removed short= ly by the RFC Production Center.) Please use "Reply All" to discu= ss 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.<o:p></o:p></p> </div> <div> <p class=3D"MsoNormal" style=3D"margin-left:36.0pt">-----------------------= --------------- <o:p></o:p></p> </div> <div> <p class=3D"MsoNormal" style=3D"margin-left:36.0pt">RFC9686 (draft-ietf-dhc= -addr-notification-13) <o:p></o:p></p> </div> <div> <p class=3D"MsoNormal" style=3D"margin-left:36.0pt">-----------------------= --------------- <o:p></o:p></p> </div> <div> <p class=3D"MsoNormal" style=3D"margin-left:36.0pt">Title : Registering Sel= f-Generated IPv6 Addresses Using DHCPv6 Publication Date : December 2024 <o:p></o:p></p> </div> <div> <p class=3D"MsoNormal" style=3D"margin-left:36.0pt">Author(s) : W. Kumari, = S. Krishnan, R. Asati, L. Colitti, J. Linkova, S. Jiang Category : PROPOSED= STANDARD <o:p></o:p></p> </div> <div> <p class=3D"MsoNormal" style=3D"margin-left:36.0pt">Source : Dynamic Host C= onfiguration <o:p></o:p></p> </div> <div> <p class=3D"MsoNormal" style=3D"margin-left:36.0pt">Stream : IETF <o:p></o:= p></p> </div> <div> <p class=3D"MsoNormal" style=3D"margin-left:36.0pt">Verifying Party : IESG<= o:p></o:p></p> </div> </div> </div> </blockquote> </div> </div> </div> </div> <div> <p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><o:p> </o:p></p> </div> </div> </div> </div> </div> </div> </div> </body> </html> --_000_PH0PR11MB4966CB7460B567D290677C05A9E8APH0PR11MB4966namp_-- --===============6449588399874815111== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KZGhjd2cgbWFp bGluZyBsaXN0IC0tIGRoY3dnQGlldGYub3JnClRvIHVuc3Vic2NyaWJlIHNlbmQgYW4gZW1haWwg dG8gZGhjd2ctbGVhdmVAaWV0Zi5vcmcK --===============6449588399874815111==--