Ted, one of the hallmarks of a successful protocol is people use it for things
it's designers think are an awful idea and it ends up working fairly well for
them. I think the heart of the issue here is that you don't believe that DHCP
should be used to configure application-layer services, like SIP. I disagree -
I think the text in the draft about when to use this is about right
It is necessary to evaluate whether it is
reasonable for this parameter to be under the control of the
administrator of whatever network a client is attached to at any
given time
Furthermore, I don't understand what definition of an application layer service
you have. Are these application layer services DNS? NTP? SIP?
I've build small battery powered sensors that use DHCP, DNS and reports
environmental measurements periodically to a server and have a very good handle
on the power usage of these devices. I've done ones that use ethernet and
802.15.4, (and also ones that don't use DNS or DHCp but run over satellite
links). On those networks, I have concrete measurements that indicate for that
system you are wrong about DNS making a significant difference to battery life.
I realize there might be other applications where it does make a difference but
so I'm having a hard time imagine such an system. The reason why is simple, the
bulk of traffic a sensor sends over a 30 day period is mostly sensor data not
DHCP or DNS.
On the flip side, for SIP phones we have seen that the level of indirection
form DNS really helps make the operational issues easier.
I think the draft should not say that IPs are preferred over FQDNs. I think it
should say the choice of IP or FQDNs depends on the applications and factors
that should be considered are size, power, extra RTT, if a DNS stack is
available, code size, and so on. But also point out some of the operational
management advantages of DNS.
Really we are talking about if you have a parameter in some new protocol X to
control, this BCP is taking the opinion that it knows more about protocol X
than the protocol X WG and that it thinks the parameter should be an IP not
FQDN. I think this is wrong, DHCP should deal with how transport the
configuration parameter that protocol X needs and if that is an IP or FQDN is
probably a choice best left to experts of protocol X. Heck, I'll go a scope
further, I think it is not in charter of the DHC working to determine if IP or
FQDN are best to configure a parameter in some future protocol done by some
other WG.
bit more inline …
On Oct 10, 2013, at 9:41 AM, Ted Lemon <Ted(_dot_)Lemon(_at_)nominum(_dot_)com>
wrote:
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.
Louse choice? What exactly would you propose that would work better ?
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.
There are large SPs in some countries that rolled this out across the NATs they
provide customers. But this argument seems way off the topic of one should
prefer use of IP addresses over FQDNs
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.
You are off in the weeds here - I never disagreed that there were not DHCP
servers that implemented this.
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.
Sure, and why does that same argument not hold for configuring similar services
which is what I complained about in the draft.
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.
Look, I am not arguing that one should not us IP address in some cases. I'm
arguing that there are equally good cases where one should use FQDN. I realize
they are not popular with the layer 2/3 folks but they are very popular with
the application layer folks because of the flexibility and easy of managment
they provide.
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? :)
This seems to be the heart of it. You don't think this should be used for
application layer services but I don't think that ship sailed long long ago.
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.
Once again, please give me an example where the ext ran DNS traffic from the
device forms any relevant percentage of the traffic and/or power usage.
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.
The refresh on DNS TTL is same as refresh on DHCP lease time
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.
Again, that's a fine argument why BOOTP should use IP, however it is not an
argument about why nothing else should use FQDN
(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.)
Well, why don't you come over to RAI and do a presentation on why we should not
use FQDN in DHCP and see what the consensus is over there. I'm sure the ADs
could arrange some agenda time in the dispatch meeting which is closest things
that RAI has to an area meeting at IETF 88. The consensus of a particular WG
does not necessarily represent the consensus of the IETF.