idnits 2.17.1 draft-ietf-dhc-isnsoption-01.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 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 (July 2002) is 7956 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 321 looks like a reference -- Missing reference section? 'RFC2119' on line 324 looks like a reference -- Missing reference section? 'DHCP' on line 303 looks like a reference -- Missing reference section? 'SEC-IPS' on line 318 looks like a reference Summary: 5 errors (**), 0 flaws (~~), 1 warning (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DHC Josh Tseng 3 Internet Draft Kevin Gibbons 4 Nishan Systems 5 Expires January 2003 July 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...........................................6 43 4. References........................................................6 44 5. Author's Addresses................................................7 45 Full Copyright Statement..............................................8 46 DHCP Option Number for iSNS February 2002 48 Abstract 50 This document describes the DHCP option to allow iSNS clients 51 devices using DHCP to automatically discover the location of the 52 iSNS server. iSNS provides discovery and management capabilities for 53 iSCSI and Fibre Channel (FCP) storage devices in an enterprise-scale 54 IP 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. RESERVED 69 fields SHOULD be set to zero. 71 This document uses the following terms: 73 "iSNS Client" - iSNS clients are processes resident in iSCSI and 74 iFCP devices that initiate transactions with the iSNS server using 75 the iSNS Protocol. 77 "iSNS Server" - The iSNS server responds to iSNS protocol query and 78 registration messages, and initiates asynchronous notification 79 messages. The iSNS server stores information registered by iSNS 80 clients. 82 "iSCSI (Internet SCSI)" - iSCSI is an encapsulation of SCSI for a 83 new generation of storage devices interconnected with TCP/IP. 85 "iFCP (Internet Fibre Channel Protocol)" - iFCP is a gateway-to- 86 gateway protocol designed to interconnect existing Fibre Channel and 87 SCSI devices using TCP/IP. iFCP maps the existing FCP standard and 88 associated Fibre Channel services to TCP/IP. 90 1. Introduction 92 The Dynamic Host Configuration Protocol provides a framework for 93 passing configuration information to hosts. Its usefulness extends 94 to hosts and devices using the iSCSI and iFCP protocols to connect 95 to block level storage assets over a TCP/IP network. 97 The iSNS Protocol provides a framework for automated discovery, 98 management, and configuration of iSCSI and iFCP devices on a TCP/IP 99 network. It provides functionality similar to that found on Fibre 100 Channel networks, except that iSNS works within the context of an IP 101 DHCP Option Number for iSNS February 2002 103 network. iSNS thereby provides the requisite storage intelligence 104 to IP networks that are standard on existing Fibre Channel networks. 106 Existing DHCP option numbers are not plausible due to the following 107 reasons: 109 1) iSNS functionality is distinctly different from other protocols 110 using existing DHCP option numbers. Specifically, iSNS provides a 111 significant superset of capabilities compared to typical name 112 resolution protocols such as DNS. It is designed to support client 113 devices that allow themselves to be configured and managed from a 114 central iSNS server. 116 2) iSNS requires a DHCP option format that provides more than the 117 location of the iSNS server. The DHCP option number needs to 118 specify the subset of iSNS services that will be actively used by 119 the iSNS client. 121 The DHCP option number for iSNS is used by iSCSI and iFCP devices to 122 discover the location and role of the iSNS server. The DHCP option 123 number assigned for iSNS by IANA is <>. 125 2. iSNS Option for DHCP 127 This option specifies the location of the primary and backup iSNS 128 servers and the subset of iSNS services that will be used by the 129 iSNS client. 131 0 1 2 3 132 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 133 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 134 | Code = TBD | Length | iSNS Function | 135 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 136 | DD Access | Administrative FLAGS | 137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 138 | a1 | a2 | a3 | a4 | 139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 140 | b1 | b2 | b3 | b4 | 141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 142 | . . . . | 143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 145 The iSNS Option specifies a list of IP addresses used by iSNS 146 servers. 148 Length indicates the number of bytes that follow the Length field. 149 The minimum value for the Length field is 6 in order to account for 150 the iSNS Function, Discovery Domain Access, and Administrative Flags 151 field. 153 iSNS Function is a bitmap field defining the iSNS server's 154 operational role (i.e., how the iSNS server is to be used). The 155 iSNS server's role can be as basic as to provide simple discovery 156 information, or as significant as to provide IKE/IPSec security 157 DHCP Option Number for iSNS February 2002 159 policies and certificates for the use of iSCSI and iFCP devices. The 160 format of the iSNS Role bit field is shown below: 162 1 2 3 163 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 165 | Site-Specific |RESERVED |S|A|E| 166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 168 Bit field Significance 169 --------- ------------ 170 31 Enabled/Disabled 171 30 Authorization/Discovery Domains 172 29 Security 173 28-24 RESERVED 174 23-16 Site-specific or Vendor-specific use only 176 Enabled/Disabled: This bit determines the validity of the iSNS Role 177 field. If this bit is enabled, then the contents of the remainder 178 of the iSNS Role field are valid. If this bit is disabled, then the 179 contents of the iSNS Role field are invalid. 181 Authorization: Indicates the role of the iSNS server in determining 182 device access authorizations. If disabled, then the function of the 183 iSNS server is for target discovery purposes only. Discovery 184 Domains MAY be used to manage the discovery process, but they do not 185 necessarily indicate authorization to access discovered devices. If 186 enabled, then Discovery Domain/Zoning features of the iSNS indicate 187 device access authorizations. Devices in a common DD SHALL be 188 allowed access to each other if they are successfully authenticated. 189 Devices not in a common DD shall not be allowed to access each 190 other. 192 Security: Indicates whether the iSNS client is to download and use 193 the security policy configuration stored in the iSNS server. If 194 enabled, then the AuthMethod and IKE/IPSec policy stored in the iSNS 195 server SHALL be used by the iSNS client for its own security policy. 196 If disabled, then the iSNS client SHALL NOT query for its own 197 security policy attributes in the iSNS server. 199 Site-Specific: These bits are used to indicate site-specific or 200 vendor-specific capabilities in the indicated iSNS server. 202 Discovery Domain Access is a bit field that indicates the types of 203 iSNS clients that are allowed to modify Discovery Domains. The 204 format of the DD Access bit field is shown below: 206 DHCP Option Number for iSNS February 2002 208 0 1 2 3 4 5 6 7 209 +---+---+---+---+---+---+---+---+ 210 | R | R | if| tf| is| ts| C | E | 211 +---+---+---+---+---+---+---+---+ 213 Bit field Significance 214 --------- ------------ 215 7 Enabled/Disabled 216 6 Control Node 217 5 iSCSI Target 218 4 iSCSI Initiator 219 3 iFCP Target Port 220 2 iFCP Initiator Port 221 1 RESERVED 222 0 RESERVED 224 Enabled/Disabled: This bit determines the validity of the DD Access 225 bit field. If this bit is enabled, then the contents of the 226 remainder of the DD Access field are valid. If this bit is 227 disabled, then the contents of this field are invalid. 229 Control Node: Determines whether Control Nodes are allowed to add, 230 delete, or modify Discovery Domains. If enabled, then Control Nodes 231 are allowed. If disabled, then Control Nodes are not allowed to 232 modify Discovery Domains. 234 iSCSI Target, iSCSI Initiator, iFCP Target Port, and iFCP Initiator 235 Port: These bits determine whether the respective registered iSNS 236 client (determined by iSCSI Node Type or iFCP Port Role) is allowed 237 to add, delete, or modify Discovery Domains. If enabled, then the 238 respective types of iSNS clients are allowed. If disabled, then 239 they are not allowed to modify Discovery Domains. 241 The Administrative Flags field configures the administrative 242 settings for the iSNS server discovered through the DHCP option. 243 The format of the Administrative Flags bit field is as follows: 245 0 1 2 3 246 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 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 | Site-Specific | RESERVED |D|M|H|E| 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 251 Bit field Significance 252 --------- ------------ 253 31 Enabled/Disabled 254 30 Heartbeat 255 29 Management SCN's 256 28 Default Discovery Domain 257 26-8 RESERVED 258 7-0 Site-specific or Vendor-specific use only 260 Enabled/Disabled: This bit determines the validity of the 261 Administrative Flags field. If this bit is enabled, then the 262 DHCP Option Number for iSNS February 2002 264 contents of the remainder of the Administrative Flags field are 265 valid. If this bit is disabled, then the contents of this field are 266 invalid, indicating that iSNS administrative settings are configured 267 through alternative means other than DHCP. 269 Heartbeat: Indicates whether the first IP address is the multicast 270 address for the iSNS heartbeat message. If enabled, then a1-a4 271 contains the heartbeat multicast address and b1-b4 contains the IP 272 address of the primary iSNS server, followed by the IP address(es) 273 of any backup servers. If disabled, then a1-a4 contains the IP 274 address of the primary iSNS server, followed by the IP address(es) 275 of any backup servers. 277 Management SCNs: Indicates whether control nodes are authorized to 278 register to receive Management SCN's. Management SCN's are a 279 special class of State Change Notification whose scope is the entire 280 iSNS database. If enabled, then control nodes are authorized to 281 register to receive Management SCN's. If disabled, then control 282 nodes are not authorized to receive Management SCN's (although they 283 may receive normal SCN's). 285 Default Discovery Domain: Indicates whether a newly registered 286 device that is not explicitly placed into a Discovery Domain (DD) 287 and Discovery Domain Set (DDS) should be automatically placed into a 288 default DD and DDS. If enabled, then a default DD shall contain all 289 devices in the iSNS database that have not been explicitly placed 290 into a DD by an iSNS client. If disabled, then devices not 291 explicitly placed into a DD are not members of any DD. 293 3. Security Considerations 295 DHCP currently provides no authentication or security mechanisms. 296 Potential exposures to attack are discussed in section 7 of the DHCP 297 protocol specification [DHCP]. 299 iSNS security considerations are discussed in [iSNS] and [SEC-IPS]. 301 4. References 303 [DHCP] Droms, R., "Dynamic Host Configuration Protocol", RFC 304 2131, Bucknell University, March 1997. 306 [iSCSI] Satran, J., et al., "iSCSI", Internet draft (work in 307 progress), draft-ietf-ips-iSCSI-13.txt, June 2002 309 [iFCP] Monia, C., et al., "iFCP - A Protocol for Internet Fibre 310 Channel Storage Networking", Internet draft (work in 311 progress), draft-ietf-ips-ifcp-11.txt, May 2002 313 [iSNS] Tseng, J. et al., "iSNS - Internet Storage Name 314 Service", Internet draft (work in progress), draft-ietf- 315 ips-isns-10.txt, May 2002 316 DHCP Option Number for iSNS February 2002 318 [SEC-IPS] Aboba, B., et al., "Securing IP Block Storage 319 Protocols", draft-ietf-ips-security-13.txt, June 2002 321 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 322 3", BCP 9, RFC 2026, October 1996. 324 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 325 Requirement Levels", BCP 14, RFC 2119, March 1997 327 5. Author's Addresses 329 Josh Tseng 330 Nishan Systems 331 3850 North First Street 332 San Jose, CA 95134-1702 333 Phone: (408) 519-3749 334 Email: jtseng@nishansystems.com 335 Internet Storage Name Service (iSNS) November 2001 337 Full Copyright Statement 339 "Copyright (C) The Internet Society (date). All Rights Reserved. 340 This document and translations of it may be copied and furnished to 341 others, and derivative works that comment on or otherwise explain it 342 or assist in its implementation may be prepared, copied, published 343 and distributed, in whole or in part, without restriction of any 344 kind, provided that the above copyright notice and this paragraph 345 are included on all such copies and derivative works. However, this 346 document itself may not be modified in any way, such as by removing 347 the copyright notice or references to the Internet Society or other 348 Internet organizations, except as needed for the purpose of 349 developing Internet standards in which case the procedures for 350 copyrights defined in the Internet Standards process must be 351 followed, or as required to translate it into languages other than 352 English. 354 The limited permissions granted above are perpetual and will not be 355 revoked by the Internet Society or its successors or assigns. 357 This document and the information contained herein is provided on an 358 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 359 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 360 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 361 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 362 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 363 Internet Storage Name Service (iSNS) November 2001