Hi everyone,
While testing DHCPv6-PD lease timer behaviors in our lab, we stumbled upon a very interesting issue regarding how the RouterOS DHCPv6 client handles state transitions (Renew -> Rebind -> Expiration/Solicit).
We would like to share our findings and ask the community if anyone can reproduce this behavior or shed some light on whether this is a known limitation.
When an upstream DHCPv6 server provides longer lease times—where the interval between T1 -> T2 or T2 -> Valid Lifetime exceeds 10 minutes (600 seconds)—the RouterOS DHCPv6 client appears to cap the state transition waiting timers at a maximum of exactly 600 seconds (10 minutes).
Because of this 10-minute ceiling, when operating under standard long leases (e.g., 1-hour or multi-day leases), the RouterOS client prematurely triggers Rebind and Solicit packets minutes or hours earlier than the server-specified T2 and Valid Lifetime allow.
To test this cleanly, we set up two RouterBOARDs running the exact same version:
-
RouterOS Version: v7.20.8 (long-term) on both units.
-
Server (RB-A): Configured as a DHCPv6-PD Server with several lease durations.
-
Client (RB-B): Configured as a DHCPv6 Client.
-
Firewall Filter: Applied on the client to drop outgoing Renew (and Rebind) packets on UDP/547 to simulate server unresponsiveness and force the client to progress through state transitions.
-
Packet Capture: Wireshark monitoring on the link between RB-A and RB-B.
We ran test cases with four different lease durations: 20 minutes, 30 minutes, 40 minutes, and 60 minutes.
| Lease Duration | Server T1 | Server T2 | Server Valid | Observed Renew → Rebind Interval | Observed Rebind → Solicit Interval | Behavior / Result |
|---|---|---|---|---|---|---|
| 20 min (1200s) | 600s | 960s | 1200s | 360s (6 min) (Expected 360s) | 240s (4 min) (Expected 240s) | Normal (Pass) |
| 30 min (1800s) | 900s | 1440s | 1800s | 540s (9 min) (Expected 540s) | 360s (6 min) (Expected 360s) | Normal (Pass) |
| 40 min (2400s) | 1200s | 1920s | 2400s | 600s (10 min) (Expected 720s) | 600s (10 min) (Expected 480s) | Capped at 10m |
| 60 min (3600s) | 1800s | 2880s | 3600s | 600s (10 min) (Expected 1080s) | 600s (10 min) (Expected 720s) | Capped at 10m |
As shown in the table above:
- Under 10 minutes: When the interval between T1 -> T2 or T2 -> Valid Lifetime is under 600 seconds (20m and 30m tests), the client works good.
- Over 10 minutes: As soon as the interval needs to be longer than 600 seconds (40m and 60m tests), the client hits a 600-second hard cap.
-
On a 60-minute lease, Rebind is sent at 2400s (1800s + 600s) instead of 2880s (T2).
-
Solicit is sent at 3000s (2400s + 600s) instead of 3600s (Valid Lifetime).
-
Has anyone else encountered this behavior?