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(_dot_)Lemon(_at_)nominum(_dot_)com>
wrote:
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.
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.