Send kea-dev mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.isc.org/mailman/listinfo/kea-dev
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of kea-dev digest..."
Today's Topics:
1. Re: DHCPv6 server reaction to repeated Solicit/Requests
(Templin, Fred L)
2. Re: Building KEA on OpenBSD (Patrik Lundin)
3. Re: Building KEA on OpenBSD (Francis Dupont)
----------------------------------------------------------------------
Message: 1
Date: Tue, 8 Dec 2015 22:42:38 +0000
From: "Templin, Fred L" <[email protected]>
To: Marcin Siodelski <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [kea-dev] DHCPv6 server reaction to repeated
Solicit/Requests
Message-ID:
<2134f8430051b64f815c691a62d9831832f85...@xch-blv-504.nw.nos.boeing.com>
Content-Type: text/plain; charset="utf-8"
Hi Marcin,
I am still investigating, but I believe this is a bug in my RFC6221 Lightweight
DHCPv6 Relay Agent implementation which does keep some internal state.
I verified that the DHCPv6 solicits are going out from the client and arriving
at the LDRA, but then disappear into a black hole and are never delivered
to the kea server. This should be easy to fix, then I will verify that the kea
server does the right thing. But for now, I think we can assume that it will.
Thanks - Fred
[email protected]
> -----Original Message-----
> From: Marcin Siodelski [mailto:[email protected]]
> Sent: Monday, December 07, 2015 2:50 AM
> To: Templin, Fred L
> Cc: [email protected]
> Subject: Re: [kea-dev] DHCPv6 server reaction to repeated Solicit/Requests
>
> Fred,
>
> The behavior you have described is incorrect on the server side. When
> the client reboots and issues a Solicit the server should find existing
> binding for this client and return this binding in the Reply message
> (assuming that the lease doesn't expire and is not hijacked by another
> client). I am surprised that you observe different behavior.
>
> Can you please answer the following clarification questions:
> - What do you mean by "Kea ignores subsequent Solicit". Does it mean
> that Kea doesn't respond to Solicit, i.e. drops it?
> - What is the lease database backend you're using? Memfile - leases
> stored in the CSV file?
> - Is the client only requesting PD or also NA?
> - When the client reboots, does it use the same client identifier (DUID)
> when it issues a second Solicit?
> - Can you please provide me a traffic capture that demonstrates this
> behavior?
>
> Marcin
>
> On 02.12.2015 18:45, Templin, Fred L wrote:
> > Hi,
> >
> > I have a DHCPv6 client that frequently reboots, loses its memory,
> > comes back up,
> > and reissues a DHCPv6 PD Solicit/Request. It appears that the kea
> > server issues
> > the PD on the first Solicit/Request, but then ignores subsequent
> > Solicit/Requests
> > after each client reboot. Rebooting the kea server clears this condition.
> >
> > Is this the correct behavior per RFC3315/RFC3633? Or, should the kea
> > server
> > process each subsequent Solicit/Request as if it were a Renew?
> >
> > Thanks - Fred
> > [email protected]
> > _______________________________________________
> > kea-dev mailing list
> > [email protected]
> > https://lists.isc.org/mailman/listinfo/kea-dev
> >
------------------------------
Message: 2
Date: Tue, 8 Dec 2015 23:51:27 +0100
From: Patrik Lundin <[email protected]>
To: Marcin Siodelski <[email protected]>
Cc: [email protected]
Subject: Re: [kea-dev] Building KEA on OpenBSD
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
Hello again,
One question has surfaced: the choice of crypto library. OpenBSD has
LibreSSL (a fork of OpenSSL) in the base system, and this is picked up
and used by the configure script.
I know Kea can also use the Botan library. Do you have any preference as
to what library is being used even though both are supported?
Personally it seems nice to use the built in LibreSSL, but before
chosing a path merely based on a gut feeling it seems reasonable to ask
upstream :).
--
Patrik Lundin
------------------------------
Message: 3
Date: Wed, 09 Dec 2015 08:56:10 +0000
From: Francis Dupont <[email protected]>
To: Patrik Lundin <[email protected]>
Cc: [email protected]
Subject: Re: [kea-dev] Building KEA on OpenBSD
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
Patrik Lundin writes:
> One question has surfaced: the choice of crypto library. OpenBSD has
> LibreSSL (a fork of OpenSSL) in the base system, and this is picked up
> and used by the configure script.
=> as far as I know the Kea OpenSSL option is compatible with LibreSSL
but it is not checked by Jenkins, and not on last versions of OpenBSD
so please warn if (when?) it will be no longer the case.
> I know Kea can also use the Botan library. Do you have any preference as
> to what library is being used even though both are supported?
=> Botan is C++ when OpenSSL and LibreSSL are C so if you have
the choice Botan is better. Now most of the OpenSSL short comings
are supposed to have been removed from LibreSSL. And Kea uses only
very basic features (hash and hmac).
> Personally it seems nice to use the built in LibreSSL, but before
> chosing a path merely based on a gut feeling it seems reasonable to ask
> upstream :).
=> The OpenSSL option was added because there is no "certified" version
of Botan so it blocked Kea on some platforms. The plan is to support
both Botan and OpenSSL/LibreSSL for Kea (*).
Regards
Francis Dupont <[email protected]>
PS (*): it is possible we remove the support of obsolete OpenSSL 0.9.8
versions after Kea 1.0 release, both because these versions won't be
supported by OpenSSL after this december, and because the HMAC API
was fixed in OpenSSL >= 1.0.0 (and of course LibreSSL). As far as I know
the only impacted system should be Apple OS X where IMHO the "system"
OpenSSL should not be used anyway.
------------------------------
_______________________________________________
kea-dev mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/kea-dev
End of kea-dev Digest, Vol 21, Issue 8
**************************************
