Re: [dhcwg] What sorts of services does DHCP configure?

[Sten Carlsen <[e-mail]>]

Another 0.02$/€

I have been thinking a bit longer. I still don't quite agree.

I see it this way:
Whatever information is depending on your location at the time of its
use needs to be handed out by the ONE service that actually knows your
location in the network, the service that actively hands out your address.

Examples:
DNS, resolvers are in most cases restricted to the local users, so you
need the local copy but it will give equivalent answers wherever you are.

IMAP, you have an account, so you need access to the one server that
keeps your data. (simplified a bit).

SIP is also very node specific, but there are two ways to look at this
service:
- a SIP phone that will always connect to the same service, so wherever
you may be, you will always use the same service. Works sort of like a
mobile phone. Example: skype.
- a SIP phone that will connect via the local serivice. Works like
bringing your own phone and plugging it into any outlet and using the
phone service of your host.

I have experienced both ways of operating.


The most common example, though it does not fit the bill, is WIFI. If
you get access, it will do the same wherever you are -> mostly network
specific. OTOH you normally have a subscription so only the paying
customer may access the node -> node specific.

I may think that IF DHCP is the only way to distribute information for
geographical reasons, it should be used. OR "somebody" should suggest a
new set of protocols and servers - including how "it" would get the
information about the client's network location from DHCP.

On 14/10/13 20.25, Ted Lemon wrote:
> During the IESG review of the DHCP Option Guidelines document, a number of issues came up, but the most contentious had to do with the question of exactly what services it makes sense to configure with DHCP.   This is an issue because the use model for one class of such services is quite different from the use model for the other class, and prospective users of DHCP to configure services of the other class therefore disputed the option document's advice on when to use FQDNs.
>
> The dichotomy that I would like us to discuss is between network-specific services and node-specific services.
>
> To illustrate what I mean, consider DNS.   DNS is the same everywhere (at least in principle).   If I ask a question of a DNS server on network A, and ask the same question on network B, I should get an equivalent answer; at the very least, the answer should come from the same data, and should validate with DNSSEC.   So it doesn't matter which DNS resolver I use, and indeed this matches how we use DNS.   So DNS is a network-specific service: the DNS server you use probably should be the one closest to you.
>
> Now, consider IMAP.   If you use IMAP, you probably have one or more IMAP servers.   These servers are fixed in location.   You do not check a different IMAP server when you are at Starbucks than you do when you are at home, or at work.   So IMAP is a node-specific service—your IMAP configuration stays with your laptop or tablet, and does not change as you move from network to network.
>
> If you look at the list of DHCPv4 options, you can find lots of IMAP-like services, and lots of DNS-like services.   I think that the DHCPv4 options for configuring node-specific services are a mistake—they are a throwback to a time when nodes didn't move around, so we weren't aware that we had a problem with the use model for DHCPv4 in configuring things like SMTP and IMAP.
>
> At the same time, during the discussion about the Option Guidelines draft, several people raised the idea of services that are configured via DHCP, even though they are node-specific, because in certain cases that's the only option, and it makes sense to configure them that way in those cases.   For instance, a desktop SIP phone might get its initial SIP configuration over DHCP, and then not use DHCP to get SIP configuration anymore.
>
> I am going to make a claim, and I would like the working group to tell me whether they agree with or disagree with this claim.   My claim is that DHCP doesn't make sense for configuring node-specific services.   There may be edge cases where a node-specific service can be configured using DHCP, but DHCP isn't the right service to be used in this case—it's used in this case because there is no better alternative, not because DHCP is a good alternative.   And while there may be edge cases where configuring a particular node-specific service using DHCP makes sense, there will be many more cases where using DHCP to configure that same service would not only not work, but would probably create serious security vulnerabilities.
>
> Thoughts?
> _______________________________________________
> dhcwg mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dhcwg

-- 
Best regards

Sten Carlsen

No improvements come from shouting:

       "MALE BOVINE MANURE!!!"