[Kea-users] kea DHCPv6 and clients not working

SoupNazi izaNpuoS soupnazi34 at gmail.com
Thu Nov 10 18:36:41 UTC 2016


I had my config setup incorrectly after I added option 24.  I have it setup
correctly now and option 23 and option 24 are both present in the packet.
Please note that ISC DHCP is installed on a different physical server that
I bring up at the same address for testing purposes so there will be some
differences in server mac address DUID etc. in the packets.

Also, it should be noted that I have a Linksys WRT 1900 ACS and D-Link
DIR-632 that will not function with Kea DHCP v6 also.  I'll attach server
side captures of each of those. I don't presently have a way to do client
side captures of them.  Each of these test devices function properly with
Kea DHCPv4 as well as ISCDHCP DHCPv6.

I also configured a local subnet (to cutout the relay) and plugged the
windows 10 laptop into the local network with the Kea server.  It did not
work as well.  Same error in command prompt on the windows laptop "The
parameter is incorrect".  The server and client side captures from that are
attached as well.

Attached is:

kea.conf (with passwords hidden).
ISC DHCPv6 server and client side captures (windows 10).
Kea DHCPv6 client and server side captures for the windows 10 computer with
the repaired config (including option 23).
Kea DHVPv6 server side capture for Linksys router.
Kea DHCPv6 server side capture for D-Link router.
Kea DHCPv6 server side capture NO RELAY
Kea DHCPv6 client side capture NO RELAY
kea2.conf (current configuration that I ended up with after all the
testing).

On Thu, Nov 10, 2016 at 5:27 AM, Włodzimierz Wencel <wlodek at isc.org> wrote:

