idnits 2.17.1 draft-tseng-dhc-isnsoption-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 2002) is 8105 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'RFC2026' on line 228 looks like a reference -- Missing reference section? 'RFC2119' on line 231 looks like a reference -- Missing reference section? 'DHCP' on line 208 looks like a reference -- Missing reference section? 'SEC-IPS' on line 224 looks like a reference Summary: 5 errors (**), 0 flaws (~~), 2 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DHC Josh Tseng 3 Internet Draft Nishan Systems 4 5 Expires August 2002 February 2002 7 DHCP Options for Internet Storage Name Service 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of [RFC2026]. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. Internet-Drafts are draft documents valid for a maximum of 18 six months and may be updated, replaced, or obsoleted by other 19 documents at any time. It is inappropriate to use Internet- Drafts 20 as reference material or to cite them other than as "work in 21 progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 Comments 31 Comments should be sent to the IPS mailing list (ips@ece.cmu.edu) or 32 to the authors. 34 Table of Contents 36 Status of this Memo...................................................1 37 Comments..............................................................1 38 Abstract..............................................................2 39 Conventions used in this document.....................................2 40 1.Introduction.......................................................2 41 2.iSNS Option for DHCP...............................................3 42 3.Security Considerations............................................4 43 4.References.........................................................4 44 5.Author's Addresses.................................................5 45 Full Copyright Statement..............................................6 46 DHCP Option Number for iSNS February 2002 48 Abstract 50 This document proposes a new DHCP option number to allow iSCSI and 51 iFCP devices using DHCP to discover the location of the iSNS server. 52 iSNS provides discovery and management capabilities for iSCSI and 53 Fibre Channel (FCP) storage devices in an enterprise-scale IP 54 storage network. iSNS provides intelligent storage management 55 services comparable to those found in Fibre Channel networks, 56 allowing a commodity IP network to function in a similar capacity as 57 a storage area network. 59 Conventions used in this document 61 iSNS refers to the framework consisting of the storage network model 62 and associated services. 64 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 65 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 66 this document are to be interpreted as described in [RFC2119]. 68 All frame formats are in big endian network byte order. 70 This document uses the following terms: 72 "iSNS Client" - iSNS clients are processes resident in iSCSI and 73 iFCP devices that initiate transactions with the iSNS server using 74 the iSNS Protocol. 76 "iSNS Server" - The iSNS server responds to iSNS protocol query and 77 registration messages, and initiates asynchronous notification 78 messages. The iSNS server stores information registered by iSNS 79 clients. 81 "iSCSI (Internet SCSI)" - iSCSI is an encapsulation of SCSI for a 82 new generation of storage devices interconnected with TCP/IP. 84 "iFCP (Internet Fibre Channel Protocol)" - iFCP is a gateway-to- 85 gateway protocol designed to interconnect existing Fibre Channel and 86 SCSI devices using TCP/IP. iFCP maps the existing FCP standard and 87 associated Fibre Channel services to TCP/IP. 89 1. Introduction 91 The Dynamic Host Configuration Protocol provides a framework for 92 passing configuration information to hosts. Its usefulness extends 93 to hosts and devices using the iSCSI and iFCP protocols to connect 94 to block level storage assets over a TCP/IP network. 96 The iSNS Protocol provides a framework for automated discovery, 97 management, and configuration of iSCSI and iFCP devices on a TCP/IP 98 network. It provides functionality similar to that found on Fibre 99 Channel networks, except that iSNS works within the context of an IP 100 DHCP Option Number for iSNS February 2002 102 network. iSNS thereby provides the requisite storage intelligence 103 to IP networks that are standard on existing Fibre Channel networks. 105 Existing DHCP option numbers are not plausible due to the following 106 reasons: 108 1) iSNS functionality is distinctly different from other protocols 109 using existing DHCP option numbers. Specifically, iSNS provides a 110 significant superset of capabilities compared to typical name 111 resolution protocols such as DNS. It is designed to support client 112 devices that allow themselves to be configured and managed from a 113 central iSNS server. 115 2) iSNS requires a DHCP option format that provides more than the 116 location of the iSNS server. The DHCP option number needs to 117 specify the subset of iSNS services that will be actively used by 118 the iSNS client. 120 The proposed DHCP option for iSNS is used by iSCSI and iFCP devices 121 to discover the location of the iSNS server. Although a standard 122 one-byte DHCP option number is strongly desired, the assignment of a 123 two-byte option number implemented by options 126 and 127 is 124 acceptable. 126 2. iSNS Option for DHCP 128 This option specifies the location of the primary and backup iSNS 129 servers and the subset of iSNS services that will be used by the 130 iSNS client. 132 0 1 2 3 133 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 134 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 135 | Code = TBD | Length | Usage | Heartbeat | 136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 137 | a1 | a2 | a3 | a4 | 138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 139 | b1 | b2 | b3 | b4 | 140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 141 | . . . . | 142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 144 The iSNS Option specifies a list of IP addresses used by iSNS 145 servers. 147 Length indicates the number of bytes that follow the Length field. 148 The minimum value for the Length field is 2 in order to account for 149 the Usage and Heartbeat bytes. 151 The Usage byte indicates whether the DHCP option overrides the 152 static configuration of the iSCSI or iFCP device, as well as the 153 subset of iSNS features that are to be used by the iSNS client 154 device. The following table indicates how iSNS is to be used by the 155 DHCP client. 157 DHCP Option Number for iSNS February 2002 159 Value iSNS Usage 160 ----- ---------- 161 0 DISCOVERY Only 162 1 DISCOVERY and AUTHORIZATION 163 3 DISCOVERY, AUTHORIZATION and SECURITY 164 All other values are reserved and should not be used 166 A Usage byte value of 0 indicates that iSNS is to be used for 167 discovery only, and that static or manual configuration of the iSCSI 168 or iFCP device overrides any discovery or configuration information 169 found in the iSNS server through iSNS protocol messages. Although 170 the Discovery Domain/Zoning features of the iSNS may be used to 171 manage the discovery process, Discovery Domain membership does not 172 indicate authorization to establish a session with any storage 173 device. 175 A Usage byte value of 1 indicates that iSNS is used for both 176 discovery and authorization. Information discovered from the iSNS 177 server overrides any static or manual configuration of the iSCSI or 178 iFCP device. The Discovery Domain/Zoning membership configuration 179 stored in the iSNS provide authorizations that determine whether 180 storage sessions may be established between peer devices. 182 A Usage byte value of 3 indicates that in addition to discovery and 183 authorization, the iSNS is used to distribute IKE/IPSec security 184 policy configuration to iSCSI and/or iFCP devices. 186 The Heartbeat byte determines if the IP address indicated in a1-a4 187 is the iSNS heartbeat multicast address. 189 If the Heartbeat byte is 0, then then a1-a4 is the IP address of the 190 primary iSNS server. Any additional IP addresses are the iSNS 191 backup servers, listed in order of precedence. 193 If the Heartbeat byte is 1, then a1-a4 is the iSNS heartbeat 194 multicast address, b1-b4 is the primary iSNS server IP address, and 195 any following IP addresses are the iSNS backup servers listed in 196 order of precedence. 198 3. Security Considerations 200 DHCP currently provides no authentication or security mechanisms. 201 Potential exposures to attack are discussed in section 7 of the DHCP 202 protocol specification [DHCP]. 204 iSNS security considerations are discussed in [iSNS] and [SEC-IPS]. 206 4. References 208 [DHCP] Droms, R., "Dynamic Host Configuration Protocol", RFC 209 2131, Bucknell University, March 1997. 211 DHCP Option Number for iSNS February 2002 213 [iSCSI] Satran, J., et al., "iSCSI", Internet draft (work in 214 progress), draft-ietf-ips-iSCSI-10.txt, January 2002 216 [iFCP] Monia, C., et al., "iFCP - A Protocol for Internet Fibre 217 Channel Storage Networking", Internet draft (work in 218 progress), draft-ietf-ips-ifcp-09.txt, January 2002 220 [iSNS] Tseng, J. et al., "iSNS - Internet Storage Name 221 Service", Internet draft (work in progress), draft-ietf- 222 ips-isns-08.txt, February 2002 224 [SEC-IPS] Aboba, B., et al., "Securing IP Block Storage 225 Protocols", draft-ietf-ips-security-09.txt, February 226 2002 228 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 229 3", BCP 9, RFC 2026, October 1996. 231 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 232 Requirement Levels", BCP 14, RFC 2119, March 1997 234 5. Author's Addresses 236 Josh Tseng 237 Nishan Systems 238 3850 North First Street 239 San Jose, CA 95134-1702 240 Phone: (408) 519-3749 241 Email: jtseng@nishansystems.com 242 Internet Storage Name Service (iSNS) November 2001 244 Full Copyright Statement 246 "Copyright (C) The Internet Society (date). All Rights Reserved. 247 This document and translations of it may be copied and furnished to 248 others, and derivative works that comment on or otherwise explain it 249 or assist in its implementation may be prepared, copied, published 250 and distributed, in whole or in part, without restriction of any 251 kind, provided that the above copyright notice and this paragraph 252 are included on all such copies and derivative works. However, this 253 document itself may not be modified in any way, such as by removing 254 the copyright notice or references to the Internet Society or other 255 Internet organizations, except as needed for the purpose of 256 developing Internet standards in which case the procedures for 257 copyrights defined in the Internet Standards process must be 258 followed, or as required to translate it into languages other than 259 English. 261 The limited permissions granted above are perpetual and will not be 262 revoked by the Internet Society or its successors or assigns. 264 This document and the information contained herein is provided on an 265 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 266 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 267 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 268 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 269 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 270 Internet Storage Name Service (iSNS) November 2001