RFC 2610

DHCP Options for Service Location Protocol

📅 published June 1999, from ietf

RFC 2610 💖 DHCP Options for Service Location Protocol

  • Network Working Group 🌸
  • Request for Comments: 2610 ✨
  • Authors: C. Perkins and E. Guttman, both from Sun Microsystems 👑
  • Category: Standards Track 🦋
  • Date: June 1999 🎀
  • Obsoletes / Updates: the title block doesn't list any RFCs this one obsoletes or updates 🧚

Status of this Memo

Okay so this doc is an Internet standards track protocol 💅 for the Internet community, and it's basically asking for discussion and suggestions for improvements. To find out where this protocol stands, check the current edition of the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited 🌈

Copyright (C) The Internet Society (1999). All Rights Reserved. 🔒

Abstract

So basically, DHCP gives hosts on a TCP/IP network a way to get their configuration info 💖 Entities that use the Service Location Protocol need to find out where their Directory Agents are so they can send messages. There's also another option that sets the scope for configuring SLP User Agents and Service Agents. 🫶

1. Introduction ✨

The Dynamic Host Configuration Protocol [2] is the framework that hands out config info to hosts on a TCP/IP network. Entities using the Service Location Protocol, Version 2 [3] and Service Location Protocol, Version 1 [4] need to get the address of Directory Agents and their Scope configuration. SLP has a default config for Scopes, and Directory Agents can be found using multicast or broadcast. 🌸 In bigger deployments, though, it's way more useful to configure SLP Agents through DHCP. That lets you centralize admin and deploy SLP in networks where multicast routing isn't available. 💅

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [1]. 📜

2. Introduction 🎀

The DHCP options below are how you configure Agents that use the Service Location Protocol, Version 2 [3] and Version 1 [4]. 🧚

The SLP Directory Agent option is what tells User Agents and Service Agents where the Directory Agents are on the network. 🦋

The SLP Scope Option takes precedence over both default and static scope configuration of SLP agents. 👑

3. SLP Directory Agent Option 💖

This option specifies the location of one or more SLP Directory Agents. 📍

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Code = 78   |    Length     |   Mandatory   |      a1       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      a2       |       a3      |       a4      |      ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

This option is basically a list of IP addresses for Directory Agents. Directory Agents MUST be listed in order of preference, if there is an order of preference. 🌟

The Length value must include one for the 'Mandatory' byte and include four for each Directory Agent address that follows. So the Length minus one of the option MUST always be divisible by 4, and the minimum value is 5. 🔢

The address of the Directory Agent is given in network byte order. 🧠

The 'Mandatory' byte in the Directory Agent option may be set to either 0 or 1. If it's set to 1, the SLP User Agent or Service Agent that got configured this way MUST NOT employ either active or passive multicast discovery of Directory Agents. 🚫

Note that for backward compatibility with some deployed software, the Mandatory byte MUST NOT be set to any byte value where the high order bit (0x80) is set. ⚠️

The Directory Agents listed in this option MUST be configured with a non-empty subset of the scope list that the Agent receiving the Directory Agent Option is configured with. See the notes below. 🫶

The SLPv2 specification [3] defines how to use this option. 📖

4. SLP Service Scope Option 🌈

The scope list is a comma delimited list that shows which scopes an SLP Agent is configured to use. 🍓

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Code = 79   |     Length    |   Mandatory   | <Scope List>...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The Length tells you the number of bytes that follow. Since the Scope-List String is encoded with UTF-8 [5] characters, it's possible the Length won't match the number of characters in the Scope-List String 🤯 The Length value must include one for the 'Mandatory' byte.

The 'Mandatory' byte decides whether SLP Agents override their static scope config with the <Scope List> string from this option. This lets DHCP admins set a policy that assigns a group of scopes to Agents for service provision. 👑 If the Mandatory byte is 0, static configuration takes precedence over the DHCP-provided scope list. If the Mandatory byte is 1, the <Scope List> provided in this option MUST be used by the SLP Agent. 🔥

The Scope List String syntax and usage are defined in the SLPv2 specification [3]. 📖

4.1. Zero Length Scope-List String Configuration 🧚

An SLP Service Scope Option with a Length of 1 (so, with the <Scope List> string left out entirely) validly configures the SLP User Agent to use "User Selectable Scopes." 🦋

The SLP Agent will use the aggregated list of scopes from all known DAs. If no DAs are known, the UA will use SA discovery to figure out the list of scopes on the network, as defined in [3]. 🔍

Hold up, this one's a big deal 🙈 This config is basically the same as giving up all centralized control of scope config for hosts on the network. That means every User Agent can see every service. It might not be what you want, since users may not be able to decide, or want to decide, which services are right for them. 💀

5. Security Considerations 🔐

This section is serious, bestie. Read every word. 😭

If a malicious host can insert fraudulent info into DHCPOFFER packets sent to a prospective SLP Agent, the SLP Agent won't be able to get service, or it could be unknowingly pointed at the wrong services. 😱

There are lots of opportunities for denial of service. A service agent might end up relying on fraudulent or otherwise malicious directory agents to advertise its services. DHCPOFFERs could also stop the regular SLP framework from working by telling clients not to use multicast, or to use directory agents that don't exist, and so on. 🚨

These problems come from a much bigger, more serious issue, namely that securing or authenticating any information at all from a DHCP server (or client!) isn't possible in common DHCP deployments. 🫠

References 📚

[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[2] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.

[3] E. Guttman, C. Perkins, J. Veizades, and M. Day, "Service Location Protocol version 2", Work in Progress.

[4] Veizades, J., Guttman, E., Perkins, C. and S. Kaplan, "Service Location Protocol", RFC 2165, July 1997.

[5] Yergeau, F., "UTF-8, a transformation format of unicode and ISO 10646", RFC 2279, October 1998.

Authors' Addresses 💌

Charles E. Perkins
Technology Development Group
Mail Stop MPK15-214
Sun Microsystems, Inc.
15 Network Circle
Menlo Park, CA  94025

Phone: +1 650-786-6464
Fax:   +1 650-786-6445
EMail: Charles.Perkins@Sun.Com
Web: http://www.svrloc.org/~charliep


Erik Guttman
Technology Development Group
Mail Stop UFRA02
Sun Microsystems, Inc.
Bahnstr. 2
74915 Waibstadt, Germany

Phone: +49 7263 911 701
  or:  +1 650 786 5992
EMail: Erik.Guttman@Sun.Com
Copyright (C) The Internet Society (1999).  All Rights Reserved.

This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works.  However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.

The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement 🫶

Funding for the RFC Editor function is currently provided by the Internet Society. 🌸

📦 where this page comes from