[Kea-users] "filename" vs "option bootfile-name"

[Tomek Mrugalski]

On 10.07.2016 17:50, Patrik Lundin wrote:
> There is one thing that confuses me: If the "file" field in the DHCP
> header is considered deprecated on favor of option 67, why does kea
> support the "next-server" option for setting siaddr? Shouldnt it depend
> on option 66 (TFTP server name) instead?
Hi,
Getting back from IETF and digging through my depressingly large pile of
mails.

Here's a bit of history behind this logic. I presume the code you're
referring to is Dhcpv4Srv::vendorClassSpecificProcessing, right? This is
a result of a demo we did couple years back during IETF in Vancouver.
The demo consisted of several cable modems being configured by Kea. It
involved a lot of trial and error to get those modems up and running. In
general, this kind of processing should be a hook lib that is loaded
only when needed (i.e. when running Kea in cable network). The general
conclusion we got from this experience was that some cable modems are
very picky and there's no viable way to fix their code. Therefore we
came with a conclusion that the server be as flexible with its
configuration as possible, even if some configuration knobs seem
redundant or unnecessary.

As for your specific proposal to use tftp-server-name instead, the
answer is no. tftp-server-name specifies name of the server, not its
address. In theory we could develop a mechanism to do the server-side
resolution and then use whatever came back from the DNS server, but that
would be against the intended way those options were designed. I'm not
sure what the original rationale was to use name, rather than an
address, but I was involved in similar discussions for DS-Lite option
for DHCPv6. There were several arguments in favor of FQDN (or name in
general) compared to IP address. Some clients could resolve the name and
if it resolves to more than one address, those will be tried in order.
Also, depending on the location of the client, the name could
potentially resolve to a different IP and some people claim that it
simplifies configuration management. There may be other reasons as well.

BTW at that time we were doing the Vancouver demo the hook API was not
as mature as it is today, so the code ended up on master instead of in a
proper hook lib. Anyway, the cable modem specific code will disappear
from master and will end up in a dedicated hook library. When we start
touching the code, there will be many improvements done in that area.
When this will happen I do not know, though. It depends heavily on how
much interest in such a hook library there is among users, prospective
and current customers.

Hope that explanation helps a bit.
Tomek