Re: Immediate RENEWING STATE - RFC 2131 section 4.4.5
Li HUANG <[email protected]>
| Newsgroups | gmane.ietf.dhc |
|---|---|
| Message-ID | <CAGGiuEZi=RSMsn6ZnRPPuKAv+483=4euuMmbnxeLxKnN3c8c-w@mail.gmail.com> |
Dec. 05 2023 19:38.hk x30 There are 80% servers in 4 hours refreshing registering messages from client to DHCP by https://datatracker.ietf.org/doc/draft-ietf-dhc-addr-notification/ If Client set netsh int ipv6 1200 seconds would the server recognized end user preferring? Did that, and most of time in days , never tried in scale second. Delay or in multiple dhcpv6 most likely not care the updating intervals well yet. ISP configurable to it, client not case, who can audit such tardy loose by ISP(s)? On Tue, Nov 21, 2023, 02:54 Bengt Storberg <bengt= [email protected]> wrote: > Hi Bernie > > > > Firmware is latest patch from 1 Aug 2023. Will contact manufacturer about > logging or CLI command, to see dhcp interactions. ISP prolonged lease from > 20 minutes to 6 hours after my contact. Still in RENEWING at all times, > while same type router (1 out of 3) with other ISP/ net owner and 12 hour > lease is BOUND for hours. I suspect “required” option missing in message > from server most likely. This since states are working correctly on one > router. 3 different ISP, but PE-routers that broadcast to client CE-router > in last hop are likely from the same net owner for 2 out of 3 sites, could > be a common error in broadcast from their equipment? Will take some time to > investigate! > > > > Thanks / Bengt > > > > *Från:* Bernie Volz <[email protected]> > *Skickat:* den 19 november 2023 20:09 > *Till:* Bengt Storberg <[email protected]> > *Kopia:* [email protected] > *Ämne:* Re: [dhcwg] Immediate RENEWING STATE - RFC 2131 section 4.4.5 > > > > There’s nothing wrong with a 1200 second (20 minutes) lease time. Renewals > should occur every 10 minutes (assuming default of 0.5 for t1 factor). > > > > Server’s can send a renew-time option (58) to specify a different time > than the default (of 1/2 the lease time). > > > > Likely you would need to get traces or logs of the dhcp interaction to see > what might be triggering the more frequent renewals (if client is doing > more often than every 10 minutes). > > > > I’d also confirm the software/firmware version of the router to assure all > are running the same (and latest). > > > > Reasons why a client renews frequently (constantly) are: > > - very short lease time (not in this case?) > > - option 58 specifies a short t1 (renew) interval > > - “required” option missing so client retries by requesting again > > - bad software/firmware (i.e, bug) > > - Bernie > > > > On Nov 19, 2023, at 1:44 PM, Bengt Storberg < > [email protected]> wrote: > > > > Dear DHC Working Group! > > > > (RFC 2131) > > > > For a short while we lost public IP-address and got CG-NAT and was then in > contact with the ISP to correct this matter. The problem was solved but the > support center complained about weird behavior from the (client) router, > almost spamming as they said. We have 3 routers of the same type on 3 sites > and with 3 different ISP’s. > > > > I decided to dig in to this to understand what they mean. They are all 3 > on DHCP on the WAN port with public IP tied to MAC-Address, but the lease > time differs by the ISP. Two clients have 1200 seconds while the third has > 43200 seconds. According to ISP is the server capable to reply a > DHCPREQUEST within 30 seconds. I questioned if it is best practice to have > a 1200 second lease and suggested 12 hours instead. I heard two arguments > over the years for 20 minutes. 1) The customer don’t have patience for > problems to be solved for longer times. 2) If customers connects the WAN > patch cable to the LAN port and the DHCP is handing out 6+ network > addresses, it shall be corrected fast. > > > > Repeated checking of the router show that routers with 1200 second lease > never enters BOUND STATE, while the 43200 second router is in BOUND for > several hours. The 1200 second routers constantly show RENEWING state for > repeated checking several time a minute and likely sends the DHCPREQUEST > immediately. The server seems not to answer immediately though and likely > replies somewhat earlier than T1. > > > > In accordance with RFC 2131 section 4.4.5 and paragraph seven “A client > MAY choose to renew or extend its lease prior to T1”. > > > > In my mind, right away is a rather substantial over-interpretation. A more > strict writing is suggested! > > > > What is your opinion on this? > > > > BR / Bengt Storberg > > > > <image001.png> > > > > <image002.png> > > > > _______________________________________________ > dhcwg mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dhcwg > > _______________________________________________ > dhcwg mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dhcwg > _______________________________________________ dhcwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/dhcwg