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

From: Ted Lemon <[email-masked]>
Date: Tue, 8 Oct 2013 17:38:08 -0400

On Oct 8, 2013, at 4:30 PM, Cullen Jennings (fluffy) <[email-masked]> wrote:
> Part of why you can't do this with DHCP is that clients are written so that when an IP address fails to work for an application connection, the application re does the DNS and gets the new address (assuming TTL had been moved down during the move). Applications can not tell the  OS to redo DHCP when they fail an application level connection. 

This use case is a good example of when to use an FQDN format for a DHCP option.   However, it's not a great example of when to use a DHCP option—configuring SIP servers with DHCP is generally a bad idea, because if your device is connected to a new network, it will blindly take the SIP server IP address or FQDN information from the DHCP server and use it, and that SIP server might well perform an MitM attack or the like.

So it's only in the very restricted use case of a Cisco IP phone permanently installed on a desktop and connected to a trusted network that (a) configuring SIP via DHCP makes sense, and (b) using the FQDN is a good idea.   Of course it's possible that my limited understanding of how SIP works is preventing me from seeing why it's safe to configure SIP service using DHCP, but I'm assuming that that's not the case in this argument; please feel free to correct me.

We've actually been having this same conversation on the iesg mailing list, and I asserted that SIP was something you ought not to configure with DHCP; your use case is the one case where it sort of makes sense.   Can you think of similar use cases where it actually makes sense to configure these parameters via DHCP?

Possibly the right solution is to update the document to talk about this sort of restricted use case as one where FQDNs actually do make sense.   The document certainly doesn't say you _can't_ use FQDNs, but we see people wanting to use them a lot in cases where they really don't make sense, hence the advice.   Historically I don't think we bothered to make this distinction when defining new DHCP options, but it seems like a useful distinction to make.

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Tue, 8 Oct 2013 20:30:36 +0000

(Dear OPs ADs, please read … )

I disagree with the advice in section 8.  Cisco IP phones have been deployed with DHCP options that use FQDN and with options that use IP addresses. For this type of use case the FQDM turned out to be much better from an operational and administration point of view. IT departments are used to making sure that changes of IP addresses on servers are well coordinated with changes to the DNS - they are good at doing that and that and have good tools for it. Conversely, they are not used to coordinating server changes with DHCP changes and do not have good tools for that. Part of why you can't do this with DHCP is that clients are written so that when an IP address fails to work for an application connection, the application re does the DNS and gets the new address (assuming TTL had been moved down during the move). Applications can not tell the  OS to redo DHCP when they fail an application level connection. 

For nearly every case in the real world, the power and RTT and reliability issues are simply not relevant -   regardless of which way you do it, the application is unlikely to work if DNS is down, the extra RTT make no speed difference the user can percieve and the power difference over a day of use of the application is so small it is not measurable. 

FQDN allow usage of things like DNS SRV for load balancing, happy eye balls for v6 transition, and make it easier to get things to geographically close servers. 

I don't think it should come a a shock to anyone that the level of indirection that FQDNs provides turns out to be a really useful tool. Lets use that indirection tool where appropriate. 

Related to this, the advice in section 12 seems a bit off to me. I understand the issues - but keep in mind that many modern applications (browsers and SIP phones for example) do the DNS inside the application instead of using the OS resolvers. Part of the reason for this is asynchronous resolution but part of it is also control of which interface is used for DNS and if multiple interfaces are used, being able to keep the applications traffic on the the appropriate interface for the DNS server that returned the address. So while I agree that 

"Existing nodes cannot be assumed to systematically segregate
   configuration information on the basis of its source;"

Equally true is you can't assume the converse of that. So I think the statement that 

   As a consequence, DNS
   resolution done by the DHCP server is more likely to behave
   predictably than DNS resolution done on a multi-interface or multi-
   homed client.

Is just plain wrong. I think it would be more accurate to say in these cases the results are not always predictable. The issue is the DHCP server may get an DNS answer that contains and server that can not even be reached by the DHCP client. 

