Report information
The Basics
Id:
35378
Status:
resolved
Estimated:
120 hours (7,200 minutes)
Worked:
72 hours (4,320 minutes)
Users:
tmark: 71.67 hours (4,300 minutes)
Left:
120 hours (7,200 minutes)
Priority:
Low/Low
Queue:

BugTracker
Version Fixed:
4.4.0 4.3.6 4.1-ESV-R15
Version Found:
4.2.5
Versions Affected:
(no value)
Versions Planned:
4.4.0, 4.3.6, 4.1-ESV-R15
Priority:
P1 High
Severity:
S2 Normal
CVSS Score:
(no value)
CVE ID:
(no value)
Component:
DHCP Server
Area:
bug

Dates
Created:Fri, 14 Feb 2014 11:30:12 -0500
Updated:Mon, 15 Jan 2018 14:56:34 -0500
Closed:Mon, 12 Jun 2017 13:57:19 -0400



This bug tracker is no longer active.

Please go to our Gitlab to submit issues (both feature requests and bug reports) for active projects maintained by Internet Systems Consortium (ISC).

Due to security and confidentiality requirements, full access is limited to the primary maintainers.

CC: marketing@isc.org
Subject: Bug Submission Form - Version dhcpd 4.2.5 - Error handling overlapping prefix6 leases with different mask lengths
Date: Fri, 14 Feb 2014 16:30:42 +0000
To: dhcp-bugs@isc.org
From: Mark Nejedlo <mark.nejedlo@tdstelecom.com>

Bug Report from www.isc.org:

  • Name: Mark Nejedlo
  • Email: mark.nejedlo@tdstelecom.com
  • Software Version: dhcpd 4.2.5
  • OS: RHEL 6.5
  • Subject:Error handling overlapping prefix6 leases with different mask lengths

Bug Detail

While testing various options for how to issue v6 leases, space which had been issueing /64 prefix delegations was changed to issue /56 delegations. This led to dhcpd attempting to issue overlapping leases.

The scenario:

The dhcp server was set up to serve "prefix6 2600:340X:YYY0:0000:: 2600:340X:YYYf:ffff:: /64" for a subnet. The next time a prefix delegation was requested, a lease was issued to the client device for 2600:340X:YYYf:ffff::/64.

Later we decided that we wanted to be able to issue both /56 and /64 leases, so 2600:340X:YYY0::/44 was split in to two prefix statements: "prefix6 2600:340X:YYY0:0000:: 2600:340X:YYY7:ffff:: /64" and "prefix6 2600:340X:YYY8:0000:: 2600:340X:YYYf:ff00:: /56".

So, we have a lease for a /64 in space which is now allocated to /56 assignments. I expected dhcpd to decline the next renewal and issue a new /64 lease out of 2600:340X:YYY0::/45, but instead it continued allowing 2600:340X:YYYf:ffff::/64.

The problem occurred later (after multiple max-lease-time had passed) when a /56 was requested. Despite the existing valid lease for 2600:340X:YYYf:ffff::/64, a lease was issued for 2600:340X:YYYf:ff00::/56, which the router promptly refused due to the new /56 delegation conflicting with the old, but valid, /64 delegation.

I'm currently running 4.2.5. I see that 4.2.6 and 4.3.0 came out earlier this month, but I have not yet upgraded. I don't see anything in the release notes to make me believe this issue (or anything related to prefix6) has been addressed.

---

This email was received through isc.org Bug Submission Form

All information within this email is considered confidential and for internal use only.


Hello Mark: You'll be pleased to learn that we've corrected your issue in our upcoming releases 4.4.0 (date is TBD) and 4.3.6/4.1-ESV-R15 due out July 31st, 2017. Sorry it took us awhile but our resources are limited and we work on what we can as we can. The were two issues. The first was in lease file parsing, which did not check for matching prefix lengths between pools and leases. This meant that a lease was considered valid so long as its address could be matched to pool. Now the server requires that the prefix lengths of the lease and pool be equal, otherwise it will log the issue and discard the lease. The second issue was in processing prefix delegations received from the client via IA_PD suboptions. While we were enforcing the requested length and pool length match, we were internally treating mismatches as an error rather than as an "out-of-range" condition and not taking the appropriate action. The server will now treat these as it would out-of-range hints from the client for address leases (IA_NA or IA_TA). In the case of SOLICITs and REQUESTs it will attempt to offer what it can based on configuration (basically it will ignore the hint). For RENEWs it will return a status of No Binding, and for REBINDS it will return the lease with lifetimes set to zero. We'd like to thank you for your submission by citing you in our release notes. If you'd like to recognized in this manner please respond with how you wish to be identified. Typically it is by name and/or organization. Sincerely, Thomas Markwalder ISC Software Engineering
Subject: RE: [ISC-Bugs #35378] Version dhcpd 4.2.5 - Error handling overlapping prefix6 leases with different mask lengths [protocol] [dhcpv6] [server]
Date: Mon, 12 Jun 2017 16:54:06 +0000
To: "dhcp-review@isc.org" <dhcp-review@isc.org>
From: "Nejedlo, Mark" <Mark.Nejedlo@tdstelecom.com>
Mark Nejedlo at TDS Telecom Thanks, Mark -----Original Message----- From: Thomas Markwalder via RT [mailto:dhcp-review@isc.org] Sent: Monday, June 12, 2017 11:05 AM To: Nejedlo, Mark Subject: [ISC-Bugs #35378] Version dhcpd 4.2.5 - Error handling overlapping prefix6 leases with different mask lengths [protocol] [dhcpv6] [server] Hello Mark: You'll be pleased to learn that we've corrected your issue in our upcoming releases 4.4.0 (date is TBD) and 4.3.6/4.1-ESV-R15 due out July 31st, 2017. Sorry it took us awhile but our resources are limited and we work on what we can as we can. The were two issues. The first was in lease file parsing, which did not check for matching prefix lengths between pools and leases. This meant that a lease was considered valid so long as its address could be matched to pool. Now the server requires that the prefix lengths of the lease and pool be equal, otherwise it will log the issue and discard the lease. The second issue was in processing prefix delegations received from the client via IA_PD suboptions. While we were enforcing the requested length and pool length match, we were internally treating mismatches as an error rather than as an "out-of-range" condition and not taking the appropriate action. The server will now treat these as it would out-of-range hints from the client for address leases (IA_NA or IA_TA). In the case of SOLICITs and REQUESTs it will attempt to offer what it can based on configuration (basically it will ignore the hint). For RENEWs it will return a status of No Binding, and for REBINDS it will return the lease with lifetimes set to zero. We'd like to thank you for your submission by citing you in our release notes. If you'd like to recognized in this manner please respond with how you wish to be identified. Typically it is by name and/or organization. Sincerely, Thomas Markwalder ISC Software Engineering