summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc4174.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc4174.txt')
-rw-r--r--doc/rfc/rfc4174.txt731
1 files changed, 731 insertions, 0 deletions
diff --git a/doc/rfc/rfc4174.txt b/doc/rfc/rfc4174.txt
new file mode 100644
index 0000000..4d2693f
--- /dev/null
+++ b/doc/rfc/rfc4174.txt
@@ -0,0 +1,731 @@
+
+
+
+
+
+
+Network Working Group C. Monia
+Request for Comments: 4174 Consultant
+Category: Standards Track J. Tseng
+ Riverbed Technology
+ K. Gibbons
+ McDATA Corporation
+ September 2005
+
+
+ The IPv4 Dynamic Host Configuration Protocol (DHCP) Option
+ for the Internet Storage Name Service
+
+Status of This Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2005).
+
+Abstract
+
+ This document describes the Dynamic Host Configuration Protocol
+ (DHCP) option to allow Internet Storage Name Service (iSNS) clients
+ to discover the location of the iSNS server automatically through the
+ use of DHCP for IPv4. iSNS provides discovery and management
+ capabilities for Internet SCSI (iSCSI) and Internet Fibre Channel
+ Protocol (iFCP) storage devices in an enterprise-scale IP storage
+ network. iSNS provides intelligent storage management services
+ comparable to those found in Fibre Channel networks, allowing a
+ commodity IP network to function in a similar capacity to that of a
+ storage area network.
+
+Table of Contents
+
+ 1. Introduction ................................................. 2
+ 1.1. Conventions Used in This Document ...................... 2
+ 2. iSNS Option for DHCP ......................................... 3
+ 2.1. iSNS Functions Field ................................... 5
+ 2.2. Discovery Domain Access Field .......................... 6
+ 2.3. Administrative Flags Field ............................. 7
+ 2.4. iSNS Server Security Bitmap ............................ 8
+ 3. Security Considerations ...................................... 9
+ 4. IANA Considerations .......................................... 11
+
+
+
+Monia, et al. Standards Track [Page 1]
+
+RFC 4174 DHCP Option Number for iSNS September 2005
+
+
+ 5. Normative References ......................................... 11
+ 6. Informative References ....................................... 11
+
+1. Introduction
+
+ The Dynamic Host Configuration Protocol for IPv4 provides a framework
+ for passing configuration information to hosts. Its usefulness
+ extends to hosts and devices using the iSCSI and iFCP protocols to
+ connect to block level storage assets over a TCP/IP network.
+
+ The iSNS Protocol provides a framework for automated discovery,
+ management, and configuration of iSCSI and iFCP devices on a TCP/IP
+ network. It provides functionality similar to that found on Fibre
+ Channel networks, except that iSNS works within the context of an IP
+ network. iSNS thereby provides the requisite storage intelligence to
+ IP networks that are standard on existing Fibre Channel networks.
+
+ Existing DHCP options cannot be used to find iSNS servers for the
+ following reasons:
+
+ a) iSNS functionality is distinctly different from other protocols
+ using DHCP options. Specifically, iSNS provides a significant
+ superset of capabilities compared to typical name resolution
+ protocols such as DNS. It is designed to support client devices
+ that allow themselves to be configured and managed from a central
+ iSNS server.
+
+ b) iSNS requires a DHCP option format that provides more than the
+ location of the iSNS server. The DHCP option has to specify the
+ subset of iSNS services that may be actively used by the iSNS
+ client.
+
+ The DHCP option number for iSNS is used by iSCSI and iFCP devices to
+ discover the location and role of the iSNS server. The DHCP option
+ number assigned for iSNS by IANA is 83.
+
+1.1. Conventions Used in This Document
+
+ iSNS refers to the Internet Storage Name Service framework, which
+ consists of the storage network model and associated services.
+
+ 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 [RFC2119].
+
+ All frame formats are in big-endian network byte order. RESERVED
+ fields SHOULD be set to zero.
+
+
+
+
+Monia, et al. Standards Track [Page 2]
+
+RFC 4174 DHCP Option Number for iSNS September 2005
+
+
+ This document uses the following terms:
+
+ "iSNS Client" - iSNS clients are processes resident in iSCSI and
+ iFCP devices that initiate transactions with the iSNS server using
+ the iSNS Protocol.
+
+ "iSNS Server" - The iSNS server responds to iSNS protocol query
+ and registration messages and initiates asynchronous notification
+ messages. The iSNS server stores information registered by iSNS
+ clients.
+
+ "iSCSI (Internet SCSI)" - iSCSI is an encapsulation of SCSI for a
+ new generation of storage devices interconnected with TCP/IP.
+
+ "iFCP (Internet Fibre Channel Protocol)" - iFCP is a gateway-to-
+ gateway protocol designed to interconnect existing Fibre Channel
+ devices using TCP/IP. iFCP maps the Fibre Channel transport and
+ fabric services to TCP/IP.
+
+2. iSNS Option for DHCP
+
+ This option specifies the location of the primary and backup iSNS
+ servers and the iSNS services available to an iSNS client.
+
+ 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 = 83 | Length | iSNS Functions |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | DD Access | Administrative FLAGS |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | iSNS Server Security Bitmap |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | a1 | a2 | a3 | a4 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | b1 | b2 | b3 | b4 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | . . . . |
+ | Additional Secondary iSNS Servers |
+ | . . . . |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Figure 1. iSNS Server Option
+
+
+
+
+
+
+
+
+Monia, et al. Standards Track [Page 3]
+
+RFC 4174 DHCP Option Number for iSNS September 2005
+
+
+ The iSNS Option specifies a list of IP addresses used by iSNS
+ servers. The option contains the following parameters:
+
+ Length: The number of bytes that follow the Length field.
+
+ iSNS Functions: A bitmapped field defining the functions supported
+ by the iSNS servers. The format of this field is described
+ in section 2.1.
+
+ Discovery Domain Access: A bit field indicating the types of iSNS
+ clients that are allowed to modify Discovery Domains. The
+ field contents are described in section 2.2.
+
+ Administrative Flags field: Contains the administrative settings
+ for the iSNS servers discovered through the DHCP query. The
+ contents of this field are described in section 2.3.
+
+ iSNS Server Security Bitmap: Contains the iSNS server security
+ settings specified in section 2.4.
+
+ a1...a4: Depending on the setting of the Heartbeat bit in the
+ Administrative Flags field (see section 2.3), this field
+ contains either the IP address from which the iSNS heartbeat
+ originates (see [iSNS]) or the IP address of the primary
+ iSNS server.
+
+ b1...b4: Depending on the setting of Heartbeat bit in the
+ Administrative Flags field (see section 2.3), this field
+ contains either the IP address of the primary iSNS server or
+ that of a secondary iSNS server.
+
+ Additional Secondary iSNS Servers: Each set of four octets
+ specifies the IP address of a secondary iSNS server.
+
+ The Code field through IP address field a1...a4 MUST be present in
+ every response to the iSNS query; therefore the Length field has a
+ minimum value of 14.
+
+ If the Heartbeat bit is set in the Administrative Flags field (see
+ section 2.3), then b1...b4 MUST also be present. In this case, the
+ minimum value of the Length field is 18.
+
+ The inclusion of Additional Secondary iSNS Servers in the response
+ MUST be indicated by increasing the Length field accordingly.
+
+
+
+
+
+
+
+Monia, et al. Standards Track [Page 4]
+
+RFC 4174 DHCP Option Number for iSNS September 2005
+
+
+2.1. iSNS Functions Field
+
+ The iSNS Functions Field defines the iSNS server's operational role
+ (i.e., how the iSNS server is to be used). The iSNS server's role
+ can be as basic as providing simple discovery information, or as
+ significant as providing IKE/IPSec security policies and certificates
+ for the use of iSCSI and iFCP devices. The format of the iSNS
+ Functions field is shown in Figure 2.
+
+ 0 1 1
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | RESERVED |S|A|E|
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Figure 2. iSNS Functions Field
+
+ Bit Field Significance
+ --------- ------------
+ 15 Function Fields Enabled
+ 14 DD-Based Authorization
+ 13 Security Policy Distribution
+
+ The following are iSNS Functions Field definitions:
+
+ Function Fields Specifies the validity of the remaining
+ Enabled: iSNS Function fields. If it is set to one, then
+ the contents of all other iSNS Function fields
+ are valid. If it is set to zero, then the
+ contents of all other iSNS Function fields MUST
+ be ignored.
+
+ DD-based Indicates whether devices in a common
+ Authorization: Discovery Domain (DD) are implicitly authorized
+ to access one another. Although Discovery
+ Domains control the scope of device discovery,
+ they do not necessarily indicate whether a domain
+ member is authorized to access discovered
+ devices. If this bit is set to one, then devices
+ in a common Discovery Domain are automatically
+ allowed access to each other (if successfully
+ authenticated). If this bit is set to zero, then
+ access authorization is not implied by domain
+ membership and must be explicitly performed by
+ each device. In either case, devices not in a
+ common discovery domain are not allowed to access
+ each other.
+
+
+
+
+Monia, et al. Standards Track [Page 5]
+
+RFC 4174 DHCP Option Number for iSNS September 2005
+
+
+ Security Policy Indicates whether the iSNS client is to
+ Distribution: download and use the security policy
+ configuration stored in the iSNS server. If it
+ is set to one, then the policy is stored in the
+ iSNS server and must be used by the iSNS client
+ for its own security policy. If it is set to
+ zero, then the iSNS client must obtain its
+ security policy configuration by other means.
+
+2.2. Discovery Domain Access Field
+
+ The format of the DD Access bit field is shown in Figure 3.
+
+ 0 1 1 1 1 1 1
+ 0 ... 9 0 1 2 3 4 5
+ +---+---+---+---+---+---+---+---+---+
+ | RESERVED | if| tf| is| ts| C | E |
+ +---+---+---+---+---+---+---+---+---+
+
+ Figure 3. Discovery Domain Access Field
+
+ Bit Field Significance
+ --------- ------------
+ 15 Enabled
+ 14 Control Node
+ 13 iSCSI Target
+ 12 iSCSI Initiator
+ 11 iFCP Target Port
+ 10 iFCP Initiator Port
+
+ The following are Discovery Domain Access Field definitions:
+
+ Enabled: Specifies the validity of the remaining DD
+ Access bit field. If it is set to one, then
+ the contents of the remainder of the DD Access
+ field are valid. If it is set to zero, then
+ the contents of the remainder of this field
+ MUST be ignored.
+
+ Control Node: Specifies whether the iSNS server allows
+ Discovery Domains to be added, modified, or
+ deleted by means of Control Nodes. If it is
+ set to one, then Control Nodes are allowed to
+ modify the Discovery Domain configuration. If
+ it is set to zero, then Control Nodes are not
+ allowed to modify Discovery Domain
+ configurations.
+
+
+
+
+Monia, et al. Standards Track [Page 6]
+
+RFC 4174 DHCP Option Number for iSNS September 2005
+
+
+ iSCSI Target, Determine whether the respective
+ iSCSI Initiator, registered iSNS client (determined
+ iFCP Target Port, by iSCSI Node Type or iFCP Port Role)
+ iFCP Initiator is allowed to add, delete, or modify
+ Port: Discovery Domains. If they are set to one,
+ then modification by the specified client type
+ is allowed. If they are set to zero, then
+ modification by the specified client type is
+ not allowed.
+
+ (A node may implement multiple node types.)
+
+2.3. Administrative Flags Field
+
+ The format of the Administrative Flags bit field is shown in Figure
+ 4.
+
+ 0 1 1
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | RESERVED |D|M|H|E|
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Figure 4. Administrative Flags
+
+ Bit Field Significance
+ --------- ------------
+ 15 Enabled
+ 14 Heartbeat
+ 13 Management SCNs
+ 12 Default Discovery Domain
+
+ The following are Administrative Flags Field definitions:
+
+ Enabled: Specifies the validity of the remainder of the
+ Administrative Flags field. If it is set to
+ one, then the contents of the remaining
+ Administrative Flags are valid. If it is set
+ to zero, then the remaining contents MUST be
+ ignored, indicating that iSNS administrative
+ settings are obtained through means other than
+ DHCP.
+
+ Heartbeat: Indicates whether the first IP address is the
+ multicast address to which the iSNS heartbeat
+ message is sent. If it is set to one, then
+ a1-a4 contains the heartbeat multicast address
+ and b1-b4 contains the IP address of the
+
+
+
+Monia, et al. Standards Track [Page 7]
+
+RFC 4174 DHCP Option Number for iSNS September 2005
+
+
+ primary iSNS server, followed by the IP
+ address(es) of any backup servers (see Figure
+ 1). If it is set to zero, then a1-a4 contain
+ the IP address of the primary iSNS server,
+ followed by the IP address(es) of any backup
+ servers.
+
+ Management SCNs: Indicates whether control nodes are authorized
+ to register for receiving Management State
+ Change Notifications (SCNs). Management SCNs
+ are a special class of State Change
+ Notification whose scope is the entire iSNS
+ database. If this bit is set to one, then
+ control nodes are authorized to register for
+ receiving Management SCNs. If it is set to
+ zero, then control nodes are not authorized to
+ receive Management SCNs (although they may
+ receive normal SCNs).
+
+ Default Discovery Indicates whether a newly registered
+ Domain: device that is not explicitly placed into a
+ Discovery Domain (DD) and Discovery Domain Set
+ (DDS) should be automatically placed into a
+ default DD and DDS. If it is set to one, then
+ a default DD shall contain all devices in the
+ iSNS database that have not been explicitly
+ placed into a DD by an iSNS client. If it is
+ set to zero, then devices not explicitly placed
+ into a DD are not members of any DD.
+
+2.4. iSNS Server Security Bitmap
+
+ The format of the iSNS server security Bitmap field is shown in
+ Figure 5. If valid, this field communicates to the DHCP client the
+ security settings that are required to communicate with the indicated
+ iSNS server.
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | RESERVED |T|X|P|A|M|S|E|
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Figure 5. iSNS Server Security Bitmap
+
+
+
+
+
+
+
+Monia, et al. Standards Track [Page 8]
+
+RFC 4174 DHCP Option Number for iSNS September 2005
+
+
+ Bit Field Significance
+ --------- ----------------
+ 31 Enabled
+ 30 IKE/IPSec
+ 29 Main Mode
+ 28 Aggressive Mode
+ 27 PFS
+ 26 Transport Mode
+ 25 Tunnel Mode
+
+ The following are iSNS Server Security Bitmap definitions:
+
+ Enabled: Specifies the validity of the remainder of the
+ iSNS server security bitmap. If it is set to
+ one, then the contents of the remainder of the
+ field are valid. If it is set to zero, then
+ the contents of the rest of the field are
+ undefined and MUST be ignored.
+
+ IKE/IPSec: 1 = IKE/IPSec enabled; 0 = IKE/IPSec disabled.
+
+ Main Mode: 1 = Main Mode enabled; 0 = Main Mode disabled.
+
+ Aggressive Mode: 1 = Aggressive Mode enabled;
+ 0 = Aggressive Mode disabled.
+
+ PFS: 1 = PFS enabled; 0 = PFS disabled.
+
+ Transport Mode: 1 = Transport Mode preferred; 0 = No
+ preference.
+
+ Tunnel Mode: 1 = Tunnel Mode preferred; 0 = No preference.
+
+ If IKE/IPSec is disabled, this indicates that the Internet Key
+ Exchange (IKE) Protocol is not available to configure IPSec keys for
+ iSNS sessions to this iSNS server. It does not necessarily preclude
+ other key exchange methods (e.g., manual keying) from establishing an
+ IPSec security association for the iSNS session.
+
+ If IKE/IPsec is enabled, then for each of the bit pairs <Main Mode,
+ Aggressive Mode> and <Transport Mode, Tunnel Mode>, one of the two
+ bits MUST be set to 1, and the other MUST be set to 0.
+
+3. Security Considerations
+
+ For protecting the iSNS option, the DHCP Authentication security
+ option as specified in [RFC3118] may present a problem due to the
+ limited implementation and deployment of the DHCP authentication
+
+
+
+Monia, et al. Standards Track [Page 9]
+
+RFC 4174 DHCP Option Number for iSNS September 2005
+
+
+ option. The IPsec security mechanisms for iSNS itself are specified
+ in [iSNS] to provide confidentiality when sensitive information is
+ distributed via iSNS. See the Security Considerations section of
+ [iSNS] for details and specific requirements for implementation of
+ IPsec.
+
+ In addition, [iSNS] describes an authentication block that provides
+ message integrity for multicast or broadcast iSNS messages (i.e., for
+ heartbeat/discovery messages only). See [RFC3723] for further
+ discussion of security for these protocols.
+
+ If no sensitive information, as described in [iSNS], is being
+ distributed via iSNS, and an Entity is discovered via iSNS,
+ authentication and authorization are handled by the IP Storage
+ protocols whose endpoints are discovered via iSNS; specifically, iFCP
+ [iFCP] and iSCSI [RFC3720]. It is the responsibility of the
+ providers of these services to ensure that an inappropriately
+ advertised or discovered service does not compromise their security.
+
+ When no DHCP security is used, there is a risk of distribution of
+ false discovery information (e.g., via the iSNS DHCP option
+ identifying a false iSNS server that distributes the false discovery
+ information). The primary countermeasure for this risk is
+ authentication by the IP storage protocols discovered through iSNS.
+ When this risk is a significant concern, IPsec SAs SHOULD be used (as
+ specified in RFC 3723). For example, if an attacker uses DHCP and
+ iSNS to distribute discovery information that falsely identifies an
+ iSCSI endpoint, that endpoint will lack the credentials necessary to
+ complete IKE authentication successfully, and therefore will be
+ prevented from falsely sending or receiving iSCSI traffic. When this
+ risk of false discovery information is a significant concern and
+ IPsec is implemented for iSNS, IPsec SAs SHOULD also be used for iSNS
+ traffic to prevent use of a false iSNS server; this is more robust
+ than relying only on the IP Storage protocols to detect false
+ discovery information.
+
+ When IPsec is implemented for iSNS, there is a risk of a denial-of-
+ service attack based on repeated use of false discovery information
+ that will cause initiation of IKE negotiation. The countermeasures
+ for this are administrative configuration of each iSNS Entity to
+ limit the peers it is willing to communicate with (i.e., by IP
+ address range and/or DNS domain), and maintenance of a negative
+ authentication cache to avoid repeatedly contacting an iSNS Entity
+ that fails to authenticate. These three measures (i.e., IP address
+ range limits, DNS domain limits, negative authentication cache) MUST
+ be implemented for iSNS entities when this DHCP option is used. An
+ analogous argument applies to the IP storage protocols that can be
+ discovered via iSNS as discussed in RFC 3723.
+
+
+
+Monia, et al. Standards Track [Page 10]
+
+RFC 4174 DHCP Option Number for iSNS September 2005
+
+
+ In addition, use of the techniques described in [RFC2827] and
+ [RFC3833] may also be relevant to reduce denial-of-service attacks.
+
+4. IANA Considerations
+
+ In accordance with the policy defined in [DHCP], IANA has assigned a
+ value of 83 for this option.
+
+ There are no other IANA-assigned values defined by this
+ specification.
+
+5. Normative References
+
+ [DHCP] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
+ March 1997.
+
+ [iSNS] Tseng, J., Gibbons, K., Travostino, F., Du Laney, C., and
+ J. Souza, "Internet Storage Name Service (iSNS)", RFC 4171,
+ September 2005.
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP
+ Messages", RFC 3118, June 2001.
+
+ [RFC3720] Satran, J., Meth, K., Sapuntzakis, C., Chadalapaka, M., and
+ E. Zeidner, "Internet Small Computer Systems Interface
+ (iSCSI)", RFC 3720, April 2004.
+
+ [RFC3723] Aboba, B., Tseng, J., Walker, J., Rangan, V., and F.
+ Travostino, "Securing Block Storage Protocols over IP", RFC
+ 3723, April 2004.
+
+6. Informative References
+
+ [iFCP] Monia, C., Mullendore, R., Travostino, F., Jeong, W., and
+ M. Edwards, "iFCP - A Protocol for Internet Fibre Channel
+ Storage Networking", RFC 4172, September 2005.
+
+ [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering:
+ Defeating Denial of Service Attacks which employ IP Source
+ Address Spoofing", BCP 38, RFC 2827, May 2000.
+
+ [RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain
+ Name System (DNS)", RFC 3833, August 2004.
+
+
+
+
+
+Monia, et al. Standards Track [Page 11]
+
+RFC 4174 DHCP Option Number for iSNS September 2005
+
+
+Authors' Addresses
+
+ Kevin Gibbons
+ McDATA Corporation
+ 4555 Great America Parkway
+ Santa Clara, CA 95054-1208
+
+ Phone: (408) 567-5765
+ EMail: kevin.gibbons@mcdata.com
+
+
+ Charles Monia
+ 7553 Morevern Circle
+ San Jose, CA 95135
+
+ EMail: charles_monia@yahoo.com
+
+
+ Josh Tseng
+ Riverbed Technology
+ 501 2nd Street, Suite 410
+ San Francisco, CA 94107
+
+ Phone: (650)274-2109
+ EMail: joshtseng@yahoo.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Monia, et al. Standards Track [Page 12]
+
+RFC 4174 DHCP Option Number for iSNS September 2005
+
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (2005).
+
+ This document is subject to the rights, licenses and restrictions
+ contained in BCP 78, and except as set forth therein, the authors
+ retain all their rights.
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+ ENGINEERING TASK FORCE DISCLAIM 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.
+
+Intellectual Property
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be
+ found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at ietf-
+ ipr@ietf.org.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+Monia, et al. Standards Track [Page 13]
+