|
|
# BOOTP support - design
|
|
|
|
|
|
We want to implement BOOTP support in 1.7. There is a business need for it. On the other hand, we don't want to scatter the code for it all around Kea, so the code can be removed. For those reasons, the preferred way to go is to implement BOOTP as an (open source) hook.
|
|
|
|
|
|
## Requirements
|
|
|
|
|
|
* need to be implemented as a core hook
|
|
|
* need to explain how to handle infinite leases (there are no lease lifetimes in BOOTP) in the BOOTP context only (vs in a generic way)
|
|
|
* need to explain how to handle 2 packet exchanges
|
|
|
* bootp does not have any options (to be confirmed)
|
|
|
* do not support private cookies (added)
|
|
|
|
|
|
## Proposal
|
|
|
|
|
|
One proposal that came up is to have a pkt4_receive hook that would insert absolute minimum necessary for the Kea engine to think it's a DHCPREQUEST (insert magic cookie, dhcp message type option) and another hook at pkt4_send that would remove those and other options being assigned.
|
|
|
|
|
|
The major benefit of this approach is that we could use host reservations, client classification and other Kea features.
|
|
|
|
|
|
Another thing to consider is that maybe we could introduce special class BOOTP, so it would be easy to understand which addresses will be assigned.
|
|
|
|
|
|
## Discussions and References
|
|
|
|
|
|
* BOOTP with options ([RFC 1497](https://tools.ietf.org/html/rfc1497), magic cookie + options that are named vendor extensions) or without options ([RFC951](https://tools.ietf.org/html/rfc951))?
|
|
|
* Truncate too large responses (vs ignore vs peel extra options)?
|
|
|
* RFC 1534 explains how a DHCP server can handle BOOTP clients (close to the proposal with some extra details)
|
|
|
* RFC 2132 (post DHCP i.e. post RFC 1531) extends a bit RFC 1497 making some new options DHCP specific (so to filter out DHCP specific options on response will be easy).
|
|
|
|
|
|
## Detailed support of infinite valid lifetime
|
|
|
|
|
|
Based on the fact that 0xFFFFFFFF is not a number but a special value. Limited to BOOTP required support extended by consistency e.g. to DHCPv6.
|
|
|
|
|
|
* Add a constant
|
|
|
* Update logging to emit "infinity" including in the premium forensic hook
|
|
|
* Add support in lease database backends:
|
|
|
- CQL uses 64 bit integers so remove MAX_DB_TIME stuff
|
|
|
- fix handling in 64 bit backends
|
|
|
- make a special case of "expire = cltt + lifetime" in 32 bit backends (proposal use expire = cltt when lifetime is infinite)
|
|
|
- update get expired statements
|
|
|
- update unit tests
|
|
|
* Issue using an infinite value to compute T1 and T2 timers:
|
|
|
- simply ignore the issue
|
|
|
- add a comment explaining the issue (and no more)
|
|
|
- create a new gitlab issue
|
|
|
- refuse to take a percentage of infinite value so using absolute configured values
|
|
|
- implement "x * infinity = 0 when x = 0., infinity when x > 0."
|
|
|
* Use infinite valid lifetime for incoming DHCPv4 packets in the BOOTP client class
|
|
|
* Open question: what to do for name change request generation?
|
|
|
- simply ignore the issue
|
|
|
- add a comment explaining the issue (and no more)
|
|
|
- create a new gitlab issue
|
|
|
- cap the expire to cltt + one year
|
|
|
|
|
|
## Detailed hook behavior
|
|
|
|
|
|
Note that incoming BOOTP packets and malformed DHCP packets look the same...
|
|
|
|
|
|
* Take incoming BOOTP packets without the magic cookie at buffer4_receive: add the cookie, DHCPREQUEST message type, DHO_END. Put in BOOTP class.
|
|
|
* Take incoming BOOTP packets with the magic cookie at pkt4_receive (no message type): add DHCPREQUEST message type. Put in BOOTP class.
|
|
|
* Take response BOOTP packets (query in BOOTP class) at pk4_send: remove DHCP specific options. Open question: check overflow and remove last options (see next point)?
|
|
|
* (optional) Take response BOOTP packets (no message type) at buffer4_send. Open question: truncate overflowed responses? RFC 1532 says it is not required. |