As a general rule of thumb, using FQDN in the configuration of a DHCP server is a really bad idea because IT admins assume that if they change the the DNS information, the clients will get the new information. But they don't. 

Cullen

On Sep 19, 2013, at 3:54 PM, The IESG <[email-masked]> wrote:

> 
> The IESG has received a request from the Dynamic Host Configuration WG
> (dhc) to consider the following document:
> - 'Guidelines for Creating New DHCPv6 Options'
>  <draft-ietf-dhc-option-guidelines-14.txt> as Best Current Practice
> 
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action. Please send substantive comments to the
> [email-masked] mailing lists by 2013-10-03. Exceptionally, comments may be
> sent to [email-masked] instead. In either case, please retain the
> beginning of the Subject line to allow automated sorting.
> 
> Abstract
> 
> 
>   This document provides guidance to prospective DHCPv6 Option
>   developers to help them creating option formats that are easily
>   adoptable by existing DHCPv6 software.  This document updates
>   RFC3315.
> 
> 
> 
> 
> The file can be obtained via
> http://datatracker.ietf.org/doc/draft-ietf-dhc-option-guidelines/
> 
> IESG discussion can be tracked via
> http://datatracker.ietf.org/doc/draft-ietf-dhc-option-guidelines/ballot/
> 
> 
> No IPR declarations have been submitted directly on this I-D.
> 
>

---

From: Ted Lemon <[email-masked]>
Date: Wed, 9 Oct 2013 11:47:51 -0400

On Oct 9, 2013, at 11:26 AM, Cullen Jennings (fluffy) <[email-masked]> wrote:
> Help educate me on this a bit - I don't see all the things that get requested of DHCP. What are some examples of things where people are request FQDN where IP would be better. I think having some real examples that have come up would make it easier to see what advice is needed.

DNS server IP address.   NTP server IP address.   Router IP address (not in DHCPv6, of course).   AFTR IP address.   Basically, network infrastructure IP addresses.

Bear in mind that the set of services configured by DHCP ought to be pretty small—just things that really are local network infrastructure services, not things that are specific to the host and not to the network.   It's not even clear to me that NTP ought to be configured by DHCP, and indeed in most cases it is not, despite there being an RFC describing how to do it.

Considering the case of SIP, when you configure SIP I think that's probably a configuration that shouldn't change as the phone moves from network to network.   So it shouldn't be configured by DHCP.   In the case where the phone happens not to be likely to move from network to network, you could _get away_ with using DHCP.   But a solution that would work for phones that _do_ move from network to network would also work for phones that do not, and that solution would therefore be preferable, particularly as an MTI solution, since it addresses all use cases.

As I mentioned in the IESG discussion, it is a shame that aggsrv didn't become a working group, since it was intended to address this specific problem, at least as I understood it.

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Wed, 9 Oct 2013 15:26:57 +0000

> So it's only in the very restricted use case of a Cisco IP phone permanently installed on a desktop and connected to a trusted network that (a) configuring SIP via DHCP makes sense, and (b) using t…

Nah, it's not quite like that - Long story how that it but the security mechanism make sure you authenticate both ends to stop that.

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 9 Oct 2013 11:32:57 -0600

> DNS server IP address.   NTP server IP address.   Router IP address (not in DHCPv6, of course).   AFTR IP address.   Basically, network infrastructure IP addresses.

Well DNS and Router obviously won't work with FQDN so lets talk about NTP for a minute. (and sorry, I don't even know what AFTR IP is). I design lots of devices that have to be plugged into a network and just start working with no user interaction. Getting the correct time is often really useful to have - particularly with synchronization protocols. 

One approach would be to hard code that NTP server name in the the product. That is not my preferred approach because stuff goes wrong and you end up with things like http://en.wikipedia.org/wiki/NTP_server_misuse_and_abuse . 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 agree that FQDN is would be a better design than IP for NTP ?

> Considering the case of SIP, when you configure SIP I think that's probably a configuration that shouldn't change as the phone moves from network to network.   

