idnits 2.17.1 draft-ietf-dhc-isnsoption-02.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: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** 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? Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' scope is the entire iSNS database. If' ) ** 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.) ** There are 158 instances of too long lines in the document, the longest one being 4 characters in excess of 72. 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 (August 2002) is 7924 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 396 looks like a reference -- Missing reference section? 'RFC2119' on line 399 looks like a reference -- Missing reference section? 'ISNS' on line 179 looks like a reference -- Missing reference section? 'DHCP' on line 393 looks like a reference -- Missing reference section? 'SEC-IPS' on line 415 looks like a reference Summary: 7 errors (**), 0 flaws (~~), 0 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DHC Working Group Josh Tseng 3 INTERNET DRAFT Kevin Gibbons 4 Expires: February 2003 Charles Monia 5 Internet Draft 6 Document: Nishan Systems 7 Category: Standards Track August 2002 9 DHCP Options for Internet Storage Name Service 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of [RFC2026]. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. Internet-Drafts are draft documents valid for a maximum of 20 six months and may be updated, replaced, or made obsolete by other 21 documents at any time. It is inappropriate to use Internet- Drafts 22 as reference material or to cite them other than as "work in 23 progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Comments 33 Comments should be sent to the IPS mailing list (ips@ece.cmu.edu) or 34 to the authors. 36 Table of Contents 38 Status of this Memo...................................................1 39 Comments..............................................................1 40 Abstract..............................................................2 41 Conventions used in this document.....................................2 42 1.Introduction.......................................................2 43 2.iSNS Option for DHCP...............................................3 44 2.1 iSNS Functions Field.............................................4 45 2.2 Discovery Domain Access Field....................................5 46 2.3 Administrative Flags Field.......................................6 47 3.Security Considerations............................................8 48 4.Normative References...............................................8 49 5.Non-Normative References...........................................8 50 6.Author's Addresses.................................................9 51 Full Copyright Statement.............................................10 52 DHCP Option Number for iSNS Revision 2 August 2002 54 Abstract 56 This document describes the DHCP option to allow iSNS clients 57 devices using DHCP to automatically discover the location of the 58 iSNS server. iSNS provides discovery and management capabilities for 59 iSCSI and Fibre Channel (FCP) storage devices in an enterprise-scale 60 IP storage network. iSNS provides intelligent storage management 61 services comparable to those found in Fibre Channel networks, 62 allowing a commodity IP network to function in a similar capacity as 63 a storage area network. 65 Conventions used in this document 67 iSNS refers to the framework consisting of the storage network model 68 and associated services. 70 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 71 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 72 this document are to be interpreted as described in [RFC2119]. 74 All frame formats are in big endian network byte order. RESERVED 75 fields SHOULD be set to zero. 77 This document uses the following terms: 79 "iSNS Client" - iSNS clients are processes resident in iSCSI and 80 iFCP devices that initiate transactions with the iSNS server using 81 the iSNS Protocol. 83 "iSNS Server" - The iSNS server responds to iSNS protocol query and 84 registration messages, and initiates asynchronous notification 85 messages. The iSNS server stores information registered by iSNS 86 clients. 88 "iSCSI (Internet SCSI)" - iSCSI is an encapsulation of SCSI for a 89 new generation of storage devices interconnected with TCP/IP. 91 "iFCP (Internet Fibre Channel Protocol)" - iFCP is a gateway-to- 92 gateway protocol designed to interconnect existing Fibre Channel 93 devices using TCP/IP. iFCP maps the Fibre Channel transport and 94 fabric services to TCP/IP. 96 1. Introduction 98 The Dynamic Host Configuration Protocol provides a framework for 99 passing configuration information to hosts. Its usefulness extends 100 to hosts and devices using the iSCSI and iFCP protocols to connect 101 to block level storage assets over a TCP/IP network. 103 The iSNS Protocol provides a framework for automated discovery, 104 management, and configuration of iSCSI and iFCP devices on a TCP/IP 105 network. It provides functionality similar to that found on Fibre 106 Channel networks, except that iSNS works within the context of an IP 108 DHCP Option Number for iSNS Revision 2 August 2002 110 network. iSNS thereby provides the requisite storage intelligence 111 to IP networks that are standard on existing Fibre Channel networks. 113 Existing DHCP option numbers are not plausible due to the following 114 reasons: 116 a) iSNS functionality is distinctly different from other protocols 117 using existing DHCP option numbers. Specifically, iSNS provides 118 a significant superset of capabilities compared to typical name 119 resolution protocols such as DNS. It is designed to support 120 client devices that allow themselves to be configured and 121 managed from a central iSNS server 123 b) iSNS requires a DHCP option format that provides more than the 124 location of the iSNS server. The DHCP option number needs to 125 specify the subset of iSNS services that will be actively used 126 by the iSNS client. 128 The DHCP option number for iSNS is used by iSCSI and iFCP devices to 129 discover the location and role of the iSNS server. The DHCP option 130 number assigned for iSNS by IANA is <>. 132 2. iSNS Option for DHCP 134 This option specifies the location of the primary and backup iSNS 135 servers and the iSNS services available to an iSNS client. 137 0 1 2 3 138 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 139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 140 | Code = TBD | Length | iSNS Functions | 141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 142 | DD Access | Administrative FLAGS | 143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 144 | a1 | a2 | a3 | a4 | 145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 146 | b1 | b2 | b3 | b4 | 147 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 148 | . . . . | 149 | Additional Secondary iSNS Servers | 150 | . . . . | 151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 152 Figure 1 -- iSNS Server Option 154 The iSNS Option specifies a list of IP addresses used by iSNS 155 servers. The option contains the following parameters: 157 Length: the number of bytes that follow the Length field. The 158 minimum value for the Length field is 6 in order to account 159 for the iSNS Functions, Discovery Domain Access, and 160 Administrative Flags fields. 162 DHCP Option Number for iSNS Revision 2 August 2002 164 iSNS Functions: A bitmapped field defining the functions supported 165 by the iSNS servers. The format of this field is described 166 in section 2.1. 168 Discovery Domain Access: A bit field indicating the types of iSNS 169 clients that are allowed to modify Discovery Domains. The 170 field contents are described in section 2.2. 172 Administrative Flags field: Contains the administrative settings for 173 the iSNS servers discovered through the DHCP query. The 174 contents of this field are described in section 2.3. 176 a1...a4: Depending on the setting of the Heartbeat bit in the 177 Administrative Flags field (see section 2.3), this field 178 contains either the IP address from which the iSNS heartbeat 179 originates (see [ISNS]) or the IP address of the primary 180 iSNS server. 182 b1...b4: Depending on the setting of Heartbeat bit in the 183 Administrative Flags field (see section 2.3), this field 184 contains either the IP address of the primary iSNS server or 185 a secondary iSNS server. 187 Additional Secondary iSNS Servers: Each set of four octets specifies 188 the IP address of a secondary iSNS server. 190 2.1 iSNS Functions Field 192 The iSNS Functions Field defines the iSNS server's operational role 193 (i.e., how the iSNS server is to be used). The iSNS server's role 194 can be as basic as providing simple discovery information, or as 195 significant as providing IKE/IPSec security policies and 196 certificates for the use of iSCSI and iFCP devices. The format of 197 the iSNS Role bit field is shown in Figure 2: 199 1 2 3 200 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 201 +--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 202 |Vendor-Specific |RESERVED |S|A|E| 203 +--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 204 Figure 2 -- iSNS Functions 206 Bit field Significance 207 --------- ------------ 208 31 Function Fields Enabled 209 30 DD-Based Authorization 210 29 Security policy distribution 211 28 - 24 Reserved 212 23 - 16 Vendor-specific 214 Enabled: This bit specifies the validity of the 215 remaining iSNS Function fields. If set to 216 one, then the contents of all other iSNS 217 Function fields are valid. If set to zero, 219 DHCP Option Number for iSNS Revision 2 August 2002 221 then the contents of all other iSNS 222 Function fields MUST be ignored. 224 DD-based Indicates whether or not devices in a 225 Authorization: common Discovery Domain (DD) are implicitly 226 authorized to access one another. Although 227 Discovery Domains control the scope of 228 device discovery, they do not necessarily 229 indicate whether or not a domain member is 230 authorized to access discovered devices. 231 If this bit is set to one, then devices in 232 a common Discovery Domain are automatically 233 allowed access to each other (if 234 successfully authenticated). If this bit 235 is set to zero, then access authorization 236 is not implied by domain membership and 237 must be explicitly performed by each 238 device. In either case, devices not in a 239 common discovery domain are not allowed to 240 access each other. 242 Security: Indicates whether the iSNS client is to 243 download and use the security policy 244 configuration stored in the iSNS server. 245 If set to one, then the policy is stored in 246 the iSNS server and must be used by the 247 iSNS client for its own security policy. 248 If set to zero, then the iSNS client must 249 obtain its security policy configuration by 250 other means. 252 Vendor- These bits are used to indicate the vendor- 253 Specific: specific capabilities supported by the 254 indicated iSNS server. 256 2.2 Discovery Domain Access Field 258 The format of the DD Access bit field is shown in Figure 3: 260 0 1 2 3 4 5 6 7 261 +---+---+---+---+---+---+---+---+ 262 | R | R | if| tf| is| ts| C | E | 263 +---+---+---+---+---+---+---+---+ 264 Figure 3 -- Discovery Domain Access 266 DHCP Option Number for iSNS Revision 2 August 2002 268 Bit field Significance 269 --------- ------------ 270 7 Enabled 271 6 Control Node 272 5 iSCSI Target 273 4 iSCSI Initiator 274 3 iFCP Target Port 275 2 iFCP Initiator Port 276 1 RESERVED 277 0 RESERVED 279 Enabled: This bit specifies the validity of the 280 remaining DD Access bit fields. If this 281 bit is set to one, then the contents of 282 the remainder of the DD Access field are 283 valid. If this bit is set to zero, then 284 the contents of the remainder of this 285 field MUST be ignored. 287 Control Node: Specifies whether the iSNS server allows 288 Discovery Domains to be added, modified 289 or deleted by means of Control Nodes. If 290 set to one, then Control Nodes are 291 allowed to modify the Discovery Domain 292 configuration. If set to zero, then 293 Control Nodes are not allowed to modify 294 Discovery Domain configurations. 296 iSCSI Target, These bits determine whether the 297 iSCSI Initiator, respective registered iSNS client 298 iFCP Target Port, (determined by iSCSI Node Type or iFCP 299 iFCP Initiator Port Role) is allowed to add, delete, or 300 Port: modify Discovery Domains. If set to 301 one, then modification by the specified 302 client type is allowed. If set to zero, 303 then modification by the specified 304 client type is not allowed. 306 (A node may implement multiple node 307 types.) 309 2.3 Administrative Flags Field 311 The format of the Administrative Flags bit field is shown in Figure 312 4: 314 DHCP Option Number for iSNS Revision 2 August 2002 316 1 2 3 317 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 319 | RESERVED |D|M|H|E| 320 +---+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 321 Figure 4 -- Administrative Flags 323 Bit Field Significance 324 --------- ------------ 325 31 Enabled 326 30 Heartbeat 327 29 Management SCNs 328 28 Default Discovrery Domain 329 27 - 8 RESERVED 331 Enabled: Specifies the validity of the remainder 332 of the Administrative Flags field. If 333 set to one, then the contents of the 334 remaining Administrative Flags are 335 valid. If set to zero, then the 336 remaining contents MUST be ignored, 337 indicating that iSNS administrative 338 settings are obtained through means 339 other than DHCP. 341 Heartbeat: Indicates whether the first IP address 342 is the multicast address from which the 343 iSNS heartbeat message originates. If 344 set to one, then a1-a4 contains the 345 heartbeat multicast address and b1-b4 346 contains the IP address of the primary 347 iSNS server, followed by the IP 348 address(es) of any backup servers. If 349 set to zero, then a1-a4 contains the IP 350 address of the primary iSNS server, 351 followed by the IP address(es) of any 352 backup servers. 354 Management SCNs: Indicates whether control nodes are 355 authorized to register to receive 356 Management State Change Notifications 357 (SCN's). Management SCN's are a special 358 class of State Change Notification whose 359 scope is the entire iSNS database. If 360 set to one, then control nodes are 361 authorized to register to receive 362 Management SCN's. If set to zero, then 363 control nodes are not authorized to 364 receive Management SCN's (although they 365 may receive normal SCN's). 367 Default Discovery Indicates whether a newly registered 368 device that is not explicitly placed 370 DHCP Option Number for iSNS Revision 2 August 2002 372 Domain: into a Discovery Domain (DD) and 373 Discovery Domain Set (DDS) should be 374 automatically placed into a default DD 375 and DDS. If set to one, then a default 376 DD shall contain all devices in the iSNS 377 database that have not been explicitly 378 placed into a DD by an iSNS client. If 379 set to zero, then devices not explicitly 380 placed into a DD are not members of any 381 DD. 383 3. Security Considerations 385 DHCP currently provides no authentication or security mechanisms. 386 Potential exposures to attack are discussed in section 7 of the DHCP 387 protocol specification [DHCP]. 389 iSNS security considerations are discussed in [iSNS] and [SEC-IPS]. 391 4. Normative References 393 [DHCP] Droms, R., "Dynamic Host Configuration Protocol", RFC 394 2131, Bucknell University, March 1997. 396 [RFC2026] Bradner, S., "The Internet Standards Process -- 397 Revision 3", BCP 9, RFC 2026, October 1996 399 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 400 Requirement Levels", BCP 14, RFC 2119, March 1997 402 5. Non-Normative References 404 [iFCP] Monia, C., et al., "iFCP - A Protocol for Internet Fibre 405 Channel Storage Networking", Internet draft (work in 406 progress), draft-ietf-ips-ifcp-13.txt, May 2002 408 [iSCSI] Satran, J., et al., "iSCSI", Internet draft (work in 409 progress), draft-ietf-ips-iSCSI-15.txt, August 2002 411 [iSNS] Tseng, J. et al., "iSNS - Internet Storage Name 412 Service", Internet draft (work in progress), draft-ietf- 413 ips-isns-12.txt, August 2002 415 [SEC-IPS] Aboba, B., et al., "Securing IP Block Storage 416 Protocols", draft-ietf-ips-security-14.txt, June 2002 417 Internet Storage Name Service (iSNS) November 2001 419 6. Author's Addresses 421 Kevin Gibbons, 422 Charles Monia, 423 Josh Tseng 425 Nishan Systems 426 3850 North First Street 427 San Jose, CA 95134-1702 428 Phone: (408) 519-3700 429 Email: cmonia@nishansystems.com 430 jtseng@nishansystems.com 431 kgibbons@nishansystems.com 433 Full Copyright Statement 435 "Copyright (C) The Internet Society August 2002. All Rights 436 Reserved. This document and translations of it may be copied and 437 furnished to others, and derivative works that comment on or 438 otherwise explain it or assist in its implementation may be 439 prepared, copied, published and distributed, in whole or in part, 440 without restriction of any kind, provided that the above copyright 441 notice and this paragraph are included on all such copies and 442 derivative works. However, this document itself may not be modified 443 in any way, such as by removing the copyright notice or references 444 to the Internet Society or other Internet organizations, except as 445 needed for the purpose of developing Internet standards in which 446 case the procedures for copyrights defined in the Internet Standards 447 process must be followed, or as required to translate it into 448 languages other than English. 450 The limited permissions granted above are perpetual and will not be 451 revoked by the Internet Society or its successors or assigns. 453 This document and the information contained herein is provided on an 454 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 455 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 456 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 457 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 458 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."