[kea-dev] DHCPv6 server reaction to repeated Solicit/Requests

Templin, Fred L Fred.L.Templin at boeing.com
Tue Dec 8 22:42:38 UTC 2015

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
fred.l.templin at boeing.com

> -----Original Message-----
> From: Marcin Siodelski [mailto:marcin at isc.org]
> Sent: Monday, December 07, 2015 2:50 AM
> To: Templin, Fred L
> Cc: kea-dev at lists.isc.org
> 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
> > fred.l.templin at boeing.com
> > _______________________________________________
> > kea-dev mailing list
> > kea-dev at lists.isc.org
> > https://lists.isc.org/mailman/listinfo/kea-dev
> >

More information about the kea-dev mailing list