> 15 feb. 2017 kl. 17:07 skrev Tomek Mrugalski <tom...@isc.org>:
> W dniu 15.02.2017 o 15:37, Torbjörn Eklöv pisze:
>> Thanks. I get remote-id and client-id in the log now but there are more 
>> issues that prevents me from using it in production.
>> I miss this now:
> Ahhh, new requirements.
>> - leasequery
> We don't have this planned. It's not a frequently requested feature by
> any means. It's unlikely leasequery would be implemented in a near
> future, unless there are people who are willing to step up and fund its
> development.
> Also, there are now 3 types of leasequery protocols defined right now. I
> presume you're talking about the "basic" one, right?

It’t the first time for me in production now and I think I need RFC5460. Its 
quite many L3-switches with IPv6 helper and if one is rebooted all routes to PD 
prefix is lost. I think...
If its lost I can set router life time to 60 seconds and send RA every 15 
seconds as a dirty fix for the home routers with PD installed so it isn’t stop 
We don’t manage the home routers here and every subscriber is using what they 
want. This is Sweden…. :)

I’ll test the duid/remote-id trick below!


> For completeness, here are the RFCs that define them:
> 1. RFC5007 - DHCPv6 Leasequery (requestor asks about specific address or
> about specific identifier and gets one reply, works over UDP)
> 2. RFC5460 - DHCPv6 Bulk Leasequery (requestor can get many responses,
> e.g. give me all clients that connected through relay X, works over TCP)
> 3. RFC7653 - DHCPv6 Active Leasequery (requestor subscribes to the
> server, and then the server sends any lease updates as soon as they
> happen, works over TCP or TLS)
>> - lease database where I assign PD prefix depended on client-id and remote-id
> I recall similar request was discussed previously, but I reviewed my
> mail archive and can't find it. Anyway, here it is:
> Reservations are stored in a separate table, so they're not exactly the
> same as "lease database". Those can be kept in MySQL, PostgreSQL or in
> the config file. (There's also an unreviewed patch for Cassandra, but I
> would recommend against doing anything with it in production).
> For any given client, do you need both client-id and remote-id? If yes,
> that's not supported. If you can do a reservation by client-id OR
> remote-id, there is something you can try. PD can be reserved for
> client-id (use "duid" keyword). PD can also be reserved for specific
> hardware address (use "hw-address" keyword) and configure your MAC
> source to use treat content of remote-id as MAC.
> See Section 8.3
> (https://jenkins.isc.org/job/Kea_doc/guide/kea-guide.html#host-reservation-v6)
> and Section 8.9
> (https://jenkins.isc.org/job/Kea_doc/guide/kea-guide.html#mac-in-dhcpv6).
> Implementing more reservation types is one of the strong candidate
> features for upcoming 1.3. However, the decision hasn't been made yet.
> Mid to late March sees to be the timeframe to scope features for 1.3.
>> Does anyone on this list know a product that can do what I want? ISC DHCP 
>> and Dibbler don’t
> Forget about Dibbler. It was a hobby project I did over weekends, but it
> isn't maintained. I did that for 13 years, but I simply don't have time
> for that any more.
> Depending if the hw-address+mac-sources trick works for you, you may be
> missing leasequery only. Or perhaps leasequery and the reservation stuff
> if the trick doesn't cover your case. One of the things we consider for
> 1.3 is a generic reservation mechanism. You'd define an expression in a
> way similar to client classification and use values of that expression
> in your reservations.
> It seems the biggest problem here is leasequery. So how badly do you
> need it?
> Tomek

Torbjörn Eklöv | Interlan Gefle AB
Norra Kungsgatan 5, 803 20 Gävle
Växel: 026-18 50 00 | Direkt: 070-683 51 75
http://www.dnssecandipv6.se <http://www.dnssecandipv6.se/>

"Ever since I can remember I always wanted to use IPv6.
To me that was better than being president of the United States.
To use IPv6 was to own the world."

Attachment: signature.asc
Description: Message signed with OpenPGP

Kea-users mailing list

Reply via email to