MIME-Version: 1.0 In-Reply-To: <79aa9f84c6cf3945bc2f8fe580781595@www.isc.org> X-Mailer: MIME-tools 5.505 (Entity 5.505) Content-Disposition: inline X-RT-Interface: Web References: <79aa9f84c6cf3945bc2f8fe580781595@www.isc.org> Content-Type: text/plain; charset="utf-8" Message-ID: Content-Transfer-Encoding: binary X-RT-Original-Encoding: utf-8 RT-Send-CC: X-RT-Encrypt: 0 X-RT-Sign: 0 Content-Length: 1578 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