Agree - it does not change as phones move network to network. It is uses DHCP the first time the phone is plugged in. The whole design is around making sure the phone can go from the manufacture to the end user without ever being removed from the box or powered up be an admin. The admin configures the call control system based on knowledge about the phone and which user the phone is going to but the admin does not need to touch the phone. When the phone first boots it imprint baby duck style on a network to get the configuration information which is encrypted with that phones public key. After that the phone use that configuration information not the DHCP (unless the phone is factory reset). It's actually a lot more complicated than that because security relies on replacement of manufacture certificates with the service provider certificates to make sure a comprise of the manufactures CA only results in service provider not being able to enroll new phones but does not compromise security of operational phone network. 

However, the first time the phone boots, DHCP needs to let the phone know who the likely service provider might be. If the phone gets the wrong DHCP information from an attacker or wrong network, the phone fails to configure but does not suffer MITM attacks. Using DHCP for phones has been used by pretty much every IP phone manufactures and most enterprise deployments and many residential providers including folks ranging from vonage to AT&T take advantage of it.  DHCP greatly reduce the deployment costs of setting up VoIP networks. 

We had a lot of learning from the phone deployments and I expect us to use what we learned there for how we do IoT. (I presented a paper on this at the IAB workshop on IoT). One of the things we learned the hard way was names work better than numbers. 

> So it shouldn't be configured by DHCP.   In the case where the phone happens not to be likely to move from network to network, you could _get away_ with using DHCP.   But a solution that would work for phones that _do_ move from network to network would also work for phones that do not, and that solution would therefore be preferable, particularly as an MTI solution, since it addresses all use cases.
>

---

From: Ted Lemon <[email-masked]>
Date: Wed, 9 Oct 2013 13:53:23 -0400

> Well DNS and Router obviously won't work with FQDN so lets talk about NTP for a minute. (and sorry, I don't even know what AFTR IP is). I design lots of devices that have to be plugged into a netwo…

An AFTR IP address is like a router IP address, but for a particular IPv4 transition technology.   Other transition technologies of this sort are classic examples of services that make sense to configure with DHCP, because they are part of the network infrastructure.

> One approach would be to hard code that NTP server name in the the product. That is not my preferred approach because stuff goes wrong and you end up with things like http://en.wikipedia.org/wiki/NTP_server_misuse_and_abuse .

Apple hard-codes the FQDN of a set of NTP servers they control into all their products.   I think other OS vendors do as well, but am not clear on the details.   The advantage of doing this is that you can then authenticate your communication with the NTP server.   If you use DHCP to configure your NTP server, you cannot validate your communication with your NTP server.   Of course there's a bit of a chicken-and-egg problem here in terms of replay attacks and key repudiation, but in principle you get more security if you hard code the FQDN of your NTP server than if you use DHCP to configure it.

Of course there are cases where this doesn't matter, and DHCP is just fine, but I can't think of any other than perhaps a self-setting wall clock.

Of course, if a CPE vendor were to hard-code the FQDN of an NTP server belonging to someone else into their devices, that would be disastrous.

> 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.

> 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.   Probably not a hugely bad thing, but that depends on the device.   A device with severe constraints probably isn't using DHCP anyway.

> We had a lot of learning from the phone deployments and I expect us to use what we learned there for how we do IoT. (I presented a paper on this at the IAB workshop on IoT). One of the things we le…

So what you've done here is to invent a service configuration protocol that leverages existing DHCP server infrastructure, uses packets that look just like DHCP packets, but is not actually DHCP.   A client that behaves in the way you have described is not following RFC3315.   It might be following the letter of RFC2131, but that's because RFC2131 has a known bug in that it doesn't _require_ clients to use new information they get from DHCP servers during lease renewals.

This is not an academic distinction: I've seen all sorts of support calls and questions about IP phones from at least one manufacturer, because these phones do not follow the DHCP protocol specification, and their behavior is surprising to network administrators.   I didn't realize until now that this was by design, and not just a bug in the implementation.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 9 Oct 2013 14:11:13 -0400

