On Oct 9, 2013, at 6:02 PM, Cullen Jennings <flu...@iii.ca> wrote: > Hard coding it means you can't make your device work if you are on a network > that behind a firewall that does not allow the traffic or is on a networks > that is not part of the internet or is being set up for use in emergency > communications where the the device is on a network say in Hati that has > become partitioned from rest of network after an disaster. Obviously one can > fallback to a hard coded option if no DHCP option is found but it's pretty > important to have a chance of being able to configure things to work on > networks with less than ideal connectivity.
If this argument were correct, we'd expect to see major O.S. vendors supporting the NTP option, but we don't—instead, it's something that can be configured in the UI for situations like the one you describe, and that otherwise is defaulted to the preconfigured value, which of course can be updated when the operating system is updated. So where I would expect to see the NTP option used is in devices that don't _have_ user interfaces. Your IP phone might be such a device. I suspect the bias you have toward using a DHCP option has a lot to do with where these devices are typically installed: in corporate environments. I don't even know if I could get one to use at home, or if it would work. So in this environment, it certainly makes sense to use a DHCP option to do NTP service, as long as you are doing something to validate the NTP server so that you can't be trivially attacked by being fed false time information. A hardware RTC would help to sanity check the result received from the DHCP-provided NTP server, for example. >>> Another approach is for DHCP to provide the NTP server info. I would argue >>> that getting a FQDN of the NTP server pool is a better design for DHCP than >>> getting an IP address because this allow DNS load balancing across the pool >>> and allows the server IP to change over time and still not have client >>> failures. >> >> You'd get the same effect if the DHCP server did the lookup. I agree that >> if you want to suddenly add an NTP server and need it to be adopted in a >> time frame shorter than your typical lease time, and your DNS TTL is shorter >> than your typical lease time, you will get better service using DNS, but >> there's no clear win here—this would be a pretty weird requirement. > > I think this is the part where we disagree. I don't think you get the same > effect if the DHCP server did the lookup and returned a single IP address. I > realize you understand DNS better than me but DNS returns a lot more than a > single IP address. In the most simple case it can be returning a list of IP > so that if one server is down, the client can contact another. I don't see > how to do that with single IP returned from DHCP. (yes, I realize that some > people have requested DHCP options to return a list of IP). There's nothing to disagree about. This is in fact how it works with most DHCP servers today: you do a DHCP transaction, the DHCP server looks up the name in the DNS, stuffs whatever it gets back into the DHCP option (hence the advice in the option guidelines draft to allow more than one IP address in cases where it makes sense), and merrily sends it to the DHCP client, which, if it only wanted one address, likely picks the first, just as it would have done had it done the DNS lookup itself. It's true that it doesn't behave exactly the same as if the device repeatedly queries the same name it got from the DHCP server, rather than repeatedly using the list of IP addresses it got from the DHCP server. > But more impotently if someone wants to do something like move the server > from one data center to another, it is well understood by admins how to do > that when clients access the server by FQDN. It's much harder when it's an IP > address that has to be updated in DHCP servers. This is a really brittle use case, even if you are using DNS. Whatever TTL you are using, you will see outages for that duration. I can't think of a single case where a service you'd sensibly configure with DHCP would be moved this way, because servers of this type are typically either related to network infrastructure, or are replicable. So you don't just pick up your DNS cache and move it to a different data center, not even if it's on an SDN. Instead, you launch a new DNS cache in the new data center, and leave the old DNS cache running until the DNS TTLs or DHCP leases have had time to expire. In either case, you get the same behavior and the same outcome. > Not to mention opening up the use DNS tools like SRV and NAPTR. Right, and SRV isn't something you'd use for a service that it makes sense to configure using DHCP. Nor is NAPTR. I would argue that if it makes any sense at all for there to be a SRV record, that's a strong argument against using DHCP to configure that service. But yes, if you can find an edge case where it does make sense to use DHCP, and a SRV record would work and would be useful, then that option should deliver an FQDN, not an IP address. > >> >>> You agree that FQDN is would be a better design than IP for NTP ? >> >> No. I think the boxes that need NTP configuration via DHCP are most likely >> constrained devices, and that requiring them to do a DNS lookup in addition >> to the DHCP transaction is unnecessary. > > This is not really a constrained device issue - it has to do with hosts that > don't have an IT administrator and need to just work. They might be > constrained, but right now my house has devices doing DHCP, DNS, and HTTP all > fitting in 12 k of flash, 512 bytes of ram, and an 8 bit processor at 16Mhz > so don't think that DNS needs to be big - probably not fully standards > compliant but it works. My house also has things like NAS, WiFI GW, TVs etc > that have pretty powerful computers yet still need to turn on and just work > with no administration. Right, and at the moment they almost certainly have their NTP server FQDNs hard-coded, and it works, and you don't even know it's working this way, because it's a solid solution in a home network. The issue with DNS on constrained devices is that it's another packet round trip, and packets burn battery. And there are constrained devices where adding another network protocol means less space for what the device needs to be doing. But I tend to agree that if you can afford to put a DHCP client in a device, there's probably room for a DNS resolver as well. >> Probably not a hugely bad thing, but that depends on the device. A device >> with severe constraints probably isn't using DHCP anyway. > > Seriously ? How do you think IPv4 constrained devices get an IP address? When I say "constrained device," I really mean 6lowpan device. Remember that this document is specifically about DHCPv6. > Hmm - this is much more interesting - help me understand what part it does > not follow 3315. When it boots, it uses DHCP to find the address of a > configuration server. If it needs a configuration, it downloads that from the > configuration server. If it does not need a configuration, it does not > download it. I would not be shocked to find out that this was not following > 3315 but I think I can speak for at least most the folks doing this that they > did not know it was not consistent with 3315 and would be very interested in > hearing why. If you are using DHCP to provide the location of a configuration server, and you make a leap of faith with that server on first configuration, and never talk to it again, then you probably are in compliance with RFC3315. If you take the value of a DHCP option and retain it forever, and do not take note of the fact that it has changed, then you are out of spec. I was under the impression from reading your explanation that you were doing the latter.
