Re: Immediate RENEWING STATE - RFC 2131 section 4.4.5

Been in contact with ISP and router is not spamming any longer according to the log. Also in contact with router manufacturer, have ticket, but still no good answer or reason for continuous RENEWING state and still router never goes to BOUND state on 2 out of 3.

IPv6 hardly available in Sweden unless you are under enterprise subscription. IPv6 is voluntary and the Swedish Post and Telecom Authority and the Internet foundation have long advocated “Communication Operators” *) to introduce IPv6, which still is voluntarily. That the never happens though, so Sweden is now far behind rest of Europe! Also many clients are under CGN unfortunately. Enterprise subscription is far more expensive than private. The IPv4 shortage is perhaps lucrative and a bundle with IPv6, Name Servers supporting DNSSEC, public IP and recursive records are things that creates a feature difference between subscription types, thus preventing IPv6 rollout on a larger scale. There have been talks about a broader IPv6 rollout for a while, so I am waiting.

For that reason I had “DHCP for IPv6” enabled on router until just recently and perhaps can that also be a reason why spamming has stopped?

*) Communication Operator is a layer in Sweden that provides equipment such as switches and routers into the fiber network in towns and villages and connects the ISP with the clients. Unfortunately quite few and thus poor competition => higher cost.

Från: Li HUANG <[email protected]>
Skickat: den 5 december 2023 12:46
Till: Bengt Storberg <[email protected]>
Kopia: Bernie Volz <[email protected]>; dhcwg <[email protected]>
Ämne: Re: [dhcwg] Immediate RENEWING STATE - RFC 2131 section 4.4.5

Dec. 05 2023 19:38.hk<http://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 <[email protected]<mailto:[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]<mailto:[email protected]>>
Skickat: den 19 november 2023 20:09
Till: Bengt Storberg <[email protected]<mailto:[email protected]>>
Kopia: [email protected]<mailto:[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]<mailto:[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]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/dhcwg
_______________________________________________
dhcwg mailing list
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/dhcwg

_______________________________________________
dhcwg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dhcwg