On Oct 9, 2013, at 11:49 PM, Cullen Jennings <fluffy(_at_)iii(_dot_)ca> wrote:
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.
This is great, but that's not all devices. And devices of this type often
wind up being very vulnerable to attack precisely because no usable escape
mechanism is offered. DHCP may be your only choice for configuring such a
device, but it's a really lousy choice.
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.
I challenge you to find a single commonly-used home gateway that supports this
RFC, and that is not VoIP-specific. If one does, it's hard to see any reason
why it matters whether the IP address of the E911 location service protocol is
delivered directly or through an FQDN.
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.
Commonly deployed by whom? The ISC DHCP server supported the functionality
that I'm describing in 1997. Nominum's DHCP server supported it on first
release. Cisco's server supported it back when it was still a separate
company called American Internet, at least as early as 1997. The only
commonly-used server that I think does not support this functionality is
Microsoft's. I suppose some enterprise environments might use this server,
which might explain why you are assuming that behavior, but we shouldn't decide
how to do things based on a single implementation that, if it operates in the
way you describe, is IMHO broken.
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.
Right, and I think I already said that (a) SIP is a bad example of a use case
for DHCP, because it's a node-specific service, not a network-specific service,
and (b) it's probably fine, if you must use DHCP to configure SIP, to use an
FQDN, as I already said several messages back.
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.
Well, for example, would you use SRV records to do load balancing on a DNS
server? An NTP server? A router (which in the context of DHCPv6 probably
means an AFTR)? I think you would not.
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.
SRV records are normally used for application-layer services, like SIP, which I
don't think should be configured with DHCP. Similarly, would you use DHCP to
configure the address of an HTTP server? :)
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.
Any device that has a battery and needs to run unattended for a long period of
time will pay a penalty for doing DNS queries over and over again; requiring it
to do so is a bad practice. If such a device does use DHCP, it almost
certainly wants to use very long information refresh timers. Using a short
TTL in DNS for a service used by such a device either will not work, or will
cause the device to prematurely drain its battery.
These devices are real, likely represent a very significant area of IP service
growth in the coming decade or two, and need to be supported. If such a
device uses a service discovery protocol, and that service discovery protocol
probably were to deliver information via FQDNs, the device would have to query
the DNS multiple times, at least one for each service, in order to resolve
those FQDNs, each time it does a service discovery refresh. It would also be
well advised to query those FQDNs again anytime the TTL on the record returned
in the previous query expired.
DHCP does all the queries for you at the same time and hands you a single
packet with all the information you need to contact all the services offered by
DHCP. This can be expected to result in many fewer packet round trips, and
consequently much less power spent. This is a significant feature; getting
rid of it in order to make life a little more convenient for operators who do
not have to deal with these constraints is a poor value proposition for the
protocol as a whole.
BTW, another example of a constrained device is a network booted device, where
despite the fact that the node itself is quite capable once it's booted, the
boot prom is quite constrained. I think this was a primary motivation for the
choice of address versus FQDN back in DHCPv4 days; I suspect relevant in fewer
cases now, but still relevant in some.
(I will note, by the way, that you have yet to raise a point that was not
considered and addressed by the working group. I think this discussion is
useful, because it points to clarifications that should be made to the
document, but I don't yet see anything that would suggest to me that the
consensus call went the wrong way.)