bug in DHCPv6 option parse for on commit {} ?

[Bill Shirley]

I don't know what DHCP sends if you ask for 3600 second lease and the default is higher.
Wireshark might answer that for you.  I haven't messed with DHCPv6 for a while but at some
point I also tried:
# data: leased_lease: not available: ," Lease: ", pick-first-value(binary-to-ascii(10,32,"",encode-int(lease-time,32)), "<none>")
#       ,"  Lease:", pick-first-value(binary-to-ascii(10, 32, "", config-option dhcp6.clt-time), "<none>")
and commented them out.

Currently there are some DHCPv6 options that don't work as expected. dhcp6.fqdn is one.
The docs say it works just like fqdn.fqdn but it throws an error message.  I'm thinking
lease-time should work just like DHCPv4 but I don't think it does.

Bill

On 12/23/2016 8:54 AM, perl-list wrote:
> 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
>         dhcp-users at lists.isc.org
>         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
>
>
>
>
> _______________________________________________
> 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/382dc9af/attachment-0001.html>