Ted, I'm trying hard to get my head around the argument you are making and obviously I am coming to the problem from a narrow point of view from the VoIP domain and I realize the WG has dealt with DHCP solutions for a wide range of solutions - but so far I'm not very convinced by this power + extra RTT when the device boots outweighs the opertational simplicity concerns of using names. I just can't think of a application or device where that extra DNS query at boot accounted for more than 0.1% of the power usage of the device. I've also received a couple private emails that I would more or less summarize as the DHCP WG is impossible on this topic, you will never convince them, just ignore the spec, it's not a MUST so just don't worry and do whatever you need to do. I really don't want to do that - if using FQDN really is the wrong choice, it sure would be nice if this draft offered a compelling argument of that. Few more comments inline…. On Oct 9, 2013, at 7:15 PM, Ted Lemon <Ted.Lemon@xxxxxxxxxxx> wrote: > On Oct 9, 2013, at 6:02 PM, Cullen Jennings <fluffy@xxxxxx> 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. Right - I am certainly more focused on the devices that don't have an administrator that can configure them locally. > > 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. Agree I am focused on the VoIP stuff but it is both SP and enterprises. > I don't even know if I could get one to use at home, or if it would work. They work in residential deployments (which might be a bit different than you mean by home) and DHCP can provide some very critical services for them. For example rfc5223 is a DHCP options that provides the LOST server that provides the mapping to locations that can be used for E911 calls and is applicable to residential. > 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. Sure I believe you about what DHCP servers are capable of doing (which I will note might be different than how they are commonly deployed). I was talking about the issue here of from a protocol design point of view, one should prefer the use of an IP address or FQDN in the DHCP option for a case like this. > 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. When I said "move" I'm talking the roughly the same thing as you mean here of bring up a new service. So lets take a VoIP provider like AT&T or a large enterprise like GE. Let say that have a server called time.ge.com in DNS. Figuring out the TTL for that is pretty easy. Changing it to reduce down around the time of the move is pretty easy as you can chance it one place and DNS sync it to the other DNS servers. Now lets consider doing the same thing with DHCP. How many DHCP server do you think either of theses have? Consistent tools to manage all them from a central location? The admin know when they are moving servers they need to deal with the DNS - but do they all even remember to update the DHCP? The we have the issue of NATs that act as DHCP clients, get an option, then re-advertise that option as a DHCP server on the private side. I realize that if they advertise it for longer on the private side than the lease was valid on the public side is just really broken, but none the less I'm sure no one will be shocked to find out there are broken NATs. I've been involved with deployments bitten by every one of of the above. That make me prefer FQDN unless it is a case where DNS might not be supported or not operational, or a case where the time / power of the DNS query makes a significant difference to the system. > >> 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 thought about what you wrote here for a long time. I suspect that is part of the issue is that people such as myself that are not DHCP experts don't know what services are not appropriate to use it for. We see it as a hammer and we are off pounding nails, or screws. I view SRV as an OK way to control load balancing across a set of servers that have different capacity - often due to be deployed on faster computers over time. Why would a service with that property not be someone one would use DHCP for. > 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. tell me more - this one I did not get. > 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. Give me an example where that makes a difference. When I look at this as the power to do a DNS query amortized over the lifetime of the lease or uptime of the device I'm just having a hard time thinking of the right example to motivate this. > 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. Space always seems to be an issue on embedded device so I sort of buy that for that very narrow case but this draft is about v6 in general. > >>> 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. Given 6lowpan is a subset of even just the wireless devices and does not include the wired devices, I had a much broader view of the word "constrained" device but point well taken that this is the DHCPv6. I had sort of assume the same arguments would apply about the IP vs FQDN for v4 options. > >> 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. Sorry for my overly brief description leading to confusion.