bug in DHCPv6 option parse for on commit {} ?

[perl-list]

Bill, 

Thank you for the response. 

That wouldn't necessarily give you the actual lease time, however, would it? It seems like it would give you the setting that you have in the pool6 {} statement. 

For example, if the client asked for a 3600 second lease but the server was configured for 28800 second lease, the server would give the client the 3600 second lease right? At least that was how it worked in IPv4/DHCPv4. So then you would log that the lease was 28800 when it was actually 3600 yes? Or is the server the absolute authority on lease times in DHCPv6? 

> From: "Bill Shirley" <bill at c3po.polymerindustries.biz>
> To: dhcp-users at lists.isc.org
> Sent: Thursday, December 22, 2016 11:42:25 PM
> Subject: Re: bug in DHCPv6 option parse for on commit {} ?

> I use (IPv6):
> log (
> info,
> concat (
> " Lease:", pick-first-value(binary-to-ascii(10, 32, "", config-option
> server.default-lease-time), "<none>")
> .
> .

> Bill

> On 12/22/2016 10:41 AM, perl-list wrote:

>> having something like this in the dhcpd.conf file for DHCPv6:

>> on commit {

>> if exists dhcp6.ia-na {

>> log(debug,

>> concat( "LEASED,",

>> "IPTIME,",binary-to-ascii(10, 32, "", substring(option dhcp6.ia-na,36,4)),","

>> )

>> );

>> }
>> }

>> Will produce a value for IPTIME that is equal to the time requested by the
>> client instead of what was given by the server.

>> For example:

>> Client (Redhat Enterprise Linux 7 - ISC DHCP 4.2.5) sends a Renew for an IPv6
>> address via DHCPv6 requesting the following times (As seen in wireshark
>> capture):

>> T1: 3600
>> T2: 5400
>> Preferred Lifetime: 7200
>> Valid Lifetime: 7500

>> Server (generic Linux - ISC DHCP 4.3.3) is configured with this time setting in
>> the pool6 {} statement:

>> default-lease-time 600;

>> Server responds with times like this (as seen in wireshark capture):

>> T1: 0
>> T2: 0
>> Preferred Lifetime: 375
>> Valid Lifetime: 600

>> What is logged in the log file is 7500 not 600.

>> The client lease file shows the following times:

>> Renew: 0
>> Rebind: 0
>> Preferred Lifetime: 375
>> Valid Lifetime: 600

>> So, it seems that the dhcp options available in on commit {} are what the client
>> sent in instead of those the server sent in response? Is that a bug? Or do I
>> not understand how on commit {} works? I assumed that on commit {} would have
>> access to the options as set by the server that were sent back to the client.

>> _______________________________________________
>> dhcp-users mailing list [ mailto:dhcp-users at lists.isc.org |
>> dhcp-users at lists.isc.org ] [ https://lists.isc.org/mailman/listinfo/dhcp-users
>> | https://lists.isc.org/mailman/listinfo/dhcp-users ]

> _______________________________________________
> dhcp-users mailing list
> dhcp-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/dhcp-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/dhcp-users/attachments/20161223/388c96d1/attachment.html>