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

Cullen Jennings <fluffy@iii.ca> Tue, 22 October 2013 17:56 UTC

Return-Path: <fluffy@iii.ca>
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC2A711E81ED; Tue, 22 Oct 2013 10:56:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.643
X-Spam-Level:
X-Spam-Status: No, score=-2.643 tagged_above=-999 required=5 tests=[AWL=-0.044, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 897YI583Gt3j; Tue, 22 Oct 2013 10:56:36 -0700 (PDT)
Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id 9C81411E81F5; Tue, 22 Oct 2013 10:56:35 -0700 (PDT)
Received: from [192.168.4.101] (unknown [128.107.239.234]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 0119650A88; Tue, 22 Oct 2013 13:56:30 -0400 (EDT)
Content-Type: text/plain; charset="windows-1252"
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Cullen Jennings <fluffy@iii.ca>
In-Reply-To: <96AD4029-F81B-4BC5-90EB-D232F0A95A1A@nominum.com>
Date: Tue, 22 Oct 2013 11:58:24 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <F769CC42-F242-42E6-9B40-31C875EA0156@iii.ca>
References: <20130919215457.30925.98345.idtracker@ietfa.amsl.com> <C5E08FE080ACFD4DAE31E4BDBF944EB123C933B2@xmb-aln-x02.cisco.com> <EF97C65E-A58C-4076-B737-014126786442@nominum.com> <C5E08FE080ACFD4DAE31E4BDBF944EB123C96CF3@xmb-aln-x02.cisco.com> <29DE3138-F0E6-4CCB-A8A0-AD5D975E0866@nominum.com> <F474FA9D-CDC4-4DB7-937E-1252E203749F@iii.ca> <F1C4B4FB-DD91-43E3-8A01-226237BA68CE@nominum.com> <140C3FBE-AADA-420D-ADFD-80C929AF8EC3@iii.ca> <96FD71CE-ED4F-4F43-A24A-BAC991455C56@nominum.com> <C57B9F23-F8A7-422F-BFC6-F2ABB899B03D@iii.ca> <96AD4029-F81B-4BC5-90EB-D232F0A95A1A@nominum.com>
To: Ted Lemon <Ted.Lemon@nominum.com>
X-Mailer: Apple Mail (2.1510)
X-Mailman-Approved-At: Tue, 22 Oct 2013 11:00:19 -0700
Cc: "dhcwg@ietf.org" <dhcwg@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>
Subject: Re: [dhcwg] Last Call: <draft-ietf-dhc-option-guidelines-14.txt> (Guidelines for Creating New DHCPv6 Options) to Best Current Practice
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dhcwg>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 22 Oct 2013 17:56:47 -0000

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.Lemon@nominum.com> wrote:

> On Oct 9, 2013, at 11:49 PM, Cullen Jennings <fluffy@iii.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.