> Thanks, we don't yet know why windows does not like messages from Kea.
> Yes, we could use equivalent capture from ISC-DHCP to make detailed
> comparison.
>
> Also you kea config file could be useful (your recent capture doesn't show
> option 23 in advertise message, did you change your config?).
>
> Thanks,
>
> Wlodek Wencel
>
> ISC, QA Engineer
> On 11/09/2016 03:07 PM, SoupNazi izaNpuoS wrote:
>
> Wlodek,
>
> Attached are matching capture files from server and client sides.  Would
> you like a capture from server/client side when using ISC DHCP for DHCPv6
> which functions correctly?  Anything else I can provide?
>
> On Tue, Nov 8, 2016 at 2:14 PM, Wlodek Wencel <wlodek at isc.org> wrote:
>
>> Ok, so this is not the option case. But that capture doesn't bring us
>> closer. Server still doesn't receive Request message.
>>
>> Can you produce capture on client site? We need to know if client is
>> sending Request and if so - where it's being lost.
>>
>> Wlodek Wencel
>> ISC, QA engineer
>>
>> On 11/08/2016 06:18 PM, SoupNazi izaNpuoS wrote:
>> > I set the option 24 (I had previously tried that).  I wouldn't know what
>> > to set for option 17.  It should be noted that the successful DHCPv6
>> > conversation with ISC DHCP and the windows 10 test machine does not
>> > contain options 17,24, and 39.  Attached is the updated packet capture.
>> >
>> > On Tue, Nov 8, 2016 at 11:28 AM, Wlodek Wencel <wlodek at isc.org
>> > <mailto:wlodek at isc.org>> wrote:
>> >
>> >     Hello,
>> >
>> >     thanks for reporting this issue, we will try to sort it out
>> together.
>> >
>> >     Differences between messages you pointed out should not make be
>> >     problematic and what you described in point 3 - Kea works according
>> >     to spec.
>> >
>> >     Your capture contains forwarded messages solicit and advertise,
>> normally
>> >     DHCPv6 is performing 4 message exchange. Client should send Request
>> >     after receiving Advertise (unless rapid-commit option is allowed,
>> you
>> >     have that one configured in kea BUT there is no rapid commit option
>> in
>> >     Solicit so clients should perform full 4 way message exchange).
>> >
>> >     It looks like windows client is not happy with what Advertise
>> message is
>> >     containing.
>> >
>> >     In Solicit message client is requesting two option that you dont
>> have
>> >     configured:
>> >     - option 17 - Vendor-specific Information
>> >     - option 24 - Domain Search
>> >
>> >     Maybe those options (or just one of them) are mandatory for your
>> >     clients? Can you configure them and send the results?
>> >
>> >     Thanks,
>> >     Wlodek Wencel
>> >     ISC, QA Engineer
>> >
>> >     On 11/08/2016 03:47 PM, SoupNazi izaNpuoS wrote:
>> >     > Folks,
>> >     >
>> >     > I am testing kea for DHCPv6 with three test clients.  A windows 10
>> >     > laptop, a Linksys router and a D-Link router.  All three of these
>> >     > clients can receive DHCPv6 addresses + PD (where applicable) from
>> ISC
>> >     > DHCP server.  Only the D-Link can successfully receive DHCPv6
>> from the
>> >     > kea server.
>> >     >
>> >     > DHCPv4 portion of the kea server is working fine.
>> >     >
>> >     > Version: Kea DHCPv6 server version 1.1.0 (installed from EPEL
>> repo on
>> >     > Centos 7)
>> >     >
>> >     > It should be noted that there is a Juniper SRX that is the relay
>> >     agent.
>> >     >
>> >     > I see the relay-forward and relay-reply messages on the server
>> with
>> >     > tcpdump.  I see the solicit/advertise messages on the windows 10
>> >     client
>> >     > with Wireshark.  Windows, using ipconfig /renew6 in command
>> prompt,
>> >     > shows an ultra-informative error:
>> >     >
>> >     > "An error occurred renewing interface Ethernet : The parameter is
>> >     incorrect"
>> >     >
>> >     > and windows 10 assigns no IPv6 address to the interface.  The
>> Linksys
>> >     > similarly assigns no address but I have no error to show or
>> anything.
>> >     >
>> >     > I compared the packet capture with the ISC DHCPv6 packet capture
>> and
>> >     > noticed three differences in the relay-reply:
>> >     >
>> >     > 1) option 3 (identity association for non-temporary address) was
>> >     listed
>> >     > first in the packet on the ISC DHCPv6 and was 3rd in the kea
>> packet.
>> >     >
>> >     > 2) option 3 had values of 500 and 400 for T1 and T2 respectively
>> >     in the
>> >     > Kea packet and both were 0 in the ISC DHCPv6 relay-reply packet.
>> >     >
>> >     > 3) Kea DHCPv6 packet had option 39 FQDN (requested by client) and
>> the
>> >     > ISC DHCPv6 packet contained no such option even though requested
>> >     by the
>> >     > client.
>> >     >
>> >     > I'm assuming I've missed something in the config that is
>> necessary for
>> >     > 67% of clients to work :)
>> >     >
>> >     > Here is the DHCPv6 portion of my config:
>> >     >
>> >     >         "Dhcp6": {
>> >     >
>> >     >                 "interfaces-config": {
>> >     >
>> >     >                         "interfaces": [
>> "enp4s0/2620:0:2e50:e4::226" ]
>> >     >
>> >     >                 },
>> >     >
>> >     >                 "dhcp-ddns": {
>> >     >
>> >     >                         "enable-updates": false
>> >     >
>> >     >                 },
>> >     >
>> >     >                 "lease-database": {
>> >     >
>> >     >                         "type": "mysql",
>> >     >
>> >     >                         "name": "keatest",
>> >     >
>> >     >                         "host": "localhost",
>> >     >
>> >     >                         "user": "<hidden>",
>> >     >
>> >     >                         "password": "<hidden>",
>> >     >
>> >     >                         "connect-timeout": 3
>> >     >
>> >     >                 },
>> >     >
>> >     >                 "preferred-lifetime": 600,
>> >     >
>> >     >                 "valid-lifetime": 600,
>> >     >
>> >     >                 "renew-timer": 500,
>> >     >
>> >     >                 "rebind-timer": 400,
>> >     >
>> >     >                 "option-data": [{
>> >     >
>> >     >                         "name": "dns-servers",
>> >     >
>> >     >                         "code": 23,
>> >     >
>> >     >                         "space": "dhcp6",
>> >     >
>> >     >                         "csv-format": true,
>> >     >
>> >     >                         "data": "2620:0:2e50:a::233,
>> >     2620:0:2e50:a::234"
>> >     >
>> >     >                 }],
>> >     >
>> >     >                 "subnet6": [{
>> >     >
>> >     >                         "subnet": "2620:0:2e50:e8::/64",
>> >     >
>> >     >                         "rapid-commit": true,
>> >     >
>> >     >                         "pools": [ {
>> >     >
>> >     >                                 "pool":
>> >     > "2620:0:2e50:e8::2-2620:0:2e50:e8::ffff"
>> >     >
>> >     >                         } ],
>> >     >
>> >     >                         "pd-pools": [{
>> >     >
>> >     >                                 "prefix": "2620:0:2e50:f000::",
>> >     >
>> >     >                                 "prefix-len": 52,
>> >     >
>> >     >                                 "delegated-len": 64
>> >     >
>> >     >                         }]
>> >     >
>> >     >                 }]
>> >     >
>> >     >         },
>> >     >
>> >     >
>> >     > Attached is the server side packet capture for Kea DHCPv6
>> >     server...  Any
>> >     > ideas?
>> >     >
>> >     >
>> >     > _______________________________________________
>> >     > Kea-users mailing list
>> >     > Kea-users at lists.isc.org <mailto:Kea-users at lists.isc.org>
>> >     > https://lists.isc.org/mailman/listinfo/kea-users
>> >     <https://lists.isc.org/mailman/listinfo/kea-users>
>> >     >
>> >     _______________________________________________
>> >     Kea-users mailing list
>> >     Kea-users at lists.isc.org <mailto:Kea-users at lists.isc.org>
>> >     https://lists.isc.org/mailman/listinfo/kea-users
>> >     <https://lists.isc.org/mailman/listinfo/kea-users>
>> >
>> >
>>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/kea-users/attachments/20161110/4bc01a7c/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kea.conf
Type: application/octet-stream
Size: 1799 bytes
Desc: not available
URL: <https://lists.isc.org/pipermail/kea-users/attachments/20161110/4bc01a7c/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ISCDHCP6-client-side.pcapng
Type: application/octet-stream
Size: 1120 bytes
Desc: not available
URL: <https://lists.isc.org/pipermail/kea-users/attachments/20161110/4bc01a7c/attachment-0001.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ISCDHCP6-server-side.pcap
Type: application/octet-stream
Size: 1034 bytes
Desc: not available
URL: <https://lists.isc.org/pipermail/kea-users/attachments/20161110/4bc01a7c/attachment-0002.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kea6-server-side-fixed.pcap
Type: application/octet-stream
Size: 4192 bytes
Desc: not available
URL: <https://lists.isc.org/pipermail/kea-users/attachments/20161110/4bc01a7c/attachment-0003.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kea6-client-side-fixed.pcapng
Type: application/octet-stream
Size: 3844 bytes
Desc: not available
URL: <https://lists.isc.org/pipermail/kea-users/attachments/20161110/4bc01a7c/attachment-0004.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kea6-server-side-D-LINK.pcap
Type: application/octet-stream
Size: 2194 bytes
Desc: not available
URL: <https://lists.isc.org/pipermail/kea-users/attachments/20161110/4bc01a7c/attachment-0005.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kea6-server-side-LINKSYS.pcap
Type: application/octet-stream
Size: 4713 bytes
Desc: not available
URL: <https://lists.isc.org/pipermail/kea-users/attachments/20161110/4bc01a7c/attachment-0006.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kea6-client-side-NO-RELAY.pcapng
Type: application/octet-stream
Size: 3844 bytes
Desc: not available
URL: <https://lists.isc.org/pipermail/kea-users/attachments/20161110/4bc01a7c/attachment-0007.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kea6-server-side-NO-RELAY.pcap
Type: application/octet-stream
Size: 3304 bytes
Desc: not available
URL: <https://lists.isc.org/pipermail/kea-users/attachments/20161110/4bc01a7c/attachment-0008.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kea2.conf
Type: application/octet-stream
Size: 2550 bytes
Desc: not available
URL: <https://lists.isc.org/pipermail/kea-users/attachments/20161110/4bc01a7c/attachment-0009.obj>


More information about the Kea-users mailing list