On Oct 9, 2013, at 1:59 PM, Joe Abley <[email-masked]> wrote:
> DNSSEC validation imposes a requirement for clock sync (to the accuracy reasonably required to consider signature inception and expiry times). There is a possible future in which such validation takes place on end hosts, rather than intermediate resolvers. (We may wind up somewhere else, but there are certainly people who think that is the Right Way).

Sure.   Including me.

> In that sense any device that needs to look up names in the DNS has a potential requirement for time sync.

Yes, definitely.

> Of course even the wall clock you imagine might have a vendor who is capable of running their own array of time servers as (e.g.) Apple does, but it seems reasonable to imagine that there will be people who are not in that position, and since I agree with you when you say:
> 
> it seems to me that there's a plausible use case for a DHCP client to receive direction on what servers to chime against.

Yup.   There's an equally plausible use case for distributing DNSSEC root keys using DHCP, so that the DHCP client has a current copy of the keys.   This totally solves the key rollover problem!

:)

Of course, the situations are not precisely analogous, but the point is that just because DHCP could be conveniently used to suit some purpose, does not mean that it _should_ be used to suit that purpose.  I think reasonable people can differ about configuring NTP over DHCP, but it really does depend on how you are using NTP.   I think the main justification for using DHCP to configure NTP is in fact that it is expedient, even though it's not secure.

---

From: Joe Abley <[email-masked]>
Date: Wed, 9 Oct 2013 10:59:57 -0700

Joe

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 9 Oct 2013 16:02:44 -0600

> Apple hard-codes the FQDN of a set of NTP servers they control into all their products.   I think other OS vendors do as well, but am not clear on the details.   The advantage of doing this is that…

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. 

> 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,…

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). 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. Not to mention opening up the use DNS tools like SRV and NAPTR. 

> 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. 

>   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?

> This is not an academic distinction: I've seen all sorts of support calls and questions about IP phones from at least one manufacturer, because these phones do not follow the DHCP protocol specific…

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.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 9 Oct 2013 21:15:44 -0400

> 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…

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.

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.   I don't even know if I could get one to use at home, or if it would work.   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.

> 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.   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.

>  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 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.   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.

> 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 doin…

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.   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.

> 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.

> 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, i…

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.

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 9 Oct 2013 21:49:10 -0600

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….

> 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…

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.
> 
> 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.
> 

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 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.
> 
>> 
>>> 
> 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. 

> 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. 

> 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 c…

Sorry for my overly brief description leading to confusion.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 10 Oct 2013 09:41:42 -0400

> 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.

> 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 pro…

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 des…

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.

> 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 /…

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…

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.

> 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? :)

> 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 thi…

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.)

---

From: Sten Carlsen <[email-masked]>
Date: Thu, 10 Oct 2013 16:20:49 +0200

One question for my information, pls. see below:

On 10/10/13 15:41, Ted Lemon wrote:
> 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.
Would the DHCP-server do a fresh lookup for every request and every
renewal? If it does, it will allow the device to follow changes in the
network though with a delay of a lease time.

-- 
Best regards

Sten Carlsen

No improvements come from shouting:

       "MALE BOVINE MANURE!!!"

---

From: Ted Lemon <[email-masked]>
Date: Thu, 10 Oct 2013 10:22:53 -0400

On Oct 10, 2013, at 10:20 AM, Sten Carlsen <[email-masked]> wrote:
> Would the DHCP-server do a fresh lookup for every request and every renewal? If it does, it will allow the device to follow changes in the network though with a delay of a lease time.

This isn't required by the protocol spec, but it's what most DHCP servers currently do.

---

From: Sten Carlsen <[email-masked]>
Date: Thu, 10 Oct 2013 16:29:09 +0200

> This isn't required by the protocol spec, but it's what most DHCP servers currently do.
Thanks, I then assume the ISC server does. Would such a requirement be a
way to settle the differences here?

-- 
Best regards

Sten Carlsen

       "MALE BOVINE MANURE!!!"

---

