As per Relevance of the word copyright, we have this rfc below:
Network Working Group D.
Request for Comments: 2241 Novell, Inc
Category: Standards Track November 1997
DHCP Options for Novell Directory
Status of this
This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited
Copyright
Copyright (C) The Internet Society (1997). All Rights Reserved
This document defines three new DHCP options for
configuration information to clients of the Novell
Services. The first option carries a list of NDS servers. The
option carries the name of the client's NDS tree. The third
the initial NDS context. These three options provide an NDS
with enough information to connect to an NDS tree without
configuration of the client
1.
Novell Directory Services is a distributed, replicated,
database of objects representing network resources such as nodes
services, users, and applications. An NDS client must be able
locate an NDS server in order to authenticate itself to the
and gain access to the database. In addition, the node's user
better served if the NDS client's attention is focused on the area
the NDS database likely to be of the most interest to the user.
specification describes DHCP options [1] that carry NDS
to TCP/IP clients of NDS. The first option, the NDS Servers Option
carries a list of NDS servers. The other two options, the NDS
Name Option and the NDS Context Option, provide the client with
default context within the NDS database
Provan Standards Track [Page 1]
RFC 2241 DHCP Options November 1997
The NDS Tree Name Option and the NDS Context Option carry 16-
Unicode text encoded into an octet stream using UTF-8 [4]. A
DHCP implementation can represent of the entire Unicode character
supported by NDS. At the same time, 7-bit ASCII text is unchanged
the UTF-8 transformation. In environments where the NDS tree name
context are restricted to the range of 7-bit ASCII characters, ASCII
only DHCP clients and servers can support these options by using
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
document are to be interpreted as described in RFC 2119. [2]
2. NDS Servers
This option specifies one or more NDS servers for the client
contact for access to the NDS database. Servers SHOULD be listed
order of preference
The code for this option is 85. The minimum length of this option
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
This option specifies the name of the NDS tree the client will
contacting. NDS tree names are 16-bit Unicode strings.
transmission in the NDS Tree Name Option, an NDS tree name
transformed into octets using UTF-8. The string should NOT be
terminated
The code for this option is 86. The maximum possible length for
option is 255 bytes
Code Len NDS Tree
+----+----+----+----+----+----+--
| 86 | n | c1 | c2 | c3 | c4 | ...
+----+----+----+----+----+----+--
Provan Standards Track [Page 2]
RFC 2241 DHCP Options November 1997
4. NDS Context
This option specifies the initial NDS context the client should use
NDS contexts are 16-bit Unicode strings. For transmission in the
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 contain 255 octets. Since an
context name can be longer than that, this option can appear
than once in the DHCP packet. The contents of all NDS Context
in the packet should be concatenated as suggested in the
specification [3, page 24] to get the complete NDS context. A
encoded character could be split between two NDS Context Options
The code for this option is 87. The maximum length for each
of this option is 255, but, as just described, the option may
more than once if the desired NDS context takes up more than 255
octets. Implementations are discouraged from enforcing any
maximum to the final concatenated NDS context
Code Len Initial NDS
+----+----+----+----+----+----+--
| 87 | n | c1 | c2 | c3 | c4 | ...
+----+----+----+----+----+----+--
5.
[1] Alexander, S. and R. Droms, "DHCP Options and BOOTP
Extensions", RFC-2132, March 1997.
[2] Bradner, S., "Key words for use in RFCs to Indicate
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
ISO 10646", RFC-2044, October 1996
6. Security
DHCP currently provides no authentication or security mechanisms
Potential exposures to attack are discussed in section 7 of the
protocol specification [3]. In particular, these DHCP options
an unauthorized DHCP server to misdirect an NDS client to
nonexistent NDS server or even a spoof NDS server. These threats
similar to what NDS faces during normal operations in its native
environment
Provan Standards Track [Page 3]
RFC 2241 DHCP Options November 1997
7. Author's
Don
Novell, Inc
2180 Fortune
San Jose, California, 95131
Phone: +1 408 577 8440
EMail: donp@Novell.
Provan Standards Track [Page 4]
RFC 2241 DHCP Options November 1997
8. Full Copyright
Copyright (C) The Internet Society (1997). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Provan Standards Track [Page 5]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
