Re: [dhcwg] Last Call: <draft-ietf-dhc-option-guidelines-14.txt> (Guidelines for Creating New DHCPv6 Options) to Best Current Practice

[Ted Lemon <[e-mail]>]

On Oct 9, 2013, at 11:49 PM, Cullen Jennings <[e-mail]> 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.)