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 _______________________________________________ Kea-users mailing list [email protected] https://lists.isc.org/mailman/listinfo/kea-users
