RFC 2241

RFC 2241: DHCP Options for Novell Directory Services 🎀

RFC: 2241 Network Working Group 🌸 Author: D. Provan, Novell, Inc. 💖 Category: Standards Track ✨ Date: November 1997 🦋 Obsoletes / Updates: nothing is listed in this document's title block 🧚

---

Status of This Memo 💅

okay so bestie, this doc is an Internet standards track protocol for the Internet community, and it's literally asking for discussion and suggestions for improvements 🫶 If you want the standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1). And the distribution of this memo is unlimited, so share it with everyone 🌈

Copyright Notice ⭐

Copyright (C) The Internet Society (1997). All Rights Reserved.

Abstract ✨

this doc defines three new DHCP options for handing out config info to clients of Novell Directory Services 🎀 The first one carries a list of NDS servers. The second one carries the name of the client's NDS tree. The third one carries the initial NDS context. Together they give an NDS client everything it needs to connect to an NDS tree, no manual config needed 🔥

1. Introduction 💖

okay so Novell Directory Services is a distributed, replicated, hierarchical database of objects, and those objects represent network resources like nodes, services, users, and applications 🧚 An NDS client has to be able to find an NDS server so it can authenticate itself to the network and get into the database. Also, the user is way better off when the client's attention is focused on the part of the NDS database that's most interesting to them 👑 This spec describes DHCP options [1] that carry NDS info to TCP/IP clients of NDS. The first one, the NDS Servers Option, carries a list of NDS servers. The other two, the NDS Tree Name Option and the NDS Context Option, give the client a default context inside the NDS database 💅

The NDS Tree Name Option and the NDS Context Option carry 16-bit Unicode text that gets encoded into an octet stream using UTF-8 [4] 🦋 A complete DHCP implementation can represent the entire Unicode character set that NDS supports, which is so iconic 😭 Plus, 7-bit ASCII text stays exactly the same under the UTF-8 transformation ✨ So in environments where the NDS tree name and context are limited to 7-bit ASCII characters, ASCII-only DHCP clients and servers can still support these options by using the ASCII text as the UTF-8 encoded data 🫶

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 RFC 2119. [2] 🌸

2. NDS Servers Option 🎀

this option specifies one or more NDS servers for the client to contact for access to the NDS database 🧚 Servers SHOULD be listed in order of preference, so the most preferred one comes first 💖

The code for this option is 85 🍓 The minimum length of this option is 4 octets, and the length MUST be a multiple of 4 ✨

   Code   Len        Address 1               Address 2
  +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+--
  | 85  |  n  |  a1 |  a2 | a3  |  a4 |  a1 |  a2 |  a3 |  a4 |  ...
  +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+--

3. NDS Tree Name Option 🦋

this option specifies the name of the NDS tree the client will be contacting 🌈 NDS tree names are 16-bit Unicode strings. For transmission in the NDS Tree Name Option, an NDS tree name is transformed into octets using UTF-8 💅 The string should NOT be zero terminated 🙈

The code for this option is 86 🍓 The maximum possible length for this option is 255 bytes 💜

    Code Len  NDS Tree Name
   +----+----+----+----+----+----+--
   | 86 | n  | c1 | c2 | c3 | c4 |  ...
   +----+----+----+----+----+----+--

4. NDS Context Option 👑

this option specifies the initial NDS context the client should use ✨ NDS contexts are 16-bit Unicode strings. For transmission in the NDS Context Option, an NDS context is transformed into octets using UTF-8 🦋 The string should NOT be zero terminated 🫶

a single DHCP option can only hold 255 octets 😭 An NDS context name can be longer than that, so this option is allowed to show up more than once in the DHCP packet 💀 To get the complete NDS context, concatenate the contents of all the NDS Context options in the packet, as suggested in the DHCP specification [3, page 24] 🧚 And heads up: a single encoded character could be split between two NDS Context Options 🙈

The code for this option is 87 🍓 The maximum length for each instance of this option is 255. But like I just said, the option can appear more than once if the desired NDS context takes up more than 255 octets 💅 Implementations are discouraged from enforcing any specific maximum on the final concatenated NDS context 🌸

    Code Len  Initial NDS Context
   +----+----+----+----+----+----+--
   | 87 | n  | c1 | c2 | c3 | c4 |  ...
   +----+----+----+----+----+----+--

5. References 📚

[1] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC-2132, March 1997.

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

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

[4] Yergeau, F., "UTF-8, a transformation format of Unicode and ISO 10646", RFC-2044, October 1996

6. Security Considerations 🔥

okay bestie, this part is serious 😭 DHCP currently provides no authentication or security mechanisms. Potential exposures to attack are discussed in section 7 of the DHCP protocol specification [3]. In particular, these DHCP options allow an unauthorized DHCP server to misdirect an NDS client to a nonexistent NDS server or even a spoof NDS server. These threats are similar to what NDS faces during normal operations in its native IPX environment. 💀

7. Author's Address 🧚

Don Provan Novell, Inc. 2180 Fortune Drive San Jose, California, 95131

Phone: +1 408 577 8440

EMail: donp@Novell.Com

8. Full Copyright Statement 💜

Copyright (C) The Internet Society (1997). 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. 🌈✨