On Oct 9, 2013, at 6:02 PM, Cullen Jennings <fluffy(_at_)iii(_dot_)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.