From: Ted Lemon <[email-masked]>
Date: Thu, 10 Oct 2013 10:39:22 -0400

On Oct 10, 2013, at 10:29 AM, Sten Carlsen <[email-masked]> wrote:
> Thanks, I then assume the ISC server does. Would such a requirement be a way to settle the differences here?

I don't think it should be done in this document, because this is really documenting best practices for protocol spec writers, not DHCP server implementors.

However, I think this behavior is worth recommending (indeed, there's a document I submitted a while back that could probably be turned to this purpose) but I don't think it can be required, because a really minimal DHCP server might not even do DNS resolution, and that ought to be allowed.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 10 Oct 2013 10:44:14 -0400

> However, I think this behavior is worth recommending (indeed, there's a document I submitted a while back that could probably be turned to this purpose) but I don't think it can be required, becaus…

BTW, the document in question is this one: http://tools.ietf.org/html/draft-lemon-dhc-topo-conf-01

Section 5 talks about this very issue.   The document could really use a non-AD author—the chances of me advancing it to standard in the near future are slim indeed.

---

From: Sten Carlsen <[email-masked]>
Date: Thu, 10 Oct 2013 16:45:06 +0200

> I don't think it should be done in this document, because this is really documenting best practices for protocol spec writers, not DHCP server implementors.
Right, it just occurred to me in this discussion.
> However, I think this behavior is worth recommending (indeed, there's a document I submitted a while back that could probably be turned to this purpose) but I don't think it can be required, becaus…
What about requiring that it does a fresh lookup, IF it has the server
specified as an FQDN? If it is only specified as an IP, obviously there
is no option for lookup.
As for the place to put it, I have no preference.

-- 
Best regards

Sten Carlsen

       "MALE BOVINE MANURE!!!"

---

From: Ted Lemon <[email-masked]>
Date: Thu, 10 Oct 2013 10:46:16 -0400

On Oct 10, 2013, at 10:45 AM, Sten Carlsen <[email-masked]> wrote:
> What about requiring that it does a fresh lookup, IF it has the server specified as an FQDN? If it is only specified as an IP, obviously there is no option for lookup.

I think you just answered your own question. :)

---

From: Ted Lemon <[email-masked]>
Date: Thu, 10 Oct 2013 10:52:03 -0400

> I think you just answered your own question. :)

No, actually I just realized that I misunderstood your point.   I think you are right—if a name is entered into the UI, it needs to be resolved by the DHCP server at least as frequently as the TTL for the record that's returned when it's queried.

---

From: Sten Carlsen <[email-masked]>
Date: Thu, 10 Oct 2013 17:20:43 +0200

> No, actually I just realized that I misunderstood your point.   I think you are right—if a name is entered into the UI, it needs to be resolved by the DHCP server at least as frequently as the TTL…
Just my point, that way any change would be picked up by devices even if
only IPs are sent in the option.

I did read your document, I think it would be good to get that finished
and made a standard. I do not quite see that it would be the place to
put the above requirement though since it states very clearly that it
places no new requirements on DHCP servers. It might be good to keep it
as a "Best practices of use" document.

-- 
Best regards

Sten Carlsen

       "MALE BOVINE MANURE!!!"

---

From: Ted Lemon <[email-masked]>
Date: Thu, 10 Oct 2013 11:26:04 -0400

On Oct 10, 2013, at 11:20 AM, Sten Carlsen <[email-masked]> wrote:
> I did read your document, I think it would be good to get that finished and made a standard. I do not quite see that it would be the place to put the above requirement though since it states very clearly that it places no new requirements on DHCP servers. It might be good to keep it as a "Best practices of use" document.

Yeah, after reviewing it I tend to think you are right.

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Sat, 12 Oct 2013 14:26:12 +0000

WG CO-CHAIR HAT OFF.

Two points:

1. A server should NOT be required to do a "fresh" lookup if the TTL for the DNS information has not expired [or it not close to expiring].

2. This doesn't solve all of the issues since the DNS TTL, as Ted has pointed out in some discussions, is not generally related to the lease (or renewal) time. Thus, it really depends on when the client is expected to use this information which could be long after the TTL for the original DNS query has expired.

Hence, depending on when a client is expected to use this information should greatly influence the decision as to whether to define an option as an FQDN or address(es). For example, for a next step bootstrap loader (or configuration file such as for DOCSIS), an address is fine as this is expected to be used by the client almost immediately. Something that may be used hours or days later when a user requests a particular application really SHOULD use an FQDN.

- Bernie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ted Lemon
Sent: Thursday, October 10, 2013 10:46 AM
To: Sten Carlsen
Cc: [email-masked] WG
Subject: Re: [dhcwg] Last Call: <draft-ietf-dhc-option-guidelines-14.txt> (Guidelines for Creating New DHCPv6 Options) to Best Current Practice

_______________________________________________
dhcwg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dhcwg

---

From: Sten Carlsen <[email-masked]>
Date: Sat, 12 Oct 2013 20:02:43 +0200

My 0.02EUR/$

> 1. A server should NOT be required to do a "fresh" lookup if the TTL for the DNS information has not expired [or it not close to expiring].
This is ok, we *should* expect that change in e.g. ntp servers coincide
with a change in DNS, hence new information should appear at a time
"natural" lookup time.
> 2. This doesn't solve all of the issues since the DNS TTL, as Ted has pointed out in some discussions, is not generally related to the lease (or renewal) time. Thus, it really depends on when the c…
It clearly does not solve the issue but makes it possible to manage the
world so it does partly solve the issue. -> make sure your DHCP renewal
period is short enough that a renewal will pick up the change soon
enough, coordinated with DNS TTLs.

I know it is not too pretty, so any better ideas are welcome.

-- 
Best regards

Sten Carlsen

       "MALE BOVINE MANURE!!!"

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 22 Oct 2013 11:58:24 -0600

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 …

> 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…

Louse choice? What exactly would you propose that would work better ?

> 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 o…

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

> 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 w…

You are off in the weeds here - I never disagreed that there were not DHCP servers that implemented this. 

> 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…

Sure, and why does that same argument not hold for configuring similar services which is what I complained about in the draft. 

> 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. 

> 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 serve…

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. 

> 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…

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, an…

The refresh on DNS TTL is same as refresh on DHCP lease time

> 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…

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 tha…

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.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 22 Oct 2013 18:55:24 +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 her…

Argh.   No.   The hallmark of a successful protocol is not that it attracts barnacles and gets used in ways that ultimately fail, either due to a really bad security model, or a bad fit, or other reasons.

DHCP in fact has been very successful in the IETF as a place to add barnacles.   There are lots of DHCP option extensions that do all kinds of really exciting things.   Most of them were implemented once, shortly after publication, never deployed, and now, if they exist at all, exist only as an attack surface that nobody has yet exploited hard enough to cause the feature to be removed from the client implementation.

The actual success of DHCP is its core ability to configure devices with the information they need to get online.   If you look at a typical DHCP packet from a typical host, it doesn't ask for SIP servers.   It doesn't ask for printers.   It doesn't ask about SMTP or IMAP or POP.

My DHCPv4 client asks for: Subnet Mask, Default Gateway, Domain Name Server, Domain Name, Domain Search List, LDAP Server Address, WPAD Proxy URL, Netbios Name Server and Netbios Node Type.   My DHCPv6 client requests DNS Server address and Domain Search List.

You will notice that it doesn't ask for an NTP option, even though it uses NTP.   This is because asking for an NTP option will generate support calls.  It doesn't ask for a printer address.   This is because although DHCPv4 provides a way to deliver printer addresses, nobody uses it.   Bonjour is easier and more convenient, and generates fewer support calls.   Even though I have an email client running, it doesn't ask for IMAP server, SMTP server or POP server, because that would be ridiculous.

So yes, DHCP is a successful protocol.   And yes, application protocol designers have attempted to use it to configure their protocols.   But they haven't succeeded, in the large, because it's a bad idea.   It is not a successful _applications service discovery_ protocol.   It is a successful _host configuration_ protocol.

> 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 don…

Indeed, in this scenario, power consumed by DNS and DHCP will not be an issue.

> On the flip side, for SIP phones we have seen that the level of indirection form DNS really helps make the operational issues easier.

Yes, and SIP is a lousy example, because it's not generally configured using DHCP—it's generally configured through a user interface.   When it _is_ configured using DHCP, it's done in a constrained environment.   The configuration model used in that environment would be a security disaster on the open internet.

> 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…

I agree that these are all good things to mention.   However, I think the document should steer people away from using FQDNs, because if they need to use FQDNs, they will regardless of what direction the document tries to steer them.

> 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 t…

It is in the charter to recommend best practices for DHCP.

> Louse choice? What exactly would you propose that would work better ?

What would be better would be a secure mechanism for configuring them.   E.g., going to a well-known URL and downloading a configuration signed using a tool that allows the device to validate the configuration.   This is what e.g. Microsoft Exchange clients do.   It works quite well.

> Sure, and why does that same argument not hold for configuring similar services which is what I complained about in the draft. 

In general, configuring similar services using DHCP won't work.   I'm not convinced it works for SIP.   I'm fairly sure it doesn't work for configuring NTP.

> 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 fo…

Can you give me an example of a use case that is _not_ an APPS-area protocol?

BTW, you mentioned that you think NTP and DNS are application layer, but they are in the INT area for a reason.   I mean a protocol that's in the APPS area, for an equally good reason.

> 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. 

The ship sailed long ago, and sank out at sea, yes.   I was on it at the time—like you, I used to think DHCP was for configuring applications.   I did not arrive at my current opinion accidentally.

> 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. 

Any time the frequency of reports from the device is similar in frequency to refreshes required by the DNS TTL expiring.

> The refresh on DNS TTL is same as refresh on DHCP lease time

Yes, and if you have to do six DNS queries per DHCP renewal, that's six more packet exchanges.

> 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 don't think you said what you meant here.   BOOTP is a predecessor to DHCP—what does that have to do with this conversation?

> 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 dis…

(a) I can't.
(b) It would be useless.   Of course RAI is going to say DHCP should support configuring application protocols.   Why not?   It's a cost-free assertion from your perspective.
(c) This document is saying what the DHC working group recommends.   RAI working groups are free to go against these recommendations.   So this document shouldn't say what RAI recommends.   It should say what DHC recommends.   If a working group doesn't want to follow the advice, they don't have to, because it's just advice, not a requirement.

---

From: Ted Lemon <[email-masked]>
Date: Fri, 25 Oct 2013 11:04:05 +0000

On Oct 25, 2013, at 1:57 AM, Cullen Jennings <[email-masked]> wrote:
> Ted, as an IESG member, are you really sticking to a that the meaning of a BCP?

Working groups are where IETF consensus comes from.   The IETF mailing list review is there to see if the IETF disagrees with the working group consensus.   I'm trying to explain to you, the only (late) dissenter in the IETF last call, why I think the IETF should have consensus to publish the DHC working group's advice about how to implement DHCP options as a BCP.   I'm doing this because I think that it is the right thing.   If you think it's the wrong thing, at least do me the courtesy of walking me through your reasoning.

Can you make a clear argument for why some RAI working group, and not the DHC working group, should be the one to offer advice on how to do DHCP options?   Would you, for example, want sipping to be where advice on how to do new DNS RRtypes comes from?

---

From: Barry Leiba <[email-masked]>
Date: Fri, 25 Oct 2013 11:36:10 -0400

> Working groups are where IETF consensus comes from.   The IETF mailing
> list review is there to see if the IETF disagrees with the working
> group consensus.   I'm trying to explain to you, the only (late)
> dissenter in the IETF last call, why I think the IETF should have
> consensus to publish the DHC working group's advice about how to
> implement DHCP options as a BCP.   I'm doing this because I think that
> it is the right thing.   If you think it's the wrong thing, at least
> do me the courtesy of walking me through your reasoning.
>
> Can you make a clear argument for why some RAI working group, and not
> the DHC working group, should be the one to offer advice on how to do
> DHCP options?   Would you, for example, want sipping to be where
> advice on how to do new DNS RRtypes comes from?

Really, now, this is over the top.

First, BCPs have IETF consensus, and are applicable across the IETF.
When you said that "RAI working groups are free to go against these
recommendations," you were completely wrong, and the IESG should and
would slap them down if they did.

Second, anyone who participates in the IETF can bring up issues, as
IETF consensus is built.  The output of working groups doesn't have
any magical force field protecting it from challenges from others.
The working group consensus means a lot, of course, but reasonable and
reasoned arguments still have to be addressed.

Third, your second paragraph above is really out of line.  So let's
back away a bit and look at the picture we're painting.

No one has tried to say that some other working group should be
telling people how to use DHCP.

What several of us have said, and what Cullen is saying, is that
various protocols (including some in the RAI area) are using DHCP to
get their configuration information.  Nothing theoretical: they ARE.
And that use has already been approved with IETF consensus.  So IF the
DHC working group means to say that such use by those protocols in
that way is ill advised, it needs to be explicitly clear about that,
and the issue needs to be discussed and have IETF consensus.
Otherwise, the document's recommendations need to be clarified to say
that this is legitimately done to configure application-layer
protocols, and different recommendations may apply to those.  Ideally,
it would give those recommendations as well.

So, one or the other:
- say "don't do that; it's bad, and here's why," *and get IETF
consensus on that*, or
- say "different recommendations apply in those situations, and here
are those recommendations," *and get IETF consensus on that*.

Barry

---

From: SM <[email-masked]>
Date: Fri, 25 Oct 2013 10:32:26 -0700

Hello,

I took a quick look at draft-ietf-dhc-option-guidelines-14.  In Section 8:

   "FQDN imposes a number of additional failure modes and issues that
    should be dealt with:

    1.  The client must have a knowledge about available DNS servers.
        That typically means that option DNS_SERVERS is mandatory.  This
        should be mentioned in the draft that defines new option.  It is
        possible that the server will return FQDN option, but not the DNS
        Servers option.  There should be a brief discussion about it;

    2.  The DNS may not be reachable;

    3.  DNS may be available, but may not have appropriate information
        (e.g. no AAAA records for specified FQDN);"

The draft recommends using IP addresses unless there is a good reason 
to use an FQDN.  I understand that everything breaks when a FQDN 
cannot be resolved.  One of the principles which is not usually 
mentioned nowadays ia that "user applications should use names rather 
than addresses".  I'll comment quickly about the above points.

The client would have to perform DNS resolution (Item 1) for the 
system to work.  There are cases where one can get away with using IP 
addresses.

When the DNS is not reachable (Item 2) people complain.  One of the 
arguments for redundancy is that the network will keep working if a 
system fails.  A person would usually see that there is some DNS 
service which is reachable.

Item 3 is odd.  The person putting in the appropriate information 
would have to think about whether the network will support, for 
example, IPv6-only hosts.

In Section 9:

   "There is no such ambiguity in DHCPv6 (with the unfortunate exception
    of [RFC5908],which was published without following the advice provided
    during the DHC working group review, and contains many errors."

This sounds like a case of a working group doing work which is not 
part of its charter (see https://datatracker.ietf.org/wg/ntp/charter/ 
).  The approval message mentioned that "This document has received 
in-depth review from both the NTP and DHC working groups and has 
strong support for advancement". Anyway, the above text does not 
sound politically correct. :-)

Section 13 discusses about chartering requirements and advice for 
Responsible ADs.  I don't think that it belongs in a document about 
guidance to prospective DHCPv6 Option developers.

Section 22 provides advice about updating existing RFCs.  I don't 
think that it belongs in a document about DHCPv6 Option guidelines.

There is advice for authors of drafts in the Security Considerations 
section.  I'll assume that authors are a security risk. :-)

Regards,
-sm

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 24 Oct 2013 23:57:22 -0600