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

Patrik Lundin patrik at sigterm.se
Tue Sep 6 15:38:00 UTC 2016


On Mon, Jul 25, 2016 at 02:39:05PM +0200, Tomek Mrugalski wrote:
> 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.

I forgot to reply to this email, thanks for sharing background
information!

-- 
Patrik Lundin



More information about the Kea-users mailing list